rechte problem?

[carpe]

Wollte ja nur ein wenig aufräumen und einige Templates löschen. Dies ging nicht wegen der Benutzerrechte und so hat mir mein Provider diese entsprechend wieder zugeteilt.
Jetzt komme ich nicht mehr ins Backend. Blog ist erreichbar, Artikelübersicht geht, Kategorieauswahl geht, Einzelartikelauswahl geht nicht. und wenn ich mich einloggen will wird zwar die serendipity_admin.php aufgerufen aber nur ein weisse Seite angezeigt. Help wanted
www.carpenter.de

Auf welche Dateien greift denn das System eigentlich zu für die Anzeige des Backends?

[Timbalu]

Das liegt wahrscheinlich an der Umleitung von
http://www.carpenter.de/admin
nach
https://www.carpenter.de:81/.cobalt/sysManage/index.html
was wahrscheinlich wieder
https://www.carpenter.de/serendipity_admin.php aufrufen soll.
Tatsächlich hast du aber unter
http://www.carpenter.de/serendipity_admin.php eine weiße Seite (sog. "white page of death").
Deren genauer Error muss sich in der error.log Datei deines Servers finden lassen.
Ob da ein Fehler vorliegt oder dein Serendpity nur nichts vom https weiß, wird man sehen.
Wer hat das umgestellt?

[carpe]

Ich kann mich nicht erinnern jemals schon auf https umgeleitet worden zu sein. Tatsächlich nutze ich eigentlich immer nur den versteckten LInk zwischen Home und Impressum um ins Backend zu gelangen. Ich selbst habe nichts umgestellt ausser ein paar Templates zu löschen. Aus diesem Grund wurden vom Provider ein paar Rechte wieder neu vergeben weil ich die Templates nicht löschen konnte. Sonstige Einstellungen wurden heute keine vorgenommen.

Eine error Log kann ich auf meinem webspace keine finden.

Ich werde eben nochmals bei manitu nachhaken.

[carpe]

antwort des support bezgl. meiner anfrage ob hier durch die Rechteänderung ein problem geschaffen wurde:
"eigentlich nicht, vorallem kann admin nie funktioniert haben, da dies
vom Server selbst belegt ist."

Ich bin so schlau wie vorher und komme keinen schritt weiter.

[Timbalu]

Naja, also diese Antwort ist ein wenig ...
Wenn manitu deinen path intern umbiegt, sollten sie dir wenigstens sagen können, wie man am besten darauf reagiert. Auch einen Auszug aus dem access bzw error.log sollten sie dir schicken können, damit man wenigstens weiß was da passiert, wenn man auf /serendipity_admin.php bzw den short /admin zugreift.
Arbeiten die eventuell (auch) mit dem Varnish-Cache-Server? Damit hatten wir hier schonmal Probleme, wenn ich mich recht erinnere (wg der :81 Umleitung).
Die Umleitung linkt nach: eine gesicherte Verbindung zu https://www.carpenter.de:81/etc und was passiert, wenn du das Zertikat zuläßt?

[yellowled]

manitu ist ja keine Feld-, Wald- und Wiesen-Bude. (Das Blog des Chefs dürfte eines der größten mit s9y betriebenen Blogs sein.) Frag einfach mal nach den Logs, das dürfte kein Problem sein – sie liegen vermutlich nur nicht im Webspace rum.

YL

[Timbalu]

...der im Übrigen keine Umleitung auf https verwendet und auch /admin funktioniert.

[carpe]

Folgende Fehlermeldung konnte ich jetzt erkennen:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Fatal error: Unknown: Failed opening required '/home/sites/site221/web/serendipity_admin.php' (include_path='.:/usr/local/php5/lib/php') in Unknown on line 0

Nur weiss ich nicht was ich mit anfangen soll.

[Timbalu]

Könntest du das ein wenig näher ausführen?

Wo und wann und wie kommt das Warning und dito für den fatal error zustande.

Insgesamt macht das höchstwahrscheinlich wenig Sinn das offensichtliche Server Problem von Serendipity Seite anzugehen, wenn du ausschließen kannst, dass du Dein Blog im Backend irgendwie geartet auf https umgestellt hast. Ich würde mich mit der weiter oben genannten kargen Antwort seitens deines ISP nicht zufriedengeben. Denn irgendetwas müssen sie gemacht haben, dass deinBlog/serendipity_admin.php nicht mehr normal erreichbar ist und mit einer white page exit Seite endet. Dazu muss man in die logs schauen. Ebenso die unmögliche Umleitung von deinBlog/admin auf obskure manitu secure Seiten (Ausgabe der Website: "CobaltRaQ"), die einen htaccess - htpassw Schutz haben. Das kann doch nicht einfach so geschehen?! Laut '/home/sites/site221/web/serendipity_admin.php' scheint dieser Path nicht zu stimmen, wenn es der augenscheinliche Umleitungsversuch ist, denn dann sucht dein PHP im include_path und wird dort ebensowenig fündig.

[carpe]

Die Error Meldung kam nachdem ich auf Providerhinweis hin in meine htaccess einen Code einfügte damit die Fehlermeldung beim Aufruf von domain.de/serendipidy_admin angezeigt wird.
Ansonsten hiess es:

"da es im Hosting wenig Sinn macht PHP-Error-Logs zu erstellen, geht das
leider nicht.

Evtl. hilft Ihnen ja folgendes weiter:

http://www.manitu.de/service/faq/?faq_entry_id=1226"

[Timbalu]

Server access und error.log sind sehr wohl sinnhaft, wenn auch eben auf Serverseite und nicht im öffentlichen Hosting - Userspace.

Du willst sagen du hast
php_value error_reporting 4095
php_value display_errors stdout
in deine htaccess geworfen und obiges Ergebnis erzielt, ja?

Wie genau sieht deine htaccess aus?

Ist es weiterhin möglich, dass dein Webserver (vielleicht plötzlich) unter einem anderen Benutzer läuft? Oder das du falsche Berechtigungen (file/dir) in deinem Webspace hast - oder sogar beides zusammen? Zb. könnte man in diesem Fall versuchen, mit chmod 755 serendipity_admin.php oder über FTP neue Perms zu setzen, da das Warning ja von failed to open stream: Permission denied spricht. Dann kannst du das debugging noch einmal laufen lassen.

[carpe]

Okay. Dein letzter Eintrag lies jetzt die Sperren in meinem Kopf aufgehen. Klar hatte ich die Berechtigungen der seredipity_admin auch im Verdacht....aber der Versuch diese zu ändern ging immer schief.
Aber....ich habe ja noch meine Webseite in einem weiteren Unterverzeichnis auf dem Webspace laufen und hatte mich anscheinend immer mit diese Zugangsdaten dort eingeloggt. Nach aus- und richtigem einloggen konnte ich die Berechtigung ändern und schon funzt wieder alles.
Danke Dir für die Mühe

[Timbalu]

Incredible!

Das löst aber immer noch nicht das Problem mit der Kurzform /admin Umleitung. Da wird deine htaccess, sollte sie dem normalen Stand von S9y entsprechen, von irgendeiner höheren bzw wichtigeren Anweisung überschrieben. Da würde ich also nachhaken.