Linux Configuration management requirements

There are a number of Linux configuration management solutions available for Linux hosts, such as Chef, CFEngine, Puppet, and Salt.

CFEngine has been around for a while and is the grand daddy of configuration management.
Salt is relatively new to the field. Salt is written primarily in Python.
Puppet is written in Ruby and is very popular as well as mature.
Chef is written in Ruby and Erlang, it is quite popular among cloud providers.

Features that a configuration management solution should ideally have:

* Client policy enforcement: If you have end users that have administrative access on clients to modify the system, and you have a need to keep configuration consistent across systems, then a CM solution can help over-ride end user changes. For instance, let’s say that you need to ensure that a Unix group called ‘admins’ always has sudo access, however you have a user who removes this group from his desktop since he is not sure about it’s purpose. A good CM will run periodically and over-write the end user changes, always ensuring that the ‘admins’ group exists.

* Fast updates is a must for large scale deployments. As the size of a deployment grows, the speed of pushing updates should not slow down. Clients may get updates from the servers every 30 minutes by default, however this value should be able to be changed to say 5 minutes or less as is needed.

* Security is paramount, since you do not want clients to download configuration from the servers to which they are not entitled. As such there should be some mechanism of client authentication, perhaps client based certificates that the server can validate from a certificate authority.

* Encryption of communication between client and server is also another consideration. If for instance the server is sending over a password file with encrypted password’s, you don’t want this to be snooped. Some sort of SSL or perhaps TLS encryption should be used between the client and server.

* Local updates merging is another feature that may be required. For instance if a password file is pushed from the server, and I need to add a user to the password file temporarily without making changes to the configuration management repository, then I should be able to add a user which the CM system respects for a given amount of time.

* Ability to roll back updates is also important on the client. In case I make a mistake that gets pushed to all the clients, I should be able to say ‘go back to previous working version’.

* Dry run of configuration changes. This will allow an service engineer to test the changes before actually pushing them out.

* Reporting capabilities for end users and also administrators. It should be easy for the CM administrators to get reports on numbers of clients, and also versions of client software.

* The administrator should be able to apply updates on a rolling basis without any downtime. Also, if clients are offline, they should be able to update themselves when they are able to reach the server the next time around.

* Easy to use, let’s not forget this feature! The language in which configuration is specified should ideally be one that is easy to create directives in. For instance, it is not hard to find folks who dislike YAML or XML.

Which configuration management system do you use and why? Share you comments in this blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s