Vorsicht Falle: .\backup - pcfg_openfile:unable to ...

ElNino

ElNino

Registered User
Hallo,

ich habe gestern und heute etliche Stunden damit verbracht einem seltsamen Fehler auf die Schliche zu kommen.

Seit einiger Zeit (RH9) ist es ja möglich, ein .\backup Verzeichnis zu erstellen, in welches man seine zu sichernden Daten kopieren kann. Die Größe darf 500 MB nicht überschreiten. siehe auch diesen thread

Da ich eigentlich einem anderen Problem (PHP-Bug) auf die Schliche kommen wollte, habe ich für eine Neuinstallation die kompletten Userdaten \var\www\web1-webX nach .\backup gesichert.

Danach die Neuinstallation in Auftrag gegeben, welche flux durchgeführt wurde. Anschliessend über Confixx die entsprechenden Domains und Kunden angelegt. Alles schön sorgfältig, zum späteren Nachvollziehen im Fehlerfall.

neuer Kunde -> Domain angelegt -> Mails eingerichtet, Seite gecheckt -> Log-file -> Dokumentiert ->nächster ...
2.3.4....
bei web5 war allerdings schluss. Nach dem Anlegen wurde ein Test-Aufruf mit "domain.tld" im Browser mit einem 403 - Forbidden quittiert. Der Aufruf über webx.xxxx.vserver.de führte jedoch korrekterweise ins confixx-Menü.
Ein Zugriff über Ftp wurde clientseitig mit Fehler 500(?) quittiert.
Falsche User/Passwort. Im Server-Logfile dagegen wurde der Zugriff als erfolgreich geloggt.

Und das, obwohl ich auch diesen User zu 100% nach dem gleichen Schema wie die andere angelegt hatte.

#=Fehlersuche

#Über Confixx im UserMenü Passwort geändert und updatescript gestartet - keine Änderung

#http.conf und includes durchgeforstet mit orginalen verglichen - keinen Fehler entdeckt.

Im Logfile fand sich:
Code: 
[client x.x.x.x] (13)Permission denied: /var/www/web5/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
und Directory index forbidden by rule: /var/www/web5/html/
Im /html/ - Verzeichnis befand sich allerdings keine .htaccess.

#Also, Kunde web5 gelöscht und neu angelegt. gleicher Fehler.
#Weiteren Kunden web6 angelegt ... gleicher Fehler.
#Subdomain zu web5-Domain für neuen TestKunde (web7) angelegt, ... das funktionierte! :confused: :confused:

Alle vor web5 angelegten Kunden/Domains funktionierten ebenfalls noch einwandfrei.

#apache restart - kein erfolg, server reboot - kein erfolg.
Speicher / Prozesse / Cpu Last alles im grünen Bereich.
Google-Suche bracte auch keinen Hinweis.

Ich war schon wieder schier am verzwatzeln...
#Verzeichnisrechte von web5/web6... überprüft und siehe da...
Die Rechte waren auf group: root und owner: root gesetzt worden
Daraufhin habe ich in .\backup\ alles Files gelöscht und für die webX´s entsprechende Rechte gesetzt .... nun funktioniert wieder alles.

Was war passiert?
(Vermutung)

Entweder während des Anlegens des Kunden web5 über Confixx wurde vom System erkannt, (disk quota script?) dass bereits vom alten web5 vorhandene Dateien im .\backup Verzeichnis existieren.(kann das denn sein?)

Da ich in einer geänderten Reihenfolge die Kunden angelegt hatte, sollte das ursprüngliche "web5" nicht mehr mit dem neuen "web5" übereinstimmten. (web5(alt) hatte zuvor 100Mb (im backup), web5(neu) sollte allerdings nur 30MB bekommen - anderer User/Domain)
Vielleicht hat beim Erstellen der Verzeichnisse durch das confixx-scripts "root" die Rechte an web5 und allen anschliessend angelegten Usern abbekommen, da "disk quota exeeded" -Fehler.

Oder durch mein Restore copy von .\backup-> webX wurden die Rechte neu gesetzt.

Ich glaube, dieses Syptom könnte auch für andere Probleme verantwortlich sein, weil...
der Server jetzt fehlerfrei rennt, trotz mehr als 12 angelegten Usern/Domains. Und das war mir mit Apache2/PHP4.3.4 und RH9 bisher nicht gelungen.

Für den Profi vielleicht ´ne "olle Kamelle",
für den Einsteiger u.U. ´ne fette Falle.

Auf jedenfall achte ich jetzt ganz genau, was ins .\backup-Verzeichnis kommt und vor allem, wie es wieder raus geht.

Gruß Tom
 
Hi,

nur kurz als Frage hattest du vor der Neuinstallation ein RedHat 9 oder hab ich dir ein Backup von 7.3 gemacht und dann ein 9 installiert, weil sich die UIDs/GIDs zwischen 7.3 und 9 fuer Confixx aendern, die alten werden jedoch nachdem Restore wiederhergestellt, das heiss du hast nach einem 7.3 Restore auf 9 auch erstmal die 7.3er UIDs, was sich natuerlich auf das Quota auswirkt.
 
Die Nutzerrechten sind wahrscheinlich bei jeder Neuinstallation ein Problem. Daher danke, daß Du darauf hinweißt.

Immer wenn man als root etwas sicherst und wieder einspielt, sollte man diese Daten gründlich prüfen. Gerade mit Confixx hat man nur bedingt (bis gar keinen) Einfluß auf die UIDs. Aber letztendlich werden immer die UIDs und nicht der User-Name bei der Datei gespeichert. So kann es zu UIDs-Verschiebungen nach einer Neuinstallation kommen.

huschi.
 
Das kann ich 100%ig verstehen!

Danke erstmal für den Hinweis mit dem /backup - Verzeichnis!
Probier halt mal (wenn du dazu fähig bist) ein PHP-downgrade zu machen.
Ich selber würde das zwar nicht hinkriegen, aber ich bin kein Maßstab...
Durchhalten!
Wenn die auf php.net sagen, dass sie nur bei den 2 Servern mit 4.3.4 Probleme haben, dann ist wohl im Moment die einzige Lösung: Downgrade!

Aber ich meine mich noch sehr schwach dran zu errinern, dass als ich den vServer ganz neu hatte (Mai 2003) hatte ich auch diesen PHP-Fehler, aber nur für kurze Zeit, dann hat sich das irgendwie gegeben. Vielleicht lags aber nur an meiner Unwissenheit, wer weiß...?
***edit***
Ich glaub der hatte damals nur PHP nicht richtig geparsed und dann das file im Browser ausgespuckt. Ich hatte nur ne Kleinigkeit umändern müssen <--bin mir aber nicht ganz sicher.
Außerdem hat das glaub nicht viel mit dem PHP-Bug zu tun.
Naja, auch egal
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top