Zet cloud-init mijn hostnaam terug na een herstart?

Niet op onze images. We stelden met hostnamectl een nieuwe naam in, herstartten, en lieten cloud-init de volgende start ook nog als een gloednieuwe instantie behandelen. De naam bleef beide keren staan, net als onze wijziging in /etc/hosts. Een herinstallatie geeft je een vers systeem met de oorspronkelijke naam.

Waarom zegt sudo „unable to resolve host” na het hernoemen?

hostnamectl verandert de naam, maar niet /etc/hosts, waar 127.0.1.1 nog naar de oude naam wijst. Op Ubuntu meldt sudo dan voor elke opdracht „unable to resolve host”. Vervang op de regel 127.0.1.1 de oude naam door de nieuwe en de waarschuwing verdwijnt.

Moet mijn server UTC of mijn lokale tijd gebruiken?

UTC is de veiligste keuze: logtijden van verschillende servers lopen gelijk en er zijn geen sprongen bij de zomertijd. Stap over op je eigen zone als je cron-taken en logtijden in je eigen tijd wilt lezen. Beide werken, en je kunt altijd weer wisselen.

Moet ik NTP instellen?

Nee. Onze Ubuntu- en Debian-images houden de klok vanaf de eerste start gelijk met systemd-timesyncd. Voer timedatectl uit en zoek naar „System clock synchronized: yes”.

Breekt een andere tijdzone mijn cron-taken?

Cron gebruikt de nieuwe zone meteen. Op onze Ubuntu 24.04-server liep een taak voor 09:48 Tokiotijd om 09:48:01 Tokiotijd, zonder cron te herstarten. Controleer wel taken die voor UTC geschreven zijn: die lopen nu op dat uur in je lokale tijd.

Hostnaam en tijdzone van een VPS wijzigen

Geef je server een nieuwe naam en zet zijn klok op jouw tijdzone in Ubuntu, Debian en Windows Server, zonder de sudo-waarschuwing die na een kale hostnamectl komt, en met controle van cron, logs en tijdsynchronisatie na de wijziging. Elke stap getest op onze images.

Een nieuwe server heet zoals je bij de bestelling hebt ingevuld, en zijn klok staat op UTC. Beide zijn makkelijk te veranderen. Hernoemen heeft één addertje: de gebruikelijke opdracht laat een oude regel in /etc/hosts staan, en op Ubuntu klaagt sudo daarover voor elke opdracht. Deze gids lost beide op in Ubuntu en Debian en toont de opdrachten voor Windows Server. We hebben elke stap op onze eigen images uitgevoerd.

Je hebt een gebruiker met sudo nodig. De Ubuntu-installatiegids maakt er een aan.

1. Bekijk de huidige naam en tijd

hostnamectl
timedatectl

Onze verse Ubuntu 24.04-server toonde de bestelnaam als statische hostnaam, plus Time zone: Etc/UTC, System clock synchronized: yes en NTP service: active. Debian 12 en 13 zagen er hetzelfde uit. De tijdsynchronisatie werkt dus al, NTP installeren is niet nodig.

2. Wijzig de hostnaam

Kies een korte naam, of een volledige als die moet kloppen met een DNS-record dat je beheert, zoals web1.example.com:

sudo hostnamectl set-hostname web1.example.com

De naam verandert meteen, maar /etc/hosts laat 127.0.1.1 nog naar de oude wijzen. Op Ubuntu was dat direct te zien:

sudo: unable to resolve host web1.example.com: No address associated with hostname

hostname -f faalde op dezelfde manier. Debian vond de naam via een andere weg en gaf geen waarschuwing, maar zijn /etc/hosts was net zo verouderd. Herstel het bestand op beide:

sudo sed -i 's/^127\.0\.1\.1 .*/127.0.1.1 web1.example.com web1/' /etc/hosts
grep 127.0.1.1 /etc/hosts
hostname -f

Daarna was sudo stil, gaf hostname -f web1.example.com en hostname -s web1.

Het commentaar bovenaan /etc/hosts zegt dat cloud-init het bestand beheert en dat je wijzigingen verloren kunnen gaan. Op onze images schrijft cloud-init het alleen bij de eerste start van de server. We herstartten en lieten cloud-init de volgende start daarna als nieuwe instantie behandelen. De naam en onze regel in /etc/hosts overleefden beide.

De hostnaam bestaat alleen op je server. Moeten andere machines hem onder die naam bereiken, voeg dan ook een DNS-record toe: een domein naar je VPS laten wijzen legt dat uit. Voor een mailserver telt ook het omgekeerde record: zie reverse DNS instellen.

3. Wijzig de tijdzone

Toon de zones en kies de jouwe. Onze server had er 497:

timedatectl list-timezones | grep -i tokyo
sudo timedatectl set-timezone Asia/Tokyo
timedatectl

De klok zelf verspringt niet. Alleen de weergave van tijden en het lezen van lokale planningen veranderen. Dit zagen we na de overstap van UTC naar Asia/Tokyo:

Wat	Na de wijziging
`date`, `journalctl`	Meteen Tokiotijd
cron	Meteen Tokiotijd: een taak voor 09:48 liep om 09:48:01 JST, zonder herstart
`/var/log/syslog` (Ubuntu)	Bleef UTC-tijden schrijven tot rsyslog werd herstart
`/etc/timezone` (Ubuntu)	Stond nog op `Etc/UTC`

Herstart dus de logger en alles wat lang draait en tijden toont, zoals je app:

sudo systemctl restart rsyslog

Debian 12 en 13 installeren geen rsyslog. Hun logs staan alleen in het journal, en dat volgt de nieuwe zone vanzelf.

Een paar oudere programma's lezen de zone uit /etc/timezone in plaats van uit de systeeminstelling. Toont er één nog UTC, schrijf daar dan dezelfde naam in en herstart dat programma:

echo Asia/Tokyo | sudo tee /etc/timezone

Kijk voor je overstapt je crontab na. Een regel 0 3 * * * die voor 03:00 UTC bedoeld was, loopt nu om 03:00 Tokiotijd, negen uur eerder in werkelijke tijd.

4. Windows Server

Open op Windows Server 2022 PowerShell als administrator. Hernoemen vraagt om een herstart:

Rename-Computer -NewName web1 -Restart

Computernamen in Windows zijn beperkt tot 15 tekens, gebruik hier dus de korte naam.

Zoek voor de tijdzone de ID op en stel die in. Dat werkt meteen, zonder herstart:

Get-TimeZone -ListAvailable | Where-Object Id -like '*Tokyo*'
Set-TimeZone -Id 'Tokyo Standard Time'
Get-TimeZone

Nu je toch bent ingelogd, is het een goed moment om RDP te beveiligen.

Welk pakket

Hostnaam en tijdzone kosten niets, dus elk pakket voldoet: Nano voor $3/maand voor een kleine Linux-server, Windows-Small voor $11/maand voor Windows Server 2022. Alle pakketten staan op de pagina VPS, en betalen gaat in USDT, USDC of ETH via Base, Ethereum of Polygon.