User:Jbroman/Ceo Architecture: Difference between revisions
(→ceo) |
|||
| 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 |
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. |
|||
Revision as of 07:51, 8 September 2010
This is a draft of a document on the architecture of ceo.
Getting
All of these components are available in source form in the the 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
The ceo ecosystem consists of the following components:
- ceo
- a command-line interface to various club-related administation functions
- ceod
- a Kerberized daemon responsible for executing tasks requiring special access (e.g. creating Kerberos principals or MySQL databases) on behalf of the user
- ceoc
- a client program used by ceo to send messages to ceod for execution
ceo
ceo is the user interface with which users interact. It is implemented in Python and presents a curses-based menu system (though some features can also be accessed by passing command-line flags). It is installed at /usr/bin/ceo by the ceo-python Debian package.
When launched, users may be prompted for their password. This is used to obtain a Kerberos ticket for the LDAP service if neither a service ticket nor ticket-granting ticket are found in the cache.
The following tasks are completed by creating a request which is relayed by ceoc and executed by ceod on the appropriate machine.
- Adding new users (members, club reps, clubs) is done on ginseng.
- Creating MySQL databases is done on caffeine since mysqld is configured to allow only local connections.
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 urwid which call the appropriate functions in the ceo package (such as ceo.members.create_member).
ceod
ceod is a Kerberized daemon (service principal ceod/hostname@CSCLUB.UWATERLOO.CA) running on TCP port 9987. Each connection forks a slave ceod process to handle that session.
ceod's basic message format is this (note that network byte order is big-endian, whereas the most common host architectures are little-endian):
| 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 ceod (and vice versa) and establish a session key.