Launchpad Entry: https://launchpad.net/products/bzr/+spec/foo
Created: 2005-12-09 by MartinPool
Contributors:
Summary
People may wish to use bzr to track changes to the /etc configuration directory. It is proposed to have this available by default in server installs of Dapper.
Rationale
It is useful to keep /etc under version control:
- a cheap, local backup as protection against user error
- multi-admin machines can use it to communicate what was done, when, and by whom
- some protection against malicious access
Further Details
A number of enhancements would be needed in bzr for this to work:
- bzr should record unix owner/group/mode of files.
- when updating the working copy, bzr should use the appropriate mode - this applies to pull, revert, etc.
- permission tracking should probably not be on by default; it's not desirable for regular source trees
- need something like --auto-add, --auto-remove options for commit
- define reasonable ignore files for /etc
- admins may want commits recorded against their real username, rather than just as 'root'. (rcs respects $LOGNAME for example; using $BZR_EMAIL may be enough.)
- any nested tree changes needed?
- what if admins want to version e.g. /etc/apache2 separately?
- suppress text diff display for binaries
- tests for all of above
Configuration/integration issues
- script to run bzr from cron
- default ignore list for /etc
- bzr may need to be in Dapper main section; therefore in before upstream version freeze in January (!!)
- send email after commit
- auto push mirror after commit
- packages are not allowed to touch /root or /home so configuration must be in /etc
- the scripts to version /etc should probably not be in bzr but rather in another package which depends on bzr. Installing this package can activate the behaviour. This could be in the server seed but not the desktop seed.
History would preferably be stored under /var, rather than /etc/.bzr.
Assumptions
1. /etc contains only directories, regular files and symlinks -- no fifos, sockets, or device files. This is true on breezy at least, and possibly(?) mandated by policy. bzr will just ignore exotic inodes. There's little point in versioning them anyhow.
1. Total contents of /etc are of moderate size (a few MB at most.)
1. We don't need to track ACLs or other extended attributes.
1. /etc/gconf/schema is very large (>1600 files on breezy), but typically not installed on servers. It's not a big problem to have it but it will create some amount of noise.
Use Cases
It is important that the description section covers the functionality-related aspects (the "what") of the change. Providing rationale (the "why") is always a plus.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Schema Changes
Data Migration
Discussion
This section should house the larger issues that need discussing; you can sprinkle XXXs around the page if you want to keep the smaller open issues in context.
Unresolved Issues