De hostnaam onder Linux blijvend wijzigen: hostnamectl, /etc/hosts en cloud-init

Een server die debian, localhost of vm-01 heet, werkt prima. Vervelend wordt het pas als er drie tegelijk draaien, als logregels niet meer uit elkaar te houden zijn of als de eerste mailserver erbij komt en de ontvangende server de naam controleert. Deze handleiding wijzigt de hostnaam zo dat hij de volgende herstart overleeft, dat sudo niet in een timeout loopt en dat ook de diensten hem kennen die hem bij de start inlezen.

Dit artikel is de verdieping bij stap 6 van de checklist voor een nieuwe rootserver. Daar staan de twee commando's die meestal volstaan. Hier leest u wat daarachter gebeurt, en wat u doet als ze niet volstaan.

Alle gegevens gelden voor Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. De commando's zijn geschreven voor gebruik als root. Werkt u als gewone gebruiker, zet dan sudo voor elk commando.

Een server heeft drie namen, niet één

De meest voorkomende oorzaak van een half gelukte naamswijziging is dat Linux niet één hostnaam kent, maar drie. Ze worden op verschillende plaatsen bewaard en door verschillende onderdelen overschreven.

De vluchtige naam wordt door de kernel bijgehouden, en elk programma krijgt hem via gethostname(). De statische naam is het sjabloon waaruit die bij het opstarten wordt gezet. De sprekende naam mag spaties en accenttekens bevatten en verschijnt alleen in interfaces, nooit op het netwerk.

Net zo belangrijk is het tweede onderscheid: welk commando haalt zijn antwoord waarvandaan. Stel dat in /etc/hostname de waarde srv01 staat en in /etc/hosts de regel 127.0.1.1 srv01.example.com srv01, dan ontstaat dit beeld.

De doorslaggevende regel is hostname -f. Dat commando leest niet /etc/hostname, maar neemt de kernelnaam en stuurt die door de naamresolutie. De volledige naam komt dus uit /etc/hosts of uit het DNS, nooit uit het hostnaambestand. Bijna alle problemen in dit artikel komen voort uit dat misverstand.

Vóór de eerste wijziging: de weg terug

Een naamswijziging alleen verbreekt uw SSH-sessie niet. Gevaarlijk is de stap daarna: het bewerken van /etc/hosts. Verdwijnt daar de regel voor localhost, dan lopen tientallen programma's in een timeout, start Postfix niet meer en heeft sudo seconden per aanroep nodig. Regel daarom vooraf drie dingen.

1. Een tweede sessie blijft openstaan

Open een tweede terminalvenster met een actieve verbinding en sluit dat niet voordat alles gecontroleerd is. Een bestaande sessie overleeft elke wijziging aan hostnaam en naamresolutie. Staat de verbinding zelf nog niet netjes, dan helpt Via SSH verbinding maken met de server.

2. De weg buiten SSH om

KVM-rootservers en dedicated servers van KernelHost hebben geen IPMI en geen iDRAC. De toegang die ook dan nog werkt wanneer er in het gastsysteem niets meer lukt, is de VNC-console in het klantenpaneel. Die hangt aan de virtualisatielaag of aan de aansluiting zelf en staat los van de naamresolutie in het gastsysteem. Log daar één keer vooraf in en overtuig uzelf ervan dat u het root-wachtwoord kent. Een vluchtweg die u pas in een noodgeval voor het eerst uitprobeert, is geen vluchtweg.

3. Twee kopieën en een rollback

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

Daarmee is de weg terug een tweeregelig commando dat u in geval van nood via de console intypt:

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

Inventarisatie in vijf commando's

Kijk eerst wat er op dit moment geldt en wie erover meebeslist.

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 niet geïnstalleerd"

De uitvoer van hostnamectl verdient een nauwkeurige blik. Normaal begint die met Static hostname:. Verschijnt er ook een regel Transient hostname:, dan wijken de statische en de draaiende naam van elkaar af en zet iets de naam actief om: bijna altijd cloud-init of een DHCP-client. Dat schakelt u eerst uit, anders is uw wijziging na de volgende herstart weer weg.

De hosts:-regel uit /etc/nsswitch.conf bepaalt de volgorde van de naamresolutie. De vier vermeldingen die daar voorkomen, betekenen het volgende:

