Try systemd-analyze blame to find out which service takes long during bootup.

For me, it was systemd-networkd-wait-online.service, apparently timing out after 2 minutes. Probably it tries to bring up all network interfaces (my PC has two NICs).

So: try SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout 5 --any to see if it can quickly bring up at least one interface within 5 seconds.

Edit /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service and add the paramters above (-timeout 5 --any) to line ExecStart=/usr/lib/systemd/systemd-networkd-wait-online.

posted at: 00:42 | path: /configuration | permanent link

Postfix, when configured with multiple domains, should present a different certificate upon STARTTLS depending on the domain (via SNI).

In /etc/postfix/main.cf, there is tls_server_sni_maps which points to a hash file, e.g. hash:/etc/postfix/vmail_ssl.map with the following content (assuming Let's Encrypt certificates):

mail.domain1.com /etc/letsencrypt/live/mail.domain1.com/privkey.pem /etc/letsencrypt/live/mail.domain1.com/fullchain.pem
mail.domain2.net /etc/letsencrypt/live/mail.domain2.net/privkey.pem /etc/letsencrypt/live/mail.domain2.net/fullchain.pem

The postmap -F hash:/etc/postfix/vmail_ssl.map command has to be run on update of the certificates.

Run ssltestssl --starttls smtp mail.domain2.net:25 to checkk the setup.

posted at: 21:36 | path: /configuration | permanent link

When a name is resolved via DNS, the application, i.e. getaddrinfo(), asks for an IPv4 and IPv6 address via the local resolver. In Ubuntu, systemd's resolved is used as a stub resolver (not so on AWS Linux 2023, but that is another story).

The stub resolver is supposed to cache the query result. But why is resolvectl statistics still showing high cache miss numbers? Turning on debug log-level in resolved (resolvectl log-level debug) reveals the answer...

Turns out, Ubuntu chooses not to cache negative responses (LP: #1668771). In case the DNS A record (IPv4) is properly resolved, but not the DNS AAAA record (IPv6), the AAAA result is not cached and will be queried over and over.

On Ubuntu 26.04 (and likely earlier), this odd behavior can be changed in /usr/lib/systemd/resolved.conf.d/cache-no-negative.conf:

# Ubuntu defaults to Cache=no-negative. See LP: #1668771.

[Resolve]
#Cache=no-negative

The command systemd-analyze cat-config systemd/resolved.conf is useful to see the full resolved config (consisting of various parts).

posted at: 00:54 | path: /configuration | permanent link

See Pieter Bakker's tips for Postfix to pass internet.nl checks.

posted at: 15:57 | path: /configuration | permanent link

gmx.de uses a TLS alert (71) to claim insufficient security. After disabling TLSv1 in postfix, it works (i.e. mail is delivered). Amazing.

postfix/smtpd[3923583]: TLS SNI mail.pmeerw.net from mout.gmx.net[212.227.15.18] not matched, using default chain
postfix/smtpd[3923583]: Untrusted TLS connection established from mout.gmx.net[212.227.15.18]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (3072 bits) client-digest SHA256
postfix/smtpd[3923583]: warning: TLS library problem: error:0A00042F:SSL routines::tlsv1 alert insufficient security:../ssl/record/rec_layer_s3.c:916:SSL alert number 71:
postfix/smtpd[3923583]: NOQUEUE: lost connection after STARTTLS from mout.gmx.net[212.227.15.18]
postfix/smtpd[3923583]: disconnect from mout.gmx.net[212.227.15.18] ehlo=1 starttls=1 commands=2

posted at: 14:49 | path: /configuration | permanent link