Cfengine3 Messaging - Revision history

Martin at 19:48, 10 July 2025

2025-07-10T19:48:34Z

@@ Line 22: / Line 22: @@
 * State Information
 In the current design of CFEngine the cf-agent then has to be extended with a promise type: messages:<br/><br/>
 It goes withoout saying that messaging needs authentication and autorization mechanisms.
 === Example CFEngine message policy ===
 <pre>

Martn admin at 14:58, 1 June 2022

2022-06-01T14:58:32Z

← Older revision		Revision as of 14:58, 1 June 2022
Line 415:		Line 415:
	</pre>		</pre>
	<hr>		<hr>
	Return to: [[~~Cfengine~~]]		Return to: [[CFEngine]]

Martin: /* Information sources */

2015-12-29T22:12:26Z

Information sources

← Older revision		Revision as of 22:12, 29 December 2015
Line 163:		Line 163:
	== Information sources ==		== Information sources ==
	* http://nichol.as/zeromq-an-introduction		* http://nichol.as/zeromq-an-introduction
			* https://github.com/zeromq/pyzmq/issues/132
	* Author: Lev Givon <lev(at)columbia(dot)edu>		* Author: Lev Givon <lev(at)columbia(dot)edu>
	* http://blog.pythonisito.com/2012/08/distributed-systems-with-zeromq.html		* http://blog.pythonisito.com/2012/08/distributed-systems-with-zeromq.html
	* http://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html		* http://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html
	* http://lists.zeromq.org/pipermail/zeromq-dev/2011-February/009490.html		* http://lists.zeromq.org/pipermail/zeromq-dev/2011-February/009490.html

	== Basic patterns ==		== Basic patterns ==
	ZeroMQ comes with five basic patterns		ZeroMQ comes with five basic patterns

Martin: /* Example CFEngine message policy */

2015-12-27T21:29:43Z

Example CFEngine message policy

← Older revision		Revision as of 21:29, 27 December 2015
Line 54:		Line 54:
	}		}
	</pre>		</pre>
			Mind the single quotes around the parameter string being the json container, when ommitted the quotes around the keys and values will be lost.

	=== Message Delivery ===		=== Message Delivery ===

Martin: /* Example CFEngine message policy */

2015-12-27T21:27:37Z

Example CFEngine message policy

