User:Jbroman/Ceo Architecture - Revision history

Jbroman: /* ceod */

2010-09-08T19:05:30Z

ceod

← Older revision		Revision as of 14:05, 8 September 2010
Line 36:		Line 36:
	== <tt>ceod</tt> ==		== <tt>ceod</tt> ==

	<tt>ceod</tt> is installed at <tt>/usr/sbin/ceod</tt> by the <tt>ceo-daemon</tt> package. It is a Kerberized daemon (service principal <tt>ceod/~~<i>~~hostname~~</i>~~@CSCLUB.UWATERLOO.CA</tt>) listening on TCP port 9987. Each connection forks a slave <tt>ceod</tt> process to handle that session.		<tt>ceod</tt> is installed at <tt>/usr/sbin/ceod</tt> by the <tt>ceo-daemon</tt> package. It is a Kerberized daemon (service principal <tt>ceod/''hostname''@CSCLUB.UWATERLOO.CA</tt>) listening on TCP port 9987. Each connection forks a slave <tt>ceod</tt> process to handle that session.

	<tt>ceod</tt>'s basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):		<tt>ceod</tt>'s basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):

Jbroman at 19:00, 8 September 2010

2010-09-08T19:00:06Z

← Older revision		Revision as of 14:00, 8 September 2010
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	This is a draft of a document on the architecture of <tt>ceo</tt>.		This is a draft of a document on the architecture of <tt>[[ceo]]</tt>.

	== Getting ==		== Getting ==

Jbroman: /* ceod */

2010-09-08T18:25:10Z

ceod

← Older revision		Revision as of 13:25, 8 September 2010
Line 65:		Line 65:

	The first field here is the host on which the operation should be executed. <tt>ceod</tt> will not execute an operation that is not configured to execute on the host. The second field is the the op name. The third field is the user/group as which the operation should execute. The fourth field is the msgtype which represents that op.		The first field here is the host on which the operation should be executed. <tt>ceod</tt> will not execute an operation that is not configured to execute on the host. The second field is the the op name. The third field is the user/group as which the operation should execute. The fourth field is the msgtype which represents that op.

			If a local op is found which matches the msgtype of the message, the corresponding op executable (located using the op name) is run as the requested user/group. For instance, the adduser op would run <tt>/usr/lib/ceod/op-adduser</tt> as <tt>root</tt>.

			Operations can be implemented in any language, but are currently implemented in C and Python. Some headers and source files in the <tt>ceo</tt> source may be useful if writing one in C; the <tt>ceo</tt> package (particularly <tt>ceo.ops</tt>) may be useful in Python.

			The body of the message may be obtained by reading from the standard input pipe. The <tt>CEO_CONFIG_DIR</tt> environment variable contains the <tt>ceo</tt> configuration directory; the <tt>CEO_USER</tt> environment variable contains the username of the authenticated user. It is important to note that while <tt>ceod</tt> does ''authenticate'' the user, it does '''not''' perform any ''authorization'' whatsoever. So, while you can rely on the user being who <tt>ceod</tt> says they are, all ops should check whether the user is authorized to perform the action (for instance, by checking their membership in a group, or by only performing that operation only on the user requesting it).

Jbroman at 18:06, 8 September 2010

2010-09-08T18:06:51Z

