How can I properly override logrotate policies?
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
- add a new log configuration file in
mail.*to a new log file, e.g.
/var/log/ourmail.log(assuming you’re using
rsyslog— change as appropriate);
/var/log/ourmail.login a new
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.
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:
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.
dkpg-divert is one of the functionalities that shows the true flexibility of the Debian package manager compared to other Linux distributions.
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.
/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:
... existing directives ...
Then create your override file, containing nothing more than your override directives:
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.