neue 1und1-server mit CGI-Problem

[gerd]

Hallo,
Ich habe einen neuen Rootserver von 1und1 mit Suse 9.3 und Plesk 7.5. Die Hotline von 1und1 konnte mir nicht helfen.
Daher wende ich mich nun an die "Profis" und an fachkundige Leidensgenossen.
Mein Problem und meine Bitte:
1.) Aufruf von einfachen Perlscripten über Browser zeigen 500 Internal Server Error und
2.) index.htm wird nicht als Startdatei bei Aufruf des Verzeichnisnamens gefunden.

Sachverhalt: In Plesk 7.5 unter Hosting aktiviert:
- Aktiviere Web-Benutzer@testdomain.de Zugriffsformat
- Skriptausführung durch Web-Benutzer erlauben

In Plesk 7.5 unter Setup/ Dienste für die Domain testdomain.de praktisch alles freigegeben, so auch
CGI-Unterstützung (aktiviert). Ã?brigens ist PHP-Unterstützung auch aktiviert und PHP läuft einwandfrei

Apache natürlich immer mit rcapache2 restart jedesmal neu gestartet:
---------------------
zu 1.)
Auszug aus suexec.log am Beispiel des Perlscriptes perldiver.cgi (so auch perldiver.pl)
[2005-11-13 12:28:30]: uid: (10002/testuser) gid: (10001/10001) cmd: perldiver.cgi

error_log der eingerichteten Domain
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] failed to open log file /var/log/apache2/suexec.log
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] fopen: Permission denied
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] Premature end of script headers: perldiver.cgi
[Sun Nov 13 12:28:30 2005] [warn] [client 84.143.201.26] mod_include: Options +Includes (or IncludesNoExec) wasn't set, INCLUDES filter removed

Auszug aus /etc/apache2/httpd.include
<Directory "/home/httpd/vhosts">
AllowOverride All
Options SymLinksIfOwnerMatch
Order allow,deny
Allow from all
php_admin_flag engine off
</Directory>
und dann natürlich den Include-Befehl
Include /home/httpd/vhosts/testdomain.de/conf/httpd.include

Auszug aus /home/httpd/vhosts/testdomain.de/conf/httpd.include
ScriptAlias /cgi-bin/ /home/httpd/vhosts/testdomain.de/cgi-bin/
Options +Includes +ExecCGI

Wie gesagt, bei Aufruf des Perl-Scriptes über Browser (egal on .pl oder .cgi) erscheint eine 500 Error-Meldung.
Ã?ber die Konsole kann ich das Script aufrufen und mit Perl -c perldiver.cgi wird mir auch die korrekte Syntax bestätigt.
Die Rechte sind natürlich auf 755 gesetzt und es ist wahrscheinlich auch kein chown-Problem. da die Erzeugung vom User und nicht von Root erfolgte.

---------------------
zu 2.)
Auszug aus /etc/apache2/httpd.conf
DirectoryIndex at_domains_index.html index.html index.htm index.shtml index.php
---------------------

Wer weiß Rat? Danke.
gerd

[Roger Wilco]

error_log der eingerichteten Domain
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] failed to open log file /var/log/apache2/suexec.log
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] fopen: Permission denied

Ich wundere mich etwas, dass trotz dieser Meldung ein Eintrag in dein suexec.log geschrieben wird. :?
Kann der Apache überhaupt in /var/log/apache2/suexec.log schreiben? Ich könnte mir vorstellen, dass das Perlskript deshalb nicht ausgeführt wird.

zu 2.)
Auszug aus /etc/apache2/httpd.conf
DirectoryIndex at_domains_index.html index.html index.htm index.shtml index.php

Wird diese Direktive vielleicht in der httpd-Konfiguration des VirtualHosts (/home/httpd/vhosts/example.org/conf/httpd.include) überschrieben?

[gerd]

Leinder nein, die Anweisung
DirectoryIndex at_domains_index.html index.html index.htm index.shtml index.php
habe ich jetzt trotzdem mal in die /home/httpd/vhosts/testdomain.de/conf/httpd.include
eingestellt und den Apache neu gestartet. Keine Ã?nderung. Die Index.htm wird nicht erkannt und der Server sucht die Index.html.

