Difference between revisions of "Configuration Management"
(→Virtualisation) |
|||
| Line 1: | Line 1: | ||
==How best to manage the configuration of the servers== |
==How best to manage the configuration of the servers== |
||
| + | '''Static Configuration Files''' |
||
| − | *It has become clear that a configuration managment system needs to be implemented for the servers |
||
| + | 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. |
||
| + | |||
| + | '''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. |
||
==Virtualisation== |
==Virtualisation== |
||
| Line 7: | Line 16: | ||
*Access can be controlled on a per-service level |
*Access can be controlled on a per-service level |
||
*Does not solve the configuration managment problem |
*Does not solve the configuration managment problem |
||
| + | *Configurations can be tested on a copy of the service before rolled out for real. |
||
| − | *Xen 3.0.3 will reach etch on Oct-31st. Remaining updates are most likely to just be bug fixes. |
||
| − | == |
+ | ==Version Control System== |
*/etc could be put into CVS |
*/etc could be put into CVS |
||
*A possible structure would have different branches for each server and trunk holds common configuration |
*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 |
*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== |
==Configuration Management Software== |
||
*Cfengine or puppy are the most popular candidates |
*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]] |
[[Category:Servers]] |
||
Revision as of 17:41, 26 March 2007
Contents
How best to manage the configuration of the servers
Static Configuration Files
These are files such as exim and apache configuration files.
In most cases, these will only be altered when the package is installed.
In most cases, the customised files will not apply to the next version of the package.
Dynamic data files
These are password files and network information.
The data is stored in the MySQL database and is managed via the website.
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.
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.
Virtualisation
- Virtualisation of services would mean that they can be set up once and moved around the servers as hardware is upgraded
- 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.
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
