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

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

Nun kann es nicht die Aufgabe eines Shopbetreibers sein, diese Datei mit Artikelinformationen, Preisen, Lagerbeständen, etc. manuell zu pflegen und aktuell zu halten. Auch das alleinige Anstoßen eines Exports nach jeder Änderung der Artikelbeschreibung, des Artikelpreises, etc. wäre zu umständlich.

Der Vorgang mußte also automatisiert werden, um die Aktualität und damit die Qualität der Daten für die Preissuchmaschine auf einen hohen Niveau zu halten. 
 

Aufgabenstellung

• Ein PHP-Skript ist zu erstellen, welches aus einer Magento-Datenbank (e-Commerce Shopsystem) die CSV-Datei für eine bestimmte Preissuchmaschine erzeugt.
   
• Dieses PHP-Skript als Cronjob in regelmäßigen Zeitabständen anzustoßen, so dass der Shopbetreiber sich keine Gedanken mehr um die Aktualität der Preissuchmaschinendatei mehr machen muss. 

Auf einem Windows-System geschrieben und getestet, lief das Skript auch wunderbar.  Beim Produktionssystem unter Linux (Suse 11.1) und Plesk (Version 8.6) erhielt ich jedoch die folgende Fehlermeldung:
 

Wie sich leicht durch eine Internetrecherche herausstellte, hatten schon viele vor mir ähnliche Fehlermeldungen. Leider gab es hierbei jedoch keine Lösung, die bei meiner Installation zum Erfolg führte.

Der Vollständigkeit halber möchte ich die gefundenen Lösungsvorschläge dennoch kurz aufführen, vielleicht führen diese ja bei einer anderen Systemkonfiguration zum Erfolg:

• Schreibweise und Existenz der Pfade prüfen
• Vorhandensein der Dateien, die nicht includiert werden konnten, prüfen (Grund: korrupte, gepackte Verzeichnisse oder Downloads)
• Richtige Schreib-/Leserechte bei den Dateien/Verzeichnisse
• PHP-Version fehlerhaft: Viele machen die PHP Version 5.2.5 für den obigen Fehler verantwortlich. Bei manchen ging nach einem Upgrade auf 5.2.6 plötzlich alles, bei anderen jedoch zeigte sich keine Veränderung.
• Plesk spezifisch: Die vhost.conf Datei um eine Eintragung erweitern

<Directory /srv/www/vhosts/deineshopdomain.de/httpdocs> (Verzeichnis kann bei anderem Linux abweichen)
php_admin_value include_path
“.:/usr/share/pear:/srv/www/vhosts/DeineShopDomain.de/httpdocs/lib:/… u.s.w. ”
</Directory>

danach ein

/usr/local/psa/admin/sbin/websrvmng -a -v

rcapache2 reload

Insbesondere dem letzten Lösungsvorschlag hatte ich große Erfolgschancen eingeräumt, zeigte doch ein phpinfo.php Aufruf, dass nunmehr der PHP include_path eindeutig die beanstandeten Laufwerke beinhaltete. 

Ein erneuter Start des Skrips

/usr/bin/php5  -f  skript.php

auf Command-Line Ebene ergab aber wieder die oben genannten Fehlermeldungen.

Lösung
Ich habe mir daraufhin die Command Line Parameter für das PHP5 Programm angeschaut und bin fündig geworden. 

Usage: php [options] [-f] <file> [--] [args...]

  -a               Run interactively
  -c <path>|<file> Look for php.ini file in this directory
  -n               No php.ini file will be used
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -f <file>        Parse and execute <file>

Die include-path Einweisung im Skriptprogramm wird ignoriert, die  include-path Anweisung in der Plesk-Vhost.conf Datei wird ignoriert, aber durch den Parameter "-c [/pfad/php.ini]" kann man PHP5 anweisen die php.ini Datei zu verwenden und plötzlich ging die Sonne auf, die Welt war wieder in Ordnung und das Skript lief sofort wieder fehlerfrei durch.   

Man beachte die Stellung des Parameters -c vor dem -f, wenn man optional keine php.ini Datei angibt, weil sich diese im gleichen Verzeichnis wie die Skriptdatei befindet:

/usr/bin/php5  -c  -f  skript.php

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.

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.

Domains mit der Verwaltungsoberfläche Plesk 9.3 eingerichtet.

Wenn man für eine Domain einen externen Mailserver verwenden möchte, dann ist der DNS-Eintrag auf den Nameservern entsprechend zu setzen. Dies funktioniert soweit bei E-Mail, die von außerhalb gesendet werden, auch recht gut.

Problem

