Cambiare l'hostname su Linux in modo permanente: hostnamectl, /etc/hosts e cloud-init

Un server che si chiama debian, localhost o vm-01 funziona benissimo. Le noie iniziano quando ne hai tre in funzione contemporaneamente, quando le righe di log non si distinguono più tra loro oppure quando arriva il primo mailserver e il server remoto controlla il nome. Questa guida cambia l'hostname in modo che sopravviva al riavvio successivo, che sudo non finisca in un timeout e che lo conoscano anche i servizi che lo leggono all'avvio.

È l'approfondimento del punto 6 della checklist per un nuovo server root. Lì trovi i due comandi che nella maggior parte dei casi bastano. Qui trovi che cosa succede dietro le quinte e che cosa fare quando non bastano.

Tutte le indicazioni valgono per Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS e Ubuntu 22.04 LTS. I comandi sono scritti per l'esecuzione come root. Se lavori come utente normale, anteponi sudo a ogni comando.

Un server ha tre nomi, non uno

Il motivo più frequente di una rinomina riuscita solo a metà è che Linux non conosce un hostname soltanto, ma tre. Si trovano in posti diversi e vengono sovrascritti da soggetti diversi.

Il nome transitorio è gestito dal kernel ed è quello che ogni programma ottiene tramite gethostname(). Il nome statico è il modello da cui viene impostato all'avvio. Il nome descrittivo può contenere spazi e lettere accentate e compare solo nelle interfacce, mai in rete.

Altrettanto importante è la seconda distinzione: da dove ogni comando prende la propria risposta. Poniamo che in /etc/hostname ci sia srv01 e in /etc/hosts la riga 127.0.1.1 srv01.example.com srv01, il quadro è questo.

La riga decisiva è hostname -f. Il comando non legge /etc/hostname, ma prende il nome dal kernel e lo passa alla risoluzione dei nomi. Il nome completo arriva quindi da /etc/hosts o dal DNS, mai dal file dell'hostname. Quasi tutti i problemi descritti in questo articolo nascono da questo malinteso.

Prima della prima modifica: la via del ritorno

Una rinomina da sola non interrompe la tua sessione SSH. Pericoloso è il passo successivo, cioè la modifica di /etc/hosts. Se lì sparisce la riga di localhost, decine di programmi restano appesi in timeout, Postfix non parte più e sudo impiega secondi a ogni chiamata. Prima di iniziare, quindi, chiarisci tre punti.

1. Una seconda sessione resta aperta

Apri una seconda finestra del terminale con una connessione attiva e non chiuderla finché non hai verificato tutto. Una sessione già stabilita sopravvive a qualsiasi modifica dell'hostname e della risoluzione dei nomi. Se la connessione stessa non è ancora a posto, ti aiuta Connettersi al server via SSH.

2. La via che aggira SSH

I server root KVM e i server dedicati di KernelHost non hanno né IPMI né iDRAC. L'accesso che continua a funzionare anche quando nel sistema ospite non risponde più nulla è la console VNC nell'area clienti. Dipende dal livello di virtualizzazione o dal collegamento stesso, non dalla risoluzione dei nomi nel sistema ospite. Accedi una volta prima tramite quella console e assicurati di conoscere la password di root. Una via di fuga che si prova per la prima volta solo in emergenza non è una via di fuga.

3. Due copie e un ritorno indietro

cp -a /etc/hostname /root/hostname.bak
cp -a /etc/hosts /root/hosts.bak
hostnamectl > /root/hostnamectl-prima.txt

Così la via del ritorno sono due righe, che all'occorrenza digiti dalla console:

cp -a /root/hosts.bak /etc/hosts
hostnamectl set-hostname "$(cat /root/hostname.bak)"

Ricognizione in cinque comandi

Guarda prima di tutto che cosa vale in questo momento e chi ha voce in capitolo.

hostnamectl
cat /etc/hostname
cat /etc/hosts
grep '^hosts:' /etc/nsswitch.conf
command -v cloud-init >/dev/null && cloud-init status --long || echo "cloud-init non installato"

Vale la pena guardare con attenzione l'output di hostnamectl. Di norma inizia con Static hostname:. Se compare anche una riga Transient hostname:, il nome statico e quello in esecuzione divergono e qualcosa sta cambiando attivamente il nome: quasi sempre cloud-init o un client DHCP. È la prima cosa da disattivare, altrimenti la tua modifica sparisce di nuovo al riavvio successivo.

La riga hosts: di /etc/nsswitch.conf stabilisce l'ordine della risoluzione dei nomi. Le quattro voci che vi compaiono significano:

