permission Problem beim Plesk 10.1 Restore

[seltener]

Hallo,
ich verzweifle gerade am Umzug von mehr als 100 Kunden von Plesk 9.5.3 nach 10.1, beide Server werden mit SuSe 11.1 bzw. 11.3 betrieben. Die reine Plesk Installation hat auch problemlos geklappt, alle Services laufen und es lassen sich neue Domains und Kunden anlegen die auch funktionieren.

Zur Datenübernahme wurde pro Domain ein komplettes Backup erstellt, meist per Kommandozeile mit

/usr/local/psa/bin/pleskbackup domains-name domain.de -v -z --output-file=/tmp/domain.backup.nozip

Das Einspielen auf Plesk 10.1 erfolgt mit

/usr/local/psa/bin/pleskrestore --restore /tmp/domain.backup.nozip -level domains -verbose -debug

Alle Accounts und Einstellungen für die Domain im Plesk werden auch angelegt, leider kann das restore nicht alle Dateien im Filesystem auspacken. Für die Verzeichnisse conf und statistics innerhalb des VH-Verzeichnisses gibt es Probleme:

(auszug)

<execution-result status="success"><object name="domain.de" type="domain">
<object name="domain.de" type="hosting"><message code="CantUnpackDomainContent" 
severity="error"><context>void plesk::DomainVHostRefferred::extractVhostDir(Vhost_RefferredVhost_&amp;)
[with Vhost_RefferredVhost_ = plesk::Vhost_RefferredVhost&lt;plesk::Cid&gt;]</context>
<file>./Cid.cpp</file><line>1177</line><text>Can not deploy content of domain domain.de</text>
<message code="tRepository::StreamError" severity="error"><text>Archiver error: 
from /var/lib/psa/dumps/domains/domain.de/backup_domain.de_vhost_1104052050.tar to /srv/www/vhosts/domain.de:
tar: conf/webalizer.conf: Kann open nicht ausführen: Keine Berechtigung
tar: conf/vhost.conf: Kann open nicht ausführen: Keine Berechtigung
tar: conf/httpd.include: Kann open nicht ausführen: Keine Berechtigung
tar: conf: Kann utime nicht ausführen: Die Operation ist nicht erlaubt
tar: statistics/logs: Kann mkdir nicht ausführen: Keine Berechtigung
tar: statistics/logs/error_log: Kann open nicht ausführen: Keine Berechtigung

Das gleiche passiert wenn der Migration Manager genutzt wird oder das Einspielen über das Backup Repository erfolgt. Auch eine Testinstallation mit Ubuntu 10.04 zeigt diesen Fehler.
Da tar scheinbar den Fehlerverursache ist, habe ich bereits einen Wrapper geschrieben um zu sehen, mit welchen Rechten tar läuft und welche temporären Dateien es nutzt. Dabei ist nichts auffälliges herausgekommen. Setzt man den tar Aufruf aus dem migration.log manuell als root ab, funktioniert alles und die Dateien sind da.
Auch das zwischenzeitliche Ändern der Rechte der betroffenen Verzeichnisse auf 777 hat keine Auswirkungen gezeigt.
Genauso ergebnislos war bisher eine Supportanfrage bei Parallels, immerhin finden sich im Forum Hinweise, daß ich mit dem Fehler kein Einzelfall bin.

Daher seht ihr mich ein wenig ratlos und auf Eure Hilfe hoffend.

 

[its]

Ähnliche Probleme sind bekannt, vielleicht versuchst du es mal mit dem Plesk Migrations Manager. Dieser hat mir schon gute Dienste bei Plesk 10.1 geleistet.

Die folgende Dokumentation solltest du dir vielleicht einmal ansehen:

http://www.parallels.com/de/products/plesk/docs/

http://download1.parallels.com/Ples...or-guide/plesk-switching-administrator-guide/
(Dieser Link beschreibt, wie Sie Daten von Plesk-Versionen 7.5 oder später nach Parallels Plesk Panel 10 übertragen.)

Natürlich kann man die Migration auch manuell ohne die Plesk Tools durchführen, doch bei 100 Kunden, wird das mehr als nur eine Nacht arbeit ohne automatische Migration.

 

[seltener]

Danke für die Doku Hinweise. Ich bin eigentlich ziemlich genau nach der Doku vorgegangen, werde jedoch den Teil "Migration von Linux/Unix Servern abschließen" nochmal schrittweise manuell durchgehen.
Den Migrations Manager habe ich schon bemüht, er liefert exakt das gleiche Ergebnis. Die Migration wird beendet, nur die angesprochenen Dateien fehlen und im Logfile findet sich die gleiche Fehlermeldung.

Wir nutzen seit Plesk 8 die backup/restore Kommandozeilentools in Verbindung mit rsync um verschiedene Plesk Server zwecks Redundanz automatisiert zu spiegeln. Bisher hat das immer problemlos funktioniert ...

 

[mg7]

... Alle Accounts und Einstellungen für die Domain im Plesk werden auch angelegt, leider kann das restore nicht alle Dateien im Filesystem auspacken. Für die Verzeichnisse conf und statistics innerhalb des VH-Verzeichnisses gibt es Probleme:

...
tar: conf/webalizer.conf: Kann open nicht ausführen: Keine Berechtigung
tar: conf/vhost.conf: Kann open nicht ausführen: Keine Berechtigung
tar: conf/httpd.include: Kann open nicht ausführen: Keine Berechtigung
tar: conf: Kann utime nicht ausführen: Die Operation ist nicht erlaubt
tar: statistics/logs: Kann mkdir nicht ausführen: Keine Berechtigung
tar: statistics/logs/error_log: Kann open nicht ausführen: Keine Berechtigung

Hallo seltener,

"Keine Berechtigung" heißt hier, dass der
User unter dem die Installation durchgeführt wird, keine Schreib- und/oder Leserechte auf die benötigten Verzeichnisse hat.

Bitte einmal prüfen mit

l # (L klein geschrieben)

und notieren. Danach entsprechend Schreib- und Leserechte gewähren per chmod (z.B. für die Installation auf 757 - und hinterher wieder zurücksetzen).

Beste Grüße,
Matthias

 

[bibabu]

l

entspricht

ls -lA

 

[seltener]

Die schrittweise Erzeugung eines Dumps und das einspielen habe ich nochmal manuell bis zum Ende durchgespielt. Das Ergenbis ist gleich, bis zum Entpacken der Verzeichnisinhalte mit tar funktioniert alles. Dann ist leider nur noch der Fehler im Logfile zu sehen und die Ausführung ist beendet. Im Webinterface wird nur darauf verwiesen dass "Warnungen" aufgetreten sind.

Die Verzeichnisrechte sehen eigentlich richtig aus:

ls -al /srv/www/vhosts/domain.de
drwxr-xr-x 21 root        root    4096  7. Apr 10:16 .
drwxr-xr-x 13 root        root    4096  7. Apr 10:03 ..
drwxr-x---  5 domainftp psaserv 4096  7. Apr 10:03 anon_ftp
drwxr-xr-x  2 root        root    4096  7. Apr 10:03 bin
drwxr-x---  3 domainftp psaserv 4096  7. Okt 22:07 cgi-bin
drwxr-x---  2 root        psaserv 4096 29. Mär 18:57 conf
drwxr-xr-x  2 root        root    4096  7. Apr 10:03 dev
drwxr-xr-x  2 root        psaserv 4096  7. Okt 22:07 error_docs
drwxr-xr-x  2 root        root    4096  7. Apr 10:03 etc
drwxr-x---  7 domainftp psaserv 4096  8. Okt 22:22 httpdocs
drwxr-x---  6 domainftp psaserv 4096  7. Okt 22:07 httpsdocs
drwxr-xr-x  2 root        root    4096  7. Apr 10:03 lib
drwxr-xr-x  2 root        root    4096  7. Apr 10:03 lib64
drwxr-x---  2 root        psaserv 4096  7. Apr 10:03 pd
drwx------  2 domainftp root    4096  7. Okt 22:07 private
dr-xr-x---  7 root        psaserv 4096  7. Apr 10:03 statistics
drwxr-xr-x  2 root        psaserv 4096  7. Apr 10:03 subdomains
drwxrwxrwt  2 root        root    4096  7. Apr 10:03 tmp
drwxr-xr-x  4 root        root    4096  7. Apr 10:03 usr
drwxr-xr-x  3 root        root    4096  7. Apr 10:03 var
drwxr-xr-x  2 root        psaserv 4096  7. Apr 10:03 web_users

Das ganze restore wird als root gestartet. Um zu sehen ob sich die UID vielleicht ändert bei einem der Aufrufe hatte ich den tar wrapper gebaut - die UID bleibt aber gleich, auch tar läuft als root.
Die Verzeichnisse werden alle erst während des restore angelegt. Ändert man die Rechte der betroffenen Verzeichnisse auf 777, dann ändert das garnichts, das Ergebnis bleibt das gleiche. Lediglich wenn man die Verzeichnisse löscht meckert tar, daß er sie nicht finden kann.

Inzwischen habe ich mal alle fehlenden Dateien mit rsync kopiert und ein backup auf 10.1 gemacht und verusucht es wieder auf der gleichen Plesk Version einzuspielen. Auch das geht schief, allerdings wird diesmal das Verzeichnis https (man beachte das "s" in der Mitte) nicht angelegt und gefüllt.

 

[seltener]

Viele Stunden später und teilweise am Rand des Wahnsinns ist das Problem jetzt vorerst "gelöst". Naja, sagen wir, es gibt einen Weg wie man mit dem Problem weiterkommt:
Das Entpacken aller Inhalte des Webverzeichnisses mit tar geschieht mit den Rechten des betreffenden FTP Nutzers, auch wenn das Restore als root aufgerufen wird. Ebenso werden alle Mails mit den Rechten des popuser entpackt.
Einige Verzeichnisse (conf, statistics, webstat etc.) sind aber für den normalen FTP Nutzer nicht schreibbar. Es hilt, den tar Befehlt per wrapper so zu verändern, daß er auch bei einem Aufruf als Nutzer wieder einen tar Aufruf als root startet. Natürlich darf das nur für das restore und die betreffende Datei funktionieren da es ansonsten ein riesiges Sicherheitsleck darstellt.
Alternativ kann man auf ähnlichem Weg die Dateien als FTP-Nutzer in ein temporäres Verzeichnis entpacken lassen und innerhalb des tar wrappers per rsync an den korrekten Ort verschieben.

Fazit: Das ist ein fetter Bug in Plesk bei dem der Hersteller einmal mehr nicht in der Lage ist einen Lösungshinweis zu liefern!