Difference between revisions of "Configuration Management"

From Warwick Student Cinema
Jump to: navigation, search
(New configuration management details)
Line 1: Line 1:
  +
=Puppet=
==How best to manage the configuration of the servers==
 
   
  +
==Adding a new client==
'''Static Configuration Files'''
 
These are files such as exim and apache configuration files.<br>
 
In most cases, these will only be altered when the package is installed.<br>
 
In most cases, the customised files will not apply to the next version of the package.
 
   
  +
On the client:
'''Dynamic data files'''
 
  +
'''sudo aptitude install puppet'''
These are password files and network information.<br>
 
  +
'''sudo puppetd --test'''
The data is stored in the MySQL database and is managed via the website.<br>
 
Most of the data will not change very regularly, but when it does, the servers need to be updated soon - otherwise you have to wait 24hrs for a password change.<br>
 
The files can easily be generated by scripts, but there are lots of scripts on lots of servers each one generating a single configuration file.
 
   
  +
On the server (puppet):
==Virtualisation==
 
  +
'''sudo puppetca --list'''
*Virtualisation of services would mean that they can be set up once and moved around the servers as hardware is upgraded
 
  +
The new client hostname should be displayed. Then
*Access can be controlled on a per-service level
 
  +
'''sudo puppetca --sign''' ''<client hostname>''
*Does not solve the configuration managment problem
 
*Configurations can be tested on a copy of the service before rolled out for real.
 
 
==Version Control System==
 
*/etc could be put into CVS
 
*A possible structure would have different branches for each server and trunk holds common configuration
 
*Update would be pushed in a similar way to the website ie. on each commit a script is run to push the updates
 
 
'''Advantages'''
 
*Allows changeing of configuration files in-place with a commit once changes have been made
 
*Easy to roll back to an earlier version or see previous changes on any file
 
 
'''Disadvantages'''
 
*Its a lot of infrastucture for files that usually don't change after installation and won't be the same when the next version is installed.
 
*People need to remember to do a commit once changes have been made
 
*No per-host permissions
 
*Does not deal with dynamic data files
 
 
==Configuration Management Software==
 
*Cfengine or puppy are the most popular candidates
 
*cfengine scripts are stored in cvs on a single server
 
 
'''Advantages'''
 
*Provides a solution for both static configuration files and dynamic data files
 
 
'''Disadvantages'''
 
*Way too complicated
 
 
==Rsync==
 
*Store configuration files all on one server
 
*Static configuration files can be in cvs
 
*dynamic data files can be automatically generated and then copied accross to server with static files
 
 
'''Advantages'''
 
*Simple
 
*Means that data files only need to be generated on one host
 
*Only modified files need to be stored
 
 
'''Disadvantages'''
 
*Is there any point storing configuration files in cvs that will only be changed when a package is installed.
 
*Difficult to alter and test files in place.
 
 
 
==In-place==
 
*Scripts generate data files where they are needed
 
*Configuration files are altered as required
 
*Any changes can be documented
 
*Easy to determine what files have been modified after install
 
 
'''Advantages'''
 
*Simple
 
*This is pretty much how it currently works
 
 
'''Disadvantages'''
 
*People need to remember to document
 
*Can't see what changes have been made, only that a file has been modified
 
   
   

Revision as of 22:19, 25 November 2010

Puppet

Adding a new client

On the client:

sudo aptitude install puppet
sudo puppetd --test

On the server (puppet):

sudo puppetca --list

The new client hostname should be displayed. Then

sudo puppetca --sign <client hostname>