• files: viene letto /etc/hosts.
• dns: il resolver interroga i nameserver indicati in /etc/resolv.conf.
• resolve: la richiesta va a systemd-resolved.
• myhostname: un modulo di systemd che associa il nome della macchina agli indirizzi IP configurati localmente, anche senza una voce in /etc/hosts.

L'ultimo punto spiega, più avanti, perché su alcuni server lo stesso errore resta invisibile per anni.

Scegliere il nome: FQDN o nome breve

Sono ammessi lettere, cifre e il trattino. Niente trattino basso, niente punto all'inizio o alla fine, niente trattino all'inizio di un'etichetta. Scrivi tutto in minuscolo: il DNS confronta senza distinguere maiuscole e minuscole, molti programmi invece alla lettera. Un'etichetta (la parte tra due punti) può essere lunga 63 caratteri, il nome completo nel DNS 253. Il kernel però accetta al massimo 64 caratteri per l'hostname, quindi un FQDN molto lungo rischia di non entrarci affatto. Scegli il nome sotto un dominio che ti appartiene: .local è riservato a mDNS e le estensioni inventate come .lan possono diventare in qualsiasi momento veri top-level domain.

Resta da decidere che cosa scrivere in /etc/hostname. Entrambe le varianti funzionano, cambia solo ciò che ti viene mostrato ovunque da quel momento in poi.

Su Debian e Ubuntu conviene la prima variante: nome breve in /etc/hostname, nome completo come prima voce in /etc/hosts. Così prompt e righe di log restano brevi e l'FQDN è comunque corretto. Anche la seconda variante è pulita, purché tu la mantenga con coerenza. L'errore vero è la mescolanza: un FQDN in /etc/hostname e uno diverso in /etc/hosts.

Crea subito il record A (con IPv6 il record AAAA) per il nuovo nome. Non costa nulla, rende corretto hostname -f anche senza /etc/hosts ed è il presupposto per qualsiasi certificato su questo nome.

Addomesticare cloud-init prima di impostare qualcosa

Sulle immagini con cloud-init, e su Ubuntu sono praticamente tutte, l'hostname viene impostato all'avvio a partire dai metadati dell'istanza. Se ne occupano i moduli set_hostname e update_hostname, più update_etc_hosts per il file /etc/hosts. Tutti e tre girano presto, ancora prima che partano i tuoi servizi. A comandare tutto questo sono due impostazioni:

grep -rE '^(preserve_hostname|manage_etc_hosts)' /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d/ 2>/dev/null

Nelle immagini Ubuntu Server, in /etc/cloud/cloud.cfg compare la riga preserve_hostname: false, quindi cloud-init può toccare il nome. L'impostazione contraria non va messa in quel file, perché un aggiornamento del pacchetto lo sostituisce, ma in /etc/cloud/cloud.cfg.d/. I file lì dentro vengono letti in ordine alfabetico e vince l'ultimo, da qui il 99:

mkdir -p /etc/cloud/cloud.cfg.d
printf 'preserve_hostname: true\n' > /etc/cloud/cloud.cfg.d/99_hostname.cfg

La seconda impostazione riguarda /etc/hosts. Viene spesso ignorata, anche se fa più danni.

Se lì c'è true e ti servono voci personali, imposta il valore su localhost oppure gestisci direttamente il modello (su Debian e Ubuntu hosts.debian.tmpl). Modificare a mano un file che viene sovrascritto a ogni avvio produce proprio il tipo di errore di cui ti accorgi solo settimane dopo.

Quello che cloud-init ha impostato per ultimo se lo ricorda in /var/lib/cloud/data/. Questo stato viene cancellato da cloud-init clean. Su un server già configurato però non farlo: al riavvio successivo tutti i moduli ripartono da capo, come se la macchina fosse nuova.

Il secondo che riscrive il nome: DHCP

Se il server ottiene il proprio indirizzo via DHCP, il client può ricavare l'hostname transitorio dalla risposta (opzione 12). Il nome statico resta intatto e questo complica la diagnosi: hostnamectl --static mostra il tuo nome, hostname un altro. Con netplan lo disattivi così:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-hostname: false

Attiva con netplan try invece di netplan apply: try annulla da solo la modifica dopo 120 secondi se non confermi. Se configuri direttamente systemd-networkd, l'impostazione si chiama UseHostname=no nella sezione [DHCPv4].

Impostare l'hostname

hostnamectl set-hostname srv01

