Problem

Nach dem Eintragen der Migrationsdaten wie Serveradresse des alten Servers etc.  steht das nicht editierbare Ziel-Server Feld noch auf  “IP address not found“.

Server IP-Adressmaske

So gelangt man zur Eingabemaske:

Linke Navigationsleiste:
- Servermanagement / Tools & Utilities
Dann Auswahl des Gruppenicons
-  IP-Adresses

Umstellung auf Shared-IP

Von Dedicated auf Shared umstellen

Migration Manager

Nach dem Wechsel auf die Eingabemaske des Migration Managers kann man nunmehr die Ziel-IP in einem Dropdownfeld auswählen.

Migrationsfortschritt

Der grüne Fortschrittsanzeige ist zwar nicht schlecht, aber aussagekräftiger ist die Maske, die sich öffnet, wenn man auf den linken Link drückt.  Dann wird einem nämlich angezeigt, welches Ablaufschritt bei der Migration gerade ausgeführt wird, was auch bei der Fehlersuche hilfreich ist.

Der Hauptgrund für die Probleme dürfte m.E. in der Änderung des Businesskonzepts (Reseller/Client/Customer) liegen, so dass der Migration Manager  oft damit zu kämpfen hat, die Daten von der alten Struktur automatisch in die neue zu transferieren.

Einleitung

Hauptgrund für den Versionswechsel war, dass die Version Plesk 10.3 zusammen mit Ubuntu 10.04 LTS gebundelt ist, also auch ein Softwareupdate für Pakete wie PHP, Apache, und Co. beinhaltete, was teilweise gewünscht/erforderlich war.

Sicherheitsaspekte spielten keine Rolle, hier hätte man bei der Version Plesk 9.x bleiben können.

Achtung
Um mein Fazit gleich vorweg zu nehmen: Bei Plesk 10 hat sich das Bedienkonzept entscheidend verändert (s.u.),  so dass ich im Nachhinein einfach nur davon abraten kann, einen ganzen Server (mit verschiedenen Clients, Domains und Anwendungsinstallationen) mit Hilfe des Migrationsmanagers von Plesk umziehen zu wollen.

Bei jedem Fall (Client/Domain) traten andere Migrationsfehler auf. Die Errormeldungen sind nicht immer sehr hilfreich, aber man muss froh sein, wenn man überhaupt welche erhält, denn manchmal bricht der Migrationsvorgang auch nur mit “Failed” ab.

Wenn man also nicht wirklich einen Mehrgewinn durch einen Plesk Versionswechsel hat, dann gilt die alte Regel: “Never change a winning team” und man sollte sich darauf beschränken, den einzelnen Client oder die Domain, die es erfordert, auf einen neuen Server zu portieren.

Läuft die automatische Migration hierbei, dann ist alles Gut, ansonsten lieber eine Anwendungsneuinstallation auf dem Zielsystem mit Import der Altdaten.  Nicht groß versuchen, den Plesk-Automatismus zum Laufen zu bringen. Lohnt sich nicht.

Dokumentation des Programmherstellers

Wer sich dennoch an die Migration heranmachen möchte, findet folgende unterstützende Dokumentation:

Plesk Provider Handbuch: Der Wechsel auf Panel 10

Die deutsche Übersetzung ist teilweise sehr schlecht und irritiert mehr, als dass sie hilft.
Hier zwei Textauszüge als Beispiel:

1.) Widersprüchliche Aussagen innerhalb einer kurzen Textpassage:

In Panel 10 gibt es keine Kunden-Accounts und Domainadministrator-Accounts mehr. Für Benutzer, die ihre Hostingdienste weiterverkaufen und ihre eigenen Websites hosten, müssen Sie Reseller-Accounts anlegen. Für Benutzer, die ihre Hostingdienste nicht weiterverkaufen, aber nur ihre eigenen Websites hosten, müssen Sie Kunden-Accounts anlegen.

2.) Wahrscheinlich keine Übersetzer aus der techn. Fachrichtung