Die Meldung
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] failed to open log file /var/log/apache2/suexec.log
finde ich auch sehr mürkwürdig, aber definitv ist zur gleichen Zeit nur ein Zugriff erfolgt. Auch jetzt erscheint der Eintrag in der suexec.log bei einer Wiederholung.
Die uid.conf mit user wwwrun und Group www kann es m.E. auch nicht sein, weil der Upload normal mit ASCII-FTP erfolgte und ein weiteres Testscript auf der Konsole erstellt wurde. Außerdem ist es auf dem alten Rootserver auch kein Problem.

Ich habe übrigens einen Benutzer vollkommen neu angelegt. Gleiches Problem.

[Joe User]

Die Index.htm wird nicht erkannt und der Server sucht die Index.html.

"I" != "i"

[gerd]

"I" != "i"
ist nicht der Grund. Die Datei heißt natürlich index.htm.
Ich vermute jetzt, dass das Problem irgendwie in der Zuordnung der conf-Dateien liegt.
Daher meine Frage: Wer hat noch den ganz neuen 1&1-Server und hat nicht dieses Problem.
Danke

[teratec]

Hallo gerd!

Hast Du das folgende Problem immer noch? Wenn "nein" wie hast Du es gelöst. Ich habe nämlich genau das gleiche Problem. Komisch ist, daß manche CGI-Skripte funktionieren und manche nicht.

error_log der eingerichteten Domain
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] failed to open log file /var/log/apache2/suexec.log
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] fopen: Permission denied
[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] Premature end of script headers: perldiver.cgi

Gruss
teratec

[timeless2]

[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] fopen: Permission denied

worauf greifst du mit fopen zu, klemmt es vielleicht da mit den Userrechten? Läuft der Virtualhost auf uid: (10002/testuser) gid: (10001/10001)?

[teratec]

[Sun Nov 13 12:28:30 2005] [error] [client 84.143.201.26] fopen: Permission denied

worauf greifst du mit fopen zu, klemmt es vielleicht da mit den Userrechten? Läuft der Virtualhost auf uid: (10002/testuser) gid: (10001/10001)?

Hallo,

bei mir wird versucht die suexec.log zu öffnen. Das komische ist, manche CGI-Skripte laufen und manche nicht. Die nicht laufen, erzeugen folgende Fehlermeldung:

[Sun Nov 27 17:41:52 2005] [error] [client 84.60.130.190] Premature end of script headers: XXX.cgi
[Sun Nov 27 17:41:52 2005] [error] [client 84.60.130.190] failed to open log file /var/log/apache2/suexec.log
[Sun Nov 27 17:41:52 2005] [error] [client 84.60.130.190] fopen: Permission denied

In der suexec.log treten keine Fehlermeldungen auf. Nur in der error_log des apache2.

Auszug aus der suexec2:
[2005-11-27 17:41:52]: uid: (10001/u35298960) gid: (10001/10001) cmd: XXX.cgi


Komisch ist auch, wenn ich suexec2 -V unter /usr/sbin/suexec2 eingebe passiert gar nichts! Nichts wird angezeigt.

Sitze schon seit Tagen an diesem blöden Fehler.

[teratec]

Hallo,

ich hatte die gleichen Feldermeldungen wie "gerd". Mein Problem habe ich entzwischen gelöst.

Bei mir funktionierten einige wenige cgi/perl-Skripte nicht. Diese nicht funktionierenden Skripte hatte ich mehrfach mit WsFTP und WinSCP auf den Rootserver hochgeladen (im ASCI-Modus/Text-Modus). Jedesmal wurden die Dateien auf dem Rootserver als "Binär"-Dateien ausgewiesen.

Festgestellt hatte ich dies, als ich diese Dateien mit "less" direkt auf dem Rootserver öffnen wollte.

Befehl: less Dateiname.cgi auf dem Rootserver ausführen.

Ich hatte diese Dateien mit verschiedenen Tools geöffnet und wieder neu gespeichert. Nichts half. Immer erhielt ich eine Binärdatei auf dem Rootserver.

Folgendes war passiert: Die cgi-Skripte, die nicht funktionierten lagen nur als gepackte zip-Dateien vor. Ich hatte diese Zip-Dateien geöffnet (Windows XP) und über das geöffnete Fenster in ein Verzeichnis auf meine Festplatte kopiert. DAS WAR DER FEHLER!!!

Wenn man so vorgeht, werden wohl immer automatisch Binärdateien erzeugt, die aber immer noch mit Textverarbeitungsprogrammen geöffnet werden können (Notepad, ähnliche)

Als ich die Zip-Datei mit WinZip entpackt hatte, erhielt ich auf einmal eine "ASCI/Text-Datei", die auch auf dem Rootserver nun nicht mehr als Binärdatei angezeigt wird.