Senza altre opzioni hostnamectl imposta insieme il nome statico e quello transitorio. Ed è esattamente quello che vuoi. Con --static cambi solo /etc/hostname e, con un nome transitorio attivo, la macchina continuerebbe a girare con il vecchio nome fino al riavvio. Le versioni più recenti di systemd conoscono anche la forma breve hostnamectl hostname srv01, mentre set-hostname funziona su tutti e quattro i sistemi.

Verifica: i due nomi devono coincidere e il file deve contenere il nuovo valore.

hostnamectl --static
hostnamectl --transient
cat /etc/hostname

Due note a margine. Primo, hostname srv01 senza ctl cambia solo il nome transitorio e dopo il riavvio è sparito. Secondo, la shell che hai aperta continua a mostrare il vecchio nome nel prompt, perché bash legge l'hostname una volta sola all'inizio della sessione. Non è un fallimento, è semplicemente una sessione vecchia. Esci e accedi di nuovo.

Se vuoi, puoi impostare anche un nome descrittivo, che compare nelle interfacce e può contenere spazi:

hostnamectl set-hostname --pretty "Server web Francoforte"
cat /etc/machine-info

Scrivere /etc/hosts nel modo giusto

hostnamectl non tocca /etc/hosts. Quel file resta compito tuo ed è il motivo per cui una rinomina così spesso funziona solo a metà.

Una riga è composta da un indirizzo IP, dal nome canonico e da un numero qualsiasi di alias. Il primo nome dopo l'indirizzo è quello canonico ed è esattamente quello che restituisce hostname -f. Per questo il nome completo sta davanti e il nome breve dietro, mai il contrario.

127.0.0.1       localhost
127.0.1.1       srv01.example.com srv01

::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Perché 127.0.1.1 e non 127.0.0.1: Debian e Ubuntu separano di proposito il nome della macchina da localhost. Se appendi il nome del server come alias alla riga di localhost, il nome canonico di quella riga resta localhost e hostname -f risponde localhost. I programmi che da lì ricavano il proprio nome scrivono poi localhost nei log e nelle intestazioni delle e-mail.

Una voce mancante la aggiungi in coda, una riga esistente la modifichi:

grep -n '^127\.0\.1\.1' /etc/hosts
printf '127.0.1.1\tsrv01.example.com\tsrv01\n' >> /etc/hosts

Se il primo comando restituisce già una riga, modifica quella invece di aggiungerne una seconda. Con due righe per lo stesso indirizzo vince la prima e finiresti per cambiare una riga che non legge più nessuno.

Verifica:

getent hosts srv01
getent hosts srv01.example.com
hostname -f
hostname -s

Le due chiamate a getent devono restituire una riga ciascuna, hostname -f il nome completo e hostname -s quello breve. Se non torna nulla, la voce non è attiva, per esempio perché la riga inizia con un carattere di commento.

Resta una decisione da prendere: 127.0.1.1 oppure l'indirizzo pubblico del server. Alcuni software si legano all'indirizzo su cui si risolve il proprio nome, oppure lo iscrivono nell'elenco dei membri di un cluster. In quel caso l'FQDN va sull'indirizzo pubblico. Con un indirizzo fisso questa è la variante più pulita, con un indirizzo variabile conviene 127.0.1.1, perché funziona anche senza connessione di rete.

Perché una voce mancante rallenta sudo

sudo a ogni chiamata ricava il nome della propria macchina e lo fa risolvere. Gli serve per la riga di log e per il confronto con i nomi host indicati in /etc/sudoers.

La risoluzione segue la riga hosts: di /etc/nsswitch.conf. Se il nome è in /etc/hosts, la faccenda si chiude con un accesso al file, quindi in meno di un millisecondo. Se non c'è, la richiesta passa alla voce successiva, di regola dns, e il resolver chiede ai nameserver di /etc/resolv.conf un nome che nel DNS non esiste. I valori predefiniti di glibc sono cinque secondi di timeout e due tentativi per nameserver. Se non risponde nessuno, l'attesa si somma, e succede a ogni singola chiamata.

C'è un fattore che peggiora ancora le cose: un nome breve non contiene punti e resta quindi sotto il valore predefinito ndots:1. Per questo il resolver appende prima ogni dominio di ricerca di /etc/resolv.conf e solo dopo interroga il nome così com'è. Due domini di ricerca significano tre giri di richieste invece di uno.

Tutto questo diventa visibile in questo avviso, che precede ogni chiamata:

sudo: unable to resolve host srv01: Name or service not known

Misurare invece di stimare:

time getent hosts "$(hostname)"
time sudo -n true

Entrambi devono restare ben sotto il decimo di secondo. Tutto ciò che supera quel valore è attesa di un nameserver.