Dieser Link ist permanent und kann nicht beschädigt werden, daher kann eine Domain nicht von einem Abonnement auf ein anderes übertragen werden.

Hilfen für die Fehlersuche

Um Fehlern auf die Spur zu kommen, sei auf einen Plesk-Knowledgebase Artikel hingewiesen, in dem man für die Migration den Speicherpfad für die Fehler- und Ausführungslogdateien erfährt:

Structure of Plesk Migration Manager logs

Aufgetretene Probleme

Ohne Vollständigkeit hier ein paar Fehler/Probleme, die bei der Migration aufgetreten sind:

• Ziel-Server IP-Adresszuweisung
• Timeout bei PHP-Prozessen
• Password was changed for user ‘Domain Adminstrator’
• Kein Matching von Reseller/Client/Domain Strukturen ins neue Geschäftsmodell
• Probleme beim chmod beim Deployen der Dateien auf dem Zielserver
• Firewall-Probleme beim Quellserver und Zielserver
• SSL-Certificate does not exist
• unable to change subscription owner, chown failed with return code 1
• failed deployment of domain xxx

Da jede Servermigration anders gelagert ist, ist das Plesk Forum voll von weiteren Problemen und Hilferufen.

Schlußwort

Nach zwei Tagen war ich mit der Migration des Servers durch. Glücklich, dass ich alle aufgetretenen Fehler und Probleme lösen konnte und somit am Ende die größten Broken automatisch transferiert wurden und nur marginal, manuell nachgearbeitet werden mußte.  Es hätte aber auch ganz anders kommen und die Chance bestand, dass man irgendwo nicht mehr weiterkommt. Letztendlich hat sich der Zeitaufwand und das Risiko meines Erachtens nicht gelohnt.

Wer sich von diesem Erfahrungsbericht jedoch nicht abbringen lassen will und sportlichen Ergeiz besitzt, dem Wünsche ich viel Ausdauer und Erfolg bei der Migration .

Links
Parallels Plesk Panel 10:  Dokumentationsüberblickseite
Plesk Provider Handbuch: Der Wechsel auf Panel 10
Plesk Knowledgebase: Structure of Plesk Migration Manager logs

PHP-Konfiguration

Nicht immer entsprechen die standardmäßig vorgegebenen PHP-Parameter den von Contao empfohlenen Werten.  Bei meinem augenblicklichen Hauptprovider (Hosteurope) sieht die Sache schon recht gut aus.

Die PHP-Grundeinstellung lautet auf safe_mode = off und register_globals = off , so dass hier schon einmal gewisse Sicherheitslöcher gestopft sind.

Gegebenenfalls wünschenswert und erwägenswert wäre (laut Screenshot unten) eine Vergrößerung der Dateigröße für hochzuladende Dateien.

Wenn auf dem Server das Administrationsprogramm Plesk installiert ist wie auf den meisten von Hostern angebotenen Servern, dann kann man pro Domain individuelle PHP.ini Einstellungen hinterlegen.

Dazu muss man

1. unter Plesk FAST_CGI aktivieren
2. und einen Eintrag für den Parameter upload_max_filesize in der Datei php.ini im Verzeichnis /var/www/vhosts/domainname.de/etc/

vornehmen.

Beispiel
Syntax der erforderlichen Eintragszeile in php.ini:

[PHP]
open_basedir = /var/www/vhosts/IhreDomain.de/httpdocs:/tmp
safe_mode = Off
upload_max_filesize = 8M

Weitere Blogbeiträge zu dieser Thematik

Perfect-Knowhow: File permission (Aktivierung von FAST_CGI unter Plesk)

Anzeige

Problem:

Bei der Installation von VMware 2.0 wurde man zu keinem Zeitpunkt aufgefordert, einen Benutzername und ein Passwort für den VMware Consolenzugriff einzugeben.

Lösung:

Es gibt kein Default-Passwort.  Sie müssen sich mit dem gleichen Loginnamen und Passwort anmelden, unter welchem Sie auch den VMware Server installiert haben.

