Ubuntu 24.04 postfix + SASL/saslauthd Fix

(napsal GeminAI podle strucnych poznamek)

Quick Fix: saslauthd Failures in Ubuntu 24.04 LTS

Upgraded to Ubuntu 24.04 LTS and saslauthd won't start, preventing Postfix authentication? The daemon is failing because it cannot reliably create its PID file in the default location while also being configured to place the socket inside Postfix's chroot (/var/spool/postfix/...).

The solution is to use a systemd override to force saslauthd to place its PID file in the same, accessible directory as its socket, and ensure it runs with the necessary group permissions.

🛠️ The Systemd Fix

1. Open the Override Editor:

   sudo systemctl edit saslauthd.service
   

2. Add the Configuration Stanza:

   Paste this into the editor to specify the correct PID location and the required sasl group:

   [Service]
   Group=sasl
   PIDFile=/var/spool/postfix/var/run/saslauthd/saslauthd.pid
   

3. Restart Services:

   Save the file, then restart to apply the fix:

   sudo systemctl restart saslauthd
   sudo systemctl restart postfix
   

This simple configuration adjustment resolves the conflict, allowing saslauthd to start successfully and communicate with Postfix inside its chroot.

Fixing OpenDKIM Signing After Upgrading Ubuntu 18.04 LTS → 24.04 LTS

 (prispevek zformuloval GPT chatbot na zaklade mych velmi strucnych poznamek)

After a long-planned upgrade from Ubuntu 18 LTS straight to Ubuntu 24 LTS, I discovered that outgoing e-mail was no longer being signed with OpenDKIM. What followed was a small adventure involving masked services, silent failures, and a missing package. Here is the full story for anyone who runs into the same issue.

1. First symptoms: DKIM signing stopped working

Right after the upgrade, outgoing mail lost its DKIM signatures.
A look into /var/log/mail.log showed a clear clue:

postfix/smtpd[153304]: warning: connect to Milter service inet:localhost:8892: Connection refused

Port 8892, where OpenDKIM normally listens, was not responding:

# ss -tuln | grep 8892
(no output)

So the DKIM milter was simply not running.

2. Trying to start OpenDKIM — and finding it masked

My next step was obvious: check the service.

# systemctl start opendkim
Failed to start opendkim.service: Unit opendkim.service is masked.

Status confirmed it:

# systemctl status opendkim
○ opendkim.service
     Loaded: masked (Reason: Unit opendkim.service is masked.)
     Active: inactive (dead)

Why the upgrade masked the service is unclear, but unmasking is straightforward:

# systemctl unmask opendkim
# systemctl start opendkim

This time the service started—at least according to systemd.
But DKIM signatures were still missing.

3. Adding debug logging

To see what was going on, I enabled more verbose logging by adding to /etc/opendkim.conf:

SyslogSuccess           yes
LogWhy                  yes

After that:

# systemctl restart opendkim

The service looked healthy, no visible errors... but still no signs of DKIM signing.

4. The surprising discovery: OpenDKIM wasn’t installed (!?)

Running locate gave the final hint:

# locate opendkim
opendkim:

It essentially returned nothing.
At this point it became clear: the service files were present, but the actual OpenDKIM binary was not installed (a side effect of the distribution jump).

A quick explicit install solved everything:

# apt install opendkim

And — voilà — DKIM signing immediately started working again.

5. Conclusion

Upgrading directly from Ubuntu 18 → 24 can leave some services in a strange state. In my case:

• opendkim.service was masked after the upgrade

• The service files survived, but the binary package was missing

• Postfix failed to talk to the milter (Connection refused)

• Installing OpenDKIM manually restored full functionality