[HowTo] Troubleshooting Plesk 9.x -> Plesk 10.x

Post by **leviathanx** » 2011-09-18 15:19

Hallo,

ich dachte ein bißchen "public documentation" könnte nicht schaden ;)

Auf die Idee hierzu kam ich nachdem mich ein Systemupdate von Lenny auf Squeeze >10h Zeit gekostet hat. Hauptgrund war eher Plesk...

Persönlich kann ich ohne Plesk auf der Konsole administrieren; wenn's da nicht so etwas wie Kunden oder andere Admins gäbe[..]

Allenfalls ich halte jetzt mal die wichtigsten Lösungen zu den schlimmsten Kopfbrechern hier fest.

Disclaimer
Ich übernehme keine Haftung für Schaden oder sonstige Ausfälle. Ich schreibe lediglich Erfahrungswerte nieder an die sich andere orientieren können.
Anwendung auf eigene Gefahr

Vorgeplänkel

Zu allererst einmal die PSA-Datenbank sichern

Code: Select all

mysqldump -u admin -p psa > ~/psa_backup.sql

das Plesk-Admin Kennwort steht im Klartext unter

Code: Select all

/etc/psa/.psa.shadow

WICHTIG
Plesk kann mit 100% Sicherheit nicht mit Sonderzeichen umgehen!
Habt ihr ein Passwort in der Form wie

230bad@\a32!

dann ändert es! Plesk wird keine erfolgreiche Installation abliefern!! Buchstaben [a-z] und Zahlen [0-9] sind erlaubt!

Ändert das Passwort über die mysql-Console und schreibt den Klartext des neuen Passworts in die .psa.shadow .

Das Systemupgrade wird alle Plesk-Pakete (da inkompatibel) entfernen. Sollte jemand ohne Systemupgrade zum neuen Plesk wechseln sind folgende Zeilen auszuführen.

Code: Select all

apt-get remove psa
apt-get remove psa-api
apt-get remove plesk-base
apt-get remove plesk-skins

Damit wäre der große Wust weg. Config-Files bleiben erhalten (keine Panik wegen dem qmail, es wird in der Regel nichts gelöscht - ich gebe generell kein Gewähr, dass es immer stimmt!)

/etc/apt/sources.list muss auch geändert werden. Von Lenny nach Squeeze z.B.

Code: Select all

deb http://autoinstall.plesk.com/debian/PSA_10.3.1 squeeze all

WICHTIG
Es gibt so eine Abhängigkeit die NICHT von Plesk geprüft wird!!!

Installiert also folgende Pakete

Code: Select all

apt-get install doctrine sw-doctrine

Sind diese nicht installiert kann der Plesk-Autoinstaller die Datenbanken nicht anlegen!!!

Ladet nun den Autoinstaller von Plesk herunter

Code: Select all

wget http://autoinstall.plesk.com/PSA_10.2.0/dist-deb-Debian-6.0-x86_64/opt/updater/psa-autoinstaller_3.9.0-110316.15_amd64.deb

Hinweis
Wer es ganz sauber möchte:

Code: Select all

mv /opt/psa /opt/psa.old
mkdir -p {/opt/psa,/opt/psa/admin/htdocs/locales}
cp -av /opt/psa.old/bootstraper /opt/psa
cp -av /opt/psa.old/version /opt/psa
cp -av /opt/psa.old/admin/htdocs/locales/default /opt/psa/admin/htdocs/locales

Installation
Installiert nun den PsaAutoInstaller und führt diesen aus

Code: Select all

dpkg -i psa-autoinstaller_3.9.0-110316.15_amd64.deb 
/opt/psa/admin/sbin/autoinstaller

Folgt den Bildschirmanweisungen und beobachtet jeden Fehler...

Wenn es auf Anhieb durchgeht ohne massive Fehler, dann muss an der Datenbank jetzt noch Hand angelegt werden. Ansonsten die Fehler bereinigen.

A. Installation durchgelaufen

Wenn ein Fehler abgearbeitet ist immer mit

Code: Select all

/opt/psa/bootstrapper/xxx/bootstrapper.sh repair

die nächsten Fehler bekommen, bis irgendwann alles grün ist (das kann sich ziehen wenn man den Fehler nicht kennt)

B. Installation abgebrochen

Autoinstaller erneut starten!

Fehlerliste

Über folgende bin ich gestolpert

Mail-Driver
Fehlerort:
während der Installation

Lösung:
Es fehlt entweder psa-mail-qc-driver oder plesk-mail-qc-driver
Je nach Sytemvorgeschichte reicht ein apt-get install auf eins der Pakete oder ein apt-get install psa-mail