Bei einem Windows 2008 Server könnte das z.B.:

administrator
myPasswort

sein

Weitere Blogartikel, die von Interesse sein könnten:

Perfect-Knowhow: Lokale Entwicklung mit einem Windows hosts Eintrag
Perfect-Knowhow: Windows 7: Zugriff auf Datei verweigert

Fehler: Server nicht gefunden

Der Server unter Ihr-Domainname konnte nicht gefunden werden.

(bzw. bei einer engl. Installation ein “Page not found”)

Hintergrund:
Bei der Installation von VMware 2.0.x auf einem Server muss man den FQDN (fully qualified domain name) angeben, unter der der VMware Server in Zukunft aufrufbar sein soll.  Wäre dieser FQDN beispielsweise Ihr-Domainname, dann wäre Ihr VMware Server optimalerweise unter

http://Ihr-Domainname:8222/ui

aufrufbar.

Lösung:
Variante 1:  Wenn Sie auf Ihrem lokalen Rechner arbeiten, müssen Sie trotz der Eingabe des FQDN’s bei der Installation die lokale IP-Adresse des Rechners verwenden, also

http://localhost:8222/ui

Variante 2:  Sie ändern die Hosteinträge auf Ihrem lokalen Rechner, so dass der URL Adressbestandteil Ihr-Domainname richtig aufgelöst wird.

Siehe hierzu den Blogartikel Lokale Entwicklung mit einem Windows hosts Eintrag

Weiterer Blogartikel, der von Interesse sein könnte:
Perfect-Knowhow: Windows 7: Zugriff auf Datei verweigert

The validity period of client account 'NameOfClient' (Contact Name 'ClientContactName') is about to expire.

The client account and all of related domains will be deactivated by Juli 1, 2011 unless the validity period is prolonged.

dann sollte man diese Meldung nicht ignorieren.

Lösung:

Sowohl bei den Client- als auch bei den Domaineinstellungen kann man ein Ablaufdatum (Expiration date) einstellen. 

1.) Veränderung der Gültigkeit des Clientaccounts:

     Plesk Panel > Clients > Resource usage   (s.a. obiges Bild)

Ganz unten findet sich dann ein Datumsfeld, in dem man explizit ein Ablaufdatum eingeben kann bzw. eine Checkbox für endlos, wenn die Domain "open end" gebucht wurde..

2.) Veränderung der Gültigkeit des Domainaccounts:

     Plesk Panel > Domains > Resource usage

   Die Version 2.0 von Moodle benötigt hierbei als Systemvoraussetzung eine PHP-Version größer als 5.2.8, welche nicht so leicht zu finden ist, aber bei der Server-Administrationssoftware Plesk in der Version 9.5.4 dabei wäre.

Lösung:
Host-Europe hat zur Zeit (bis 6. Februar 2011) den Preis für seine Windows-Server gesenkt, mit dem sehr interessanten Zusatz, dass der erniedrigte Preis nicht nur für eine beschränkte Einführungszeit, wie bei anderen Anbietern gang und gebe, sondern für die gesamte Laufzeit des Vertrags gilt.

Eigentlich setze ich Server auf Basis von Linux auf, aber da der Windows Server genauso wie bei Linux mit Plesk als leicht zu bedienendes Server Administrationsprogramm arbeitet, sah ich darin kein Problem. Was dann auch so war.

Schnelle Einrichtung des Servers

Fünf Stunden nach der Bestellung des Windows Servers XL 4.0 war dieser schon eingerichtet und ich hatte alle Zugangsdaten per E-Mail erhalten. 

Welche PHP Version steht zur Verfügung?

Ich hatte mich schon zuvor über die Host-Europe FAQ Seite darüber informiert, welche Plesk Version für Windows Server 2003 bei zur Verfügung stehen und hatte gehofft, dass die Grundinstallation gleich mit der stabilen Plesk 9.5.4 Version erfolgt, die PHP 5.2.13 mit sich bringt.
   Dem war aber leider nicht so. Die Grundinstallation erfolgte mit Plesk 9.2.1, was doch zunächst etwas enttäuschend war.

