How can I properly override logrotate policies?

Question

Various Debian packages, including logrotate and rsyslog, put their own log rotation definitions in /etc/logrotate.d/

What is the correct way to override those definitions?

If I modify the files, I get warnings at every system update and I risk losing the changes if I (or someone else) give the wrong answer; or risk not getting new upstream definitions for new log files if I (or someone else) fail to merge the files by hand. Both things have happened regularly in the past few years.

I tried overriding the definition in 00_* or zz_* files, but I get a duplicate error:

error: zz_mail:1 duplicate log entry for /var/log/mail.log
error: found error in /var/log/mail.log , skipping

Is there any clean solution? Should I write a cron script to re-apply my changes to the definition files every day?

---

Edit: to be more clear, ideally I would like to keep 99% of rsyslog's log rotation definitions in place, and automatically updated with APT. Except for a single definition, that of /var/log/mail.log, for which I need to apply a different rotation policy.

If Logrotate allowed duplicate definitions, and only used the first or the last one for each file, my problem would be solved. If it had an override option, to flag a definition as overriding a previous one on purpose, that would also solve it.

But alas, it seems I need to override the entire /etc/logrotate.d/rsyslog (and nginx, and others) with my own versions.

Answer 1

First of all, I recommend using a tool such as etckeeper to keep track of changes to files in /etc; that avoids data loss during upgrades (among other benefits).

The “correct” way to override the definitions is to edit the configuration files directly; that’s why dpkg knows how to handle configuration files and prompts you when upgrades introduce changes. Unfortunately that’s not ideal, as you discovered.

To actually address your specific configuration issue, in a Debian-friendly way, I would suggest actually logging your mail messages to a different log file, and setting that up in logrotate:

• add a new log configuration file in /etc/rsyslog.d, directing mail.* to a new log file, e.g. /var/log/ourmail.log (assuming you’re using rsyslog — change as appropriate);
• configure /var/log/ourmail.log in a new logrotate configuration file.

Since this only involves adding new configuration files, there’s no upgrade issue. The existing log files will still be generated and rotated using the default configuration, but your log files will follow your configuration.

Answer 2

In Debian, one way to keep copies of configuration/binaries different from the intended by the defaults of the distribution, is "diverting" the file. e.g. telling the package manager when installing/updating to new versions of any deb package, to install a particular file to another directory out of way.

I have been using the dpkg-divert functionality to keep an init.d sys V wrapper for BIND and ISC-DHCP for years, that checks the DNS and DHCP configuration files for consistency, and automatically increases the serial number of changed files zones when restarting the service in BIND.

I also use it in my nfsen server to keep a version of a binary compiled for me, instead of the version of the deb package.

In that way, you can modify the original location to your heart´s content.

I manage too many systems for my liking, so to speak, and to change standard places of file system configurations - so hence using this functionality in some more esoteric configuration where I do not want the modification squashed but still want to benefit from the upgrades.

You might even already have file divertions in place used by Debian by default, just use the following command to list them:

dpkg-divert --list

From man dpkg-divert

EXAMPLES

   To  divert  all  copies  of  a /usr/bin/example to /usr/bin/example.foo, i.e.
   directs  all  packages  providing   /usr/bin/example   to   install   it   as
   /usr/bin/example.foo, performing the rename if required:

   dpkg-divert --divert /usr/bin/example.foo --rename /usr/bin/example

   To remove that diversion:

   dpkg-divert --rename --remove /usr/bin/example

   To    divert    any   package   trying   to   install   /usr/bin/example   to
   /usr/bin/example.foo, except your own wibble package:

   dpkg-divert   --package   wibble   --divert   /usr/bin/example.foo   --rename
          /usr/bin/example

   To remove that diversion:

   dpkg-divert --package wibble --rename --remove /usr/bin/example

See also from the Debian-Administration.org site Replacing binaries with dpkg-divert

Obviously, that whilst the directive is quite useful, I do not recommend abusing it too much.

As for @Stephen Kitt addressing possible problems with configuration files, what happens is that the upgrades will touch the diverted file, and if the configuration has significant changes, for instance, the odds are greater that upgrading to a new Debian version, the daemon won't boot, and that situation has to be addressed manually. Also, to be entirely fair, that can also happen even without having the configuration file diverted.

IMO dkpg-divert is one of the functionalities that shows the true flexibility of the Debian package manager compared to other Linux distributions.

Answer 3

As Stephen said, you have to edit the configuration files directly, but it doesn't mean that you have to put your custom directives there.

Edit /etc/logrotate.d/rsyslog adding at the end of the existing directives, just one line which includes a separate file containing your own override directives:

/var/log/syslog
{
        ... existing directives ...

        include /etc/logrotate.d/override/rsyslog
}

Then create your override file, containing nothing more than your override directives:

/etc/logrotate.d/override/rsyslog

weekly
rotate 0

You still have to pay attention during the system upgrade, but it's really simple to patch back again the default configuration provided by the packages: It's just one line to add.

For me it's an acceptable compromise, since at least it saves me from merging manually the differences on each system upgrade, while keeping my system standards compliant, clear and understandable.

Answer 4

Lets back up a moment and think about the changed configuration file warning. Why do you get it and what does it mean? Is it a good thing?

Debian in most cases ships default configuration files that mostly do what is wanted. there are two ways they can change, the administrator or the packager changes them. Either is normal and expected, but if both what is the correct thing to do? Ideally both would make the same change and could be merged, but even this is hard to do and I have never seen it happen. In most cases you want to note the changes the packager made and accept and merge them or reject them on a line by line basis. To date there has been only one way to do this in a limited fashion, and that is a directory of configuration fragments which allows addition of additional in a easy way, but not changes or removals, and is still not as useful as could be desired in the case of significant changes, so embrace the warning, head it and take a moment to compare the changes so you can do the right thing.

That said in your specific case (since it is a minor change) I would disable the offending fragment (either by revoking all read permissions, diverting it or renaming) and create a new fragment with a different name. I also recommend using etckeeper as backups are a good thing.