• files: /etc/hosts wordt gelezen.
• dns: de resolver bevraagt de nameservers uit /etc/resolv.conf.
• resolve: de aanvraag gaat naar systemd-resolved.
• myhostname: een module van systemd die de eigen hostnaam afbeeldt op de lokaal geconfigureerde IP-adressen, ook zonder vermelding in /etc/hosts.

Dat laatste punt verklaart verderop waarom dezelfde fout op sommige servers jarenlang onopgemerkt blijft.

De naam kiezen: FQDN of korte naam

Toegestaan zijn letters, cijfers en het koppelteken. Geen underscore, geen punt aan het begin of einde, geen koppelteken aan het begin van een label. Schrijf alles in kleine letters: DNS vergelijkt zonder te letten op hoofdletters en kleine letters, veel programma's doen dat juist letterlijk. Een label (het deel tussen twee punten) mag 63 tekens lang zijn, de volledige naam in het DNS 253. De kernel accepteert voor de hostnaam echter hooguit 64 tekens, dus een heel lange FQDN past er mogelijk helemaal niet in. Kies de naam onder een domein dat van u is: .local is gereserveerd voor mDNS, en verzonnen extensies zoals .lan kunnen op elk moment echte topleveldomeinen worden.

Blijft de vraag wat er in /etc/hostname komt te staan. Beide varianten werken, ze verschillen in wat u daarna overal te zien krijgt.

Op Debian en Ubuntu verdient de eerste variant de voorkeur: de korte naam in /etc/hostname, de volledige naam als eerste vermelding in /etc/hosts. Zo blijven de prompt en de logregels kort, en klopt de FQDN toch. De tweede variant is net zo netjes, zolang u die consequent volhoudt. De echte fout is de mengvorm: een FQDN in /etc/hostname en een andere in /etc/hosts.

Maak de A-record (bij IPv6 de AAAA-record) voor de nieuwe naam het beste meteen aan. Die kost niets, laat hostname -f ook zonder /etc/hosts het juiste antwoord geven en is de voorwaarde voor elk certificaat op deze naam.

cloud-init temmen voordat u iets instelt

Op images met cloud-init, en bij Ubuntu is dat vrijwel elk image, wordt de hostnaam bij het opstarten uit de metadata van de instantie gezet. Verantwoordelijk zijn de modules set_hostname en update_hostname, plus update_etc_hosts voor het bestand /etc/hosts. Alle drie draaien vroeg, nog voordat uw eigen diensten starten. Twee instellingen sturen dat aan:

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

Op de serverimages van Ubuntu staat in /etc/cloud/cloud.cfg de regel preserve_hostname: false, cloud-init mag de naam dus aanpassen. De tegenhanger hoort niet in dat bestand thuis, want een pakketupdate vervangt het, maar in /etc/cloud/cloud.cfg.d/. De bestanden daar worden alfabetisch gelezen en het laatste wint, vandaar de 99:

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

De tweede instelling betreft /etc/hosts. Die wordt vaak over het hoofd gezien, terwijl ze meer schade aanricht.

Staat daar true en heeft u eigen vermeldingen nodig, zet de waarde dan op localhost of onderhoud in plaats daarvan het sjabloon (op Debian en Ubuntu hosts.debian.tmpl). Een bestand met de hand wijzigen dat bij elke start wordt overschreven, levert precies het soort fout op dat u pas weken later opmerkt.

Wat cloud-init het laatst heeft ingesteld, onthoudt het onder /var/lib/cloud/data/. Die toestand wist cloud-init clean. Doe dat op een ingerichte server alstublieft niet: bij de volgende start lopen alle modules opnieuw, alsof de machine nieuw is.

De tweede overschrijver: DHCP

Haalt de server zijn adres via DHCP, dan kan de client de vluchtige hostnaam uit het antwoord overnemen (optie 12). De statische naam blijft ongemoeid, wat het zoeken naar de fout bemoeilijkt: hostnamectl --static toont uw naam, hostname een andere. Onder netplan schakelt u dat uit:

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

Activeer met netplan try in plaats van netplan apply: try draait de wijziging na 120 seconden vanzelf terug als u niet bevestigt. Bij een rechtstreeks geconfigureerde systemd-networkd heet de instelling UseHostname=no in de sectie [DHCPv4].

De hostnaam instellen

hostnamectl set-hostname srv01

