I am experiencing problems with the opendkim-2.10.3-r13 ebuild at present when attempting to use a socket, and with openrc. By taking a working config and simply changing: Socket inet:8891@localhost to Socket local:/run/opendkim/opendkim.sock Then OpenDKIM fails to start. Logs show: May 3 10:10:13 lightning opendkim[5453]: OpenDKIM Filter: Unable to bind to port local:/run/opendkim/opendkim.sock: No such file or directory May 3 10:10:13 lightning opendkim[5453]: OpenDKIM Filter: Unable to create listening socket on conn local:/run/opendkim/opendkim.sock May 3 10:10:13 lightning opendkim[5453]: smfi_opensocket() failed It looks like there is no mechanism currently in the init file to create the /run/opendkim/ directory, so the socket creation fails. If I manually create this directory and then launch opendkim, it starts up normally. The pid file for opendkim is also put directly in /run - it would also make sense to put this in /run/opendkim/ as well. Unrelated to the startup problem, the reference to the use of sockets in the opendkim.conf file isn't expanded properly: -------- # To use a local socket instead, specify a path here. The "standard" # location is under @runstatedir@/opendkim, and it's best to agree # on that directory so that various init systems can configure its --------- Presumably that should be expanded to /run/opendkim .
Reuben, just to make sure I understand you correctly: Did you follow our description in https://wiki.gentoo.org/wiki/OpenDKIM or did you only change the "Socket" entry without paying any attention to groups etc.?
Also, is "opentmpfiles-setup" launched at "boot" runlevel?
Yes - followed the instructions at that link: lightning # cat /etc/group | grep dkim opendkim:x:108:postfix,opendkim dkimsocket:x:1005:postfix lightning /etc/opendkim # cat /etc/passwd | grep dkim opendkim:x:108:1005:added by portage for opendkim:/dev/null:/sbin/nologin The opentmpfiles-setup was not being started in the boot runlevel. I've just now added that to the boot runlevel and restarted, and I can see the directory is now being created: lightning /run # ls -la opendkim total 0 drwxr-xr-x 2 opendkim opendkim 40 May 4 00:29 . drwxr-xr-x 14 root root 580 May 4 00:29 .. lightning /run # But still the error remains: May 4 00:29:16 lightning opendkim[4078]: OpenDKIM Filter: Unable to bind to port local:/run/opendkim/opendkim.sock: No such file or directory May 4 00:29:16 lightning opendkim[4078]: OpenDKIM Filter: Unable to create listening socket on conn local:/run/opendkim/opendkim.sock May 4 00:29:16 lightning opendkim[4078]: smfi_opensocket() failed My opendkim config is this: AlwaysAddARHeader yes Canonicalization relaxed DomainKeysCompat yes InternalHosts /etc/opendkim/InternalHosts KeyTable /etc/opendkim/KeyTable PeerList /etc/opendkim/PeerList PidFile /run/opendkim/opendkim.pid SigningTable refile:/etc/opendkim/SigningTable Socket local:/run/opendkim/opendkim.sock SoftwareHeader yes Syslog Yes SyslogSuccess Yes UMask 0117 UserID opendkim
Glad to hear that /run/opendkim is now being created. It should have happened in the ebuild's pkg_postinst step as well by the way, and in my tests it is reliably created then. > lightning # cat /etc/group | grep dkim > opendkim:x:108:postfix,opendkim > dkimsocket:x:1005:postfix That means opendkim is not a member of group dkimsocket. Please try something along these lines: $ grep dkim /etc/passwd /etc/group /etc/passwd:opendkim:x:119:119::/dev/null:/sbin/nologin /etc/group:opendkim:x:119: /etc/group:dkimsocket:x:978:opendkim,postfix > PidFile /run/opendkim/opendkim.pid https://github.com/OpenRC/openrc/blob/master/service-script-guide.md (the section about PID files) explains why this is a security risk. Leave this as /run/opendkim.pid.
> Unrelated to the startup problem, the reference to the use of sockets in the opendkim.conf file isn't expanded properly: Thanks, I changed the RUNSTATEDIR variable to uppercase and missed it in one location. It's fixed in our upstream pull request, and I'll regenerate the patch in Gentoo the next time we make a revision (maybe to fix your berkely DB issue). > The opentmpfiles-setup was not being started in the boot runlevel. I've just now added that to the boot runlevel and restarted, and I can see the directory is now being created: You're the second person who's had this problem... I'm CCing the opentmpfiles maintainers. The current Gentoo stage3 tarball has that service in the boot runlevel, and opentmpfiles' pkg_postinst() phase should be adding them for you if they don't exist (at least during an upgrade). So, I'm not sure why you didn't have it there already. But if this problem is going to bother other users, I'd like to know about it ASAP. Newer versions of opentmpfiles only add the service to your boot runlevel during a new installation (i.e. not during an upgrade). I guess it's possible that some older stage3 was missing them, and that they were never added because every reinstallation of opentmpfiles was an upgrade? I'd just like to know.
(In reply to Michael Orlitzky from comment #5) > > The opentmpfiles-setup was not being started in the boot runlevel. I've just now added that to the boot runlevel and restarted, and I can see the directory is now being created: > > You're the second person who's had this problem... I'm CCing the > opentmpfiles maintainers. The current Gentoo stage3 tarball has that service > in the boot runlevel, and opentmpfiles' pkg_postinst() phase should be > adding them for you if they don't exist (at least during an upgrade). So, > I'm not sure why you didn't have it there already. But if this problem is > going to bother other users, I'd like to know about it ASAP. > > Newer versions of opentmpfiles only add the service to your boot runlevel > during a new installation (i.e. not during an upgrade). I guess it's > possible that some older stage3 was missing them, and that they were never > added because every reinstallation of opentmpfiles was an upgrade? I'd just > like to know. This system was built on June 15 2018 - I would have built it from a stage3 snapshot of around that time. I've checked my other systems and this was the only one that didn't have that service set to run on boot. Curiously it is also missing opentmpfiles-dev on sysinit too but all other services look to be ok. I guess that's all really outside of the opendkim package though.
(In reply to Ralph Seichter from comment #4) > Glad to hear that /run/opendkim is now being created. It should have > happened in the ebuild's pkg_postinst step as well by the way, and in my > tests it is reliably created then. > > > lightning # cat /etc/group | grep dkim > > opendkim:x:108:postfix,opendkim > > dkimsocket:x:1005:postfix > That means opendkim is not a member of group dkimsocket. Please try > something along these lines: > > $ grep dkim /etc/passwd /etc/group > /etc/passwd:opendkim:x:119:119::/dev/null:/sbin/nologin > /etc/group:opendkim:x:119: > /etc/group:dkimsocket:x:978:opendkim,postfix Ok I've done that now, but that does seem to differ from what is documented at https://wiki.gentoo.org/wiki/OpenDKIM in the example, where the primary group of the opendkim user is switched to dkimsocket, rather than left as opendkim. Still no go though: lightning /run # ls -la opendkim total 0 drwxr-xr-x 2 opendkim opendkim 40 May 4 09:32 . drwxr-xr-x 14 root root 580 May 4 09:32 .. lightning /run # May 4 09:33:28 lightning postfix/cleanup[4317]: warning: connect to Milter service unix:/run/opendkim/opendkim.sock: No such file or directory > > PidFile /run/opendkim/opendkim.pid > https://github.com/OpenRC/openrc/blob/master/service-script-guide.md (the > section about PID files) explains why this is a security risk. Leave this as > /run/opendkim.pid. Ah. Yes, interesting read. Point taken.
I'm sorry Reuben, but I cannot reproduce the issue here. Sockets are created during my tests as I expect them to be. I am not sure what to suggest that might help you.
I've now gotten this working. I had one system which worked and another which did not. After comparing both and matching up all the settings everything worked, even after a reboot. It seems one of the last problems with the system that was not working was a missing UserID statement (most likely cropped off the very bottom of the config file at some stage, as it was originally there). This seems to be a fatal misconfiguration - perhaps we should warn on this on init if it is not defined. The other problems were to do with opentmpfiles-dev and opentmpfiles-setup not being set to start at all, or in the right runlevels. This meant that /run/opendkim was not created in /run on boot prior to opendkim even starting, which is also rather fatal. Identifying those two problems earlier and explicitly would have saved me a fair bit of time and may save others. But overall I'm OK for this bug ID to be closed off now as I have no outstanding issues.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=23d19d3e32cb1033301470afbbb80d89e9139a20 commit 23d19d3e32cb1033301470afbbb80d89e9139a20 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2019-05-06 15:33:31 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2019-05-06 15:45:42 +0000 mail-filter/opendkim: fix @runstatedir@ -> @RUNSTATEDIR@ in a patch. Bug: https://bugs.gentoo.org/684956 Package-Manager: Portage-2.3.62, Repoman-2.3.11 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> mail-filter/opendkim/files/opendkim-2.10.3-openrc.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I was hoping someone would chime in with an explanation for the opentmpfiles-setup runlevel thing, but if not, we'll just have to keep an eye out for it. I did fix the @runstatedir@ thing. As for the missing UserID statement: that's a valid configuration, so we can't warn about it. The upstream configuration file ships without it and we append "UserID opendkim" ourselves in Gentoo. When it's not present, that just means that you want the daemon to run as root, ill-advised as that is.