Ed ecco il motivo per cui l'errore non salta all'occhio ovunque: se nella riga hosts: compare la voce myhostname, è questo modulo a rispondere da solo alla richiesta sul nome della macchina, senza DNS e senza /etc/hosts. Lì l'avviso non compare, anche se il file è incompleto. Non appena la stessa configurazione finisce su un sistema privo di quella voce, l'errore torna a farsi vedere.

Un secondo problema, più raro, riguarda l'assegnazione dei permessi: in /etc/sudoers ogni regola può essere limitata a determinati nomi host. Le regole fornite da Debian e Ubuntu usano ALL e non sono critiche. Le regole personali con un nome host perdono invece efficacia e l'utente coinvolto non può più fare nulla. Controlla prima:

grep -rhvE '^[[:space:]]*(#|$)' /etc/sudoers /etc/sudoers.d/

Servizi che leggono il nome all'avvio

Molti programmi chiedono l'hostname una volta sola, all'avvio, e poi continuano a lavorare con il vecchio nome. Questo spiega buona parte della confusione dopo una rinomina.

• La shell aperta. Il prompt mostra il vecchio nome. Apri una nuova sessione e hai finito.
• rsyslog, dove è installato. Basta un systemctl restart rsyslog. Debian 12 e 13 nelle installazioni minime non portano con sé rsyslog, lì scrive journald.
• Le voci di log già scritte conservano il vecchio nome, ed è giusto così. Se invece il vecchio nome compare nelle voci nuove, riavvia il servizio che le scrive.
• MariaDB e MySQL ricavano dall'hostname i nomi predefiniti di file come il log degli errori e il log binario, a meno che i percorsi non siano indicati esplicitamente nella configurazione.
• Le applicazioni Java. InetAddress.getLocalHost() solleva una java.net.UnknownHostException non appena il nome della macchina non si risolve. Riguarda tanto gli application server quanto i game server.
• Gli agenti di monitoraggio riportano spesso il nome nel proprio file di configurazione. Altrimenti dopo la rinomina lo stesso server compare due volte.

systemctl list-units --type=service --state=running

Se hai comunque in programma una finestra di manutenzione, un riavvio è la soluzione più completa. Come registrare i tuoi programmi come unità in modo pulito, così che sopravvivano a un riavvio, lo trovi in Creare un servizio systemd.

Mailserver: il nome che vedono gli altri

Nell'invio della posta l'hostname non è più un dettaglio estetico. Il server remoto lo vede nell'EHLO e lo verifica. Tre elementi devono combaciare:

1. Il nome con cui si presenta il tuo mailserver (con Postfix myhostname).
2. Il record PTR del tuo indirizzo IP, cioè la risoluzione inversa.
3. Un record A (con IPv6 un record AAAA) esattamente per quel nome, che rimandi allo stesso indirizzo.

Se la catena non si chiude, molti destinatari declassano il messaggio o lo rifiutano. Verifica senza pacchetti aggiuntivi:

hostname -f
getent hosts 203.0.113.10
getent hosts srv01.example.com

Il controllo diventa più preciso con dig, dal pacchetto bind9-dnsutils:

apt install -y bind9-dnsutils
dig +short -x 203.0.113.10
dig +short srv01.example.com A

Il record PTR non appartiene al server. È legato all'indirizzo IP e viene gestito dall'operatore della rete, in KernelHost tramite l'area clienti. Nessuna chiamata a hostnamectl lo cambia, ed è esattamente qui che le rinomine dei mailserver vanno storte.

Postfix non recepisce la rinomina da solo. Su Debian e Ubuntu il pacchetto scrive durante la configurazione un valore fisso in /etc/postfix/main.cf, e accanto c'è /etc/mailname con il nome che Postfix usa come dominio mittente per la posta locale. Entrambi restano invariati:

postconf myhostname mydomain myorigin
cat /etc/mailname

Adegua i valori e riavvia, tenendo presente che /etc/mailname è una scelta a sé e non deve per forza avere lo stesso valore di myhostname:

postconf -e "myhostname = srv01.example.com"
postfix check
systemctl restart postfix

SPF, DKIM e DMARC dipendono invece dal dominio mittente e non dall'hostname. Una rinomina quindi non risolve i problemi di consegna che hanno lì la loro causa.

Certificati

Il nome di sistema non compare in nessun certificato, perché un certificato copre i nomi DNS indicati nella richiesta. Nonostante questo, una rinomina si fa sentire in tre punti.

