Title: Plan an automated configuration system
Course: CIS 208: Linux/UNIX III: Intermediate System Administration, Networking, and Security ~ For IGNITE Review > Section: Learning Modules

Plan an automated configuration system

An automated configuration tool is desirable in most environments and is essential in the enterprise.  Among the benefits are consistent deployments, central management, quick updates and less chance of human error.  While there are several good automated configuration programs, we will work with Puppet which is the most popular and is available in an open source version.

When planning a new configuration management system, it is important to plan ahead and implement it in phases.

Start by creating a file versioning system such as subversion or git.  This will allow new versions of configuration files to be tested before implementing on production servers.  It will also support a quick way to see what has been updated and to rollback if necessary.

Plan one or more servers with good network connections and sufficient cpu and memory resources.  If desired, give the main server the hostname "puppet" since the puppet client will automatically use this host if it is available.  Be sure that all names resolve correctly on all hosts, and use the fully qualified domain name when referring to hosts in puppet.

Install the puppetmaster software on the server.  The puppetmaster will provide a Certificate Authority to ensure that all communications are authentic and encrypted.  Test the certificate before adding clients, and rebuild the CA if needed.

Set up a test host, preferably a virtual machine which can be quickly restored to "like new" condition.  This host will be used to test and debug policies in puppet.  Install the puppet client software and ensure that it can connect to the master.

When creating policies, it is good to start simple and add complexity in discrete steps.  For example, it is difficult to implement a policy to create a user with a set of ssh keys and a sudoers entry. It is better to create a user first and test that it works correctly.  Next ensure that the user has a home directory with the correct permissions.  Only after the home directory is properly created can ssh keys be managed.  Finally ensure that the sudoers file is updated as needed.

In each step files will be updated.  Tests will need to be made for all the possible states.  For example, one run will have the user already created with correct settings.  Another run will test with the user already created, but with the wrong home directory or the wrong UID.  Also it is good to have a run on a "like new" system that does not have the user account.  Ensure that all the tests are good, before deploying them to production systems.