Kann keine cgi ausführen

[Patrick Klein]

Hallo,

ich hab hier ein Problem mit einem Formmailer:
Ich habe deswegen schon einmal hier gepostetd.
Es scheint aber nicht an meinem Formmailer zu liegen, sondern am cgi-bin. Ich habe den CHMOD für das script auf 000 gesetzt, also gar keine Rechte. Ich bekomme trotzdem immer noch den Internal Server Error. Da kann es doch nur an perl liegen, oder?
Muss ich auf dem Server was starten? Perl oder so etwas?
Muss ich einen Verweis vom cgi-bin zum perl-Verzeichnis anlegen?
Wenn ja, wie kann ich das machen?

Vielen Dank
Patrick Klein

[Patrick Klein]

Noch etwas:
Das script läuft auf meinem anderen Webspace einwandfrei.
Also kann es daran wirklich nicht liegen.

Cu
Patrick

Hallo,

ich hab hier ein Problem mit einem Formmailer:
Ich habe deswegen schon einmal hier gepostetd.
Es scheint aber nicht an meinem Formmailer zu liegen, sondern am cgi-bin. Ich habe den CHMOD für das script auf 000 gesetzt, also gar keine Rechte. Ich bekomme trotzdem immer noch den Internal Server Error. Da kann es doch nur an perl liegen, oder?
Muss ich auf dem Server was starten? Perl oder so etwas?
Muss ich einen Verweis vom cgi-bin zum perl-Verzeichnis anlegen?
Wenn ja, wie kann ich das machen?

Vielen Dank
Patrick Klein

[Stefan Muenz]

Hallo Patrick,

Ich habe den CHMOD für das script auf 000 gesetzt, also gar keine Rechte. Ich bekomme trotzdem immer noch den Internal Server Error.

Wie bitte? Was heisst hier "trotzdem"? Wenn niemand irgendein Recht hat, irgendwas mit dieser Datei zu tun, dann kann doch auch nichts gehen. Versuchs mal mit dem praktischen Menschenverstand: der Perl-Prozess (oder der Webserver-Prozess), der das Script ausfuehrt, ist aus Sicht des Rechners ein Benutzer, der zu einer Gruppe gehoert usw. Dieser Benutzer und seine Gruppe haben nun bei dir (wie alle anderen Gruppen und Benutzer) keinerlei Rechte, irgendwas mit dieser Datei zu tun. Weder sie zu lesen, noch sie auszufuehren. Und da wunderst du dich, warum nichts geht? Also: z.B. chmod 755 oder 775 oder 770 oder 771 mal probieren.

viele Gruesse
  Stefan Muenz

[Patrick Klein]

Hallo Stefan,

natürlich war der CHMOD auf 755 gesetzt, ich wollte es nur ausprobieren, was er macht, wenn ich den auf 000 setze.
Normalerweise müsste doch ein anderer Fehler kommen, kein Zugriff oder so!
Aber es kommt gar nichts. Immer nur 500.

Ich hab mal perl -w Datei.cgi ausgeführt und bekam folgende Fehler:

False [] range "\w-" before HERE mark in regex m/[^\w- << HERE ./\]+/ at af2.c
gi line 186.
False [] range "\w-" before HERE mark in regex m/[^\w- << HERE ./\]+/ at af2.c
gi line 198.
Name "Mail::Sendmail::error" used only once: possible typo at af2.cgi line 301.
Use of uninitialized value in string ne at af2.cgi line 58.

Nur verstehe ich nicht, was diese Fehler bedeuten.
Wer kann mir weiterhelfen?

Vielen Dank
Patrick Klein

Hallo Patrick,

Ich habe den CHMOD für das script auf 000 gesetzt, also gar keine Rechte. Ich bekomme trotzdem immer noch den Internal Server Error.

Wie bitte? Was heisst hier "trotzdem"? Wenn niemand irgendein Recht hat, irgendwas mit dieser Datei zu tun, dann kann doch auch nichts gehen. Versuchs mal mit dem praktischen Menschenverstand: der Perl-Prozess (oder der Webserver-Prozess), der das Script ausfuehrt, ist aus Sicht des Rechners ein Benutzer, der zu einer Gruppe gehoert usw. Dieser Benutzer und seine Gruppe haben nun bei dir (wie alle anderen Gruppen und Benutzer) keinerlei Rechte, irgendwas mit dieser Datei zu tun. Weder sie zu lesen, noch sie auszufuehren. Und da wunderst du dich, warum nichts geht? Also: z.B. chmod 755 oder 775 oder 770 oder 771 mal probieren.

