Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RHEL 7 no longer supported #39

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

yakatz
Copy link

@yakatz yakatz commented Dec 5, 2023

9d582fa breaks support for RHEL 7 as RuntimeDirectory is not supported in that version of systemd.

9d582fa breaks support for RHEL 7 as `RuntimeDirectory` is not supported in that version of systemd.
@GertjanBijl
Copy link

Auch, having 143 mail servers running on RHEL7, I'm not particularly happy with this... RHEL7 is still in support until June 30 2024, and will be in extended support until June 30 2028. It feels a bit early to me to drop support now.

@yakatz
Copy link
Author

yakatz commented Dec 6, 2023

Auch, having 143 mail servers running on RHEL7, I'm not particularly happy with this... RHEL7 is still in support until June 30 2024, and will be in extended support until June 30 2028. It feels a bit early to me to drop support now.

Have you tested the most recent version of this module on RHEL7? I get warnings that the SystemD Unit file has invalid options and the /run/opendkim directory isn't created. I am not saying the module should drop RHEL7, I am pointing out that it already did effectively drop RHEL7.

@scorillo
Copy link

scorillo commented Apr 8, 2024

@yakatz You see those warnings because the author of the module is using a wrong way to override the vendor settings.
Puppet is trying to add two lines in the opendkim systemd unit file that are added in the wrong section (at the end of the file, because the line that begins with 'Restart=' is missing).

So instead of opening a PR to drop the support for RHEL 7, you should open an issue and point the author to the systemd documentation:

Overriding vendor settings

There are two methods of overriding vendor settings in unit files: copying the unit file from /usr/lib/systemd/system to /etc/systemd/system and modifying the chosen settings. Alternatively, one can create a directory named unit.d/ within /etc/systemd/system and place a drop-in file name.conf there that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename.

I would go with the second method: a drop-in file for the [Service] section containing those two lines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants