How can I revert a config file back to the originally installed version after I have edited it?

I want to revert a file in /etc/ back to its originally-installed form. I have edited the file since it was installed. How can I revert this config file? Apt is smart enough not to overwrite edited config files, so how do I tell it that I want it to do so?

For argument's sake, let's say that I want to revert the file /etc/foo.conf from the package foo.

Solution 1:

The answer provided by Ryan Thomson was heading to the right way. Still it would not be able to do the job (The details reason is given below).

The correct (and easiest) way of doing so is using -o with apt to pass dpkg option and force dpkg to ask you whether you want to retain the modified config files or the original ones. The command will be like this -

sudo apt-get --reinstall -o Dpkg::Options::="--force-confask" install foo

This would ask you a question like

Configuration file '/etc/foo/foo.conf'
 ==> Modified (by you or by a script) since installation.
     Version in package is the same as at last installation.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** foo.conf (Y/I/N/O/D/Z) [default=N] ? 

You have to press either Y or I to install package maintainer's original config file. You can even press D to see what the changes or start a root shell with Z option to fix yourself.

Note: After the replacement, you'll find your modified file as at /etc/foo/foo.conf.dpkg-old

Why other options would not work?

Because the other options in dpkg doesn't work well. The options which deals with a package's config files are

• --force-confmiss
• --force-confnew
• --force-confold
• --force-confdef

--force-confmiss would not work when package version doesn't change. From man-page

If a conffile has been modified and the version in the package did change, always install the new version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred.

--force-confmiss works with missing conffiles. It too will fail when version didn't change. Quoting man-page

confmiss: If a conffile is missing and the version in the package did change, always install the missing conffile without prompting. This is dangerous, since it means not preserving a change (removing) made to the file

--force-confold will retain modified version only if the version is changed. For same package, it too will fail. Quoting man-page

confold: If a conffile has been modified and the version in the package did change, always keep the old version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred.

--force-confdef will also fail because the default action is to retain older file (Indicated from the message shown with --force-confask. It has line (Y/I/N/O/D/Z) [default=N] which means retaining is default. See above). And if --force-confnew is specified but version do not change, that too will not work. Quoting man-page

confdef: If a conffile has been modified and the version in the package did change, always choose the default action without prompting. If there is no default action it will stop to ask the user unless --force-confnew or --force-confold is also been given, in which case it will use that to decide the final action.

Only --force-confask will work, because it will explicitly ask you the question even when the version is same. Quoting man-page

confask: If a conffile has been modified always offer to replace it with the version in the package, even if the version in the package did not change (since dpkg 1.15.8). If any of --force-confmiss, --force-confnew, --force-confold, or --force-confdef is also given, it will be used to decide the final action.

Hope that will help.

Solution 2:

If the harm is already done, here's a command line way of getting back the official version of the configuration file. First, download the package file (either with apt-get --download-only as below, or from the package page on packages.ubuntu.com), then extract its contents in a temporary location. You can then copy the file into /etc. Make sure to respect the original permissions (most files in /etc are owned by root and mode 644 (i.e. word-readable and root-writable), but each exception is there for an important reason).

sudo apt-get --download-only --reinstall install foo
mkdir /tmp/foo
dpkg-deb -x /var/cache/apt/archives/foo_VERSION_ARCH.deb /tmp/foo

Note that this doesn't apply to the configuration files that are not from a package, such as /etc/fstab or /etc/passwd. If you lose these, you're on your own. (Most are very system-dependent anyway.)

For the future, I recommend using etckeeper . Install the package and run sudo etckeeper init. This sets up version control for all files in /etc. You don't need to do anything else to manage etckeeper; you only need to interact with it when you want to do a version control operation, such as referring to older files. Files are automatically committed before and after each run of apt and every night (this is configurable).

By default, on Ubuntu, etckeeper uses Bazaar. Change the setting in /etc/etckeeper/etckeeper.conf before running etckeeper init if you prefer Darcs, Git or Mercury.

With Bazaar, to revert /etc/foo.conf to the last committed version:

cd /etc
sudo bzr revert foo.conf

If you want to go back further in time, use sudo bzr log foo.conf to view the history of the file, and sudo bzr revert -r 42 foo.conf if you've determined that revno: 42 is the revision you want to revert to.

Solution 3:

You could download the package manually from packages.ubuntu.com, extract the file and replace your version with it.

Or you could:

sudo rm /etc/foo.conf # just for good measure
sudo apt-get --purge --reinstall install foo

The second feels a lot more brutish. It might wipe other config out too if it uses more than one file. The first is more clicking and effort but it seems much safer.

For the second, you might be able to just delete the file and --reinstall might replace it. If so, that would be safer.