Locales missing
Fehlerort:
Nach der Installation

Lösung:
Nach der Installation fehlt lustiger weise das englische locale-Verzeichnis. Einfach reinstallieren da es (bei mir jedenfalls) als installiert markiert ist

Code: Select all

apt-get install --reinstall psa-locale-base-en-us

Wenn der AutoInstaller oder der Bootstrapper endlich fehlerfreie Meldungen zurückliefern ist es zeit die nächsten Fehler am Panel zu beheben!

Zertifikate kopieren
Hat jemand sich an der sauberen Lösung probiert, so kopiert noch die Zertifkate aus dem alten /opt/psa.old/var/certificates an die gleiche Stelle wie im neuen /opt/psa !

Plesk 10 - Panelprobleme

Erst einmal ins Panel einloggen. Dies sollte jetzt ohne Probleme funktionieren!

Im Panel sieht man die Übersichtsseite. Fehlermeldungen á la "Configuration could not be updated" vorerst ignorieren.

Bei mir hat ein Klick auf die Administrationlinks dazu geführt, dass erstmal gar nichts ging.

Warum? Ganz einfach: Plesk-Updater hat die Datenbank nicht hochgezogen!!
Zum Glück ist es nur eine Tabelle die hier Probleme macht!

Der reguläre Fehlertext ist

SQLSTATE[42S22]: Column not found: 1054 Unknown column 's.custom' in 'where clause'

Dies zu beheben geht auf die mysql-Console und führt folgendes Script aus

Code: Select all

ALTER TABLE Subscriptions ADD custom ENUM('true', 'false') NOT NULL DEFAULT 'false';
ALTER TABLE Subscriptions ADD uuid VARCHAR(36) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL;
ALTER TABLE Subscriptions ADD UNIQUE (object_id, object_type);
ALTER TABLE Subscriptions ADD UNIQUE (uuid);

Ein Reload im Plesk-Panel und schon sieht man seine Domains wieder

User-Control panel
Es kam bei mir vor, dass das User-Control panel nicht auf ging. Die Lösung die ich gefunden habe:

JEDEN Kunden anklicken dort "Edit contact details" und dann einfach auf "OK" zum Speichern der nicht geänderten Werte drücken :arrow: User-Control panel geht wieder!!

Wer weiß wie das automatisch geht möge es doch bitte mitteilen :)

Webserver configuration could not be updated

So, der aller lustigste Fehler überhaupt!
Mein Server besitzt zwei Ips und Plesk 10 hat die Konfigurationsschicht "etwas" geändert.

Nach über einer Stunde am rumsuchen warum die Domains keine Config-Dateien bekommen haben, das Resultat:

Klickt jede Domain an, dort auf "Change Host-Settings" und wählt dort die IP aus!!. Ein finaler Klick auf "Save" und schon wie durch Zauberhand wird die Konfiguration für diese Domain erzeugt!!

Ich habe auch keine automatisierte Lösung jetzt finden können (ok es war mittlerweile 2:30 Uhr in der früh und langsam aber sicher war ich kurz davor mir den Kopf gegen die Wand zu schlagen aufgrund dieser stumpfsinnigen Fehler) und 49 Domains komplett durchgeklickt...

Hinweis

Prüft vorher über "Tools & Settings" dass Plesk eure Ips erkannt hat. Draufklicken, ansehen und speichern drücken.

Der ultimative Spaß kommt bei den Forwarding-Domains:

1. Forwarding-Url in die Zwischenablage kopieren.
2. Webhosting-Setting auf "NONE" (!) setzen
3. Speichern
4. Webhosting-Setting auf "Forward"
5. IP Auswählen(!!!!)
6. Url eintragen
7. Speichern

Kommt mal auf so eine Idee! Ich hab echt gedacht ich Fall vom Glauben ab...

Sicherheitslücke Statistics

Mir ist dann später noch aufgefallen, dass Plesk 10 keine protected directories mehr anlegt für die statistics! Das heißt: jeder der weiß dass Ihr Plesk einsetzt kann über "http://domain.tld/statistics" bzw. "http://domain.tld/webstat" in Euren Statistiken lesen.

Um das global zu umgehen habe ich mir eine Lösung überlegt. Sie ist zwar nicht perfekt (ich sage am Schluss warum), aber sie ist schon einmal wesenlich geschützter als das Standardverhalten

Dazu müssen folgene Pakete installiert und aktiviert werden

Code: Select all

apt-get install libapache2-mod-authnz-external pwauth
a2enmod authnz_external

Jetzt muss das Plesk-Standard-Template angepasst werden

Code: Select all

vi /opt/psa/admin/conf/templates/default/domain/domainVirtualHost.php

