Umbenennen eines Linux-Servers mit hostnamectl, ohne DNS-Probleme zu verursachen

Die Umbenennung eines Linux-Servers beschränkt sich nicht nur auf die Änderung des im SSH-Prompt angezeigten Textes. Der Name kann auch verwendet werden in /etc/hostsDNS, Zertifikate, Überwachung, Datensicherung oder Flotteninventar.

hostnamectl Dadurch ändert sich der Systemname, aber weder Ihre DNS-Zone noch die Tools, die den Rechner noch mit dem alten Namen identifizieren, werden angepasst. Daher empfehle ich Ihnen, diese Abhängigkeiten vor der Änderung zu notieren und anschließend einzeln zu überprüfen.

Tux ersetzt die Identität eines Servers während der DNS-Netzwerkverifizierung. — Der System-Hostname, die lokale Namensauflösung und der DNS-Server müssen separat überprüft werden.

Notieren Sie sich den aktuellen Namen und die Adressen des Servers.

Beginnen Sie damit, eine SSH-Sitzung offen zu halten. Wenn sich der Server an einem entfernten Standort befindet, stellen Sie außerdem sicher, dass Sie eine alternative Konsole bei Ihrem Hosting-Anbieter haben. Das Ändern des Hostnamens führt normalerweise nicht zum Abbruch von SSH, aber ein Fehler in /etc/hostsDNS oder Automatisierung können die Wiederverbindung erschweren.

hostnamectl status
Hostname
Hostname -f
cat /etc/hostname
getent hosts "$(hostname)"
IP-BR-Adresse

Hostname zeigt den vom Kernel verwendeten Namen an. Die Datei /etc/hostname enthält den statischen Namen, der beim Systemstart auf einem von systemd verwalteten System geladen wird. Der Befehl Hostname -f Es wird versucht, den vollqualifizierten Namen über die lokale Namensauflösung zu ermitteln. Schlägt dies fehl oder liefert es ein unerwartetes Ergebnis, sollte die Änderung nicht sofort erzwungen werden: Prüfen Sie zunächst, ob eine Änderung vorliegt. /etc/hosts und DNS.

Beachten Sie auch die tatsächliche Adresse, die der Server verwendet. Die Anleitung dazu finden Sie hier: IP-Adresse unter Linux wird Ihnen dabei helfen, die Schnittstellenadresse, die verwendete Route und jede von einem NAT bereitgestellte öffentliche IP-Adresse zu unterscheiden.

Speichern Sie vor dem Schreiben die beiden Dateien, die möglicherweise korrigiert werden müssen:

sudo cp -a /etc/hostname "/etc/hostname.bak-$(date +%F-%H%M)"
sudo cp -a /etc/hosts "/etc/hosts.bak-$(date +%F-%H%M)"

Ändern Sie den Hostnamen mit hostnamectl

Wählen Sie einen kurzen, stabilen und DNS-kompatiblen Namen, zum Beispiel srv-app-02Vermeiden Sie Leerzeichen, Akzente, Unterstriche und Namen, die eine sich wahrscheinlich ändernde IP-Adresse beschreiben. Ein statischer Hostname hat Vorrang vor einem temporären, per DHCP zugewiesenen Namen.

sudo hostnamectl set-hostname srv-app-02
hostnamectl status
Hostname
cat /etc/hostname

Ohne Targeting-Optionen Aktualisiert die hübschen, statischen und temporären Namen. Für einen Server ist ein kurzer Name wie srv-app-02 Vermeidet die Vermischung des System-Hostnamens mit seinem FQDN. srv-app-02.example.netDie Handbuchseite für hostnamectl beschreibt diese drei Ebenen.

Der Befehl sollte sofort wirksam werden. Allerdings behält die Eingabeaufforderung Ihrer SSH-Sitzung möglicherweise den alten Namen bei, bis eine neue Shell geöffnet wird. Starten Sie den Server nicht neu, nur um die Eingabeaufforderung zu aktualisieren. Öffnen Sie stattdessen eine zweite Sitzung und vergleichen Sie die Ausgabe von Hostname.

/etc/hosts reparieren, ohne die lokale Auflösung zu beeinträchtigen

nicht umschreiben /etc/hostsSuchen Sie vor der Bearbeitung der Datei nach dem alten Namen:

[:space:]grep -nE '(^|[])srv-app-01([]|$)' /etc/hosts[:space:]
sudoedit /etc/hosts

Unter Debian und Ubuntu, eine Zeile in 127.0.1.1 wird häufig verwendet, um den FQDN und den Kurznamen lokal zu verknüpfen:

127.0.0.1 localhost
127.0.1.1 srv-app-02.example.net srv-app-02

