Strato Server geht nicht mehr richtig

Bluebase

Registered User
Also seit neuesten geht mein Strato Powerserver nicht mehr. ich habe schon alle möglichen Logs angeguckt und es liegt wohl an SuPHP
hier die http log:
[Sun May 08 09:46:38 2005] [error] [client 145.254.189.51] Premature end of script headers: 1.php
[Sun May 08 09:46:38 2005] [error] [client 145.254.189.51] Error in suphp.c on line 247: Inappropriate permissions set on script
jetzt die suphplog:
[Sun May 08 09:46:38 2005] [error] Script (/home/b/bluebase-guide.net/public_html/1.php) is writeable by others
[Sun May 08 09:48:45 2005] [info] Executing /home/b/bluebase-guide.net/public_html/start.php as user bluebaseguidenet (500), group www (60006)
[Sun May 08 09:51:07 2005] [error] UID of /home/d/de-ats.tk/public_html/index.php or its target (0 / root) < 100
[Sun May 08 09:56:35 2005] [info] Executing /home/b/bluebase-guide.net/public_html/Forum/index.php as user bluebaseguidenet (500), group www (60006)
ich hab schon alle möglichen Chmods probiert, es kommt immer bei der eingabe der adresse:
Server error!

The server encountered an internal error and was unable to complete your request.

Error message:
Premature end of script headers: index.php

If you think this is a server error, please contact the webmaster.
Error 500

Seit neuestens geht auch mein Gameserver nicht mehr, ich kann ihn nicht mehr starten, da kommt sinngemäß der Fehler dass er bereits an ist. bei ps -al steht er aber nicht drinne, doch bei pstree und in Visas. also kann ch den ja auch nicht beenden, weil ich ja keine PID rausbekomme...
Ich binlangsam echt am verzweifeln, wir wollen, falls wir nicht mehr dahinter kommen, debian installieren.
Vielleicht weiß ener von euch noch weiter
 
Code:
[Sun May 08 09:46:38 2005] [error] [client 145.254.189.51] Premature end of script headers: 1.php
[Sun May 08 09:46:38 2005] [error] [client 145.254.189.51] Error in suphp.c on line 247: Inappropriate permissions set on script
Die erste Zeile besagt nur, dass keine korrekten HTTP-Header vom Script gesendet wurden -- das ist auch kein Wunder, solange suPHP Fehlermeldungen ausspuckt, statt das Script auszuführen.
Das zweite ist sehr allgemein und wird ja im suPHP-Log deutlicher...:

Code:
[Sun May 08 09:46:38 2005] [error] Script (/home/b/bluebase-guide.net/public_html/1.php) is writeable by others
[Sun May 08 09:48:45 2005] [info] Executing /home/b/bluebase-guide.net/public_html/start.php as user bluebaseguidenet (500), group www (60006)
[Sun May 08 09:51:07 2005] [error] UID of /home/d/de-ats.tk/public_html/index.php or its target (0 / root) < 100
[Sun May 08 09:56:35 2005] [info] Executing /home/b/bluebase-guide.net/public_html/Forum/index.php as user bluebaseguidenet (500), group www (60006)
Zeile 1: Setz die Rechte mal auf 755 (sind vermutlich 777 oä.).
Zeile 2 sagt nur, dass das Ausführen geklappt hat.
Zeile 3: Das Script gehört dem User root. User root hat die UID 0 und liegt damit (richtigerweise...) unter deinem UID Limit von 100. Lösung: Das Script einem anderen User 'chow'nen, zB. bluebaseguidenet oder was auch immer, also chown bluebaseguidenet:www index.php.
Zeile 4 ist wieder nur eine Erfolgsmeldung.
 
gesagt etan, aber der server tut immernoch nix... vor allem is das letzte aus der suphplog vom 8.Mai...
bei visas kann ich http beenden und https auch, visas läuft überhttps. wenn ich http beende, geht dann auch visas nimmer? weil sonst könnte ich mal probieren http neuzustarten.
 