Sucht folgende Zeilen

Code: Select all

<?php if ($VAR->domain->www): ?>
    ServerAlias  "www.<?php echo $alias->asciiName ?>"
    <?php endif; ?>
<?php endforeach; ?>

und fügt dahinter folgendes ein (ACHTUNG: die ganzen Leerzeilen hinter den "?>" sind wichtig; NICHT entfernen!!)

Code: Select all

<IfModule mod_authnz_external.c>
        DefineExternalAuth pwauth<?php echo $VAR->domain->physicalHosting->login ?> pipe /usr/sbin/pwauth
</IfModule>

<?php
        $preDocRoot = $OPT['ssl'] ? $VAR->domain->physicalHosting->httpsDir : $VAR->domain->physicalHosting->httpDir;
        $preDocRoot = preg_replace("/http(s)?docs/", "", $preDocRoot);
?>

<Directory "<?php echo $preDocRoot; ?>statistics">
        AuthType Basic

        AuthName "Restricted Access"

        <IfModule mod_authz_user.c>
                AuthzUserAuthoritative On
        </IfModule>

        Require user <?php echo $VAR->domain->physicalHosting->login ?>

        <IfModule mod_authnz_external.c>

                AuthBasicProvider external
                AuthExternal pwauth<?php echo $VAR->domain->physicalHosting->login ?>

        </IfModule>

</Directory>

<?php
        unset($preDocRoot);
?>

Speichert das template und führt

Code: Select all

/opt/psa/admin/bin/httpdmng --reconfigure-all

aus. Die Configs werden neu erzeugt und apache neu gestartet.

Was macht der eingefügte Teil in der Config?
Wir benutzen hier eine externe Authentifizierung. Das heißt es ist unnötig eine .htpasswd anzulegen und diese zu pflegen.

Zu gut um wahr zu sein?!
In der Tat, es gibt einen kleinen Drawback. Die direktive "require user <username>" wird seltsamerweise komplett ignoriert. Das bedeutet jeder gültige Benutzer kann rein (effektiv ein "Require valid-user").
Persönlich finde ich das unschön, aber dazu sollte man beachten:

Der Nutzer muss wissen, dass...
1. ...die Fremddomain auf dem gleichen System ist wie er
2. ...hier kein .htpasswd benutzt wird

Wenn hierfür jemand eine bessere (ebenso voll automatische) Lösung hat oder eine Idee hat diese Methode zu verbessern, so bin ich gerne dafür offen :-D

PSA-DB-Dump

Jetzt sollte erst einmal die Konfigurationsdatenbank gedumpt werden!

Plesk Billing*
Wer dies nicht braucht, der kann es wie folgt los werden

Code: Select all

/usr/local/psa/bin/sso --disable
apt-get purge plesk-billing plesk-billing-plugins

danach in der mysql-command

Code: Select all

DELETE FROM cl_param where param='ppb-url';

(*Source: http://www.codarbyte.de/2011/02/plesk-b ... entfernen/ )

PSA Webmail
Ein Satz: "Kaputt @Stock". Es funktioniert NICHT! Ich schlage euch die Lösung vor, welche ich benutze:

Ladet das Horde-Projekt in der aktuellsten Fassung mit allen von euch benötigten Plugins runter. Setzt das Horde-Framework in einem Webspace in dem ihr Zugriff habt auf.

Seit hier damit fertig, verschiebt das fix und fertige Verzeichnis nach

/usr/share/horde

Dann noch folgende Befehle

Code: Select all

chwon root.root /usr/share/horde -R
mv /usr/share/psa-horde /usr/share/psa-horde.orig
ln -s /usr/share/horde psa-horde

Schon habt ihr das aktuellste Horde mit eigener Konfiguration und Plugins. Plesk kann hier nichts überschreiben, da es in /etc/ die Konfigurationen verwaltet und diese im Originalverzeichnis nur per symbolischen Link angezogen werden. Ich benutze diese Lösung seit Monaten und bin deutlich zufriedener was Zuverlässigkeit, Geschwindigkeit und Erweiterbarkeit anbelangt!

So, ich hoffe ich kann damit einigen Leuten mit Upgrade-Problemen helfen :) Vielleicht könnte man ja ein Sammeltopic daraus machen; da ich der Meinung bin, dass ich nur ein Subset der ganzen Plesk-Probleme abbekommen habe...

Grüße

Edit:

Nachtrag

qmail ohne Funktion
Das liegt daran, dass die xinetd-configurationfiles LEER sind!!

Hier hat ein anderer User den Inhalt gepostet. qmail funktioniert nach füllen der Dateien wieder bestens :)