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 \u00f6ffnen dort die Tabelle server_ips. In dieser Sollte bereits ein Datensatz \u00e4hnlich zu Datensatz 1 stehen. Hier erg\u00e4nzen wir einen weiteren analog dem Beispiel aus Datensatz 2:<\/p>\n
\r\nip_id 1\r\nip_number 127.0.0.1\r\nip_domain localhost\r\nip_alias localhost\r\n\r\nip_id 2\r\nip_number 192.168.0.1\r\nip_domain somehost\r\nip_alias aliasname\r\n<\/pre>\n\u00c4nderungen speichern und weiter! Unser n\u00e4chster Stopp ist die Tabelle domain. In dieser gibt es eine Spalte domain_ip_id. Hier \u00e4ndern wir f\u00fcr 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 \u00c4ndern des Domain-Status vergessen werden, wird die \u00c4nderung nicht \u00fcbernommen, sondern bleibt solange, bis an dieser Domain irgendeinmal eine \u00c4nderung stattfinden soll vorgemerkt.<\/p>\n
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 \u00c4nderung der IP IMMER global f\u00fcr alle Subdomains mit. Wird also die IP einer Domain ge\u00e4ndert, m\u00fcssen auch alle Subdomains in der Tabelle subdomain, die zu dieser Domain geh\u00f6ren 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 \ud83d\ude09<\/p>\n
Das Gleiche wiederholen wir nun in der Tabelle domain_aliases: Diesmal sind die beiden ben\u00f6tigten 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\u00e4ndert setzt, da diese sonst genauso funktional sind, wie im Fall normaler Subdomains \ud83d\ude09<\/p>\n
H\u00e4tten wir eigentlich fast alles erledigt, was die Backend-Konfiguration angeht. Einzig die \u00dcberwachungs-Einstellungen f\u00fcr den Server-Status w\u00e4ren jetzt noch zu erledigen, sollte man die neue IP der Domains \u00fcberwachen lassen (an Stelle der alten). Hierzu \u00f6ffnet man die Tabelle config und sucht die Konfigurationszeile ‚PORT_HTTP‘ in der etwas \u00e4hnliches 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\u00fcr ‚PORT_HTTPS‘.<\/p>\n
Ferner sollte man beachten, dass man die neue IP bei seinen Resellern korrekt eintr\u00e4gt. Hierzu dient die Tabelle reseller_props, und die Spalte reseller_ips, in der die IDs der erlaubten IPs f\u00fcr diesen Reseller durch Semikolon getrennt eingetragen werden. Jeder Eintrag ist dabei mit einem Semikolon abzuschlie\u00dfen.<\/p>\n
Nach dem wir nun alle Einstellungen get\u00e4tigt haben, kann es an’s \u00fcbernehmen gehen. Hierzu verbinden wir uns auf eine Root-Shell auf dem Server und f\u00fchren ein beherztes<\/p>\n
\/var\/www\/ispcp\/engine\/ispcp-rqst-mngr<\/pre>\naus. Dieser Vorgang kann nun, je nach Anzahl der ge\u00e4nderten Domains durchaus eine Weile brauchen (bei mir hat das f\u00fcr 12 Domains + 40 Aliase 3 Minuten gedauert). Nach dem ispCP fertig ist,, sollte man zudem noch einmal explizit den Apache neustarten:<\/p>\n
apache2ctl restart<\/pre>\nNach dem nun die neuen IPs bereits in der Konfiguration eingetragen sind, und korrekt funktionieren, verr\u00e4t ein Blick mit<\/p>\n
apache2ctl -S<\/pre>\ndie aktuelle Konfiguration. Diese beinhaltet, wie in der Dokumentation von ispCP beschrieben auch noch die alten vHosts unter den nun obsoleten IPs. Da das \u00c4ndern einer IP im Internet jedoch durchaus 1-2 Tage brauchen kann, sollte man diese f\u00fcr’s Erste noch in der Konfiguration belassen und sich nun um die Aktualisierung der DNS-Eintr\u00e4ge im Nameserver k\u00fcmmern, sofern dieser extern ist. L\u00e4uft dieser lokal, hilft es, die Zonefiles wie in der Dokumentation beschrieben, von den alten IPs zu reinigen.<\/p>\n
Sollte nun, nach dem Abwarten des Cache-Timeouts der Nameserver-Eintr\u00e4ge der Zugriff nur noch \u00fcber die neue IP stattfinden, kann man die alten vHost-Bl\u00f6cke aus der Konfigurationsdatei \/etc\/apache2\/site-enabled\/ispcp entfernen. Nach dem \u00dcbernehmen dieser \u00c4nderung ist man fertig und kann seine Domains auf der neuen IP benutzen.<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"