In the UNIX operating system everything is a file, which makes it an easy-to-manage and administrator-friendly system.

The traditional way of managing UNIX was to use the telnet interface, but being a plaintext protocol, telnet exposes you to the risk of network snooping and compromise oflogin credentials. SSH works on an encrypted channel to overcome the snooping issues. A UNIX administrator can SSH into the box from a remote machine and change the configuration or execute commands remotely.

Generally, it is considered a good practice to take a configuration backup before making any changes to the production configuration so that the old configuration is available for roll-back. Also, as a part of the organisation's policy, the same base configuration should be configured on all the servers to reflect consistency and as a server-hardening practice. A majority of the problems in the UNIX environment occur due to ad-hoc changes, which can be mitigated by following proper change management procedures. Handling and monitoring ad-hoc changes, and restoring the previous state, remains a challenge for organisations.

Meeting such challenges is quite workable for a small set-up of 1-20 servers and a dedicated UNIX administration. But during hardware failure or other problems, where the servers need to be reconfigured from scratch, it takes a lot of effort and time in restoring the servers to the previous state. To handle such scenarios, a quick solution would be to hire another UNIX administrator who could act as a secondary resource and offloads other activities from the primary resource during disaster conditions.

Think about a scenario of managing a globally-distributed data centre with 500 "'NIX servers or more, comprising Solaris, Debian, Ubuntu, Fedora, CentOS, etc. Here, servers are running with the same base configuration and packages, where configuration files need to be checked-out to a version controlled repository. Only planned changes are allowed and the previous configuration state is restored for unplanned changes.

Additionally, centralised user and policy management, along with automated configuration recovery during disaster conditions are required. In such a case, building a team of 10-20 administrators would not be a recommended approach. Rather, using a centralised configuration tool to automate the administration tasks would be a better option to follow.

Along with commercial tools like BladeLogic and OpsWare, there are a couple of open source systems automation and configuration management tools available like Bcfg2, Cfengine and Puppet. Cfengine has been an administrator's favourite configuration management framework since the past few years and is widely being used by many companies. Puppet turns out to be a next -generation configuration management tool to overcome many ofCfengine's weaknesses.

Puppet is written in Ruby and is released under the GPL. It supports a number of operating systems like CentOS, Debian, FreeBSD, Gentoo, OpenBSD, Solaris, SuSE Linux, Ubuntu, etc. Puppet is being used by many organisations including Google, which uses it to manage all Mac desktops, laptops and Linux clients.

Puppet installation
Puppet installation is fairly easy and is, in fact, a matter of seconds. Puppet runs in client-server configuration, where the client polls the server at port 8140 every 30 minutes to check for the new instructions or to match the configuration files. The client also listens to a port to have push-updates from the server. In Puppet terminology, a client is called a Puppet node and a server is called a Puppet master. Figure I shows the set-up.