Ich muss zugeben, ich bin begeistert, wie offen ispCP Omega für Änderungen durch den Benutzer im Backend ist, wenn dieser weiß, was er denn tun möchte. So geschehen heute, als ich einen kleinen Fehler in meiner Server-Konfiguration behoben habe: Bei der Einrichtung des Servers wurde ispCP auf die falsche der beiden IP-Adressen gebunden. Dies über das Webinterface zu korrigieren ist eine einzige Klick-Orgie und braucht einfach zu lange. Schneller geht es da mit einem beherzten Griff in die Datenbank des Systems.
Bevor man nun versucht, die IP zu ändern, sollte man mit dem groben Vorgehen vertraut sein. Hierbei hilft die Dokumentation von ispCP, in der ein recht ähnliches Szenario im Detail erklärt wird. Ziel dort ist es, eine bestehende Installation von ispCP auf einen fremden Server umzuziehen. Will man aber eine bestehende Installation auf dem gleichen Server belassen und nur die IPs ändern, unter denen diese erreichbar ist, so entfallen eine Reihe von Schritten, während man an anderer Stelle noch etwas nacharbeiten muss.
Fangen wir also an, unseren Server von 127.0.0.1 nach 192.168.0.1 umzuziehen (mal als Beispiel). Dazu begeben wir uns als erstes in die Datenbank von ispCP und öffnen dort die Tabelle server_ips. In dieser Sollte bereits ein Datensatz ähnlich zu Datensatz 1 stehen. Hier ergänzen wir einen weiteren analog dem Beispiel aus Datensatz 2:
ip_id 1
ip_number 127.0.0.1
ip_domain localhost
ip_alias localhost
ip_id 2
ip_number 192.168.0.1
ip_domain somehost
ip_alias aliasname
Änderungen speichern und weiter! Unser nächster Stopp ist die Tabelle domain. In dieser gibt es eine Spalte domain_ip_id. Hier ändern wir für jede Domain, die wir auf die neue IP umziehen wollen den dort eingetragenen Wert und setzen gleichzeitig das Feld domain_status auf change. Sollte das Ändern des Domain-Status vergessen werden, wird die Änderung nicht übernommen, sondern bleibt solange, bis an dieser Domain irgendeinmal eine Änderung stattfinden soll vorgemerkt.
Zu beachten ist hierbei speziell auch eine Eigenheit, die mir kurzzeitig vorhin meinen Blog lahmgelegt hat: Da Sub-Domains keine eigene IP-Zuweisung besitzen, gilt eine Änderung der IP IMMER global für alle Subdomains mit. Wird also die IP einer Domain geändert, müssen auch alle Subdomains in der Tabelle subdomain, die zu dieser Domain gehören auf den Status change gesetzt werden. Vergisst man dies, wird dies mit der Nichterreichbarkeit der betroffenen Subdomains (unter der neuen IP) bestraft – und genau dieses Schicksal ist meinem Blog vorhin wiederfahren 😉
Das Gleiche wiederholen wir nun in der Tabelle domain_aliases: Diesmal sind die beiden benötigten Spalten alias_ip_id und alias_status. Das Vorgehen ist identisch zu dem bei Domains. Auch hier muss unbedingt darauf geachtet werden, dass man alle betroffenen Subdomain-Aliase in der Tabelle subdomain_alias, auch auf geändert setzt, da diese sonst genauso funktional sind, wie im Fall normaler Subdomains 😉
Hätten wir eigentlich fast alles erledigt, was die Backend-Konfiguration angeht. Einzig die Überwachungs-Einstellungen für den Server-Status wären jetzt noch zu erledigen, sollte man die neue IP der Domains überwachen lassen (an Stelle der alten). Hierzu öffnet man die Tabelle config und sucht die Konfigurationszeile ‚PORT_HTTP‘ in der etwas ähnliches wie ’80;tcp;HTTP;1;0;127.0.0.1′ stehen sollte. Hier passt man am Ende einfach die IP an (also ’80;tcp;HTTP;1;0;192.168.0.1′) und speichert. Je nach Wunsch, wiederholt man dies für ‚PORT_HTTPS‘.
Ferner sollte man beachten, dass man die neue IP bei seinen Resellern korrekt einträgt. Hierzu dient die Tabelle reseller_props, und die Spalte reseller_ips, in der die IDs der erlaubten IPs für diesen Reseller durch Semikolon getrennt eingetragen werden. Jeder Eintrag ist dabei mit einem Semikolon abzuschließen.
Nach dem wir nun alle Einstellungen getätigt haben, kann es an’s übernehmen gehen. Hierzu verbinden wir uns auf eine Root-Shell auf dem Server und führen ein beherztes
/var/www/ispcp/engine/ispcp-rqst-mngr
aus. Dieser Vorgang kann nun, je nach Anzahl der geänderten Domains durchaus eine Weile brauchen (bei mir hat das für 12 Domains + 40 Aliase 3 Minuten gedauert). Nach dem ispCP fertig ist,, sollte man zudem noch einmal explizit den Apache neustarten:
apache2ctl restart
Nach dem nun die neuen IPs bereits in der Konfiguration eingetragen sind, und korrekt funktionieren, verrät ein Blick mit
apache2ctl -S
die aktuelle Konfiguration. Diese beinhaltet, wie in der Dokumentation von ispCP beschrieben auch noch die alten vHosts unter den nun obsoleten IPs. Da das Ändern einer IP im Internet jedoch durchaus 1-2 Tage brauchen kann, sollte man diese für’s Erste noch in der Konfiguration belassen und sich nun um die Aktualisierung der DNS-Einträge im Nameserver kümmern, sofern dieser extern ist. Läuft dieser lokal, hilft es, die Zonefiles wie in der Dokumentation beschrieben, von den alten IPs zu reinigen.
Sollte nun, nach dem Abwarten des Cache-Timeouts der Nameserver-Einträge der Zugriff nur noch über die neue IP stattfinden, kann man die alten vHost-Blöcke aus der Konfigurationsdatei /etc/apache2/site-enabled/ispcp entfernen. Nach dem Übernehmen dieser Änderung ist man fertig und kann seine Domains auf der neuen IP benutzen.