← Older revision		Revision as of 13:06, 8 September 2010
Line 5:		Line 5:

	All of these components are available in source form in the the [http://git.csclub.uwaterloo.ca/?p=public/pyceo.git public/pyceo.git] repository. The official Debian packages are on http://debian.csclub.uwaterloo.ca/. This server should be in the APT sources list of all club machines.		All of these components are available in source form in the the [http://git.csclub.uwaterloo.ca/?p=public/pyceo.git public/pyceo.git] repository. The official Debian packages are on http://debian.csclub.uwaterloo.ca/. This server should be in the APT sources list of all club machines.

	= Architecture =

	== Overview ==		== Overview ==

Jbroman at 16:51, 8 September 2010

2010-09-08T16:51:34Z

← Older revision		Revision as of 11:51, 8 September 2010
Line 1:		Line 1:
	__NOTOC__		__NOTOC__

	This is a draft of a document on the architecture of <tt>ceo</tt>.		This is a draft of a document on the architecture of <tt>ceo</tt>.

Jbroman at 16:51, 8 September 2010

2010-09-08T16:51:24Z

← Older revision		Revision as of 11:51, 8 September 2010
Line 1:		Line 1:
			__NOTOC__

	This is a draft of a document on the architecture of <tt>ceo</tt>.		This is a draft of a document on the architecture of <tt>ceo</tt>.

Jbroman: /* Overview */

2010-09-08T16:51:00Z

Overview

← Older revision		Revision as of 11:51, 8 September 2010
Line 11:		Line 11:
	The <tt>ceo</tt> ecosystem consists of the following components:		The <tt>ceo</tt> ecosystem consists of the following components:

	; <tt>ceo</tt>		; <tt>[[#ceo\|ceo]]</tt>
	: a command-line interface to various club-related administation functions		: a command-line interface to various club-related administation functions

	; <tt>ceod</tt>		; <tt>[[#ceod\|ceod]]</tt>
	: a Kerberized daemon responsible for executing tasks requiring special access (e.g. creating [[Kerberos]] principals or [[MySQL]] databases) on behalf of the user		: a Kerberized daemon responsible for executing tasks requiring special access (e.g. creating [[Kerberos]] principals or [[MySQL]] databases) on behalf of the user

	; <tt>ceoc</tt>		; <tt>[[#ceoc\|ceoc]]</tt>
	: a client program used by <tt>ceo</tt> to send messages to <tt>ceod</tt> for execution		: a client program used by <tt>ceo</tt> to send messages to <tt>ceod</tt> for execution

Jbroman: /* ceod */

2010-09-08T13:44:09Z

ceod

← Older revision		Revision as of 08:44, 8 September 2010
Line 37:		Line 37:
	== <tt>ceod</tt> ==		== <tt>ceod</tt> ==

	<tt>ceod</tt> is a Kerberized daemon (service principal <tt>ceod/<i>hostname</i>@CSCLUB.UWATERLOO.CA</tt>) ~~running~~ on TCP port 9987. Each connection forks a slave <tt>ceod</tt> process to handle that session.		<tt>ceod</tt> is installed at <tt>/usr/sbin/ceod</tt> by the <tt>ceo-daemon</tt> package. It is a Kerberized daemon (service principal <tt>ceod/<i>hostname</i>@CSCLUB.UWATERLOO.CA</tt>) listening on TCP port 9987. Each connection forks a slave <tt>ceod</tt> process to handle that session.

	<tt>ceod</tt>'s basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):		<tt>ceod</tt>'s basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):
Line 60:		Line 60:

	Clients are expected to authenticate (using MSG_AUTH messages) before attempting to execute operations. Failure to do so will result in the connection being unceremoniously terminated. The body of an authentication message is a GSSAPI (Kerberos) token. These are used according to the Kerberos protocol to authenticate the client to <tt>ceod</tt> (and vice versa) and establish a session key.		Clients are expected to authenticate (using MSG_AUTH messages) before attempting to execute operations. Failure to do so will result in the connection being unceremoniously terminated. The body of an authentication message is a GSSAPI (Kerberos) token. These are used according to the Kerberos protocol to authenticate the client to <tt>ceod</tt> (and vice versa) and establish a session key.

			The msgtype of an op message identifies the operation to be run. This is a reference to the appropriate op as defined in a configuration file in <tt>/etc/csc/ops</tt>. One such file is <tt>/etc/csc/ops/adduser</tt>:

			ginseng adduser root 0x01

			The first field here is the host on which the operation should be executed. <tt>ceod</tt> will not execute an operation that is not configured to execute on the host. The second field is the the op name. The third field is the user/group as which the operation should execute. The fourth field is the msgtype which represents that op.

Jbroman: /* Architecture */

2010-09-08T12:51:21Z

Architecture

← Older revision		Revision as of 07:51, 8 September 2010
Line 33:		Line 33:
	The library feature queries a PostgreSQL database; all other functions (at time of writing) are done over LDAP using the user's previously obtained ticket.		The library feature queries a PostgreSQL database; all other functions (at time of writing) are done over LDAP using the user's previously obtained ticket.

	The interface itself consists of a series of menus and wizards using [http://excess.org/urwid/ urwid] which call ~~back to~~ appropriate functions in the ceo package (such as <tt>ceo.members.create_member</tt>).		The interface itself consists of a series of menus and wizards using [http://excess.org/urwid/ urwid] which call the appropriate functions in the ceo package (such as <tt>ceo.members.create_member</tt>).

			== <tt>ceod</tt> ==

			<tt>ceod</tt> is a Kerberized daemon (service principal <tt>ceod/<i>hostname</i>@CSCLUB.UWATERLOO.CA</tt>) running on TCP port 9987. Each connection forks a slave <tt>ceod</tt> process to handle that session.

			<tt>ceod</tt>'s basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):

			{\| class="wikitable"
			! Field
			! Data Type
			! Description
			\|-
			\| msglen
			\| 32-bit unsigned integer (network order)
			\| Length of the message body, in bytes
			\|-
			\| msgtype
			\| 32-bit unsigned integer (network order)
			\| Type of message (MSG_AUTH = 0x8000000, all other values are treated as an op message)
			\|-
			\| body
			\| Raw bytes
			\| Body of the message
			\|}

			Clients are expected to authenticate (using MSG_AUTH messages) before attempting to execute operations. Failure to do so will result in the connection being unceremoniously terminated. The body of an authentication message is a GSSAPI (Kerberos) token. These are used according to the Kerberos protocol to authenticate the client to <tt>ceod</tt> (and vice versa) and establish a session key.

Jbroman: /* ceo */

2010-09-08T12:15:10Z

ceo

← Older revision		Revision as of 07:15, 8 September 2010
Line 32:		Line 32:

	The library feature queries a PostgreSQL database; all other functions (at time of writing) are done over LDAP using the user's previously obtained ticket.		The library feature queries a PostgreSQL database; all other functions (at time of writing) are done over LDAP using the user's previously obtained ticket.

			The interface itself consists of a series of menus and wizards using [http://excess.org/urwid/ urwid] which call back to appropriate functions in the ceo package (such as <tt>ceo.members.create_member</tt>).