Es hat sich was im Hintergrund getan …
Wie soll ich sagen … man wird es hoffentlich kaum gemerkt haben, aber in den letzten Tagen war ich damit beschäftigt einige Arbeiten im Hintergrund dieses Blogs zu erledigen. Es war schon eine längere Zeit fällig, aber nun habe ich das endlich mal in Angriff genommen!
Ich habe meinen Server umgezogen!
Um ehrlich zu sein, war das auch wirklich notwendig! Ich habe zwar immer ganz ordentlich die diversen Sicherheitsupdates eingespielt und immer mein Blog auf dem aktuellsten Stand gehalten, aber dennoch gab es hier die eine oder andere Schwachstelle im System, die sich nicht mehr beheben lassen wollte, da das eingesetzte Betriebssystem mittlerweile einfach out-dated war.
Anyway … hier will ich dann mal kurz und grob beschreiben, wie der Umzug so abgelaufen ist.
Im ersten Schritt habe ich mir erst einmal angeschaut, was denn so alles auf meinem alten System läuft:
- insgesamt zeigten 15 unterschiedliche Domains auf meinen Web-Server
- jeder Domain hatte einen Mail-Server konfiguriert
- es liefen zwei Blogs auf meinem System
- es liefen zwei CMS auf meinem System
- es waren diverse virtuelle Apache-Hosts mit diversen Sub-Domains konfiguriert
- auf den anderen Domains waren „Standard Webpages“ eingerichtet
- Benutzer waren kaum auf dem System angelegt – insgesamt nur 3 Standard-User und ein Admin-Account
- bei den Mail-Servern war clamav und SpamAssasin eingebunden
- es gab drei Webmail-Seiten
- im MySQL-Server waren diverse Datenbanken eingebunden
Im Grunde ist das alles kein sonderlich großes Hexenwerk, aber die Masse machte den Umzug dann doch ein wenig komplizierter. Um das ganze ein wenig zu vereinfachen, habe ich mir im nächsten Schritt überlegt, was denn überhaupt wirklich umgezogen werden soll bzw. ob es nicht sogar etwas gibt, was ich so gar nicht mehr brauche.
- die Domains
Bingo! Hier habe ich schon mal ganz kräftig aufgeräumt! Insgesamt habe ich sage und schreibe 7 Domains gekündigt! Nicht alle diese 7 Domains waren rein meine Domains und/oder nur just-for-fun. Bei 4 Domains habe ich mich an die Leute gewendet, für die ich die nur gehostet habe. Eigentlich habe ich ihnen angeboten hier bei einem ggf. notwendigen Umzug zu helfen, aber letztendlich wurden 4 Domains nach mehreren Monaten ohne Rückmeldung von mir gekündigt. Gleiches gilt für die restlichen drei Fun-Domains, die auf meinem Server liefen.
Poff! Und schon war es weniger umzuziehen. :top_ang:
- wie sollte es zukünftig laufen?
Im nächsten Schritt habe ich mir nun überlegt, wie der Server denn dann zukünftig aussehen sollte. Klar war, dass da wieder ein Web-Server mit diversen VHosts drauf sollte und natürlich sollte da auch wieder ein ordentlicher Mail-Server drauf. Also …
- Web-Server aussuchen
- Mail-Server aussuchen
- POP3 oder IMAP? Ich habe mich für Pop3 entschieden
- Root-Mail-Client (Eigenbau)
- Webmail-Client
- ab sofort nur noch via SSL!
Nachdem ich mir diverse Web-Server angeschaut hatte, habe ich mich für den entschieden, der auch schon auf dem alten Server lief. Einzige Änderung hier … ich habe die aktuellste Version installiert und nur noch die Mods, die ich auch wirklich benötige. Klarer Vorteil: Hier weiß ich genau, wie der konfiguriert wird und was ich wo einstellen muss.
Beim Mail-Server habe ich mich gar nicht groß umgeschaut, denn ich wollte das eigentlich so lassen, wie es war… tja … eigentlich. Problem hierbei … mein eingesetzter POP3-Server wird so nicht mehr unterstützt und ist in der momentan aktuellen Distribution gar nicht mehr enthalten :-? Also musste doch eine Alternative her. Na immerhin konnte ich meinen Message Transfer Agent (MTA) weiter einsetzen.
Die restlichen Punkte sollte im Grunde so bleiben, wie sie waren … also das Blog sollte weiter so bleiben, die MySQL-Datenbanken sollten so bleiben und nur die CMS konnten weg, da die zugehörigen Domains auch weg waren.
- MTA & Pop3
Um hier entsprechend den MTA und den POP3-Server problemlos einrichten und testen zu können, ohne eine direkte Auswirkung auf die alten Domains zu haben, habe ich zwei neue Domains geordert und auf den neuen Server zeigen lassen. Nachdem die beiden Domains entsprechend geordert waren und ordentlich im Nameserver hinterlegt waren, konnte ich das testen. Wie bereits gesagt, habe ich mich wieder für meinen alten MTA entschieden. Also die neueste Version installiert und eingerichtet. Wichtig hierbei war das einrichten der „virtuell user“, was aber mehr oder minder problemlos klappte.
Im nächsten Schritt musste also nun ein POP3-Server her und dieser musste ja auch mit den virtuellen Benutzern und mit mehreren Domains auf ein und der selber IP umgehen können. Ich habe mir diverse Möglichkeiten angeschaut, sie installiert, sie versucht zu testen und dann wieder verworfen … :smiley_hammer_ang: … bis ich endlich einen POP3-Server gefunden habe, der das macht, was ich brauchte.
Eigentlich war ja mal die Überlegung, den POP3-Server auch direkt sicherer zu machen und nur noch einen verschlüsselten Verkehr via TLS zu erlauben, aber das stellt sich als nicht so leicht bei Multiple-Domains dar. Muss ich mir also später mal genauer anschauen, ob das nicht mit SNI umgesetzt werden kann.
Immerhin klappte jetzt der Empfang von Mails und das Bereitstellen via POP3. :top_ang:
- Schritt für Schritt
Als nächstes habe ich mir nun eine Liste mit notwendigen Schritte für den Umzug erstellt.
- Web-Server Directory anlegen /home/web-server/<DOMAIN>/default.WEB/
- Web-Server Dateien vom alten auf den neuen Server kopieren
- User für eMail anlegen (ACHTUNG!!! Home-Verzeichnis richtig setzen!)
- Virtuser-Datei für Domain anlegen
- Apache-Konfiguration anlegen
- Domain im MTA hinterlegen
- für die Domain den Nameserver-Eintrag anpassen (auf neue IP)
- Domain vertragstechnisch auf den neuen Server übertragen
- Apache & MTA RESTART (vorher nameserver IP ändern)
- Test-Mail aus Google an alle neuen Mailboxen (siehe 4.)
- umkopieren der alten Mails vom alten Server auf den neuen (ACHTUNG! Permission!!!)
- Boxen auf altem Server löschen bzw. weg-kopieren nach ~/root/Data/<BACKUP>
- auf altem Server User ändern „^WEG-*“ (auch im Passwort-File)
- auf altem Server die Apache Config wegkopieren /root/Data/Migrated_Server/<DOMAIN>
- auf altem Server die Einstellung im MTA ändern (Domain weg)
- Apache und MTA auf altem Server RESTART
- unter Root-Page Mail-User eintragen
Das sind schon mal reichlich Schritte, aber sie gelten auch nur für „einfache“ „Standard“-Domains. Zusätzlich musste hier ja auch noch der Übertrag der Blogs berücksichtigt werden. Hierzu dann später noch mehr.
- der erste Test-Ballon
So .. eigentlich alles soweit vorbereitet, dann kann ja jetzt der erste Test starten! :rock_ang:
Ich habe mir also eine Domain ausgesucht, die aus meiner Sicht recht einfach sein sollte. Nur wenige eMail-Boxen, eine ganz einfache HTML-Seite und nichts extrem wichtiges. Also schön Schritt für Schritt abarbeiten und schauen, ob das alles problemlos funktioniert. Natürlich hat das nicht alles problemlos funktioniert :cry: Hier mal die Punkte, die gehakt haben:
–> Nameserver wurde nicht ordentlich aktualisiert
Ursprünglich sollte mein Service-Provider die Namesserver-Einträge entsprechend anpassen. Ich habe einen internen Domainumzug von Vertrag A auf Vertrag B beantragt und ausgewählt, dass hier der Nameserver-Eintrag entsprechend aktualisiert werden sollte. Ich habe dann ein Trouble-Ticket bei meinem Service-Provider eröffnet, habe hier aber nur unqualifizierte Antworten bekommen „…das dauert halt bis zu 48 Stunden … da müssen sie sich gedulden ….“ Geduld!? Schön und gut, nur das bedeutete für mich, dass ich regelmäßig den Nameserver abfragen musste, um mitzubekommen, wenn das endlich aktualisiert ist. Ein Tip von mir: die Android-App „PingTools Network Utilities“ von StreamSoft. Eine geniale App, die alles beinhaltet, was man braucht!
Nachdem hier weiter nichts passiert ist, habe ich ein Update auf das Ticket gemacht und ein anderer Technik hat mir erklärt, wie ich die Nameserver-Einträge selber aktualisieren konnte. Nachdem ich die Einträge selber bereinigt hatte, lief es auch problemlos!
–> Mails abgelehnt
Nachdem ich die Mailboxen entsprechend im zugehörigen Mail-Client aktualisiert hatte (Benutzername sind nun wesentlich strukturierter auf dem neuen Server und die Passwörter sind jetzt WIRKLICH sicher!), konnte das erst einmal ausführlich getestet werden. Eigentlich lief das auch soweit … bis ein Reply an eine Web.de eMail-Adresse mit Fehler zurück kam. Fehlermeldung: „554-Bad DNS PTR resource record.“ Nach kurzer Suche im Netz scheint es so zu sein, dass Web.de meine eMails als Spam klassifiziert. Das Problem liegt hier bei meinem Server-Provider, denn der Reverse-DNS-Eintrag zeigt auf den Service-Provider bzw. einen internen Domainnamen vom Service-Provider und das klassifiziert Web.de als Spammer.
Da ich ja nun wusste, wie ich den Nameserver aktualisieren konnte, habe ich geschaut, ob ich hier auch den PTR setzen konnte und in der Tat konnte ich den Reverse-DNS-Eintrag auf eine meiner Domains ändern. Kaum war das erledigt, ging auch die eMails an web.de raus.
- Nach und nach … MySQL & Blog
Nachdem ich den Test-Ballon einige Tage habe fliegen lassen, konnte ich nach einer Weile ohne weitere Fehler mit dem nächsten Schritt fortfahren. Als nächstes Schritt hatte ich mir eine Domain ausgesucht, auf der ein Blog läuft. Hier musste also auch noch folgendes zusätzlich umgezogen werden:
–> die Blog-Software (wordpress)
–> die MySQL-Daten
Hier war die Überlegung direkt den Datenbank-Namen etwas sicherer zu gestalten (sprich länger als vorher) und der MySQL-User sollte auch abgesichert werden. Auf dem alten Server war das ja alles mehr Try-And-Error und nun konnte das Neuaufsetzen etwas strukturierter statt finden. Im ersten Schritt habe ich die alte Datenbank ausgelsen:
login to old server OLDserver:~# mysqldump -u root -p BLOGDB > MySQL_BLOGDB.sql
Nun lag also der Inhalt der Datenbank im File „MySQL_BLOGDB.sql“ vor und ich konnte das File via scp auf den neuen Server übertragen. Hier auf dem neuen Server habe ich nun eine neue Datenbank inklusive zugehörigem User anglegt:
login to new server
NEWserver:~# mysql -u root -p
mysql> create database MY_WEB_BLOG;
mysql> grant all privileges on MY_WEB_BLOG.* to newbloguser@localhost
identified by '<strong-password>';
mysql> flush privileges;
mysql> quit
Jetzt gab es also die neue Datenbank und es gab einen entsprechenden User. Eigentlich hätte jetzt nur die Datenbank (also das sql-File) zurückgespielt werden müssen, aber ich greife hier mal vorweg … es ging nicht. Hintergrund hier … ich habe ja jetzt alles auf SSL umgestellt, sprich auf wenn man http://www.domain.de eingibt, wird man automatisch auf https://www.domain.de umgeleitet. Außerdem hat sich die Sub-Domain von vormals „WP.“ auf „www.“ geändert. Leider sind teilweise aber die Pfade hardcoded in der SQL-Datenbank. Gleiches trifft auch auf die wirklcih Pfadangabe zu. Also habe ich vorher das sql-File entsprechend aktualisiert:
login to new server NEWserver:~# cp MySQL_BLOGDB.sql MySQL_BLOGDB.sql_BAK NEWserver:~# vim MySQL_BLOGDB.sql :%s!http://WP.!https://www.!g :%s!!!g ZZ
Jetzt war das SQL-File also entsprechend angepasst und konnte wieder in die Datenbank:
login to new server NEWserver:~# mysql -u newbloguser -p MY_WEB_BLOG < MySQL_BLOGDB.sql NEWserver:~# mysqladmin -u root -p flush-privileges
Nachdem alles wieder eingespielt war, musste noch schnell die Config entsprechend angepasst werden (also auf den neuen User, die neue DB und das neue Passwort) und schon lief auch alles wieder.
… :big_victory_ang: …
- Der Rest
Da nun die beiden Test-Ballons erfolgreich am fliegen waren, konnte ich nach und nach die weiteren wichtigen Domains aufsetzen. Nach und nach habe ich nun die Domains umgezogen und bisher läuft alles einwandfrei!
Sodele … jetzt noch den alten Server kündigen und dann sollte ich erst einmal wieder Up-To-Date sein!
Solltet ihr jedoch irgendwelche Fehler bemerken, dann wäre es prima, wenn ihr mir kurz eine Nachricht zukommen lassen könntet!
Merci
. :big_bye_ang: .
Last 10 Comments