9

I'm new to system administration and I'm helping admin a server for a student group. I was wondering, what is the best practice for when you're upgrading packages and a config file has changes. I've been looking at the differences and then usually just leaving the old version unless it looks like there is something important to add, and otherwise merging the config files manually with kdiff3, but is there a better way to do it?

Also, do I have to backup the old file somewhere myself or does dpkg automatically make a backup? I sometimes I noticed .old files in some directories for old versions of config files.

This issue is complicated by the fact that since I'm new to this group, I don't know why some changes are the way they are, but if in doubt I've been deferring to the existing version.

By the way, I'd like some specificity. Eg, when dpkg prompts you with the whole Y/N/I/O/D/etc thing, what do you do? Do you back up the old file, install the new one, and then merge, or is there a better way to merge the files when you're in that ncurses prompt thing?

Ibrahim
  • 394
  • 5
  • 12

4 Answers4

10

that seems like a reasonable way of doing it. similar to what i've been doing for about 15 years (been using debian since 1994). it's always worked for me :)

i start with the basic assumption that if i've modified a config file, then i had a good reason for it, and my changes are likely to be better/more important than anything in the new default config file.

i then examine both my config and the new packaged version and either:

  1. completely ignore any differences because they're either not important or not relevant to my setup.

  2. merge anything useful from the new config into my existing config.

  3. if there's a lot of new stuff and only a small amount of my changes that i want to keep, then i do the reverse and merge my changes into the new config file and then use that.

i don't use any specialised or GUI tools for this. i just use 'diff -u' and less and vi plus occasionally some of the standard text processing tools like sed or perl. colordiff is nice, too, when the diff output is more than a screenful or so.

cas
  • 6,783
  • 32
  • 35
  • 1
    By the way, does dpkg automatically stick the new and old files somewhere or does it just delete the old file when you install the new one? – Ibrahim Aug 03 '09 at 10:10
  • 2
    yes, if you choose to replace your current config file, it will be renamed to filename.dpkg-old. if you choose to keep your current config file, the packaged file will be renamed to filename.dpkg-dist – cas Aug 03 '09 at 10:28
  • 1
    BTW, this renaming to .dpkg-old and .dpkg-dist is the main reason why run-parts won't, by default, run files with a . in them, otherwise it would end up doing bad things like running both the old and the new version of cron jobs in /etc/cron.*/ which would be ++ungood. – cas Aug 03 '09 at 10:41
  • Just like to ACK this answer, it's exactly what I've done for many years – LapTop006 Aug 03 '09 at 11:38
  • Another +1. This approach certainly works well for a single or small number of systems. Anything bigger and you should start looking at configuration management tools. – Kamil Kisiel Aug 06 '09 at 00:52
1

Just spotted this post looking for the answer to a similar question of mine.

What I ended up doing after all is choose to open a terminal, do a 3-way merge with meld,

meld file.conf file.conf.dpkg-old file.conf.dpkg-new

save the result to file.conf and go on with that

Nick Andrik
  • 19
  • 1
  • 1
    That's an answer to how to merge changes. The OP is asking about larger issues caused by editing configuration files that are managed by a package management system. – itsbruce Oct 24 '12 at 22:18
  • Heh, at this point I don't even know what I was asking about. Merge tools are useful of course. One thing I've found since I posted this that's quite helpful is etckeeper. At least for smaller systems I see no reason not to use it, it just puts /etc under version control (git in my case) which is pretty handy if you're confused about what changes you've made in the past. The auto commits won't tell you why you did something though. – Ibrahim Oct 25 '12 at 07:11
1

Although I agree with Craig Sanders' answer, I have to add one caveat: During many upgrades (usually between releases -- like Hardy --> Intrepid) apt reports config files as changes when I haven't changed them. If I'm confident that I haven't changed a config file, I'll just choose to dump the old one and keep the package maintainer's version.

Schof
  • 972
  • 1
  • 6
  • 10
0

Yes the best to do is, IMHO, to get the maintainer version and report in it the customized values.

This way you are ensured to have the very up to date config file, with updated comments, commented out default values and so on.

When you got a confict in the updating process because of a new config file version the best to to is to keep the best between our version and the maintainer one, keep note of the file to review and then manually edit the file to merge th differneces by hand (vimdiff is a very powerful way, but kdiff is a good choice too :)

The very important thing to keep in mind is to avoid having custom config files out of date!

My 2 cents :)

drAlberT
  • 10,949
  • 7
  • 39
  • 52
  • Hmm, I should get my vimfoo up to snuff. I've been through vimtutor and it seems fairly nice, but I've been kind of preferring emacs because of elisp and its customizability. But emacs is annoying to run over ssh and a bad connection, whereas vim is not as bad. – Ibrahim Aug 03 '09 at 10:13
  • 1
    the trouble with just accepting the maintainer version is that it is FAR more likely to break your currently working setup (because it wipes your hand-edited changes) than keeping your customised version. it's extremely rare for an upgraded package to have an incompatible new config file (and when they do, the package often has a postinst script to handle it), so keeping your config file is generally safe. in most cases, your config file will work perfectly well, as is with no extra work required....but the maintainer file will always require editing to bring back your changes. – cas Aug 03 '09 at 10:34
  • I do not told to barely accept the maintainer file, but to absolutely make every effort in order to keep our customization in sink with it!... sorry for having been not so clear – drAlberT Aug 03 '09 at 10:37