viele Gruesse
  Stefan Muenz

[Klaus Mock]

Hallo,

Es scheint aber nicht an meinem Formmailer zu liegen, sondern am cgi-bin. Ich habe den CHMOD für das script auf 000 gesetzt, also gar keine Rechte. Ich bekomme trotzdem immer noch den Internal Server Error. Da kann es doch nur an perl liegen, oder?

Nicht zwangsläufig. Also das mit chmod 000 dürfte ja inzwischen geklärt sein. Du hast uns aber auch vorenthalten, was denn nun im Error-Log des Webservers steht. Wenn der Scriptaufruf oder sonst etwas nicht richtig funktioniert, sollte Deine ganze Aufmerksamkeit dieser Datei gewidmet sein. Ohne dieser Information ist die Fehlerbeseitigung nur ein Herumraten.

Hier nur die wichtigsten Fehlerquellen:

• Perl ist nicht am Server installiert
• Der Webserver ist nicht für die Ausführung von Scripts konfiguriert
• Das Script liegt in einem Verzeichnis, welches nicht für Scriptausführung viorgesehen ist
• Der Scriptname wurde falsch eingegeben (Case-Sensitiv)
• Der Pfad zum Perlinterpreter (#!/usr/bin/perl) ist für diese Maschine falsch angegeben. Vielleicht ist es /usr/local/bin/perl.
• Ein benötigtes Modul ist nicht vorhanden
• Der User, unter dem der Webserver arbeitet, hat keine Rechte, die Datei zu lesen ( überprüfe den lokalen Pfad auch mit)
• Im Script hat sich ein Fehler eingeschlichen
• Bei der Übertragung auf den Server per FTP wurde das Script nicht im ASCII-Mode gesendet

Es gibt sicherlich noch mehr mögliche Ursachen, aber wirklich wichtig ist der Server-Log.

Grüße
  Klaus

[Patrick Klein]

Hallo Klaus,

ich hab mal ein paar Kommentare hinterlassen, ich weis echt nicht mehr weiter.
 Danke
Patrick

Hier nur die wichtigsten Fehlerquellen:

• Perl ist nicht am Server installiert

Doch, ist es

• Der Webserver ist nicht für die Ausführung von Scripts konfiguriert

Wie bitte? Wie geht denn das? Was muss ich da machen?

• Das Script liegt in einem Verzeichnis, welches nicht für Scriptausführung viorgesehen ist

Doch, im cgi-bin

• Der Scriptname wurde falsch eingegeben (Case-Sensitiv)

Was heist das?

• Der Pfad zum Perlinterpreter (#!/usr/bin/perl) ist für diese Maschine falsch angegeben. Vielleicht ist es /usr/local/bin/perl.

Es ist #!/usr/bin/perl

• Ein benötigtes Modul ist nicht vorhanden

Welches Modul könnte da fehlen?

• Der User, unter dem der Webserver arbeitet, hat keine Rechte, die Datei zu lesen ( überprüfe den lokalen Pfad auch mit)

Wie richte ich die ein, wenn es das sein sollte?

• Im Script hat sich ein Fehler eingeschlichen

Glaub ich nicht, denn woanders läuft es, hab es 1:1 kopiert

• Bei der Übertragung auf den Server per FTP wurde das Script nicht im ASCII-Mode gesendet

Es wurde im ASCII gesendet, das ist mir schonmal passiert, dann nie wieder. Aus Fehlern lernt man...;-)

Es gibt sicherlich noch mehr mögliche Ursachen, aber wirklich wichtig ist der Server-Log.

Grüße
  Klaus

[Klaus Mock]

Hallo,

• Der Webserver ist nicht für die Ausführung von Scripts konfiguriert
  Wie bitte? Wie geht denn das? Was muss ich da machen?

Das kommt auf den verwendeten Webserver an, für Apache findest DU das wichtigste unter http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm bzw. http://httpd.apache.org/docs/howto/cgi.html.

• Der Scriptname wurde falsch eingegeben (Case-Sensitiv)
  Was heist das?

Beachte auch Groß-Kleinschreibung heißt das;-)
Am server heißt das script 'Formmailer.cgi' und Du rufst es per '/cgi-bin/formmailer.cgi' auf.

• Ein benötigtes Modul ist nicht vorhanden
  Welches Modul könnte da fehlen?

Was weiß ich, nur Dein Script kann da Aufschluß geben. Suche nach den Anweisungen mit 'use' bzw. 'require' im Script. Sämtliche darin vorkommenden Module müssen auch auf dem Zielsystem vorhanden sein (undauch gefunden werden können). Näheres steht in der Perl-Dokumentation (perldoc perlmod).

