Launchpad Entry: server-lucid-puppet-etckeeper-integration
Puppet leverages a VCS when it creates and modifies (configuration) files.
Puppet leverages the bzr version control system to keep track of changes made to files under its control. Local changes are now taken into account and puppet can decide what to do in this case.
The use of a VCS for configuration files has been a best practice for system administration for some time as it helps in tracking changes made to the system and debugging. Since puppet can create and update text files using a VCS for tracking purposes is useful.
Puppet could also take advantage of client-side VCS to differentiate between puppet master configuration has changed and local changes on the client.
- Patrice, a system administrator, uses puppet to manage his infrastructure. After pushing an update, the mail service fails to restart. In a hurry he can log into the production system via ssh and look at the changes made to the actual configuration files lately.
- Cid, a junior system administrator, is asked to update the mail aliases file on the mail server. He logs into the server and manually edit the alias file. Next time puppet runs on the system, it detects that the alias has been modified locally and aborts by emitting a warning message.
VCS integration in puppet
Whenever puppet is about to create or modify a text file it uses a VCS to:
- Detect local changes
- If a local change is made puppet relies on a policy to take an action:
- Always overwrite
- Always abort with reporting of an error message (and the diff)
- If the file is going to be updated the client records the new version of the file in the local VCS and updates the file.
WI: Write a design document outlining the changes required to the puppet client to support a VCS (upstream): TODO WI: Implement VCS support in puppet client: TODO WI: Integrate bzr as the VCS for puppet client: TODO
VCS support for meta-data file:
WI: etckeeper: fix .bazaar/ owned as root bug: TODO WI: move etckeeper into main: TODO WI: implement new features/commands - diff, log, status: TODO WI: discuss proper meta-data (file permissions, user/group, acls, selinux, ...) support for the underlying VCS (bzr): TODO WI: implement proper file permissions and ownership support in bzr: TODO WI: implement proper acls support in bzr: TODO WI: implement proper selinux in bzr: TODO
See the Work Items in the blueprint
BoF agenda and discussion
UDS Session notes
Puppet should use etckeeper to keep track of the configuration files it generates. It should also leverage etckeeper (and the underlying vcs) to detect local changes to files it manages and report any differences.
* integration with puppet template engine: 1. VCS? 2. etckeeper? * etckeeper/vcs support to puppet reporting engine
* candidate for main / install during installation * bug to solve: .bazaar created as root (bug 376388) * integration of permissions/ownership in bzr diff/revert
- configuration management framework
- puppet currently uses a backing filesystem for revision control (like git?)
- file contents stored by md5 sum, would like to replace backend with a real revision control system
- - only 2-3 places where to hook the vcs:
- one single commit for the whole run ( – lose meta data)
- individual commits (per ressource)
- - only 2-3 places where to hook the vcs:
etckeeper integration: give a new version of the file (content, path), etckeeper decides by policy what needs to be done (overwriting). replacing backup system with etckeeper/vcs.
- capistrano, symlinks?
- revision control over /etc
- configuration changes committed to revision control, hooked into apt/dpkg installs
- maintains history of configuration file changes
- can install and "forget about it"
- ensure that puppet integrates with etckeeper for change control of /etc
- general integration of puppet with a VCS so that all of its changes are in
- revision control
- dpkg conffile integration?
detecting local changes in puppet
- could take advantage of client-side VCS to differentiate between
- puppet master configuration has changed
- local changes on the client
- puppet cannot tell the difference today
- this would be useful to trigger different conflict handling (e.g. human mediation)
* move into main:
- - a few bugs to fix: .bazaar/ owned as root
* support in the installer:
- - when to install it? as early as possible - use of dpkg triggers?
* new features/commands: diff, log, status * files outside /etc? * proper files permissions
Design document: by the end of the month