majorlinux/majorwiki
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'code/majorair/wiki-stale-hostname-config-variant'

Browse source
This commit is contained in:
Marcus Summers 2026-06-14 04:00:25 -04:00
commit e5d1e39af9
1 changed files with 43 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
05-troubleshooting/logwatch-wrong-hostname-after-migration.md
View file

@ -2,10 +2,10 @@
title: "Logwatch Reports the Wrong Hostname (`<host>-hetzner`) After a Migration"
domain: troubleshooting
category: monitoring
tags: [logwatch, hostname, hetzner, migration, monitoring, provisioning]
tags: [logwatch, hostname, hetzner, migration, monitoring, provisioning, fail2ban]
status: published
created: 2026-06-12
updated: 2026-06-12
updated: 2026-06-14
---
# Logwatch Reports the Wrong Hostname (`<host>-hetzner`) After a Migration
@ -87,8 +87,47 @@ done
```
Any value ending in `-hetzner` (or your provider's build label) needs the fix above.
In the 2026-06 sweep, `tttpod` and `dcaprod` were still `*-hetzner`;
`majortoot`, `majormail`, and `majorlinux` were already correct.
In the 2026-06 sweep, `tttpod` and `dcaprod` were still `*-hetzner` at the OS
level; `majortoot`, `majormail`, and `majorlinux` had the correct system hostname
— but see the variant below: `majormail`'s *configs* were still stale even though
its hostname wasn't.
## Variant: hostname is correct, but a config has the old name baked in
A second, sneakier form of this drift: the **system hostname is already right**, so
the sweep above passes and the Logwatch report *title* is correct — yet mail still
arrives **from** `<host>-hetzner` because the old label is hardcoded in a service's
`From`/`sender` field. These fields are static text, not derived from the live
hostname, so fixing `hostnamectl` does nothing for them.
Seen on `majormail` (2026-06-14): system hostname was `majormail`, but
`Logwatch@majormail-hetzner...` was still the sender. Two configs held it:
```bash
# sweep a box for the old provisioning label in any send-related config
ssh root@<host> 'grep -rsn "<host>-hetzner" /etc/logwatch/ /etc/fail2ban/ \
/etc/postfix/ /etc/aliases /etc/mailname 2>/dev/null'
# /etc/logwatch/conf/logwatch.conf:MailFrom = Logwatch@<host>-hetzner.majorshouse.com
# /etc/fail2ban/jail.local:sender = fail2ban@<host>-hetzner.majorshouse.com
```
Fix in place (no restart needed for Logwatch; reload fail2ban for its change):
```bash
ssh root@<host> '
sed -i "s/<host>-hetzner/<host>/g" /etc/logwatch/conf/logwatch.conf /etc/fail2ban/jail.local
systemctl reload fail2ban
'
```
> [!warning] Check the Ansible source, or it comes back
> A live `sed` is undone by the next playbook run if the repo still carries the old
> value. Distinguish two cases:
> - **Templated** (safe): e.g. `logwatch.yml` sets `MailFrom = Logwatch@{{ inventory_hostname }}...`. If the inventory host is named correctly, a run *regenerates* the right value — it even self-heals a stale box.
> - **Static file** (will regress): e.g. `roles/fail2ban/files/hosts/<host>/jail.local` with the literal `sender = ...@<host>-hetzner...`. Grep the repo (`grep -rn "<host>-hetzner" .`) and fix the file too, or every deploy re-pushes the stale sender.
Inert backups (`jail.local.bak*`, `*~`) may still contain the old string — they
don't send mail, so leave them.
## Prevention