• Der User, unter dem der Webserver arbeitet, hat keine Rechte, die Datei zu lesen ( überprüfe den lokalen Pfad auch mit)
  Wie richte ich die ein, wenn es das sein sollte?

In der server-Konfiguration steht, mit welchem User-Account der Webserver arbeitet (wwwrun oder nodoby oder was auch immer). Dieser User muß per Dateirechte die Möglichkeit haben, die Datei zu lesen und auszuführen. Das gleiche gilt für jedes Verzeichnis im (lokalen) Pfad.

• Im Script hat sich ein Fehler eingeschlichen
  Glaub ich nicht, denn woanders läuft es, hab es 1:1 kopiert

Glauben heißt oft einfach nur, es nicht wirklich zu wissen;-)

• Bei der Übertragung auf den Server per FTP wurde das Script nicht im ASCII-Mode gesendet
  Es wurde im ASCII gesendet, das ist mir schonmal passiert, dann nie wieder. Aus Fehlern lernt man...;-)

Das ist ja schon was.

Es gibt sicherlich noch mehr mögliche Ursachen, aber wirklich wichtig ist der Server-Log.

Ich wiederhole es nochmals ganz langsam:
_W a s_  s t e h t  i n  d e n  L o g f i l e s  d e s  S e r v e r s ?

Alles andere ist Spekulation. Du kannst es drehen und wenden, diese Frage gehört beantwortet.

Grüße
  Klaus

[Patrick Klein]

Hallo Klaus,

im Log steht: Premature end of script headers.
Sorry, hab ich eben vergessen.

Cu
Patrick

Hallo,

• Der Webserver ist nicht für die Ausführung von Scripts konfiguriert
  Wie bitte? Wie geht denn das? Was muss ich da machen?

Das kommt auf den verwendeten Webserver an, für Apache findest DU das wichtigste unter http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm bzw. http://httpd.apache.org/docs/howto/cgi.html.

• Der Scriptname wurde falsch eingegeben (Case-Sensitiv)
  Was heist das?

Beachte auch Groß-Kleinschreibung heißt das;-)
Am server heißt das script 'Formmailer.cgi' und Du rufst es per '/cgi-bin/formmailer.cgi' auf.

• Ein benötigtes Modul ist nicht vorhanden
  Welches Modul könnte da fehlen?

Was weiß ich, nur Dein Script kann da Aufschluß geben. Suche nach den Anweisungen mit 'use' bzw. 'require' im Script. Sämtliche darin vorkommenden Module müssen auch auf dem Zielsystem vorhanden sein (undauch gefunden werden können). Näheres steht in der Perl-Dokumentation (perldoc perlmod).

• Der User, unter dem der Webserver arbeitet, hat keine Rechte, die Datei zu lesen ( überprüfe den lokalen Pfad auch mit)
  Wie richte ich die ein, wenn es das sein sollte?

In der server-Konfiguration steht, mit welchem User-Account der Webserver arbeitet (wwwrun oder nodoby oder was auch immer). Dieser User muß per Dateirechte die Möglichkeit haben, die Datei zu lesen und auszuführen. Das gleiche gilt für jedes Verzeichnis im (lokalen) Pfad.

• Im Script hat sich ein Fehler eingeschlichen
  Glaub ich nicht, denn woanders läuft es, hab es 1:1 kopiert

Glauben heißt oft einfach nur, es nicht wirklich zu wissen;-)

• Bei der Übertragung auf den Server per FTP wurde das Script nicht im ASCII-Mode gesendet
  Es wurde im ASCII gesendet, das ist mir schonmal passiert, dann nie wieder. Aus Fehlern lernt man...;-)

Das ist ja schon was.

Es gibt sicherlich noch mehr mögliche Ursachen, aber wirklich wichtig ist der Server-Log.

Ich wiederhole es nochmals ganz langsam:
_W a s_  s t e h t  i n  d e n  L o g f i l e s  d e s  S e r v e r s ?

Alles andere ist Spekulation. Du kannst es drehen und wenden, diese Frage gehört beantwortet.

Grüße
  Klaus

[Klaus Mock]

Hallo,

im Log steht: Premature end of script headers.