Jetzt funktionieren wieder alle CGI-Skripte!!!

[horst]

Ich bin jetzt auch mit einem 1&1 Root Server beschäftigt. Wenn ich "suexec2 -V" eingebe, passiert bei mir auch nichts. Ich will eigentlich nur awstats konfigurieren. Da ich aber nichts an suexec ändern kann, kann ich auch nicht den DOCROOT ändern. Wenn der DOCROOT nicht übereinstimmt, kommt "Premature end of script headers".

Ich will nur den Docroot ändern und alles wird gut :) suexec-Modul ist geladen und logs werden auch erstellt - nur kann ich mit suexec (suexec2) nichts machen.

Was kann ich tun, um suexec zu bearbeiten (die Einstellungen)?

[EDIT]PL-Skripte laufen im angegebenen DOCROOT, aber awstats hat auf dem Server ein eigenes Docroot bekommenm worauf alle Anfragen der VHOSTS verweisen sollen...[/EDIT]

[teratec]

Zitat: Ich bin jetzt auch mit einem 1&1 Root Server beschäftigt. Wenn ich "suexec2 -V" eingebe, passiert bei mir auch nichts. Ich will eigentlich nur awstats konfigurieren.

Das gleiche Problem habe ich auch noch. Gib doch bitte mal bei Dir folgendes ein: rcapache2 extreme-configtest

Also ich bekomme dabei folgende Fehlermeldung:
Syntax: NOT OK:
httpd2-prefork: could not open document config file /home/httpd/vhosts/domain.../conf/httpd.include

Dieser Fehler hängt wohl mit den Zugriffsrechten zusammen. Irgendwie spinnt hier suexec und die von plesk verwendete suexec herum! Deshalb funktionieren manchmal die CGI-Skripte und manchmal eben nicht.

Der Fehler liegt nach meinen Recherchen an einem vom Hersteller falsch konfigurierten Plesk. Den Fehler mit den falsch gesetzten Zugriffsrechten trat bereits vor 1,5 Jahren bei Plesk auf und ist scheinbar immer noch nicht behoben.

[horst]

Ich habe exakt die gleiche Fehlermeldung. Und nun? Es muss doch einen Weg geben, suexec doch noch "zum Laufen" (Konfigurieren) zu bekommen. Kann man das Modul nicht einfach neu installieren und dann konfigurieren? Wenn ja, wie?

[sledge0303]

Stichwort Suchfunktion...

http://www.rootforum.org/forum/viewtopi ... ght=suexec

[horst]

Gut, das werde ich heute Abend mal durchackern... :)

[gerd]

Meine CGI-Probleme sind zwar noch ungelöst. Auch andere Nutzer klagen aber laut Hotline über cgi-Probleme. Und die 1&1-Hotline hat mir versichert, dass an der CGI-Problematik mit Hochdruck gearbeitet wird. Wer also zum Beispiel folgendes Problem hat, sollte sich noch etwas gedulden oder vielleicht weiß hier jemand vorab die Antwort:

So klappt ein einfaches SSI mit dem Aufruf eines Perlscriptes nicht korrekt aus dem Browser, aber einwandfrei auf der Konsole.
Beispiel eines SSI-Problems in HTML-Datei:
<!--#include virtual="../cgi-bin/testscript.pl"-->

Fehlermeldungen in der error_log
[Mon Dec 5 20:40:13 2005] [warn] [client xxxx] mod_include:
Options +Includes (or IncludesNoExec) wasn't set, INCLUDES filter
removed

Das Include-Modul ist aber geladen.
Ã?brigens klappt auch folgender SSI-Aufruf zur Inkludierung einer Textdatei nicht korrekt:
<!--#include virtual="../cgi-bin/test.txt"-->

Kein Problem hingegen bei:
<!--#include virtual="/test.txt"-->
oder
<!--#include virtual="test.txt"-->

Soweit zur allgemeinen Info.

[horst]

Ich habe das Problem gelöst - ohne Ã?nderung der suexec...

Das in die httpd.conf eingefügt (nach dem Zeug von awstats):

Code: Select all

<Directory "/usr/local/awstats/wwwroot/cgi-bin">
	Options +ExecCGI
</Directory>

<Files ~ (.pl$)>
	SetHandler perl-script
	PerlHandler ModPerl::Registry
	Options ExecCGI
	allow from all
	PerlSendHeader On
</Files>