Zonder verdere opties stelt hostnamectl de statische en de vluchtige naam samen in. Precies dat wilt u. Met --static wijzigt u alleen /etc/hostname, en bij een actieve vluchtige naam zou de machine tot de herstart onder de oude naam doordraaien. Nieuwere systemd-versies kennen daarnaast de korte vorm hostnamectl hostname srv01, terwijl set-hostname op alle vier de systemen werkt.

Controle: beide namen moeten overeenkomen en het bestand moet de nieuwe inhoud bevatten.

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

Twee kanttekeningen. Ten eerste wijzigt hostname srv01 zonder ctl alleen de vluchtige naam, en die is na de herstart verdwenen. Ten tweede toont uw draaiende shell nog steeds de oude naam in de prompt, omdat bash de hostnaam eenmalig bij de start van de sessie inleest. Dat is geen mislukking, maar een oude sessie. Log opnieuw in.

Optioneel legt u een sprekende naam vast die in interfaces verschijnt en spaties mag bevatten:

hostnamectl set-hostname --pretty "Webserver Frankfurt"
cat /etc/machine-info

/etc/hosts correct schrijven

hostnamectl raakt /etc/hosts niet aan. Dat bestand blijft uw taak, en het is de reden dat een naamswijziging zo vaak maar half doorwerkt.

Een regel bestaat uit een IP-adres, de canonieke naam en een willekeurig aantal aliassen. De eerste naam na het adres is de canonieke, en precies die levert hostname -f. Daarom staat de volledige naam vooraan en de korte naam erachter, nooit andersom.

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

Waarom 127.0.1.1 en niet 127.0.0.1: Debian en Ubuntu scheiden de eigen hostnaam bewust van localhost. Hangt u de servernaam als alias achter de localhost-regel, dan blijft localhost de canonieke naam van die regel, en antwoordt hostname -f met localhost. Programma's die daar hun eigen naam uit afleiden, zetten vervolgens localhost in logbestanden en e-mailheaders.

Een ontbrekende vermelding voegt u toe, een bestaande regel past u aan:

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

Levert het eerste commando al een regel op, bewerk dan die regel in plaats van er een tweede achteraan te zetten. Bij twee regels voor hetzelfde adres wint de eerste, en wijzigt u daarna een regel die niemand meer leest.

Controle:

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

De twee getent-aanroepen moeten elk één regel opleveren, hostname -f de volledige naam en hostname -s de korte naam. Komt er niets terug, dan werkt de vermelding niet, bijvoorbeeld omdat de regel een commentaarteken draagt.

Eén keuze blijft over: 127.0.1.1 of het publieke adres van de server. Sommige software bindt zich aan het adres waarnaar de eigen naam oplost, of zet dat adres in de ledenlijst van een cluster. Dan hoort de FQDN op het publieke adres. Bij een vast adres is dat de nettere variant, bij een wisselend adres de 127.0.1.1, omdat die ook zonder netwerkverbinding werkt.

Waarom een ontbrekende vermelding sudo traag maakt

sudo bepaalt bij elke aanroep de eigen hostnaam en laat die oplossen. Het heeft die naam nodig voor de logregel en voor de vergelijking met de hostvermeldingen in /etc/sudoers.

De resolutie verloopt langs de hosts:-regel uit /etc/nsswitch.conf. Staat de naam in /etc/hosts, dan is de zaak na één bestandstoegang klaar, dus binnen een milliseconde. Staat hij daar niet, dan schuift de aanvraag door naar de volgende vermelding, meestal dns, en vraagt de resolver de nameservers uit /etc/resolv.conf naar een naam die in het DNS niet bestaat. De standaardinstellingen van glibc zijn vijf seconden timeout en twee pogingen per nameserver. Antwoordt niemand, dan telt dat op, en wel bij elke afzonderlijke aanroep.

Daar komt nog bij: een korte naam bevat geen punt en valt daarmee onder de standaardinstelling ndots:1. De resolver plakt daarom eerst elk zoekdomein uit /etc/resolv.conf erachter en vraagt pas daarna de naam zelf op. Twee zoekdomeinen betekenen drie ronden met aanvragen in plaats van één.

Zichtbaar wordt dat aan deze waarschuwing, die aan elke aanroep voorafgaat:

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

Meten in plaats van schatten:

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

Beide horen ver onder een tiende seconde te blijven. Alles daarboven is wachttijd op een nameserver.

