On Tue, Nov 22, 2016 at 11:52:03AM +1100, Peter Ross wrote:
The default configuration may change, according to best practice(e.g. which encryption protocols are safe to use etc). so you are happy to use whatever the package provides (if it is well-maintained)
However, some things you may not like, say: the "PermitRootLogin yes" line. [...]
not sure what you're running (freebsd, i think) but here's what debian does: When you upgrade a debian package that has a listed conffile, what happens depends on whether either the installed version of the file has been changed from the default and/or the package version has been changed from the previous version. If the installed version of a conffile hasn't been changed (i.e. edited in some way by the local admin) then: - if the package version hasn't changed, nothing happens - if the package version HAS changed, it replaces the current installed version. If the installed conffile has been edited and the package version hasn't changed then nothing happens. If the installed conffile has been edited and the package version HAS changed, then the user is asked what they want to do - the three main options are: - replace customised config file with package config file - keep custom config - view diff (you can also fork a shell or switch to another terminal and manually diff and/or edit the relevant files, view man pages etc, before making a decision) anyway, if the user chooses to replace their custom config file, it is renamed to filename.dpkg-old if the user chooses to keep their custom config file, the packaged version is renamed to filename.dpkg-dist These renames allow you to easily diff the config files from the command line and manually cherry-pick any changes. They also make it easy to change your mind later with just a simple mv to replace the current config file with the .dpkg-old or dpkg-dist version. This is still useful/convenient even when using revision control for your config files.
I wonder whether there is any better support from configuration management tools you are using.
Package: etckeeper Version: 1.18.5-1 Description-en: store /etc in git, mercurial, bzr or darcs The etckeeper program is a tool to let /etc be stored in a git, mercurial, bzr or darcs repository. It hooks into APT to automatically commit changes made to /etc during package upgrades. It tracks file metadata that version control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control. Homepage: http://etckeeper.branchable.com/ automated revision control of /etc and all subdirectories. nicely integreated with apt to automatically commit changes before and after any package installs/upgrades/removals (i think it also has similar support for yum, and dnf). commits are also run nightly from cron. and, of course, you can manually commit any file with a useful commit log message whenever you want. using etckeeper and git makes it even easier to cherry-pick config file changes, and is useful for all files under /etc, not just those listed in a package as a "conffile". and the changelog and history that git (or whatever) gives you is as useful for config files as it is for programming. plus you get all the other benefits of git. a long time ago, i used to manually use subversion on most systems (and rcs before that), but having etckeeper available as a package means that revision control of my config files just happens automatically on all my systems whether i'm paying particular attention to it or not. and adding a remote in git is easy, so I can push configs to any git repo...and clone (and fork and merge and cherry-pick and diff and ...) them as needed. craig -- craig sanders <cas@taz.net.au>