Bluebase said:
gesagt etan, aber der server tut immernoch nix... vor allem is das letzte aus der suphplog vom 8.Mai...
Versteh nicht ganz was du meinst. Wie lauten die aktuellen Fehlermeldungen?
bei visas kann ich http beenden und https auch, visas läuft überhttps. wenn ich http beende, geht dann auch visas nimmer? weil sonst könnte ich mal probieren http neuzustarten.
Für HTTPS läuft normalerweise ein getrennter Apache, dh. das Beenden des normalen HTTPds dürfte keinen Einfluss auf den SSL-HTTPd haben. Notfalls kannst dus ja auch per Konsole neustarten.
 
Bluebase said:
gibt eben keine aktuellen logs, sind alle vom 8.mai...
ich ruf mal bei strato an
Ach so war das gemeint.. auch nicht vom Apache? Evtl. vHost-spezifische Errorlogs?
 
ok die von Strato haben jetzt zumindest hinbekommen, dass er wieder Error Logs schreibt. Ich lad die dann mal runter
 
so hier die aktuelle log von apache
[Thu May 19 16:20:06 2005] [error] [client 80.109.155.71] File does not exist: /home/b/bluebase-guide.net/public_html/start.phpindex2.php
[Thu May 19 16:21:06 2005] [error] [client 80.109.155.71] File does not exist: /home/b/bluebase-guide.net/public_html/start.phpindex2.php
[Thu May 19 16:22:06 2005] [error] [client 80.109.155.71] File does not exist: /home/b/bluebase-guide.net/public_html/start.phpindex2.php
[Thu May 19 16:23:06 2005] [error] [client 80.109.155.71] File does not exist: /home/b/bluebase-guide.net/public_html/start.phpindex2.php
[Thu May 19 16:23:27 2005] [error] [client 145.254.189.215] Premature end of script headers: index.php
[Thu May 19 16:23:27 2005] [error] [client 145.254.189.215] Error in log.c on line 68: Could not open logfile (Permission denied)
[Thu May 19 16:23:31 2005] [error] [client 145.254.189.215] File does not exist: /home/b/bluebase-guide.net/public_html/favicon.ico
und suphp:
[Sun May 08 10:05:40 2005] [info] Executing /home/b/bluebase-guide.net/public_html/Forum/index.php as user bluebaseguidenet (500), group www (60006)
[Sun May 08 10:05:45 2005] [info] Executing /home/b/bluebase-guide.net/public_html/Forum/index.php as user bluebaseguidenet (500), group www (60006)
die herren vom strato support haben mir noch folgendes geschrieben:
MAIL 1


1. Richtige Zugriffs- und Benutzerrechte auf das Skript und das Skript-Verzeichnis setzen:

a) auf Visas-Installationen können die Zugriffs- und Benutzerrechte aller Dateien im Heimatverzeichnis der Domain über den Domain-Administrator, Menüpunkt "Tools, Verzeichnisrecte", "Verzeichnisrechte reparieren" korrigiert werden.

b) auf Confixx-Installationen stellen Sie bitte sicher, dass das Verzeichnis und das Skript, das sich in dem Verzeichnis befindet, über folgende Zugriffs- und Benutzerrechte verfügt:

Verzeichnis - Zugriffs- und Benutzerrechte:
Zugriffsrechte: 755
Besitzer: der jeweilige web[x]-Benutzer
Gruppe: wie in der /etc/apache2/confixx_vhost.conf angegeben, in der VHOST-Sektion der entsprechenden Domain: geben Sie den zweiten Wert als Gruppe an, der hinter dem Schalter "SuexecUserGroup" steht.

Skript - Zugriffs- und Benutzerrechte:
Zugriffsrechte: 755
Besitzer: der jeweilige web[x]-Benutzer
Gruppe: wie in der /etc/apache2/confixx_vhost.conf angegeben, in der VHOST-Sektion der entsprechenden Domain: geben Sie den zweiten Wert als Gruppe an, der hinter dem Schalter "SuexecUserGroup" steht.

Die Zugriffs- und Benutzerrechte können mit den Befehlen chmod und chown oder innerhalb von WinSCP (rechter Klick auf das Verzeichnis / Skript, "Eigenschaften") korrigiert werden.

2. Das Tool dos2unix über Yast installieren und das Skript in das UNIX-Format konvertieren mit dem Befehl:

dos2unix Skript-Datei

