1 03/11/2026 9 min

Cambiare l’hostname su Linux sembra una modifica banale, ma in produzione conviene farla con metodo: prima capisci quale nome è davvero in uso dal sistema, poi scegli il percorso più adatto al tuo stack, infine verifichi che il cambiamento resti persistente dopo un riavvio. Su molte distribuzioni moderne il punto di riferimento è hostnamectl, ma non è l’unico approccio disponibile: esistono ancora i file di configurazione classici, le correzioni temporanee e i casi in cui serve allineare anche /etc/hosts.

In pratica, i “4 modi” utili da conoscere sono questi: modifica temporanea con hostname, modifica persistente con hostnamectl, modifica manuale dei file di sistema, e configurazione tramite strumenti della distribuzione o del cloud-init. Non hanno tutti lo stesso impatto, e soprattutto non sempre agiscono sullo stesso livello: il nome mostrato dal prompt, quello restituito dal kernel, quello usato da systemd e quello risolto localmente possono divergere se il sistema è stato configurato male.

Prima di cambiare hostname: cosa stai davvero modificando

L’hostname è il nome con cui la macchina si presenta localmente e, in molti casi, sulla rete. Su Linux moderno conviene distinguere tre elementi:

  • Static hostname: il nome persistente memorizzato dal sistema.
  • Transient hostname: il nome temporaneo assegnato in sessione, spesso via DHCP o manualmente.
  • Pretty hostname: una variante “umana”, usata da alcuni ambienti desktop o strumenti grafici.

Se stai amministrando un server, nella maggior parte dei casi ti interessa lo static hostname. È quello che vuoi vedere dopo il reboot, nei log, nel prompt e nelle integrazioni con servizi come monitoraggio, SMTP, backup o cluster. Se modifichi solo il nome temporaneo, al riavvio torni al valore precedente.

Per capire lo stato attuale, il controllo minimo è questo:

hostnamectl status
hostname
cat /etc/hostname

Se i tre output non coincidono, non sei davanti a un errore raro: stai vedendo una configurazione incoerente. Prima di cambiare nome, conviene sistemare la fonte autorevole e capire se il sistema usa systemd.

Metodo 1: hostnamectl, la strada più pulita sui sistemi moderni

Su distribuzioni con systemd, hostnamectl è in genere il metodo corretto perché aggiorna il nome persistente in modo consistente. È la scelta migliore su server recenti, VPS e VM standard, soprattutto se vuoi evitare incongruenze tra runtime e configurazione salvata.

Per impostare un nuovo hostname statico:

sudo hostnamectl set-hostname nuovo-hostname

Verifica immediata:

hostnamectl status
hostname

Se tutto è andato bene, vedrai il nuovo nome sia nello stato statico sia nell’output di hostname. In molte distribuzioni non serve neppure riavviare: il cambiamento è attivo subito per la sessione in corso.

Quando usare questo metodo: quasi sempre, se il sistema è recente e non hai vincoli particolari. È il più semplice da auditare, il più facile da documentare e quello con meno probabilità di lasciare residui in giro.

Attenzione però a un dettaglio spesso trascurato: se il server risolve il proprio nome tramite /etc/hosts, conviene aggiornare anche quello. Altrimenti il sistema può continuare a mappare il vecchio nome sull’IP locale, con effetti strani su mail, servizi di monitoraggio e alcune applicazioni che si affidano al nome locale per identificarsi.

Metodo 2: hostname temporaneo, utile solo per test rapidi

Se vuoi provare un nome diverso senza toccare la configurazione persistente, puoi cambiare l’hostname in modo temporaneo. Questo è utile in troubleshooting, in una sessione di laboratorio o quando vuoi verificare l’impatto di un nome diverso prima di formalizzare il cambio.

Comando tipico:

sudo hostname nuovo-hostname

Verifica:

hostname

Il punto chiave è che non persiste al reboot. Dopo un riavvio, il sistema tornerà al nome definito nella configurazione permanente o a quello ricevuto da servizi esterni. Per questo non è il metodo giusto per un cambio reale di produzione, ma è perfetto per testare rapidamente se un’applicazione, un prompt o un controllo di inventario reagisce male a un hostname nuovo.

Se stai lavorando su un server esposto a utenti o servizi critici, considera questo metodo come una prova reversibile: non tocca file, non altera la configurazione persistente, non richiede rollback complessi. Il “rollback” è semplicemente reimpostare il nome precedente con lo stesso comando.

Metodo 3: modifica manuale di /etc/hostname e /etc/hosts

Questo è il metodo classico, ancora utile quando non hai hostnamectl, quando lavori su sistemi minimali o quando vuoi controllare tutto a mano. È anche il percorso che ti serve conoscere se stai gestendo container, ambienti molto ridotti o installazioni vecchie dove systemd non è presente o non è il punto di controllo principale.

Il file da aggiornare per il nome persistente è /etc/hostname. In genere contiene una sola riga con il nome scelto:

nuovo-hostname

Per farlo in sicurezza, conviene prima salvare una copia del file:

sudo cp /etc/hostname /etc/hostname.bak
sudoedit /etc/hostname

Dopo la modifica, controlla il contenuto:

cat /etc/hostname

Su molte macchine va aggiornato anche /etc/hosts. Una configurazione tipica associa il nuovo hostname all’IP locale o a 127.0.1.1, a seconda della distribuzione e delle abitudini locali. Esempio:

127.0.0.1 localhost
127.0.1.1 nuovo-hostname