En dan nu de reden dat de fout niet overal opvalt: staat in de hosts:-regel de vermelding myhostname, dan beantwoordt die module de vraag naar de eigen naam zelf, zonder DNS en zonder /etc/hosts. Daar blijft de waarschuwing uit, hoewel het bestand onvolledig is. Zodra dezelfde opzet naar een systeem zonder die vermelding verhuist, is de fout terug.

Een tweede, zeldzamer probleem betreft de rechtentoekenning: in /etc/sudoers kan elke regel beperkt zijn tot bepaalde hostnamen. De meegeleverde regels van Debian en Ubuntu gebruiken ALL en zijn ongevaarlijk. Eigen regels met een hostnaam verliezen daarentegen hun werking, en de betrokken gebruiker mag daarna niets meer. Kijk dat vooraf na:

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

Diensten die de naam bij de start inlezen

Veel programma's vragen de hostnaam precies één keer op, bij de start, en werken daarna met de oude naam verder. Dat verklaart een groot deel van de verwarring na een naamswijziging.

• De draaiende shell. De prompt toont de oude naam. Nieuwe sessie openen en klaar.
• rsyslog, waar het geïnstalleerd is. Een systemctl restart rsyslog volstaat. Debian 12 en 13 leveren bij minimale installaties geen rsyslog mee, daar schrijft journald.
• Al weggeschreven logregels behouden de oude naam, en dat hoort ook zo. Staat de oude naam daarentegen in nieuwe regels, start dan de schrijvende dienst opnieuw op.
• MariaDB en MySQL leiden standaardbestandsnamen zoals het foutlogbestand en de binaire log af van de hostnaam, tenzij de paden uitdrukkelijk in de configuratie staan.
• Java-applicaties. InetAddress.getLocalHost() gooit een java.net.UnknownHostException zodra de eigen naam niet oplost. Dat treft applicatieservers net zo goed als gameservers.
• Monitoringagents hebben de naam vaak in hun eigen configuratiebestand staan. Anders duikt dezelfde server na de naamswijziging twee keer op.

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

Staat er toch een onderhoudsvenster gepland, dan is een herstart de meest complete oplossing. Hoe u eigen programma's netjes als unit vastlegt zodat ze een herstart overleven, leest u in Een systemd-service aanmaken.

Mailserver: de naam die anderen zien

Bij het verzenden van e-mail is de hostnaam geen cosmetiek meer. De ontvangende server ziet hem in de EHLO en controleert hem. Drie dingen moeten bij elkaar passen:

1. De naam waarmee uw mailserver zich meldt (bij Postfix myhostname).
2. De PTR-record van uw IP-adres, oftewel de reverse lookup.
3. Een A-record (bij IPv6 een AAAA-record) voor precies deze naam, dat weer naar hetzelfde adres wijst.

Sluit de keten niet, dan waarderen veel ontvangers het bericht af of weigeren ze het. Controleren zonder extra pakketten:

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

Nauwkeuriger wordt het met dig uit het pakket bind9-dnsutils:

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

De PTR-record is niet van de server. Hij hangt aan het IP-adres en wordt bij de beheerder van het netwerk onderhouden, bij KernelHost via het klantenpaneel. Geen enkele aanroep van hostnamectl verandert daar iets aan, en precies hier lopen naamswijzigingen bij mailservers mis.

Postfix neemt de naamswijziging niet vanzelf over. Op Debian en Ubuntu schrijft het pakket bij de installatie een vaste waarde naar /etc/postfix/main.cf, en daarnaast ligt /etc/mailname met de naam die Postfix als afzenderdomein voor lokale post gebruikt. Beide blijven ongewijzigd staan:

postconf myhostname mydomain myorigin
cat /etc/mailname

Aanpassen en opnieuw starten, waarbij /etc/mailname een eigen afweging is en niet per se dezelfde waarde draagt als myhostname:

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

SPF, DKIM en DMARC hangen daarentegen aan het afzenderdomein en niet aan de hostnaam. Een naamswijziging repareert dus geen bezorgproblemen die daar hun oorzaak hebben.

Certificaten

De systeemnaam staat in geen enkel certificaat, want een certificaat dekt de DNS-namen die in de aanvraag stonden. Toch werkt een naamswijziging op drie plaatsen door.

Ten eerste bij de aanvraag. Haalt u een certificaat op de servernaam zelf, bijvoorbeeld voor de mailserver, dan moet die naam in het DNS staan voordat de certificaatautoriteit gaat kijken. Anders eindigt de run met een melding als DNS problem: NXDOMAIN looking up A for srv01.example.com. De A-record hoort vóór de aanvraag, niet erna.