Bitte beachten Sie, dass durch die Konvertierung mit Hilfe von dos2unix die Zugriffsrechte, der Besitzer und die Gruppe des Skripts geändert werden können. Deswegen nach der Konvertierung die Zugriffsrechte, der Besitzer und die Gruppe auf Richtigkeit hin kontrollieren und ggf. ändern. Das Korrigieren der Besitz- und Zugriffsrechte kann auch durch Anwendung des folgenden Schritts durchgeführt werden:

3. Sicherstellen, dass der Besitzer und die Gruppe für das Skript richtig zugeordnet sind.

(Hinweis: Dies kann in VISAS im VISAS-Domainadministrator, Menü Tools, Verzeichnisrechte ändern, erreicht werden. Dies ist ein komfortabler Lösungsweg, falls eine Vielzahl von Skripten korrigiert werden müssen, was die Zuordnung von Besitzer und Gruppe betrifft).

4. VISAS: Überprüfen, ob die richtige Version von suexec auf dem Server aktiviert ist:

Zwei Varianten von suexec liegen im Verzeichnis /usr/sbin/:

suexec
suexec.visas

bzw.

suexec2
suexec2_visas

Führen Sie folgenden Befehl aus, um zu erfahren, in welchem übergeordneten DocumentRoot-Verzeichnis der Suexec-Mechanismus greift:

# suexec -V

bzw.

# suexec2_visas -V

Falls Sie die Ausgabe

"-D DOC_ROOT="/home"

erhalten, dann greift der suexec-Mechanismus im richtigen Verzeichnis für Visas-Installationen.

Falls der Wert:

-D DOC_ROOT="/srv/www/htdocs"

ausgegeben wird, führen Sie bitte Folgendes durch:

# mv suexec suexec.BAK
# mv suexec.visas suexec

bzw.

# mv suexec2 suexec2.BAK
# mv suexec2_visas suexec2

5. Eine weitere mögliche Ursache ist der Quellcode von PHP-S




Mail 2(anderer Mitarbeiter)



Nach einer Untersuchung Ihres Systems hat sich ergeben, dass etliche
Scriptdateien nicht dem Nutzer "bluebaseguidenet" oder der Gruppe
"www" zugeordnet waren. Weiterhin haben die Scriptdateien oft nicht
die benötigten Rechte von "755" gesetzt. Bitte überprüfen Sie die
Zuordnungen und Rechte der Scriptdateien.

Weiterhin hat die Analyse der Log-Dateien ergeben, dass der Webserver
seit dem Sun May 08 10:08:32 2005 nicht mehr die Rechte besitzt alle
notwendigen Log-Dateien zu schreiben. Dieser bricht darauf hin mit
einer Fehlermeldung ab.

Bitte versuchen Sie zu ermitteln welche Konfiguration damals geändert wurde.

Nur schlecht dass grade zu der Zeit gar nix geändert wurde
Und hab auch alles gemacht was da stand... Die Dateirechte kommen von versuchen. Einfachste ausgaben von Buchstaben gehen ja auch net
 
Bluebase said:
weiß keiner weiter?
Punkt 1: Nicht ungeduldig werden.
Punkt 2: Boardregeln (Punkt 3) beachten.

strato said:
mv suexec.visas suexec
Unglaublich! Und nach dem nächsten update gibt es kein Backup mehr...
Bitte direkt in 'cp -p suexec.visas suexec' ersetzen.
Falls suexec.visas nicht mehr existiert sofort zurück kopieren.

Ausserdem fehlt hier noch der Hinweiß, daß man danach Apache neu starten muß.

Zu Deinen Logfiles:
Was mich irritiert ist die Zeile:
[Sun May 08 10:05:45 2005] [info] Executing /home/b/bluebase-guide.net/public_html/Forum/index.php as user bluebaseguidenet (500), group www (60006)

Die GID von www ist viel zu hoch. Bei mir (Suse 9.1) liegt die auf 8.

Ansonsten paßt das suphp_log zeitlich nicht zur access_log.
Es ist also nicht sehr aussagekräftig.

huschi.
 
ja suphp schreibt keine logs mehr... KA wieso.
und den ersten teil deiner ausführungen kann ich grade net folgen...
mv suexec.visas suexec
was is daran falsch?
apache hab ich scho lange restartet :)
 
Bluebase said:
und den ersten teil deiner ausführungen kann ich grade net folgen...
Vorallem das mit den Boardregeln nicht. Zweite Ermahnung!

