Description

This is an interim fix for DMS v15 until a proper fix can more confidently be implemented.

Changes:

• Migrates what was originally contributed in Oct 2019 to setup-stack.sh for container restart support.
• Ensures permissions of /var/log/mail/ and it's contents are corrected if a volume mount differs.

History for these changes is messy (as documented in the "proper fix" link), but looks like it shouldn't really be necessary going forward (new permissions fix may be relevant to avoid the logrotate failure scenario).

Workaround for volume mounts that are too relaxed

In the kubernetes helm project, a user reports their /var/log/mail mount with 777 permissions which appears to impact logrotate service as a result:

/etc/cron.daily/logrotate:
error: skipping "/var/log/mail/mail.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail/rspamd.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
run-parts: /etc/cron.daily/logrotate exited with return code 1

According to that linked discussion, correcting that mount permissions for a specific mount in the Helm chart is problematic? 🤷‍♂️

Chance of regression low

In addition these are runtime corrections intended for volume mounts, thus is intended as part of the DMS v15 improved restart support.

Prior to this PR these changes would have occurred much earlier during startup:

There is a slight chance that shifting the changes to apply at the end of _setup() introduces a regression, but it should be unlikely:

Restart support calls same two methods + (rsyslog daemon starts with /var/log/mail/mail.log):

DMS v15 is to release with the two separate call sites shown above as no maintainer presently has the time to investigate test failures introduced when moving methods those into a unified location.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• [?] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• New and existing unit tests pass locally with my changes
• I have added information about changes made in this PR to CHANGELOG.md