Hello, ( note to those who didn't expect to receive mails from the opensuse-factory mailinglist ;-) I bcc'd you because you have an etckeeper package in your OBS home project. It would be nice if you can give a short summary of your experience with etckeeper. Please reply to the opensuse-factory mailinglist. (If you are not subscribed there, feel free to reply to me - I'll forward your mail. ) Am Donnerstag, 10. Mai 2012 schrieb Obexer Christoph:
Am Donnerstag, 10. Mai 2012, 13:38:37 schrieb Christian Boltz:
I notided that Ubuntu is thinking about keeping an unmodified copy of all /etc files which can then be used to make various things easier (upgrades, "what did the user change?" etc.)
You can find more details on http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pris tine-conffiles/ and/or listen to the audio livestream (linked on that page) in some hours - the time specified on the page is in PDT timezone, which translates to May 10 (= today) 17:00:00 UTC.
IMHO this feature would also be useful for openSUSE, so someone[tm] should follow this session ;-)
actually keeping a second copy of the config files on /etc seems bad considering the UsrMove "movement"
maybe all config files should be moved to /usr/etc and symlinked to /etc (where users would be allowed to override)
Only if you find a way to ensure that the symlink is replaced by a plain file before editing - otherwise users would (accidently) edit the files in /usr...
but not having a VCS for the config files is stupid IMHO anyway:
That's what the Ubuntu developers also decided quite quickly ;-) They'll probably use "etckeeper" ( http://joeyh.name/code/etckeeper/ ) which can use various VCS as backend and additionally tracks file permissions and ownership. Ubuntu will probably use bzr as backend (not surprising because it's used for launchpad). etckeeper also supports git which might be a better choice for openSUSE. They also think about additional goodies like a failsafe boot mode that uses the last-known-working config files (might be useful if you break the pam or systemd config ;-) BTW: # osc se etckeeper home:cphennessy etckeeper (empty package) home:mfladischer etckeeper (last change 30 months ago) home:openttdcoop:server etckeeper (last change 8 months ago)
Thanks for pointing out this feature request!
note: I don't have a launchpad account and could only read this too late to attend so if someone has an account maybe forwar this to them, thanks
Here's a copy&paste from the etherpad for http://summit.ubuntu.com/uds-q/meeting/20293/foundations-q-dpkg-pristine-con... ----------------------------------------------------------------------- * could we mitigate disk space overhead using reflinks somehow? - No, unfortunately - only btrfs supports them * use a FS that has built-in rollback functionality to avoid making an actual copy. * use etckeeper? what is VC overhead (/etc/init/.git/, /etc/init/.bzr ~= 3-10M) * cost for ISO image = 2.8M compressed for etckeeper and dependencies * cost for post-install system: 17.7M. * friendly-recovery could interface with etckeeper to revert (not uncommit!) to some arbitrary known good commit to allow the normal boot to proceed. Add tags for last-known-good-boot. Change the tag when say DM launched and /etc is writeable. * if we want a pristine copy, should not go in /etc - put it in /lib (can't be /var as may be on a separate partition). * implemented through a descrete pkg so for small footprint devices with no/little chance users will modify conffiles (think ubuntu phone), this can be not implement by not installing that pkg thus saving the disk footprint hit * ability to revert user-made-changes vs packaging changes on boot in friendly-recovery. * should this also apply to server? * should have ability to white/black list files: - don't store core files, /etc/passwd, /etc/shadow, /etc/cups/printers.conf (automatically updated by BrowsePoll), binary files, etc? - arguably the cups thing is a bug * use btrfs snapshot hooks for pkg upgrade changes? * is there a generic etckeeper facility to ignore files or patterns or do we add such patterns to /etc/.bzrignore? what if etckeeper changed to git say? * test this as part of upgrade testing. * discuss this change with QA. * testing the friendly recovery as well. * should we keep the .bzr/ directory *outside* of /etc (in /lib say?) = Actions = * review /etc for binary files and raise bugs to get them moved to /usr * seed changes to include etckeeper * review apt/dpkg post-install hook * add tags on commit * friendly recovery interface * ensure friendly-recovery disallow rolling back to previous release :-) * add upstart job to add last-known-good-boot bzr tag * ensure do-release-upgrade/upgrade-manager adds appropriate tags. * consider changing dpkg to add tags for each pre-inst and post-inst phase of a package install/upgrade [OPTIONAL]. Only needs to be used if dpkg invoked directly - not done if dpkg called via apt. * check to see if etckeeper can provide a "mainline" branch which is the "pristine" set of files and offer the user the option to "revert to pristine" [adam] * [SECURITY]: get security team to review this plan (imagine an admin changes the root password in a VM, then publishes that VM on a website: consumers of that VM could get back to original copy of /etc/passwd, /etc/shadow and brute-force attack it). - NetworkManager wireless passwords, CUPS printer passwords, ldap.conf -- basically anything non-world-readable in /etc comes to mind here ----------------------------------------------------------------------- I also managed to record the audio livestream. You can find the denoised version on http://www.cboltz.de/tmp/2012-05-10-uds-etc-pristine-etckeeper-denoised.ogg (45 MB) Regards, Christian Boltz -- Diese Signatur ist vorübergehend nicht erreichbar. Versuchen Sie es später noch einmal oder hinterlassen Sie eine Nachricht vor dem Signaturtrenner. Piep. -- To unsubscribe, e-mail: firstname.lastname@example.org To contact the owner, e-mail: email@example.com