Difference between revisions of "Configuration Management"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Historical}} |
||
| − | ==How best to manage the configuration of the servers== |
||
| + | =Puppet= |
||
| − | '''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. |
||
| + | ==Adding a new client== |
||
| − | '''Dynamic data files''' |
||
| − | These are password files and network information.<br> |
||
| − | 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 client: |
||
| − | ==Virtualisation== |
||
| + | '''sudo aptitude install puppet''' |
||
| − | *Virtualisation of services would mean that they can be set up once and moved around the servers as hardware is upgraded |
||
| + | '''sudo puppetd --test''' |
||
| − | *Access can be controlled on a per-service level |
||
| − | *Does not solve the configuration managment problem |
||
| − | *Configurations can be tested on a copy of the service before rolled out for real. |
||
| + | On the server (puppet): |
||
| − | ==Version Control System== |
||
| + | '''sudo puppetca --list''' |
||
| − | */etc could be put into CVS |
||
| + | The new client hostname should be displayed. Then |
||
| − | *A possible structure would have different branches for each server and trunk holds common configuration |
||
| + | '''sudo puppetca --sign''' ''<client hostname>'' |
||
| − | *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 |
||
| + | [[Category:IT]] |
||
| − | '''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 |
||
| − | |||
| − | |||
| − | [[Category:Servers]] |
||
Latest revision as of 22:53, 9 February 2019
 | This page is obsolete. It is kept for historical interest only. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
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>