Primo, nella richiesta. Se ottieni un certificato sul nome del server stesso, per esempio per il mailserver, il nome deve essere già nel DNS prima che l'autorità di certificazione vada a controllare. Altrimenti l'esecuzione termina con un messaggio del tipo DNS problem: NXDOMAIN looking up A for srv01.example.com. Il record A va creato prima della richiesta, non dopo.

Secondo, nei certificati esistenti. Restano intestati al vecchio nome e vengono rinnovati finché non li rimuovi:

certbot certificates
certbot delete --cert-name vecchio.example.com

Cancella solo quando nessun servizio punta più a quel percorso, altrimenti al prossimo ricaricamento il webserver non parte più.

Terzo, nel mailserver. Se Postfix si presenta con il nuovo nome ma mostra un certificato per il vecchio, i server remoti che controllano il nome in modo rigoroso falliscono. Certificato e myhostname devono puntare allo stesso nome.

Non c'è invece alcun legame tra il nome di sistema e server_name in nginx. nginx decide in base all'header Host della richiesta, non in base al nome della macchina. Se dopo una rinomina ti viene servita la pagina sbagliata, cerca nella configurazione del server, non nell'hostname. Le basi le trovi in Installare nginx su Debian e Ubuntu.

Errori frequenti e soluzioni

sudo: unable to resolve host srv01: Name or service not known
Il nome della macchina non è in /etc/hosts ed è sconosciuto al DNS. Aggiungi la riga 127.0.1.1 srv01.example.com srv01. Finché manca, ogni chiamata attende un timeout del resolver.

hostname: Name or service not known
È la risposta di hostname -f quando il nome del kernel non si risolve da nessuna parte. Stessa causa, stessa soluzione. Poi verifica con getent hosts "$(hostname)" che torni davvero qualcosa.

Could not set property: Access denied
hostnamectl è stato chiamato senza permessi di root, oppure la chiamata è avvenuta in un container che non può cambiare il nome nel kernel. Su un server tuo basta sudo. In un container non privilegiato imposti il nome nella configurazione del container, non al suo interno.

fatal: unable to use my own hostname
Arriva dal log di Postfix. Il valore di myhostname non si risolve. Aggiungi la voce in /etc/hosts, poi systemctl restart postfix.

504 5.5.2 <srv01>: Helo command rejected: need fully-qualified hostname
Il tuo mailserver si presenta con il nome breve, mentre il server remoto pretende un nome completo. Imposta myhostname sull'FQDN e riavvia Postfix.

450 4.7.1 Client host rejected: cannot find your reverse hostname
Per il tuo indirizzo IP non esiste alcun record PTR oppure punta nel vuoto. Non si risolve sul server, ma solo presso l'operatore della rete IP.

java.net.UnknownHostException: srv01
Un'applicazione Java ha provato a risolvere il proprio nome e non ci è riuscita. Di nuovo /etc/hosts. Dopo aver aggiunto la voce, l'applicazione va riavviata.

DNS problem: NXDOMAIN looking up A for srv01.example.com
Il nuovo nome nel DNS non esiste ancora. Crea il record A, aspetta la propagazione e ripeti la richiesta.

Dopo il riavvio il nome è di nuovo quello vecchio.
Controlla in quest'ordine: se preserve_hostname: true è impostato in /etc/cloud/cloud.cfg.d/, se il client DHCP non fornisce più un nome, se /etc/hostname contiene davvero il nuovo nome. Se dopo l'avvio hostnamectl mostra una riga Transient hostname:, una di queste fonti è ancora attiva.

/etc/hosts torna svuotato dopo ogni riavvio.
È impostato manage_etc_hosts: true e cloud-init rigenera il file dal modello. Passa a localhost oppure gestisci il modello.

Differenze tra le distribuzioni

Uguale su tutti e quattro i sistemi: hostnamectl non modifica mai /etc/hosts e nessuno strumento del sistema operativo crea record DNS o PTR. Questi due passaggi restano lavoro manuale.

Il controllo finale

Un comando che non dà errori non è una prova. L'unico test affidabile è il riavvio, seguito da queste cinque righe:

hostnamectl --static
hostname -f
getent hosts "$(hostname)"
time sudo -n true
grep -c '^127\.0\.1\.1' /etc/hosts

Ti aspetti: il nuovo nome breve, il nuovo nome completo, una riga da /etc/hosts, un tempo di esecuzione ben sotto il decimo di secondo ed esattamente una riga per 127.0.1.1. Solo quando tutti e cinque i risultati sono corretti la rinomina è conclusa, e solo allora puoi chiudere la seconda finestra del terminale.