Difference between revisions of "User:Jbroman/Ceo Architecture"

From CSCWiki
Jump to navigation Jump to search
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.

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.