← Older revision		Revision as of 21:27, 27 December 2015
Line 29:		Line 29:
	vars:		vars:
	"role" string => "x2gvdt";		"role" string => "x2gvdt";
	# "host": { "uqhost": $(sys.uqhost), "domain": $(sys.domain), "role": $(role) },

	"host_info" data => parsejson('		"host_info" data => parsejson('
	{		{
Line 40:		Line 38:
	commands:		commands:

	"/root/client-synchronous-request-response.py ${host_store}";		"/root/client-synchronous-request-response.py '${host_store}'";

	reports:		reports:
Line 56:		Line 54:
	}		}
	</pre>		</pre>

	=== Message Delivery ===		=== Message Delivery ===
	We use Python to do the messaging until an alternative in C is available (work in progress). 0mq is the first messaging system to consider, others may follow. This is the Python script the agent uses to send a message:		We use Python to do the messaging until an alternative in C is available (work in progress). 0mq is the first messaging system to consider, others may follow. This is the Python script the agent uses to send a message:

Martin: /* Message Delivery */

2015-12-15T12:43:43Z

Message Delivery

← Older revision		Revision as of 12:43, 15 December 2015
Line 63:		Line 63:
	import sys		import sys
	import zmq		import zmq
	import json

	context = zmq.Context()		context = zmq.Context()

Martin: /* cf-messaged */

2015-12-15T09:23:15Z

cf-messaged

← Older revision		Revision as of 09:23, 15 December 2015
Line 152:		Line 152:
	{host:{uqhost:x2gvdt0001,domain:webhuis.nl,role:x2gvdt}}		{host:{uqhost:x2gvdt0001,domain:webhuis.nl,role:x2gvdt}}
	</pre>		</pre>
			When a message is received the daemon places the message in a local queue for processing. The sending node receives a hard coded response "message received", but this could be any response as a result on the side of the listener. The response is useful when it triggers the node to supply more information in more messages.
	This is work in progress, the Puthon script does not yet treat the data container very well. When a message is received the daemon places the message in a local queue for processing.

	= 0mq =		= 0mq =

Martin: /* Information processing Nodes */

2015-12-15T08:57:55Z

Information processing Nodes

← Older revision		Revision as of 08:57, 15 December 2015
Line 117:		Line 117:

	== Information processing Nodes ==		== Information processing Nodes ==
	Information processing Nodes receive their information through message feeds and for their part may be willing to share their information through views. Data would be an information processing Node, relying on a defined set of feeds, an information processing process that builds the Universal ~~truth~~ and defined ~~aytorized~~ views that share the information stored.		Information processing Nodes receive their information through message feeds and for their part may be willing to share their information through views. Data would be an information processing Node, relying on a defined set of feeds, an information processing process that builds the Universal Truth and defined autorized views that share the information stored.
	=== cf-messaged ===		=== cf-messaged ===
	In this proof of concept the listener simply adds every message to a file, queue.txt as were it a queue. Nodes in fect feed the listener with information and the listener knows how to process incoming messages. Feeds are input schemas. The example uses the typical Zeromq port 5555, but why would we not use a more typical CFEngine port 5309?		In this proof of concept the listener simply adds every message to a file, queue.txt as were it a queue. Nodes in fect feed the listener with information and the listener knows how to process incoming messages. Feeds are input schemas. The example uses the typical Zeromq port 5555, but why would we not use a more typical CFEngine port 5309?

Martin: /* Information processing Nodes */

2015-12-15T08:57:07Z

Information processing Nodes

← Older revision		Revision as of 08:57, 15 December 2015
Line 117:		Line 117:

	== Information processing Nodes ==		== Information processing Nodes ==
	Information processing Nodes for their part may be willing to share their information through views.		Information processing Nodes receive their information through message feeds and for their part may be willing to share their information through views. Data would be an information processing Node, relying on a defined set of feeds, an information processing process that builds the Universal truth and defined aytorized views that share the information stored.
	=== cf-messaged ===		=== cf-messaged ===
	In this proof of concept the listener simply adds every message to a file, queue.txt as were it a queue. Nodes in fect feed the listener with information and the listener knows how to process incoming messages. Feeds are input schemas. The example uses the typical Zeromq port 5555, but why would we not use a more typical CFEngine port 5309?		In this proof of concept the listener simply adds every message to a file, queue.txt as were it a queue. Nodes in fect feed the listener with information and the listener knows how to process incoming messages. Feeds are input schemas. The example uses the typical Zeromq port 5555, but why would we not use a more typical CFEngine port 5309?

Martin: /* cf-messaged */

2015-12-15T08:52:21Z

cf-messaged

← Older revision		Revision as of 08:52, 15 December 2015
Line 119:		Line 119:
	Information processing Nodes for their part may be willing to share their information through views.		Information processing Nodes for their part may be willing to share their information through views.
	=== cf-messaged ===		=== cf-messaged ===
			In this proof of concept the listener simply adds every message to a file, queue.txt as were it a queue. Nodes in fect feed the listener with information and the listener knows how to process incoming messages. Feeds are input schemas. The example uses the typical Zeromq port 5555, but why would we not use a more typical CFEngine port 5309?
	<pre>		<pre>
	import time		import time
Line 125:		Line 126:
	context = zmq.Context()		context = zmq.Context()
	socket = context.socket(zmq.REP)		socket = context.socket(zmq.REP)
	socket.bind("tcp://10.22.23.184:5555")		socket.bind("tcp://10.68.71.184:5555")

			response = "message received"
	while True:		while True:
	# Wait for next request from client		# Wait for next request from client
Line 134:		Line 136:
	# Do some 'work'		# Do some 'work'
	time.sleep(1)		time.sleep(1)

			with open("queue.txt", "a") as queue:
			queue.write(message + "\n")

	# Send reply back to client		# Send reply back to client
	socket.send( ~~message~~)		socket.send( response )

	</pre>		</pre>
	The output would be:		The output would be:
	<pre>		<pre>
			root@wbhs-pkg:~# tail -F queue.txt
	Received request:
			{host:{uqhost:x2gvdt0001,domain:webhuis.nl,role:x2gvdt}}
	['/root/client-synchronous-request-response.py',
			{host:{uqhost:kvmutl0004,domain:webhuis.nl,role:kvmutl}}
	'{', 'host', ':',
	'{~~', '~~uqhost~~', '~~:~~', '~~x2gvdt0001', ~~','~~,		{host:{uqhost:x2gvdt0001,domain:webhuis.nl,role:x2gvdt}}
			{host:{uqhost:x2gvdt0001,domain:webhuis.nl,role:x2gvdt}}
	'domain', ':', 'webhuis.nl', ',',
	'role', ':', 'tstutl',
	'}',
	'}']
	</pre>		</pre>
	This is work in progress, the Puthon script does not yet treat the data container very well. When a message is received the daemon places the message in a local queue for processing.		This is work in progress, the Puthon script does not yet treat the data container very well. When a message is received the daemon places the message in a local queue for processing.