Auf einem Server mit einer stabilen privaten Adresse kann man eine direkte Verbindung zu dieser Adresse herstellen, zum Beispiel 192.0.2.25 srv-app-02.example.net srv-app-02Kopieren Sie keine Vorlage wahllos. Korrigieren Sie nur die Zeile, die bereits die Maschine angibt, und behalten Sie die Einträge bei. localhost IPv4 und IPv6.

getent hosts srv-app-02
getent hosts srv-app-02.example.net
Hostname -f

getent fragt die von konfigurierte Auflösung ab /etc/nsswitch.confDaher berücksichtigt es /etc/hostsDNS und, je nach Umgebung, Quellen wie LDAP. Dies ist aussagekräftiger als das bloße Lesen der Datei.

Aktualisieren Sie die Forward- und Reverse-DNS-Einträge separat.

Der neue lokale Name erzeugt keine DNS-Einträge. Fügen Sie in der betroffenen Zone den A-Eintrag, den AAAA-Eintrag (falls vorhanden) und, falls Sie ihn verwalten, den PTR-Eintrag für die Adresse hinzu oder ändern Sie ihn. Behalten Sie den alten Eintrag während der Umstellung bei, falls er noch von Anwendungen verwendet wird, und entfernen Sie ihn nach der Überprüfung.

dig +short A srv-app-02.example.net
dig +short AAAA srv-app-02.example.net
dig +short -x 192.0.2.25

Führen Sie diese Tests von einem anderen Rechner aus und gegebenenfalls mit mehreren Resolvern durch. Der Artikel über dig unter Linux zeigt, wie man lokale DNS-Server, einen öffentlichen Server und den autoritativen Server vergleicht, ohne dabei zufällig Caches zu leeren.

Ein korrekter DNS-Eintrag garantiert nicht, dass alles einwandfrei funktioniert. Überprüfen Sie TLS-Zertifikate, Konfigurationsdateien mit dem alten FQDN und namensbasierte Firewall-Regeln. Bei SSH verwendet eine Verbindung zum neuen Namen weiterhin den Host-Schlüssel des Servers, erstellt aber einen neuen logischen Eintrag in der DNS-Konfiguration. bekannte_HostsVergleichen Sie den Fingerabdruck, bevor Sie ihn akzeptieren.

SSH, Protokolle und Überwachung nach der Umbenennung steuern

Öffnen Sie eine zweite SSH-Verbindung mit dem neuen FQDN, ohne die erste zu schließen. Überprüfen Sie anschließend, ob Dienste ausgefallen sind oder Meldungen im Zusammenhang mit der Änderung vorliegen.

hostnamectl status
systemctl --fehlgeschlagen
journalctl -u systemd-hostnamed --since "-15 minutes" --no-pager
journalctl --since "-15 minutes" --no-pager | grep -iE 'hostname|srv-app-01|srv-app-02'

Das Vorhandensein des alten Namens in den vor der Änderung geschriebenen Zeilen ist normal. Entscheidend ist der Name, der in den neuen Ereignissen verwendet wird. Starten Sie nicht automatisch alle Dienste neu. Überprüfen Sie zuerst diejenigen, die beim Start explizit den Hostnamen angeben, wie z. B. bestimmte Protokollierungs-, Sicherungs- oder Überwachungsagenten.

Überprüfen Sie in Ihrem Überwachungstool, ob der Rechner nicht als neuer, leerer Host angezeigt wird, während der alte offline geht. Führen Sie dieselbe Prüfung für Inventar, Backups und Warnmeldungen durch. Andernfalls kann eine erfolgreiche Umbenennung unter Linux dazu führen, dass zwei separate Objekte auf diesen Plattformen entstehen.

Wenn nach dem Neustart der alte Hostname wiederhergestellt wird

Wenn der Name wieder seinen vorherigen Wert annimmt, prüfen Sie vor dem Neustart, ob eine Bereitstellungsschicht vorhanden ist. hostnamectlEin Cloud-Image kann den Hostnamen beim Start mithilfe von cloud-init anwenden:

grep -R "preserve_hostname" /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d 2>/dev/null
journalctl -b -u cloud-init --no-pager
cat /etc/hostname
hostnamectl status

Überprüfen Sie außerdem das Hosting-Kontrollpanel, Terraform, Ansible oder das Initialisierungsskript, das die VM verwaltet. Korrigieren Sie die Fehlerquelle, anstatt bei jedem Start erneut zu versuchen, das Problem zu beheben. Sobald der Name stabil ist, wiederholen Sie die Überprüfungen. getent, grabenSSH, Protokolle und Überwachung. Sie werden dann wissen, dass der Server überall dort umbenannt wurde, wo diese Änderung tatsächlich relevant ist.