The SUSE Manager client stack is rather simple, in regular intervals it asks the SUSE Manager Server for scheduled actions and executes them. Typical actions are:
- install patch
- install/update/remove package
- verify contents of config files
There are a couple of issues with this approach:
- scalability: load on server and database each time a client asks for actions - even if no actions are scheduled
- scalability: server can't cope with many clients requesting actions within a scheduled maintenance window
- availability: client actions depend on the server, if the server is down / not reachable, the client can't perform actions
- availabilty: we have many requests to support low bandwidth connections and remote locations
- compliance: clients are not compliant to the desired configuration in between intervals
- rogue sysadmins: admins still run zypper or rpm on managed clients, circumventing the desired configuration defined on the server
- DRY: the majority of actions are supported by standard configuration management systems, no need to duplicate them in a separate client stack
- limited to packages, patches, and complete config files, no services, processes, etc.
- decrease of disk space. Adding the client software stack to a minimal SLES system adds a couple of dozen megabytes
- synchronous operation: clients carrying out an action must contact the server. This easily overloads the server if you have many clients and a short maintenance window.
Goals to achieve
Using an existing configuration management software, I want to achieve the following goals
- move from imperative (action based) to declarative (policy based) configuration settings
- scalability: decrease load on server - server generates policies, client applies policies without interacting with the server
- scalability: maintenance window times should be a part of policies, where clients should operate autonomously within the maintenance window
- scalability: clients might re-distribute policies to other clients
- availability: client operates autonomously
- availability: with a local update repository, only policies need to be transferred, with minimized bandwidth requirements
- compliance: configuration management can enforce policy on client more often and report or remediate actions done by rogue sysadmins
- DRY: drop homegrown client stack in favor of community adopted existing software instead
- extend to parameterized config file templates, localized change within an existing config file, control of services, processes, etc.
- minimized disk space requirements - e.g. CFEngine needs around 10 megabytes
- reporting: client status (list of package, hardware information, etc.) back to the server.
- asynchronous operation: separate 'prepare client for the change' from 'apply the change'. Prepare all clients (download list of changes to be applied, download required packages and patches) before the actual maintenance window. Clients should be able to operate autonomously, without the need to contact the server while applying a configuration change.
- Monitoring: any decent CMS can do monitoring and even react for required events. There is how monitoring could be "integrated".
Use an existing configuration management system (CMS). Deploy the master of the CMS on the SUSE Manager Server and the slave of the CMS on the client system. Write a small daemon which runs on the server and translates actions to policies. Distribute these policies via the existing CMS master-slave deployment mechanism and let the client operate autonomously.
ruby-spacewalk git repository at [https://github.com/kkaempf/ruby-spacewalk] contains
- A command to fake a client registration
- A command to convert pending action to CFEngine promises
Looking for mad skills in:
manager cfengine configurationmanagement
This project is part of:
Hack Week 11