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(a)taz.net.au>