mv suexec.visas suexec
was is daran falsch?
Das danach keine suexec.visas mehr existiert. D.h., wenn nochmal ein Problem damit entsteht, hast Du kein Backup der visas-eigenen suexec mehr.

huschi.
 
Mir fällt gerade noch auf:
suexec hat nichts mit suphp zu tun. Denn suphp ist ein Apache-Modul.
Evtl. wird diese nicht mehr geladen. Schau mal in der Modullist nach.

huschi.
 
OK sorry ich achte jetzt auf Groß- und Kleinschreibung :)
Das mv suexec.visas hab ich gar nich ausgeführt, da der Punkt davor ja schon gestimmt hat.
Wenn du mir noch erklärst wie ich ohne phpinfo() in die Modulliste komme, denn eine andere Möglichkeit ist mir nicht bekannt :-/
 
Bluebase said:
Wenn du mir noch erklärst wie ich ohne phpinfo() in die Modulliste komme
Indem Du die Apache-Config-Files nach der Direktive 'LoadModul' durchsuchst.
Oder - falls Du ein SuSe >9.0 hast - sollten diese Module alle in /etc/apache2/sysconfig.d/loadmodule.conf aufgelistet sein.

huschi.
 
LoadModule access_module /usr/lib/apache2-prefork/mod_access.so
LoadModule actions_module /usr/lib/apache2-prefork/mod_actions.so
LoadModule alias_module /usr/lib/apache2-prefork/mod_alias.so
LoadModule auth_module /usr/lib/apache2-prefork/mod_auth.so
LoadModule auth_dbm_module /usr/lib/apache2-prefork/mod_auth_dbm.so
LoadModule autoindex_module /usr/lib/apache2-prefork/mod_autoindex.so
LoadModule cgi_module /usr/lib/apache2-prefork/mod_cgi.so
LoadModule dir_module /usr/lib/apache2-prefork/mod_dir.so
LoadModule env_module /usr/lib/apache2-prefork/mod_env.so
LoadModule expires_module /usr/lib/apache2-prefork/mod_expires.so
LoadModule include_module /usr/lib/apache2-prefork/mod_include.so
LoadModule log_config_module /usr/lib/apache2-prefork/mod_log_config.so
LoadModule mime_module /usr/lib/apache2-prefork/mod_mime.so
LoadModule negotiation_module /usr/lib/apache2-prefork/mod_negotiation.so
LoadModule setenvif_module /usr/lib/apache2-prefork/mod_setenvif.so
LoadModule ssl_module /usr/lib/apache2-prefork/mod_ssl.so
LoadModule suexec_module /usr/lib/apache2-prefork/mod_suexec.so
LoadModule suphp_module /usr/lib/apache2/mod_suphp.so
LoadModule php4_module /usr/lib/apache2-prefork/libphp4.so
 
Bluebase said:
LoadModule suphp_module /usr/lib/apache2/mod_suphp.so
Mmmmh, da steht es ja...

Die nächste Idee wäre den LogLevel auf 'info' zustellen um detailiertere Fehler zu erhalten.

huschi.
 
Suche im Verzeichnis /etc/apache2/ nach einem Eintrag von LogLevel und setzte ihn neu. Danach den Indianer neu starten.

huschi.
 
Ich denke mal du meinst die mod_log_config.conf ;)
da steht folgendes:
#
# The following directives define some format nicknames for use with
# a CustomLog directive.
#
# http://httpd.apache.org/docs-2.0/mod/mod_log_config.html
#

#
# Format string: Nickname:
#
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
LogFormat "%h %l %u %t \"%r\" %>s %b \
\"%{Referer}i\" \"%{User-Agent}i\"" combined

# To use %I and %O, you need to enable mod_logio
<IfModule mod_logio.c>
LogFormat "%h %l %u %t \"%r\" %>s %b \
\"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
</IfModule>

# Use one of these when you want a compact non-error SSL logfile on a virtual
# host basis:
<IfModule mod_ssl.c>
Logformat "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \
\"%r\" %b" ssl_common
Logformat "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \
\"%r\" %b \"%{Referer}i\" \"%{User-Agent}i\"" ssl_combined
</IfModule>
Was muss ich da jetzt ändern?
 
Back
Top