Meine mittels Drupal (Version 5.3) gestaltete Seite sollte auf eine neue Hardware umziehen (beim gleichen Provider). Zudem sollte (später!) auch die Drupal-Version auf den aktuellen Stand (Version 6.19) gebracht werden (dazu wird es in Kürze hier einen eigenen Beitrag geben. Nur soviel vorab: Es ist gelungen).

Im W3 gab es verschiedene Anleitungen zu diesem Umzugs-Szenario (Update blieb erst Mal außen vor), u.a. gelegentlich der Hinweis, dass dies auch 1:1 - also per "einfachem" kopieren - ging. Das weckte mein Interesse, ob dies tatsächlich "so einfach" sein konnte (vorweg: War es nicht, aber passieren konnte nicht viel, da meine bisherige Web-Präsenz ja nicht damit abgeschaltet wurde). Deshalb habe ich es zunächst auf die 1:1-Methode versucht bzw. gemacht.

Ausgehend von dieser Anleitung (englisch) für Debian 5 (Lenny) habe ich auf einem neuen Root-Server mit Ubuntu 10.04 LTS einen Mail-Server aufgesetzt. Dabei stieß ich zunächst auf nur geringfügige Unterschiede zwischen den beiden Linux-Derivaten bzw. -Distributionen.

Vorweg genommenes Fazit: Am Ende hatte ich einen funktionierenden Mail-Server mit Spam-Erkennung (Markierung) und Virenschutz für verschiedene Domains und mehrere Mail-Konten.

Nachfolgend einige Probleme, die ich bei der Installation (zu lösen) hatte:

Ich weiß nicht, ob es an der SSH-Verbindung liegt, aber wenn ich in einer solchen Session umfangreiche Kopieraktionen von einem Server auf meinen lokalen Rechner (z.B. zum Backup von Internet-Web-Servern) starte, bricht die Sitzung während des Einlesens der Verzeichnisse und Dateien reproduzierbar zusammen und die entsprechende gFTP-Sitzung schließt sich.

Sehr oft erhalte ich mittlerweile bei der Pflege meiner Websites auf meinem Power-vServer bei Strato die Meldung:

Unable to connect to database server
...
The MySQL error was: #HY000Can't create a new thread (errno 11); 
if you are not out of available memory, you can consult the manual 
for a possible OS-dependent bug.
...

Diese Meldung (Anzeige / Wortlaut beeinflusst durch mein Drupal-CMS) erhielt ich in der Standard-Server-Konfiguration schon beinahe nach jedem 2. bis 4. Änderungs- / Neueintrag in der MySQL-Datenbank von Drupal. Nach einer Optimierung der Memory-Funktionen des MySQL-Dienstes trat eine kurzzeitige Besserung dieses Zustandes ein (für 2 Tage, um genau zu sein).

Trotz "ServerSignature off" in den *.conf-Dateien wird in den Fehlerseiten (z.B. 404er) des Apache2 die Signatur mit Versionsangabe angezeigt. Das liegt daran, dass - wenn Sie keine eigenen Fehlerseiten definiert haben - die Standard-Fehlerseiten des Apache Verwendung finden.

netstat liefert Protokollstatistiken
-a zeigt alle offenen Verbindungen (UDP ist verbindungslos)
-r Routing-Tabelle
-s Protokollstatistiken
-h wie immer Erklärungen zu den restlichen Optionen.

Man kann über das Absichern eines vServers per "Firewall" geteilter Meinung sein. Einiges dazu finden Sie z.B. in diesem Foren-Thread.

Ich möchte für meine per PHP/MySQL erzeugten dynamischen Web-Seiten nicht den vom vServer-Provider hinterlegten root-Zugang nutzen (weil der meist das selbe Passwort hat wie der Shell-Benutzer "root"). Diesen Zustand sollte man zwar eh schnellstmöglich ändern, aber dennoch...

Ich habe mir nach dem Eklat mit meinem bisherigen Hoster (Reseller) einen am Markt etwas etablierteren Provider gesucht und nach 4 Wochen für die KK-Anträge endlich auch in Betrieb nehmen können. Zunächst habe ich versucht dafür zu sorgen, dass ich E-Mail-mäßig wieder erreichbar war.