Und da sind wir dieder dort wo Dein erster Thread schon war:-(
Kannst Du uns irgendwie den _gesamten_ Script-Source zur verfügung stellen? Am besten durch einen Link, das posten des Sources ist nicht gerade angebracht.

Diese Fehlermeldung sagt nur aus, daß Du keinen oder falschen HTTP-Header ausgegeben hast. Irgendwo im Script sollte eine Anweisung stehen, die in etwa so lauten kann:

print "Content-Type: text/html\n\n";

Der Teil des Scripts, den Du weiter unten gepostet hast, enthält keinerlei print-Anweisungen. Wenn das wirklch da sganze Script sein sollte, dann ist die Fehlermeldung durchaus verständlich, weil da vom Script gar nichts kommt.
Es könnte auch sein, daß das Script auf irgendwelche externen Resourcen (Dateien, Programme) zugreifen will, _bevor_ der Header ausgegeben wird. Wenn dann z.B. ein 'open(...) or die "Fehlermeldung"' vorkommt, und eben diese Fehlermeldung zuerst ausgegeben wird, dann findest Du auch die von Dir genannte Fehlermeldung im Log.

Grüße
  Klaus

[Patrick Klein]

Hallo,

im Log steht: Premature end of script headers.

Und da sind wir dieder dort wo Dein erster Thread schon war:-(
Kannst Du uns irgendwie den _gesamten_ Script-Source zur verfügung stellen? Am besten durch einen Link, das posten des Sources ist nicht gerade angebracht.

Diese Fehlermeldung sagt nur aus, daß Du keinen oder falschen HTTP-Header ausgegeben hast. Irgendwo im Script sollte eine Anweisung stehen, die in etwa so lauten kann:

print "Content-Type: text/html\n\n";

Der Teil des Scripts, den Du weiter unten gepostet hast, enthält keinerlei print-Anweisungen. Wenn das wirklch da sganze Script sein sollte, dann ist die Fehlermeldung durchaus verständlich, weil da vom Script gar nichts kommt.
Es könnte auch sein, daß das Script auf irgendwelche externen Resourcen (Dateien, Programme) zugreifen will, _bevor_ der Header ausgegeben wird. Wenn dann z.B. ein 'open(...) or die "Fehlermeldung"' vorkommt, und eben diese Fehlermeldung zuerst ausgegeben wird, dann findest Du auch die von Dir genannte Fehlermeldung im Log.

Grüße
  Klaus

[Patrick Klein]

Sorry, da war ich wohl zu schnell.

Hier die URL zum Script:

http://www.cgi.tj/scripts/alienform/af.txt

Wird dann in .cgi umbenannt.

Danke
Patrick

[Michael Schröpl]

Hi Patrick,

das scheint ja wirklich ein munteres Rätselraten zu werden.

Hier die URL zum Script:
http://www.cgi.tj/scripts/alienform/af.txt

das war schon mal eine gute Idee.

Auch wenn mich Dein Skript nicht sonderlich glücklich macht, weil da viel Unsinn drin steht, der Dir die Fehlersuche sehr erschweren wird.
Hättest Du beispielsweise "use CGI;" drin statt dieses komische "parse"-Zeug, dann könntest Du den Aufruf mit den Parametern, wie sie über die URL angefügt werden, ganz einfach auf der Kommandozeile ausprobieren und dann die (leider immer noch nirgendwo aufgetauchte) Meldung sehen, welche als allererste von Deinem Skript ausgegeben wird.

Ich bin mir ziemlich sicher, daß das irgend eine Fehlermeldung ist.
Und Dein Skript definiert zwar einen Content-type - aber wann und wo wird der denn jemals ausgegeben? Bis dahin kann alles Mögliche schief gegangen sein. Und wenn die erste (!) Ausgabe des Skripts kein korrekter HTTP-Header ist, hast Du verloren.

Also: Schreib mal gnadenlos
      print "Content-type: text/html\n\n"
in Zeile 2 des Skripts und laß es noch mal über den Browser laufen.
Die Chance, daß Du dann mehr siehst, ist nicht schlecht.

Die nächste Verbesserung wäre es,
      use CGI::Carp qw(fatalsToBrowser);
ebenfalls ganz weit oben einzufügen.
Was immer an Fehlermeldung erzeugt wird, geht bisher offenbar nach stderr und damit verloren - mit dieser Anweisung lenkst Du es nach stdout und damit in den Browser.

Mach das mal - danach sehen wir weiter.

Die Idee mit "perl -w" wäre für sich genommen nicht verkehrt gewesen - aber dafür ist die Substanz des vorliegenden Skripts einfach zu schlecht.

Das Skript ist wirklich _schauerlich_ programmiert.
In der Zeit, in der Du _das_ debuggst, hättest Du es wahrscheinlich selbst neu schreiben können - und dann würdest Du es auch verstehen.

Viele Grüße
      Michael