So far I have just ignore bots visiting my resources, no more. There is just no limit, in particular for rather expensive script-generated content. So...

RewriteCond %{HTTP_USER_AGENT}  ^.*(GPTBot|Amazonbot|ClaudeBot|bingbot|meta-externalagent|PetalBot|DotBot|GoogleBot|SemrushBot|Sogou|AhrefsBot|YandexBot|applebot).*$ [NC]
RewriteRule .* - [R=410,L]

posted at: 22:34 | path: /rant | permanent link

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