Plesk 9.5.4 Update ist problemlos und total einfach

 Was mich dann allerdings sofort wieder versöhnte, war die absolut leichte Anleitung, die Host-Europe zur Verfügung stellt, um auf die neueste Version 9.5.2 zu updaten. Von Version 9.2 auf 9.5 ist es ja wirklich ein Sprung, aber die Anleitung mit Bildern ist so easy vorzunehmen, dass absolut jeder Laie das Pleskupdate ohne Probleme selbst durchführen kann.

   Werbung        

Siehe auch:

Host-Europe: Plesk Updates unter Windows

Problem: Kein Zugriff auf neueingerichtete Subdomain pq.domainname.de

Ruft man die Subdomainadresse auf, dann erhält man die Browserausgabe "It works!". (Man wird noch vom System verhöhnt!) Die im Subdomainverzeichnis vorhandene index.html Datei wird ignoriert, wie auch alle anderen dort hinterlegten Dateien ignoriert werden. Beim Versuch auf eine Datei explizit zuzugreifen, erhält man die Zugriffsfehlermeldung 404-Error. Man kann nicht auf die Dateien im Subdomainverzeichnis zugreifen. Kein Eintrag im Apache access_log und kein Fehlereintrag im error_log.

Fehlersuche:

Da es sich um einen vollkommen neuen Server handelte, lag zunächst die Vermutung nahe, dass der Fehler genereller Art ist:

• irgendeine Systemkomponente nicht eingespielt ist
• ein Apache Modul fehlt
• die Verzeichniszugriffsrechte nicht stimmen
• die Einträge in der Apache-Konfigurationsdatei falsch verweisen
• die DNS-Einträge falsch sind
• die Plesk http.includes Datei noch eingebunden werden muss
• ein Restart von Apache nach dem Einrichten der Subdomain erforderlich ist
• oder der Nameserver noch nicht die neue Domainauflösung richtig zurückliefert
• ….    und so weiter

Ursache:

Nach vielen Stunden vergeblicher Fehlersuche:
Die Länge des Subdomainnamens war mit zwei Buchstaben "pq" zu kurz. Wählt man einen Subdomainnamen mit einer Länge ab drei Buchstaben, dann wird die Subdomainangabe vollkommen problemlos aufgelöst und die Dateien im Subdomainverzeichnis sind zugreifbar!!

Eine Recherche im Internet hat ergeben, dass es eigentlich keine Restriktion bzgl. der Mindestlänge des Domainnamens gibt und durchaus "single character subdomains" zulässig sind.  Aber so manche DNS-Software scheint hier seine eigenen Längenregeln einzubringen.

Fazit:

Wenn eine Subdomain nicht aufrufbar ist, kann es neben den oben aufgezählten Fehlergründen auch ganz banal an einem zu kurzem Subdomainnamen liegen. Für die Mindestlänge gibt es keine allgemeingültige Vorgabe, für die Maximallänge spielen sicherlich andere externe Faktoren wie z.B. die maximale Länge eines DNS A-Records, CNAME-Records hinein.

Meine Empfehlung: Länge des Subdomainnamens:  3-15 Zeichen.

Wenn jemand andere Erfahrungswerte hat, bitte einen Kommentar hinterlassen.

Schwieriger zu testen sind dabei datumsabhängige Funktionen, womit Funktionen gemeint sind, die auf Basis der Systemzeit eine Aktion ausführen.

Geburtstag: Blogartikel Nr. 100

Beispiel: 

Eine Funktion verarbeitet die Daten des Vortages. In der Datenbank seien hierbei viele Datensätze für den 11. Mai abgespeichert. Die korrekte Abarbeitung der Funktion hängt nun davon ab, dass die Systemzeit den 12. Mai als Datum zurückliefert.

Problem:

Das Gastsystem der virtuellen Maschine syncronisiert sich mit der Systemzeit des Hostrechners beim Start der virtuellen Maschine.   Der Versuch, die Gastrechnersystemzeit manuell einzustellen, zeigt nur einen kurzfristigen Erfolg, da die Systemzeit vom Gastsystem periodisch (Defaultwert ca. 1 min) mit dem Hostsystem syncronisiert wird, so dass die Veränderung wieder verloren geht.

Zielsetzung:

Die Systemzeit des Gastsystems soll unabhängig von der Systemzeit des Hostsystems sein und im Idealfall bei jedem Start der virtuellen Maschine auf einen bestimmten Datums-/Zeitwert gesetzt werden.

Lösung:

In der *.vmx Steuerungsdatei der virtuelle Maschine sind folgende Einträge einzufügen:

tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
rtc.startTime = "1178953200"

Anmerk.:  Der letzte Befehl rtc.startTime setzt die virtuelle Maschine auf den gewünschten Datums-/Zeitpunkt vom 1. Mai 2007, 9:00:00 Uhr  (s. a. UTC Linkverweis)

Siehe auch:

Vmware: Timekeeping in Virtual Maschines  (Information Guide)

Vmware: Timekeeping in Virtual Maschines (White Paper)

Wikipedia: Koordinierte Weltzeit UTC

1. Einfangen von Domain-Vertippern
   Es ist heutzutage sehr schwer geworden, noch einen freien Domainnamen zu finden. Ich habe es mir angewöhnt, neben der richtigen Schreibweise auch Domain-Namensvariationen und Vertippmöglichkeiten gleich mitzureservieren. Diese zusätzlichen Domains bedeuten zwar permanente, finanzielle Zusatzkosten, sind aber günstiger als später ein Rechtsstreit gegen Trittbrettfahrer. Neben reinen Domain-Namens-Vertippern, sollte man hierbei auch an evtl. mögliche Schreibweisen mit Bindestrich bzw. ohne Bindestrich denken.
2. Berücksichtigung der Domain Schreibweise mit und ohne “www.”
   Dies ist wohl einer der klassischen Anwendungsgründe warum man einen “Permanent Redirect” verwendet, weil man ansonsten eine Google-Abstrafung wegen “Duplicate Content” riskiert.

Mein Stufenplan

Ich empfehle eine mehrstufige Vorgehensweise:

1. Die Nameserver-Einträge bzw. DNS Einträge auf die gewünschte Haupt-/Zieldomain setzen.
2. Auf der Hauptdomain die entsprechenden Serveraliase für die www.domainname.tld Variante und die Domainnamensvariationen anlegen.
3. Durch einen Rewrite Befehl auf dem Apache Server eine HTTP-Permanent-Redirect Antwort absetzen.

Begründung

zu Punkt 1:

Durch den entsprechenden Nameserver bzw. DNS Eintrag genügt eine einfache Domainregistrierung.
Es ist kein Webhostingpaket pro Domain erforderlich.

zu Punkt 2:

Durch die Serveraliase werden die erhaltenen Domainnamen erkannt und mit der Zieldomain verknüpft, dieser zugeordnet.

zu Punkt 3:

Wichtig, damit die Domain-Namensvariationen für Google keine Abstrafung wegen “Duplicate Content” nach sich ziehen.

Permanent Redirect

Je nachdem den Möglichkeiten, die man zur Verfügung hat oder nach der jeweiligen Vorliebe ist an einer der Stellen

• http.conf  (Apache Konfigurationsdatei)
• .htaccess (auf Verzeichnisebene)
• vhost.conf (Plesk Konfigurationsdatei)

der entsprechende mod-rewrite Code abzusetzen:

RewriteEngine On
RewriteCond %{HTTP_HOST} !www.domain.tld
RewriteRule (.*) http://www.domain.tld/$1 [R=301,L]

Bei Plesk das abschließende

/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=yourDomainname.de
/etc/init.d/apache2 restart

nicht vergessen.