Ten tweede bij de bestaande certificaten. Die blijven op de oude naam staan en worden verlengd tot u ze verwijdert:

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

Verwijder ze pas als geen enkele dienst nog naar het pad verwijst, anders start de webserver bij het volgende herladen niet meer.

Ten derde bij de mailserver. Meldt Postfix zich met de nieuwe naam maar presenteert het een certificaat voor de oude, dan mislukt de aflevering bij ontvangende servers die de naam streng controleren. Certificaat en myhostname horen op dezelfde naam te staan.

Er is geen verband tussen de systeemnaam en server_name in nginx. nginx beslist aan de hand van de Host-header van de aanvraag, niet aan de hand van de hostnaam. Wie na een naamswijziging de verkeerde pagina geserveerd krijgt, zoekt in de serverconfiguratie en niet bij de hostnaam. De basis daarvan staat in nginx installeren op Debian en Ubuntu.

Veelvoorkomende fouten en oplossingen

sudo: unable to resolve host srv01: Name or service not known
De hostnaam staat niet in /etc/hosts en is onbekend in het DNS. Vul de regel 127.0.1.1 srv01.example.com srv01 aan. Zolang die ontbreekt, wacht elke aanroep op een timeout van de resolver.

hostname: Name or service not known
Het antwoord van hostname -f wanneer de kernelnaam nergens kan worden opgelost. Dezelfde oorzaak, dezelfde oplossing. Controleer daarna met getent hosts "$(hostname)" of er werkelijk iets terugkomt.

Could not set property: Access denied
hostnamectl is zonder rootrechten aangeroepen, of de aanroep liep in een container die de kernelnaam niet mag wijzigen. Op een eigen server helpt sudo. In een niet-geprivilegieerde container stelt u de naam in de configuratie van die container in, niet erbinnen.

fatal: unable to use my own hostname
Uit het logboek van Postfix. De waarde in myhostname lost niet op. Vul de vermelding in /etc/hosts aan en voer daarna systemctl restart postfix uit.

504 5.5.2 <srv01>: Helo command rejected: need fully-qualified hostname
Uw mailserver meldt zich met de korte naam, terwijl de ontvangende server een volledige naam eist. Zet myhostname op de FQDN en start Postfix opnieuw.

450 4.7.1 Client host rejected: cannot find your reverse hostname
Bij uw IP-adres bestaat geen PTR-record, of hij wijst nergens heen. Dat lost u niet op de server op, maar alleen bij de beheerder van het IP-netwerk.

java.net.UnknownHostException: srv01
Een Java-applicatie wilde haar eigen naam oplossen en is daarin mislukt. Opnieuw /etc/hosts. Na de vermelding moet de applicatie opnieuw worden gestart.

DNS problem: NXDOMAIN looking up A for srv01.example.com
De nieuwe naam bestaat nog niet in het DNS. Maak de A-record aan, wacht de verspreiding af en herhaal de aanvraag.

Na de herstart is de naam weer de oude.
Controleer in deze volgorde: staat preserve_hostname: true onder /etc/cloud/cloud.cfg.d/, levert de DHCP-client geen naam meer, bevat /etc/hostname werkelijk de nieuwe naam. Toont hostnamectl na de start een regel Transient hostname:, dan grijpt nog een van deze bronnen in.

/etc/hosts is na elke herstart weer leeggeruimd.
manage_etc_hosts: true staat ingesteld, cloud-init maakt het bestand opnieuw aan op basis van het sjabloon. Zet de waarde om naar localhost of onderhoud het sjabloon.

Verschillen tussen de distributies

Op alle vier de systemen hetzelfde: hostnamectl wijzigt nooit /etc/hosts, en geen enkel hulpmiddel van het besturingssysteem maakt DNS- of PTR-records aan. Die twee stappen blijven handwerk.

De eindcontrole

Een commando zonder foutmelding is geen bewijs. De enige betrouwbare test is de herstart, gevolgd door deze vijf regels:

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

Verwacht worden: de nieuwe korte naam, de nieuwe volledige naam, één regel uit /etc/hosts, een looptijd ruim onder een tiende seconde en precies één regel voor 127.0.1.1. Pas als alle vijf kloppen, is de naamswijziging rond, en pas dan mag u het tweede terminalvenster sluiten.