Wie vor jedem Umzug habe ich mich auch dieses Mal wieder im Netz schlau gemacht, wie man alle Dienste umziehen kann, ohne das Webseiten nicht mehr geladen werden, Emails verloren gehen und auf den DNS Cache gewartet werden muss. Leider gab es nur sehr wenige Informationen und bei den meisten musste man zudem auch diverse Offlinezeiten hinnehmen. Gerade beim Transfer von Postfix und Cyrus gab es keine Lösungen, die ohne Unterbrechung funktionieren. Die Anleitung bezieht sich auf eine Installation von Opensuse Leap 42.3. Abgesehen von einigen abweichenden Pfaden kann sie aber auf die meisten Distributionen angewendet werden.
Grundeinrichtung des neuen Servers
Im ersten Schritt habe ich mir einen neuen Server bestellt und ein Minimal-Image installieren lassen. Damit war der Zugriff auf den Server per SSH möglich. Hier gab es auch schon das erste Problem. Um weitere Dienste zu installieren, brauchte ich YaST2. Dieses war nicht im Image enthalten. Google hatte erst auf der zweiten oder dritten Seite die Lösung. Alle Ergebnisse der ersten Seite waren absolut unbrauchbar. Zur Installation von YaST2 und aller erforderlichen Module zur Serververwaltung wird folgender Befehl über SSH ausgeführt:
Danach kann YaST2 über yast aufgerufen werden. Welche Dienste nun installiert werden, hängt von jedem selbst ab. In der Regel sind die Pakete apache2, postfix, cyrus, bind, mysql-community-server und der persönlich favorisierte FTP-Server dabei. Nachdem die Grundinstallation abgeschlossen ist, machen wir uns an die Config-Dateien der jeweiligen Dienste. Diese müssen am Ende mit denen des alten Server identisch sein.
Damit der alte Server mit dem neuen und natürlich auch umgekehrt kommunizieren kann, muss der öffentliche Schlüssel aus /root/.ssh/id_rsa.pub in die jeweilige /root/.ssh/authorized_keys des jeweils anderen Servers eingetragen werden. Die Datei kann auch id_dsa.pub heißen. Ist keine Datei vorhanden, wird sie mit ssh-keygen -q -N " -f ~/.ssh/id_rsa erstellt. Wer über Passwort in seinen Server einloggt, kann diesen Schritt überspringen.
Konfiguration des neuen Servers
In welcher Reihenfolge die Dienste konfiguriert werden, spielt im Grunde keine Rolle. Als ersten Dienst habe ich mir den Webserver vorgenommen. Da wir hier aber auch schon einige Dateien vom alten Server umkopieren, muss noch dafür gesorgt werden, das die entsprechenden User vorhanden sind. Dafür schauen wir in die Dateien /etc/passwd, /etc/group und /etc/shadow auf dem alten Server. Neben den Usern wie root, cyrus und der anderen installierten Dienste, sind auch die Besitzer der Webs und Postfächer enthalten. Diese und nur diese kopieren wir in die jeweiligen Dateien auf dem neuen Server.
Apache2 Webserver
Die erste wichtige Konfigurationsdatei ist die httpd.conf. Auch wenn hier nicht wirklich etwas geändert werden muss, muss sie mit der alten Version abgeglichen werden. In meinem Fall mussten nur einige Includes eingefügt werden, da ich nicht die default-server.conf verwendet habe, sondern eine eigene Config. Egal ob ihr nun eine eigene oder die Standard Datei verwendet, passt sie an den alten Server an. Nur die IPs müssen natürlich die vom neuen Server sein.
Jetzt wird /etc/sysconfig/apache auf beiden Servern verglichen. In der Regel müssen hier im neuen Server unter dem Parameter APACHE_MODULES noch einige Module hinzugefügt werden.
Sobald das erledigt ist, können die Konfigurationsdateien der Webs kopiert werden. Das geschieht einfach über rsync, das auf dem neuen Server ausgeführt wird. (Pfad kann je nach Distribution abweichen)
In den kopierten Dateien muss jetzt die alte IP durch die neue ersetzt werden. Wem das per Hand zuviel Arbeit ist, kann folgendes Script als ausführbare Datei auf dem neuen Server speichern und es einmal ausführen. Das gleiche Script kann später noch für andere Aufgaben angepasst werden. AlteServerIP und AlteServerIP müssen durch die jeweiligen IP Adressen ersetzt werden.
Jetzt starte ich den Webserver mit rcapache2 start und merze ggf. kleine Fehler aus, die durch den Versionssprung entstanden sein können. Was das genau sein kann, kann in den Logs nachgelesen werden.
Abschließend sorge ich dafür, das der Apache2 als Dienst bei jedem Serverstart/Reboot automatisch startet. Entweder nutzt man dafür YaST2 oder tippt systemctl enable apache2.service in die Konsole.
MySQL Community Server
Im nächsten Schritt habe ich mir die Datenbanken vorgenommen. an der my.conf musste ich nichts verändern. Das umfangreiche und umständliche transferieren der Datenbanken mittels mysqldump habe ich nie gemacht. Oft gab es bei großen Datenbanken jede Menge Fehler und ich durfte manuell eingreifen.Es ist deutlich einfacher, die Datenbanken direkt zu kopieren. (Pfad kann je nach Distribution abweichen)
Damit sind die kompletten Datenbanken inkl. aller Einstellungen auf dem neuen Server und MySQL kann mittels rcmysql start gestartet werden. Auch diesen Dienst lasse ich mittels systemctl enable mysql.service automatisch starten.
Postfix und Cyrus
Diese beiden Dienste bereiten erfahrungsgemäß die größten Probleme. Aber mit den richtigen Handgriffen lassen sich auch diese unterbrechungsfrei übertragen. Bei Cyrus muss in der Regel nichts an Konfigurationsdateien geändert werden. Bei Postfix sieht es schon anders aus.
Als erstes passen wir die neue /etc/postfix/main.cf an die alte an und ersetzen die IP Adressen durch die neue. Die Konfiguration der Email Adressen kann je nach Distribution sehr unterschiedlich sein. Da ich immer noch Confixx verwende, waren alle Mailkonten in einer Datei namens confixx_virtual. Wurde die Standardeinstellung verwendet, liegen sie in /etc/postfix/virtual. In diese kopieren wir den Inhalt der gleichen Datei auf dem alten Server. Damit die Änderung wirksam wird, führen wir noch postmap /etc/postfix/virtual aus.
Es kann jetzt noch sein, dass zusätzliche Dienste wie Spamfilter genutzt werden. Diese müssen dann natürlich auch auf dem neuen Server eingerichtet werden.
Nun holen wir uns sämtliche Postfächer vom alten Server. (Pfad kann je nach Distribution abweichen)
Postfix kann jetzt über rcpostfix start gestartet und über systemctl enable postfix.service automatisiert werden.
Jetzt werden die Daten vom Cyrus IMAP Server auf den neuen Server kopiert. (Pfad kann je nach Distribution abweichen)
In /var/lib/imap löschen wir die deliver.db, die Probleme verursacht und von Cyrus neu aufgebaut wird. Dann fügen wir noch eine neue Datei mit touch /var/lib/imap/user_deny.db ein und passen die Rechte an die der anderen db Dateien in diesem Verzeichnis an. Diese ist nicht vorhanden, wird aber vom Cyrus laufend abgefragt, was an Fehlermeldungen in den Logs zu sehen ist.
Abschließend kann auch Cyrus mit rccyrus start gestartet und mit systemctl enable cyrus.service automatisiert werden.
Wir haben jetzt den neuen Server soweit eingerichtet, dass wir langsam aber sicher mit dem Umschalten beginnen können. Ein kurzer Hinweis noch zum Starten der Dienste. Sind keine RC Scripte vorhanden, kann z.B. Cyrus nicht mit rccyrus gestartet werden. In diesem Fall muss der Pfad wie beispielsweise /etc/init.d/cyrus genutzt werden.
↑ Inhaltsverzeichnis
Transfer der Daten vom alten Server
Da der neue Server weitgehend eingerichtet ist, können wir mit dem Transfer der eigentlichen Daten beginnen. Als erstes holen wir die Stammverzeichnisse der User, in denen auch die Webs liegen. Auf dem neuen Server stoppen wir MySQL und Webserver mit rcapache2 stop und rcmysql stop.
Je nach Umfang kann dieser Schritt eine ganze Weile dauern. Ich musste mehrere Stunden warten, bis alles übertragen war. Das ist auch der Grund, warum dieser Schritt als erstes erfolgt. In der Zwischenzeit können alle erforderlichen Veränderungen am alten Server vorgenommen werden. Kurz bevor diese durch einen Reload des Webservers aktiviert werden, muss obige Zeile erneut ausgeführt werden, damit Änderungen, die zwischenzeitlich erfolgten auch übertragen werden. Das gleiche gilt auch für die Datenbanken, die noch einmal synchronisiert werden müssen.
Vorbereitung einer Umleitung aller Webseiten
Damit die Umleitung via Proxy funktioniert, muss auf dem alten Server /etc/sysconfig/apache aufgerufen werden. Dort ergänzen wir die lange Liste der Module unter APACHE_MODULES um proxy und proxy_http, sslproxy und sslproxy_http.
Dann wechseln wir in das Verzeichnis /etc/apache2/vhosts.d. Die folgenden Änderungen müssen natürlich auch auf alle anderen Configs angewendet werden, die möglicherweise noch existieren. Ich habe z.B. noch einige unter /etc/apache2/special.d liegen.
Jede Virtualhost Direktive ergänzen wir direkt unter ServerName bzw. ServerAlias um die folgenden Zeilen:
Der neue Eintrag müsste dann in etwa so aussehen:
Bei einem Web mit SSL muss der einzufügende Codeschnipsel etwas anders aussehen:
SSLProxyEngine On SSLProxyCheckPeerCN on SSLProxyCheckPeerExpire on ProxyPass / https: //NeueIPAdresse/ ProxyPassReverse / https: //NeueIPAdresse/
Das wiederholen wir für alle Dateien in diesem Ordner. Virtualhost Direktiven mit einem Redirect lassen wir jedoch außen vor.
Unterbrechungsfreier Umzug der Webseiten
Wie oben schon erwähnt führen wir auf dem neuen Server erneut folgende Befehle aus:
Jetzt starten wir auf dem neuen Server Apache und MySQL mit rcapache2 start und rcmysql start. Ohne Verzögerung laden wir auf dem alten Server mit rcapache2 reload unsere Änderungen in den Server. Das war es auch schon und sämtliche Webs laufen auf dem neuen Server.
Vorbereitung der Umleitung aller Emailkonten
Dieser Teil bereitet den meisten Kopfzerbrechen. Änderungen im DNS brauchen bis zu 48 Stunden. Daher landen einige noch auf dem alten Server, während andere bereits den neuen ansteuern. Wohin also mit den Emails? Alle einfach weiterleiten? Was ist dann mit denen, die noch auf dem alten Server abrufen? Oft wird hier der Weg über /etc/postfix/transport empfohlen. Das funktioniert soweit auch gut. Alle eingehenden Mails werden auf den neuen Server weitergeleitet. Es hat aber keinen Einfluss auf POP und IMAP, also das Abrufen der Mails. Es nützt wenig, wenn alle Mails auf dem neuen Server liegen, während der Kunde immer noch auf dem alten einloggt und sie abzurufen versucht. Also müssen wir sämtliche Ports weiterleiten und dazu eignet sich xinetd (muss ggf. über YaST2 installiert werden) hervorragend. Als erstes stoppen wir Postfix und Cyrus auf dem neuen Server mit rccyrus stop und rcpostfix stop.
Damit der neue Server diese Mails aber auch annimmt, müssen wir ihm nun sagen, das der alte Server vertrauenswürdig ist. Das geschieht in der /etc/postfix/main.cf des neuen Servers. Sofern noch nicht geschehen, entfernen wir das # vor mynetworks und ergänzen es um die IP des alten Servers. Fertig sieht das dann etwa so aus:
Wir erstellen jetzt für jeden Port eine Datei in /etc/xinetd.d. Das folgende Beispiel zeigt die Weiterleitung des SMTP Ports:
Diese Datei speichern wir als /ect/xinetd.d/forward-25. Für die Ports 110, 143, 587 und 995 legen wir ebenfalls Dateien an und ersetzen immer die Ports. Falls euer Mailserver andere Ports nutzt, müssen natürlich dafür die Dateien erstellt werden.
Dateiname: /ect/xinetd.d/forward-PORTNUMMER
Übertragen und aktivieren der Mailkonten auf dem neuen Server
Jetzt kommen wir zum entscheidenden Part. Folgende Schritte sollten schnell gehen. Am besten öffnet man dazu jeden Server in einem eigenen Terminal und tippt die Befehle bereits vor.
1.) Erneute Synchronisation der Mailkonten: (Auf dem neuen Server ausführen)
Die Datei /var/lib/imap/deliver.db wieder löschen. Kann auch nach den folgenden Schritten passieren, damit es keine Downtime gibt.
2.) Postfix und Cyrus auf dem alten Server abschalten: (Auf dem alten Server ausführen)
3.) Postfix und Cyrus auf dem neuen Server starten: (Auf dem neuen Server ausführen)
4.) Die Umleitungen auf dem alten Server aktivieren: (Auf dem alten Server ausführen)
Jetzt werden alle eingehenden Mails auf den neuen Server weitergeleitet. Darüber hinaus landen auch die Kunden auf dem neuen Server, wenn sie ihre Mails abrufen wollen und bekommen vom Wechsel nichts mit. Auf diese Weise habe ich gerade 2 Server umgezogen, ohne eine Downtime zu haben und auf Nameserver achten zu müssen.
Abschließend werden die Domains auf dem Server beim Provider oder den eigenen Nameservern mit der neuen IP Adresse versehen. Wie lange es dann dauert, bis die neue IP weltweit bekannt ist, spielt dank der Umleitungen keine Rolle.
↑ Inhaltsverzeichnis