Non esiste una regola unica valida per ogni distro, ma il principio è semplice: il nome locale deve risolversi in modo coerente, soprattutto se il sistema usa il proprio hostname per servizi di posta, backup, log shipping o agent di monitoraggio.

Per applicare il cambiamento senza reboot, puoi allineare la sessione corrente con:

sudo hostname nuovo-hostname

Questa combinazione ha un buon compromesso tra controllo e reversibilità: i file restano modificati in modo persistente, ma se qualcosa non torna puoi ripristinare i backup e riportare la sessione al nome precedente senza toccare altro.

Metodo 4: strumenti della distribuzione, cloud-init e configurazioni automatizzate

In ambienti gestiti, il nome della macchina può essere imposto da strumenti di provisioning, template cloud o configurazioni centralizzate. È il caso di immagini cloud, ambienti IaC, VM create da template e server che ricevono il nome al bootstrap. Qui il problema non è solo “come cambio l’hostname”, ma “chi lo riscrive al prossimo avvio”.

Su cloud-init, per esempio, il nome può essere definito dal profilo di inizializzazione o dal metadata service del provider. Se modifichi a mano il sistema senza aggiornare la sorgente di verità, il nome potrebbe tornare indietro al riavvio o al reprovisioning. In questi casi la verifica non si limita al sistema operativo: devi controllare anche il layer di provisioning.

La diagnosi pratica è questa: se dopo un reboot il nome torna quello vecchio, il problema non è il comando usato, ma il meccanismo che lo sovrascrive. Cerca quindi nelle configurazioni di cloud-init, nei file del template, nel pannello del provider o nel sistema di automazione che crea la macchina.

Per capire se cloud-init sta gestendo il nome, i controlli utili sono:

cloud-init status --long
cloud-init query hostname

Se il comando non esiste, il sistema probabilmente non usa cloud-init oppure non è installato. In quel caso la verifica si sposta sul pannello del provider o sugli script di provisioning.

Quando cambiare hostname senza rompere il resto

Il cambio hostname è una di quelle operazioni che sembrano innocue, ma in realtà possono avere effetti su servizi che si aspettano un’identità stabile. Il rischio aumenta se il server fa parte di un cluster, se invia mail direttamente, se è monitorato con agent che identificano il nodo tramite nome o se usa certificati e configurazioni che includono l’hostname nei percorsi o nei CN/SAN.

Prima di cambiare il nome, controlla almeno questi punti:

  • presenza del nome nei file di configurazione applicativa;
  • eventuali record DNS interni o esterni associati al vecchio hostname;
  • mapping locale in /etc/hosts;
  • configurazioni di backup, monitoraggio e mail che usano il nome della macchina;
  • template di automazione o provisioning che potrebbero ripristinare il vecchio valore.

Se il server fornisce servizi esposti, la modifica dell’hostname non cambia automaticamente l’IP, ma può influire sull’identificazione del nodo e sulla risoluzione locale. Per questo la verifica finale non deve limitarsi a “il comando ha funzionato”, ma includere almeno un controllo di coerenza tra nome, risoluzione e servizi in ascolto.

Verifiche finali dopo il cambio

Dopo aver cambiato hostname, esegui un controllo completo ma rapido. L’obiettivo è confermare che il nome sia coerente in runtime, persistente e risolvibile localmente.

  1. Controlla il nome corrente con hostname.
  2. Controlla il valore persistente con hostnamectl status oppure cat /etc/hostname.
  3. Verifica la risoluzione locale con getent hosts nuovo-hostname.
  4. Se usi /etc/hosts, conferma che l’IP e il nome corrispondano alla policy della tua distribuzione.
  5. Se il server usa servizi critici, controlla i log applicativi e di sistema per eventuali errori legati alla risoluzione del nome.
hostname
hostnamectl status
getent hosts nuovo-hostname

Se getent hosts non restituisce nulla o mostra ancora il vecchio nome, il problema è quasi sempre nel mapping locale o nel DNS interno. In quel caso non serve rifare il cambio hostname: serve correggere la risoluzione.

Rollback: come tornare indietro in modo pulito

Il rollback dipende dal metodo usato. Se hai lavorato con hostnamectl, basta ripristinare il nome precedente con lo stesso comando. Se hai modificato file manualmente, ripristina i backup prima di riavviare o di far ripartire servizi che dipendono dal nome della macchina.

Esempio di rollback con hostnamectl:

sudo hostnamectl set-hostname vecchio-hostname

Esempio di rollback manuale:

sudo cp /etc/hostname.bak /etc/hostname
sudoedit /etc/hosts
sudo hostname vecchio-hostname

Se il sistema è gestito da cloud-init o da un sistema di provisioning, il rollback vero non è solo locale: va corretto anche il template o la sorgente che riscrive il nome. Altrimenti il vecchio valore tornerà al prossimo ciclo di bootstrap.

Quale dei quattro metodi scegliere davvero

Se il sistema è moderno, scegli hostnamectl. Se ti serve solo testare, usa il cambio temporaneo con hostname. Se lavori su un sistema minimale o vuoi il controllo completo, modifica /etc/hostname e, quando serve, /etc/hosts. Se il nome viene sovrascritto dopo il reboot, il problema è quasi certamente a monte: provisioning, cloud-init o template della macchina.

La regola pratica è semplice: cambia l’hostname nel punto giusto della catena, non solo nel punto più comodo. Se il tuo server è parte di un’infrastruttura più ampia, il nome locale è solo una delle fonti di verità; le altre vanno aggiornate insieme, altrimenti il cambio resta cosmetico e crea inconsistenze difficili da inseguire dopo.