severity 861169 important retitle 861169 systemd service overrides opendkim.conf socket at start thanks
The previous report mentioned by the bug submitter is #853769. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769) >From that bug report, message #38 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769#38) says: Using the existing service file I confirmed that changes in /etc/opendkim.conf do affect the configuration of the running service after it is restarted. There's no change needed. Apparently, this not correct when the service is started, or at least in the specific way the submitter used to configure opendkim. Still, the behavior described in this new bug report is exactly how the sysvinit script behaves (according to #853769), which means the local admin is supposed to *override* this in the initscript. While this is NOT nearly as userfriendly as one might like, the *same* logic may be applied to systemd support if no better fix is possible at this time. IMHO, if a better choice is not available (e.g. due to security concerns or complexity of the required fix to avoid regressing any already-installed systems that depended on the initscript/systemd unit forced unix socket path), this could be properly documented in NEWS.debian/README.debian and also in the default /etc/ config file (and maybe as comments in the systemd unit and also the sysvinit initscript -- being through in these things pays off). I am downgrading this bug to important (which does *NOT* mean it should not be fixed, and if the fix is actually going to be just documentation, IMO that fix should be uploaded ASAP since it has zero regression risk and should be present in the next Debian stable if possible). Reasons for the severity downgrade: 1. It does *NOT* render the package unusable to the majority of its users, and it only affects more complex setups that would never work out-of-the-box without local configuration being done. 2. AFAIK, it matches previous behavior of Debian stable, and also when using initscripts instead of systemd. 3. It is not a regression in itself, and it doesn't cause regressions when the package is updated, as far as I can tell. 4. The issue it causes is going to be detected when the local admin is first configuring opendkim, and it is easy to work around (by editing the sysvinit script -- which is a conffile -- or by dropping an override for the systemd unit in the appropriate place under /etc). Bugs #853769 and #861169 are available as temporary documentation for the issue and provide hints to the required configuration change for the workaround. 5. The "grave" severity is very troublesome for every package depending on opendkim, and risks kicking all those packages out of the next Debian stable. -- Henrique Holschuh
