EQVPS
Tableau de bordCommencer

Changer le nom d'hôte et le fuseau horaire d'un VPS

Renommez votre serveur et mettez son horloge à votre fuseau sous Ubuntu, Debian et Windows Server, sans l'avertissement de sudo qui suit un simple hostnamectl, en vérifiant cron, les journaux et la synchronisation de l'heure après le changement. Chaque étape testée sur nos images.

Un nouveau serveur porte le nom que vous avez saisi à la commande, et son horloge est en UTC. Les deux se changent facilement. Le renommage a un piège : la commande habituelle laisse une ancienne ligne dans /etc/hosts, et sous Ubuntu sudo s'en plaint avant chaque commande. Ce guide corrige les deux sous Ubuntu et Debian et donne les commandes pour Windows Server. Nous avons exécuté chaque étape sur nos propres images.

Il vous faut un utilisateur avec sudo. Le guide de configuration d'Ubuntu en crée un.

1. Vérifier le nom et l'heure actuels

hostnamectl
timedatectl

Notre serveur Ubuntu 24.04 tout neuf affichait le nom de la commande comme nom d'hôte statique, ainsi que Time zone: Etc/UTC, System clock synchronized: yes et NTP service: active. Debian 12 et 13 donnaient la même chose. La synchronisation fonctionne déjà, inutile d'installer NTP.

2. Changer le nom d'hôte

Choisissez un nom court, ou complet s'il doit correspondre à un enregistrement DNS que vous gérez, comme web1.example.com :

sudo hostnamectl set-hostname web1.example.com

Le nom change tout de suite, mais /etc/hosts fait toujours pointer 127.0.1.1 vers l'ancien. Sous Ubuntu, cela s'est vu immédiatement :

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

hostname -f échouait de la même façon. Debian trouvait le nom par une autre voie et n'affichait pas d'avertissement, mais son /etc/hosts était tout aussi périmé. Corrigez le fichier sur les deux :

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

Ensuite, sudo est resté silencieux, hostname -f a affiché web1.example.com et hostname -s a affiché web1.

Le commentaire en haut de /etc/hosts indique que cloud-init gère ce fichier et que vos modifications peuvent être perdues. Sur nos images, cloud-init ne l'écrit qu'au premier démarrage du serveur. Nous avons redémarré, puis fait traiter le démarrage suivant par cloud-init comme une nouvelle instance. Le nom et notre ligne dans /etc/hosts ont survécu aux deux.

Le nom d'hôte n'existe que sur votre serveur. Si d'autres machines doivent le joindre par ce nom, ajoutez aussi un enregistrement DNS : faire pointer un domaine vers votre VPS l'explique. Pour un serveur de messagerie, l'enregistrement inverse compte aussi : voir configurer le DNS inverse.

3. Changer le fuseau horaire

Listez les fuseaux et choisissez le vôtre. Notre serveur en comptait 497 :

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

L'horloge elle-même ne bouge pas. Seules changent la façon d'afficher l'heure et la lecture des horaires locaux. Voici ce que nous avons vu après le passage d'UTC à Asia/Tokyo :

QuoiAprès le changement
date, journalctlHeure de Tokyo tout de suite
cronHeure de Tokyo tout de suite : une tâche prévue à 09:48 s'est lancée à 09:48:01 JST, sans redémarrage
/var/log/syslog (Ubuntu)A continué en heure UTC jusqu'au redémarrage de rsyslog
/etc/timezone (Ubuntu)Indiquait toujours Etc/UTC

Redémarrez donc le journal système et tout ce qui tourne longtemps en affichant des heures, comme votre application :

sudo systemctl restart rsyslog

Debian 12 et 13 n'installent pas rsyslog. Leurs journaux ne vivent que dans le journal systemd, qui suit le nouveau fuseau de lui-même.

Quelques programmes anciens lisent le fuseau dans /etc/timezone plutôt que dans le réglage système. Si l'un d'eux affiche encore l'UTC, écrivez-y le même nom et redémarrez ce programme :

echo Asia/Tokyo | sudo tee /etc/timezone

Avant de changer, parcourez votre crontab. Une ligne 0 3 * * * écrite pour 03:00 UTC tournera désormais à 03:00 heure de Tokyo, soit neuf heures plus tôt en temps réel.

4. Windows Server

Sous Windows Server 2022, ouvrez PowerShell en tant qu'administrateur. Le renommage demande un redémarrage :

Rename-Computer -NewName web1 -Restart

Les noms d'ordinateur Windows sont limités à 15 caractères, utilisez donc ici le nom court.

Pour le fuseau, trouvez l'identifiant et appliquez-le. C'est immédiat, sans redémarrage :

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

Puisque vous êtes connecté, c'est le bon moment pour sécuriser RDP.

Quelle offre

Nom d'hôte et fuseau ne coûtent rien, toute offre convient donc : Nano à $3/mois pour un petit serveur Linux, Windows-Small à $11/mois pour Windows Server 2022. Toutes les offres sont sur la page VPS, et le paiement se fait en USDT, USDC ou ETH sur Base, Ethereum ou Polygon.

FAQ

cloud-init va-t-il remettre l'ancien nom après un redémarrage ?

Pas sur nos images. Nous avons défini un nouveau nom avec hostnamectl, redémarré, puis fait traiter le démarrage suivant par cloud-init comme une instance toute neuve. Le nom est resté les deux fois, tout comme notre modification de /etc/hosts. Une réinstallation vous donne un système neuf avec le nom d'origine.

Pourquoi sudo affiche-t-il « unable to resolve host » après le renommage ?

hostnamectl change le nom mais pas /etc/hosts, où 127.0.1.1 pointe toujours vers l'ancien nom. Sous Ubuntu, sudo affiche alors « unable to resolve host » avant chaque commande. Remplacez l'ancien nom par le nouveau sur la ligne 127.0.1.1 et l'avertissement disparaît.

Mon serveur doit-il être en UTC ou à mon heure locale ?

UTC est le choix le plus sûr : les heures des journaux de plusieurs serveurs concordent et il n'y a pas de saut au changement d'heure. Passez à votre fuseau si vous voulez lire les tâches cron et les heures des journaux à votre propre heure. Les deux fonctionnent, et vous pouvez changer à tout moment.

Dois-je configurer NTP ?

Non. Nos images Ubuntu et Debian synchronisent l'horloge avec systemd-timesyncd dès le premier démarrage. Lancez timedatectl et cherchez « System clock synchronized: yes ».

Changer de fuseau va-t-il casser mes tâches cron ?

Cron utilise le nouveau fuseau tout de suite. Sur notre serveur Ubuntu 24.04, une tâche prévue à 09:48 heure de Tokyo s'est lancée à 09:48:01 heure de Tokyo, sans redémarrer cron. Vérifiez en revanche les tâches écrites pour l'UTC : elles tournent maintenant à cette heure-là dans votre fuseau.

Commentaires

Pas encore de commentaires. Soyez le premier.

Laisser un commentaire

Les commentaires sont modérés avant leur publication.