Wird jedoch auf der Internetseite selbst eine E-Mail an eine interne Adresse versendet, z.B. an  kontakt@meineDomain.de,  so erhält man eine Fehlermeldung der Art

Hi. This is the qmail-send program at n1.meineDomain.de.

I’m afraid I wasn’t able to deliver your message to the following addresses.

This is a permanent error; I’ve given up. Sorry it didn’t work out.

<kontakt@meineDomain.de>:

This address no longer accepts mail.

Lösung

Die Fehlermeldung kommt, weil auf der Domainebene kein E-Mail Account angelegt wurde. Das ist ja aber gerade auch erwünscht und soll so bleiben. Da jedoch die Domain auf diesem Server lokal angelegt ist, versucht das System die E-Mails zuzustellen.

Man muss nocheinmal explizit den Mail-Service deaktivieren.

Also Mail-Settings (E-Mail Einstellungen) anklicken und das Häkchen aus dem Ankreuzfeld nehmen.

Die Besucheranzahl ist eine wichtige Kenngröße für den Erfolg einer Webseite. Die Defaulteinstellung bei einem Server, der mit Plesk verwaltet wird, ist, dass die Ermittlung der Besucherstatistik einmal nachts für alle Domains erfolgt.  Das macht Sinn, da das System kurz nach Mitternacht, die vollständigen Daten für den Vortag vorfindet und bei einem Nachtlauf auch recht wenig Besucher gestört werden (Performancelast, größere Antwortzeiten des Servers).

Was aber, wenn man den Erfolg einer Webseitenänderung verfolgen will und sich im Tagesverlauf die Frage stellt:

“Wieviel Besucher hatten wir denn heute schon auf der Webseite?”

Leider wird von Plesk wie schon gesagt, die Statistik nur einmal am Tag aktualisiert. Es ist recht unbefriedigend, um 15:00 Uhr zu sehen, wie hoch die Besucherzahl am Vortag war und dass bis 0:15 Uhr nachts, als der Berechnungslauf startete, schon 20 Besucher auf der Internetseite unterwegs waren. Diese Anzahl mag zwar richtig sein, ist aber für den Informationshungrigen, der tagesaktuelle Daten sucht, nicht ausreichend.

Sicher muss man nicht übertreiben und stündlich eine Aktualisierung der Besucheranzahl anstoßen, denn die Erzeugung der Statistik geht zu Lasten der Webseitenzugriffszeit und das könnte so manchen Besucher stören. Aber eine zusätzliche Aufbereitung um 11 Uhr für die Abdeckung des Morgens und um 16 Uhr wäre sicherlich nicht schlecht.

Lösung: Cronjob für AWSTATS einrichten

Da bei vielen Servern heutzutage Plesk als Server-Verwaltungsoberfläche eingesetzt wird, möchte ich die Vorgehensweise beschreiben, das Aufbereitungsintervall für die Statistik zu verkürzen.

Den Anstoß für die Aufbereitung der AWSTATS-Statistik unter Plesk gibt das Programm

-r-x — —  root root  /usr/local/psa/admin/sbin/statistics

Wie man sehen kann, darf nur der Benutzer ROOT dieses Programm ausführen.
Das ist wichtig zu wissen.
Trägt man bei Plesk bei irgendeinem anderen Benutzer den Cronjob ein, so würde dieser Cronjob ins Leere laufen und nichts würde passieren.

für Plesk 9.3, das auf vielen Altsystemen noch installiert ist und die aktuelle Plesk Version 10.3 beschreiben,

1. Schritt:  Plesk Verwaltungsoberfläche aufrufen

Rufen Sie zunächst unter dem Menüpunkt HOME die SYSTEM USER auf, und suchen Sie den Benutzer root.

Ein alternativer Zugang zu der Einstellungsmaske ist hierbei
HOME / Settings / Scheduled Tasks

2. Schritt: Neuen Crontab Eintrag anlegen

Eigentlich hat man das Schwierigste, die richtige Stelle für seinen Eintrag zu finden, mit dem 1. Schritt schon erledigt.  Der rechtsstehende Screenshot zeigt den anzulegenden Eintrag.

Um einen neuen Cronjob anzulegen, ist auf den “Add New Tasks” Schaltfläche oben zu klicken.

Bei Stunden, Minuten, Tag und Monat einfach die gewünschten Werte in die Felder eintragen und beim auszuführenden Programm

/usr/local/psa/admin/sbin/statistics   >/dev/null 2>&1

/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=blabla.com   >/dev/null 2>&1

Der Aufruf zur Aktualisierung aller Domains (=default) lautet:

/usr/local/psa/admin/sbin/statistics –calculate-all