fix: fetchmail environment variables

[casperklein]

Description

Executing supervisor restart fetchmail causes:

Feb 20 17:12:45 mail fetchmail[2543]: /root/.netrc: cannot open file for reading: Permission denied

Fetchmail checks the wrong location to see if .netrc exists. That's because $HOME is set to /root. fetchmail does not have permission to access /root.

http://supervisord.org/subprocess.html#subprocess-environment

No shell is executed by supervisord when it runs a subprocess, so environment variables such as USER, PATH, HOME, SHELL, LOGNAME, etc. are not changed from their defaults or otherwise reassigned. This is particularly important to note when you are running a program from a supervisord run as root with a user= stanza in the configuration

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change that does improve existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

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
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary, I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have added information about changes made in this PR to CHANGELOG.md

[casperklein]

@georglauterbach @polarathene Not related to this PR and just cosmetic: What is your opinion about renaming target/supervisor/conf.d/supervisor-app.conf to something like DMS.conf or similar?

[georglauterbach]

@georglauterbach @polarathene Not related to this PR and just cosmetic: What is your opinion about renaming target/supervisor/conf.d/supervisor-app.conf to something like DMS.conf or similar?

Not an issue if you ask; we should classify it as breaking, though.

[polarathene]

What is your opinion about renaming target/supervisor/conf.d/supervisor-app.conf to something like DMS.conf or similar?

I don't see any value in doing so (especially as uppercase). I'd rather a motivation for it, as we do have a separate config for sasl login mechanisms too, you could probably split it into separate service groups if that makes more sense? 🤷‍♂️

[casperklein]

I think "supervisor-app" is completely generic. The "app" (all services combined) we are using is called docker-mailserver (DMS). So it makes more sense to me, to name the config accordingly.

[georglauterbach]

Having service groups is something I'd support as well. Maybe for anti-spam, then dovecot-specific, and then dms.conf for the rest?

[casperklein]

Having it all in one place, like now, is fine for me. The file isn't that big or confusing that would justify a splitting IMO.
It is really just the name supervisor-app, that triggers me for some time now 😆 If you both want to keep that name, that's fine 👍

[georglauterbach]

Nah, go ahead and change it to dms.conf, I like that one better too.

[polarathene]

The file isn't that big or confusing that would justify a splitting IMO.

I was thinking more in terms of feature isolation. I probably won't get around to it, but thought about exploring a file structure that groups scripts related to features/services together, just gets a bit messy when integration is involved. Probably not worth it.

It is really just the name supervisor-app, that triggers me for some time now 😆 If you both want to keep that name, that's fine 👍

I don't mind either way. dms-services.conf might be more appropriate than just dms.conf if you do go forward with such a change. Might be best to schedule it for v15, as v14 breaking changes is already quite a large list in changelog 😅

[casperklein]

dms-services.conf sounds perfect 👍

Might be best to schedule it for v15, as v14 breaking changes is already quite a large list in changelog

One more tiny change makes no big difference IMO. But I don't care if this is done in v14 or 15.

[georglauterbach]

I agree that this can easily go into v14.

[polarathene]

Fair enough 👍