[Kolab-devel] Configuration Management in Kolab 3.0

[Jeroen van Meeuwen (Kolab Systems)]

Hi there,

I've been pondering the configuration management in Kolab for a little 
while now, and this mail is to ask you for some feedback.

In this idea, every operating system instance is a 'node' with a 
(unique) fully qualified domain name, and each node has one or more 
'roles' ('imap-server', 'web-server', etc.).

Each role in turn corresponds with one or more 'services' that should 
be performed for any given role.

A node that has the role of an IMAP server for example, should 
naturally run an IMAP service, but could also need an MTA - depending on 
the topology of your environment, and the mode of delivery from a mail 
exchanger to the node that is the IMAP server.

A single host Kolab deployment for example (say, node: 'localhost') 
would typically fulfil all roles needed to run Kolab. The delivery from 
the MTA to IMAP happens over either an LMTP AF_UNIX or an AF_INET socket 
(over the loopback interface?).

On multi-host deployments however there's the opportunity to continue 
with the LMTP AF_INET socket, but you can also use SMTP to relay the 
message from the (internal) mail exchanger to the (backend) mail 
exchanger (on the IMAP server).

Long story short, an IMAP server may have two roles: 'imap-server' and 
'mta-backend'.

Suppose the role 'imap-server' corresponds with running the IMAP 
service with service 'cyrus-imapd', then the files that could need to be 
managed would include '/etc/cyrus.conf' and '/etc/imapd.conf'.

Suppose you have an LDAP group or role that is 'cn=cyrus-admin', and we 
let its members correspond to what we want listed in /etc/imapd.conf's 
"admins" setting.

One would then;

- create the node, 'imap.example.org'
- create the role, 'imap-server'
- associate the 'imap-server' role with the 'imap.example.org' node,
- create the service, 'cyrus-imapd'
- associate the 'cyrus-imapd' service with the 'imap-server' role,
- create the file you wish to manage for the service, '/etc/imapd.conf'
- associate the '/etc/imapd.conf' service with the 'cyrus-imapd' 
service,
- create the settings you want to manage for the file, in this case, 
'admins'
- associate the 'admins' setting with the '/etc/imapd.conf' file.

Now, the way I'm thinking of getting to the (desired) value of the 
setting is by either providing a value, or by providing a string 
containing the function to call (with parameters to use).

With, for the sake of argument, the value available, I'm thinking of 
using Augeas to substitute the current value in the configuration file 
in question, with the desired value.

I think perhaps the purpose of all of this may become a little clearer 
with a slightly more complex example running a Cyrus IMAP Discrete 
Murder topology, where a dedicated frontend IMAP server proxies 
connections to the dedicated backend IMAP server on which a given 
mailbox actually resides.

The IMAP frontend server requires a setting called 'serverlist', which 
contains the addresses of the backend servers that are to be included in 
the pool of servers on which new mailboxes can be created when 
attempting to determine which one has the most free space.

The IMAP frontend server also needs 'proxy_authname' and 
'proxy_password' settings, containing the credentials the IMAP frontend 
should use in order to login to the backend and authorize itself as the 
original user.

In turn, the IMAP backend server requires a setting 'proxyservers', 
which is a space-separated list of login names that are allowed to 
authorize themselves as other users.

In this case, one would;

- create node 'frontend.example.org',
- create role 'imap-server-frontend',
- associate role 'imap-server-frontend' with node 
'frontend.example.org',
- create node 'backend.example.org',
- create role 'imap-server-backend',
- associate role 'imap-server-backend' with node 'backend.example.org',
- create service 'cyrus-imapd',
- associate the service 'cyrus-imapd' with the 'imap-server-frontend' 
and 'imap-server-backend' roles,
- create file '/etc/imapd.conf',
- associate file '/etc/imapd.conf' with service 'cyrus-imapd',
- create setting 'admins',
- associate setting 'admins' with file '/etc/imapd.conf',

- create setting 'serverlist' calling function 
list_nodes_by_role('imap-server-backend'),
- associate setting 'serverlist' with file '/etc/imapd.conf',
- associate setting 'serverlist' with role 'imap-server-frontend',
- create setting 'proxy_authname' with value 'cyrus-murder',
- associate setting 'proxy_authname' with file '/etc/imapd.conf',
- associate setting 'proxy_authname' with role 'imap-server-frontend',
- create setting 'proxy_password' with value 'V3ryS3cret',
- associate setting 'proxy_password' with file '/etc/imapd.conf',
- associate setting 'proxy_password' with role 'imap-server-frontend',

- create setting 'proxyservers' with function 
list_users_by_role('cyrus-proxyserver')
- associate setting 'proxyservers' with file '/etc/imapd.conf',
- associate setting 'proxyservers' with role 'imap-server-backend'.

Node 'frontend.example.org' can now;

- request its roles,
- boil this down to a list of files and settings it should care about,
- select only those settings that are not specifically linked to a 
specific role it doesn't perform,
- call augeas to update /etc/imapd.conf with the new values,
- select those settings that are specifically linked to roles it 
doesn't perform,
- call augeas to remove those settings from /etc/imapd.conf,
- restart/reload the corresponding service.

And of course, the same goes for a backend.

For the interested, I have some code demonstrating all of this might 
actually be doable. Let me know if you want to get your hands on it.

Thoughts? Questions? Comments?

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08