apache2 - perl - qmail - Strato
Hallo zusammen, seit Tagen knobele ich an einem Problem und bekomme es einfach nicht in den Griff. Ich möchte vorausschicken, dass ich weder mit SuSE 9.3 (nur ältere 7/8-Versionen), noch mit Apache2 (nur 1.x), noch mit qmail (bisher sendmail) vertraut bin. Das möge man mir bitte nachsehen und bei Antworten berücksichtigen. Zur Sache: Umgebung: Strato High-End-Server mit SuSE 9.3 und ServerAdmin24, Apache2, Qmail Domain: www.megabiene.de, komplett konfiguriert, Domain und Maildienste laufen 1A. Die Ausführung eigener CGI's ist über ServerAdmin24 aktiviert. Der Benutzer heißt megabienede. Problem: Ich habe auf dem alten Server mit SuSE 7.0 ein von mir minimal modifiziertes formmail.pl (umbenannt in mailmanager.pl) seit 5 Jahren im Einsatz, völlig problemlos. Dieses Script habe auch auf den neuen Server kopiert und es mag zum Verrecken nicht laufen. Ich erhalte die Fehlermeldung: Premature end of script headers: mailmanager.pl Nachdem ich Google befragt und und unzähliche WEB-Seiten dazu gefunden und deren Tipps befolgte, habe ich mich in meiner Verzweiflung an den Strato-Support gewandt. Der hat auch zügig geantwortet (großes Lob) und mir im Grunde aber nur mitgeteilt, was ich via Google-Suche probiert habe. Hier mal die Antwort: ---Strato-Zitat---- Hierfür kann es mehrere Gründe geben. Überprüfen Sie zuerst in Serveradmin24, ob für den jeweiligen Kunden und die entsprechende Domain CGI-Skripte erlaubt sind. Stellen Sie bitte außerdem sicher, dass die CGI-Skripte nur von dem entsprechenden Benutzer gehören und nur von diesem schreibbar sind. Dies gilt auch für das cgi-bin Verzeichnis selbst. Falls FTP für die Übertragung der Skripte verwendet wird, benutzen Sie den ASCII-Modus im FTP-Programm. Weiterhin kann es sein, dass durch ein Update des Webservers, die Datei, die die Nutzungsrechte der CGI-Skripte überprüft, überschrieben wurde. -- Ende Strato-Zitat -- Zu Absatz 1 Habe ich geprüft, O.K. Zu Absatz 2 Alles zig-Mal geprüft und wiederholt. Zu Absatz 3 Das scheint zu funktionieren. Man kann mit ServerAdmin diese Rechte automatisch setzen lassen. Dabei kommt folgendes heraus (Datei gehörte vorher Root, da von mir bearbeitet und überschrieben): Rechte des Verzeichnisses: drwx---r-x 2 megabienede www 4096 Nov 9 09:43 cgi-bin/ Rechte des Perl-Scripts: -rwx---r-x 1 megabienede www 22868 Nov 9 09:43 mailmanager.pl* In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem Strato-Support dazu folgende Frage: Da auf dem Server qmail läuft (auf dem alten SuSE 7.0-System Sendmail) habe ich den Verdacht, dass dort der Hund begraben ist. Als Mailprogramm habe ich /var/qmail/bin/sendmail angegeben (aber auch SMTP:www.megabiene.de), da ich vermute(!), dass es sich dabei um eine Kompatibilitätshilfe für Leute wie mich handelt. Diese Frage blieb seitens Strato leider unbeantwortet. Vielleicht weiß von Euch jemand, ob meine Vermutung stimmt. Abschließend sei gesagt, dass ich das Script nmsformmail.pl, welches Strato zum Download anbietet, genau die selben Zicken macht, wie das alte Script. Ich _muss_ dieses Problem kurzfristig lösen, weiß aber einfach nicht mehr weiter. Über Eure Hilfe freue ich mich riesig. Gruß, Rolf P.S. Auf o.g. Domain ist ein Miniformular zum Testen hinterlegt. Einfach auf Abschicken klicken, dann erhält man eine ganz frisch generierte Fehlermeldung :-)
Rolf Scheurer wrote:
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem Strato-Support dazu folgende Frage:
Da auf dem Server qmail läuft (auf dem alten SuSE 7.0-System Sendmail) habe ich den Verdacht, dass dort der Hund begraben ist. Als Mailprogramm habe ich /var/qmail/bin/sendmail angegeben (aber auch SMTP:www.megabiene.de), da ich vermute(!), dass es sich dabei um eine Kompatibilitätshilfe für Leute wie mich handelt.
Schau doch mal in die Logs des Servers, was dort zu der Fehlermeldung steht. Sendet dein Script per smtp oder benutzt es die Kommandozeilenversion zum Abschicken der Mail?
P.S. Auf o.g. Domain ist ein Miniformular zum Testen hinterlegt. Einfach auf Abschicken klicken, dann erhält man eine ganz frisch generierte Fehlermeldung :-)
Dummerweise hilft diese Meldung nicht weiter. Meine Vermutung: du hast entweder einen falschen Pfad für sendmail angegeben, oder die Datei existiert nicht oder die Optionen, mit denen Sendmail aufgerufen wird, stimmen im Script nicht. Was passiert denn, wenn du das Script manuell auf der Kommandozeile startest mit Beispieldaten? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Mittwoch, 9. November 2005 10.56 schrieb Sandy Drobic:
Rolf Scheurer wrote:
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem Strato-Support dazu folgende Frage:
Da auf dem Server qmail läuft (auf dem alten SuSE 7.0-System Sendmail) habe ich den Verdacht, dass dort der Hund begraben ist. Als Mailprogramm habe ich /var/qmail/bin/sendmail angegeben (aber auch SMTP:www.megabiene.de), da ich vermute(!), dass es sich dabei um eine Kompatibilitätshilfe für Leute wie mich handelt.
Schau doch mal in die Logs des Servers, was dort zu der Fehlermeldung steht. Sendet dein Script per smtp oder benutzt es die Kommandozeilenversion zum Abschicken der Mail?
P.S. Auf o.g. Domain ist ein Miniformular zum Testen hinterlegt. Einfach auf Abschicken klicken, dann erhält man eine ganz frisch generierte Fehlermeldung :-)
Dummerweise hilft diese Meldung nicht weiter. Meine Vermutung: du hast entweder einen falschen Pfad für sendmail angegeben, oder die Datei existiert nicht oder die Optionen, mit denen Sendmail aufgerufen wird, stimmen im Script nicht. Was passiert denn, wenn du das Script manuell auf der Kommandozeile startest mit Beispieldaten?
Hast Du etwas am Script geändert? (Evtl. den Anführungszeichen, Semikolon o.ä. irgendwo vergessen.) Hast Du das Script evtl. mal auf einem Windows - System bearbeitet? Das könnte zu Problemen wegen den Zeilenenden <CR><LF> anstatt <LF> führen. Ich habe dasselbe Problem (mit derselben Fehlermeldung) mal erlebt, nachdem ich das CGI-Mailscript nur kurz in einem Windows-Editor hatte und dieses dann unter Windows abgespeichert habe. Gruss Werner
Hallo Werner, -snip-
Hast Du etwas am Script geändert? (Evtl. den Anführungszeichen, Semikolon o.ä. irgendwo vergessen.)
Geändert ja, aber das müsste alles stimmen.
Hast Du das Script evtl. mal auf einem Windows - System bearbeitet? Das könnte zu Problemen wegen den Zeilenenden <CR><LF> anstatt <LF> führen. Ich habe dasselbe Problem (mit derselben Fehlermeldung) mal erlebt, nachdem ich das CGI-Mailscript nur kurz in einem Windows-Editor hatte und dieses dann unter Windows abgespeichert habe.
Nein. Den Fehler habe ich damals begangen, als ich das formmail-Script angepasst habe, diesmal nicht. Ich habe es mit dem Midnight-Commander bearbeitet, der macht das offenbar richtig (0A am Zeilenende). War aber ein guter Tipp! Gruß, Rolf
Hallo Sandy, Rolf Scheurer wrote:
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem Strato-Support dazu folgende Frage:
Da auf dem Server qmail läuft (auf dem alten SuSE 7.0-System Sendmail) habe ich den Verdacht, dass dort der Hund begraben ist. Als Mailprogramm habe ich /var/qmail/bin/sendmail angegeben (aber auch SMTP:www.megabiene.de), da ich vermute(!), dass es sich dabei um eine Kompatibilitätshilfe für Leute wie mich handelt.
Schau doch mal in die Logs des Servers, was dort zu der Fehlermeldung steht. Sendet dein Script per smtp oder benutzt es die Kommandozeilenversion zum Abschicken der Mail?
P.S. Auf o.g. Domain ist ein Miniformular zum Testen hinterlegt. Einfach auf Abschicken klicken, dann erhält man eine ganz frisch generierte Fehlermeldung :-)
Dummerweise hilft diese Meldung nicht weiter. Meine Vermutung: du hast entweder einen falschen Pfad für sendmail angegeben, oder die Datei existiert nicht oder die Optionen, mit denen Sendmail aufgerufen wird, stimmen im Script nicht. Was passiert denn, wenn du das Script manuell auf der Kommandozeile startest mit Beispieldaten?
Da ich nicht sicher bin, ob das Script wasserdicht ist, habe ich es mit einem "Hallo Welt" Test probiert. Damit das gleiche Problem. Wenn "Hallo Welt" geht sehen wir mal weiter... Dank & Gruß, Rolf
Hallo, Für all die armen Teufel, die an dem Problem ähnlich verzweifeln wie ich, hier eine Lösung, die erst mal weiterhilft. Hier nocmal mein original-Posting:
Von: Rolf Scheurer [mailto:linux@scheurer-la.de] Betreff: apache2 - perl - qmail - Strato
Hallo zusammen,
seit Tagen knobele ich an einem Problem und bekomme es einfach nicht in den Griff.
Ich möchte vorausschicken, dass ich weder mit SuSE 9.3 (nur ältere 7/8-Versionen), noch mit Apache2 (nur 1.x), noch mit qmail (bisher sendmail) vertraut bin. Das möge man mir bitte nachsehen und bei Antworten berücksichtigen.
Zur Sache:
Umgebung: Strato High-End-Server mit SuSE 9.3 und ServerAdmin24, Apache2, Qmail Domain: www.megabiene.de, komplett konfiguriert, Domain und Maildienste laufen 1A. Die Ausführung eigener CGI's ist über ServerAdmin24 aktiviert. Der Benutzer heißt megabienede.
Problem: Ich habe auf dem alten Server mit SuSE 7.0 ein von mir minimal modifiziertes formmail.pl (umbenannt in mailmanager.pl) seit 5 Jahren im Einsatz, völlig problemlos. Dieses Script habe auch auf den neuen Server kopiert und es mag zum Verrecken nicht laufen. Ich erhalte die Fehlermeldung: Premature end of script headers: mailmanager.pl
Nachdem ich Google befragt und und unzähliche WEB-Seiten dazu gefunden und deren Tipps befolgte, habe ich mich in meiner Verzweiflung an den Strato-Support gewandt. Der hat auch zügig geantwortet (großes Lob) und mir im Grunde aber nur mitgeteilt, was ich via Google-Suche probiert habe. Hier mal die Antwort:
---Strato-Zitat---- Hierfür kann es mehrere Gründe geben. Überprüfen Sie zuerst in Serveradmin24, ob für den jeweiligen Kunden und die entsprechende Domain CGI-Skripte erlaubt sind.
Stellen Sie bitte außerdem sicher, dass die CGI-Skripte nur von dem entsprechenden Benutzer gehören und nur von diesem schreibbar sind. Dies gilt auch für das cgi-bin Verzeichnis selbst. Falls FTP für die Übertragung der Skripte verwendet wird, benutzen Sie den ASCII-Modus im FTP-Programm.
Weiterhin kann es sein, dass durch ein Update des Webservers, die Datei, die die Nutzungsrechte der CGI-Skripte überprüft, überschrieben wurde. -- Ende Strato-Zitat --
Zu Absatz 1 Habe ich geprüft, O.K.
Zu Absatz 2 Alles zig-Mal geprüft und wiederholt.
Zu Absatz 3 Das scheint zu funktionieren. Man kann mit ServerAdmin diese Rechte automatisch setzen lassen. Dabei kommt folgendes heraus (Datei gehörte vorher Root, da von mir bearbeitet und überschrieben):
Rechte des Verzeichnisses: drwx---r-x 2 megabienede www 4096 Nov 9 09:43 cgi-bin/
Rechte des Perl-Scripts: -rwx---r-x 1 megabienede www 22868 Nov 9 09:43 mailmanager.pl*
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem Strato-Support dazu folgende Frage:
Da auf dem Server qmail läuft (auf dem alten SuSE 7.0-System Sendmail) habe ich den Verdacht, dass dort der Hund begraben ist. Als Mailprogramm habe ich /var/qmail/bin/sendmail angegeben (aber auch SMTP:www.megabiene.de), da ich vermute(!), dass es sich dabei um eine Kompatibilitätshilfe für Leute wie mich handelt.
Diese Frage blieb seitens Strato leider unbeantwortet. Vielleicht weiß von Euch jemand, ob meine Vermutung stimmt.
Abschließend sei gesagt, dass ich das Script nmsformmail.pl, welches Strato zum Download anbietet, genau die selben Zicken macht, wie das alte Script.
Ich _muss_ dieses Problem kurzfristig lösen, weiß aber einfach nicht mehr weiter. Über Eure Hilfe freue ich mich riesig.
Zunächst mal vielen Dank an Alle, die versucht haben mir zu helfen. Von Strato kam auch nach mehreren Versuchen nur Unfug. Jedesmal das Gleiche, immer Dinge die ich schon wusste :-( Ich finde das schade, denn das Angebot von Strato ist ansonsten o.k., die Hardware ist ausgesprochen agil. Unsicherheit herrschte bei mir, ob die Datei /var/qmail/bin/sendmail das gute alte Sendmail emuliert. Ob dem so ist habe ich noch nicht ausprobiert, aber "which sendmail" liefert den korrekten Pfad. Ich erwähne das, damit später ein nach Hilfe googelnder niemand auf meine Mutmaßung reinfällt. Das aber war nicht der Auslöser meiner Verzweiflung. Werner Merz hat es im Prinzip erkannt, der Apache ist falsch konfiguriert. Ich habe zwar inzwischen viel über Apache 2 gelernt, aber einige Sachen liegen noch im dunkelen. Apache benötigt die Datei suexec2, mit deren Hilfe man ihm mitteilt, als welcher Benutzer u. welcher Gruppe die Scripts ausgeführt werden sollen (dürfen). Das wird beim Kompilieren festgelegt. Zaghafte Versuche, dies zu tun sind gescheitert, nicht zuletzt wohl auch, weil trotz Nachfrage keine Antwort von Strato kam, mit welchen Parametern das zu geschehen hat. Blauäugig habe ich suexec2 mal in suexec2-old umbenannt und Apache neu gestartet, erst mal ohne Erfolg. Ich weiß nicht recht, was mich geritten hat, aber ich habe das System dann neu gebootet, Bingo! Danach ging's auf Anhieb. Innerhalb von wenigen Minuten waren 3 Perl-Scripte lauffähig modifiziert. Wenn jemand eine elegantere Lösung findet freue ich mich über einen Tipp. Vielleicht freut sich ja irgendwann jemand über meine Notlösung ;-) Grüße und gute Nacht, Rolf
Hallo Rolf, hallo Leute, Am Samstag, 26. November 2005 04:05 schrieb nineteensixtythree@gmx.de: vorweg: Packst Du bitte Deinen Realname in den Absender? Obiges liest sich etwas holprig ;-)
Von: Rolf Scheurer [mailto:linux@scheurer-la.de] [...]
Ich habe auf dem alten Server mit SuSE 7.0 ein von mir minimal modifiziertes formmail.pl (umbenannt in mailmanager.pl) seit 5 Jahren im Einsatz, völlig problemlos. Dieses Script habe auch auf den neuen Server kopiert und es mag zum Verrecken nicht laufen. Ich erhalte die Fehlermeldung: Premature end of script headers: mailmanager.pl [...] Unsicherheit herrschte bei mir, ob die Datei /var/qmail/bin/sendmail das gute alte Sendmail emuliert. [...]
AFAIK ist das der Fall.
Werner Merz hat es im Prinzip erkannt, der Apache ist falsch konfiguriert. Ich habe zwar inzwischen viel über Apache 2 gelernt, aber einige Sachen liegen noch im dunkelen. Apache benötigt die Datei suexec2, mit deren Hilfe man ihm mitteilt, als welcher Benutzer u. welcher Gruppe die Scripts ausgeführt werden sollen (dürfen). Das wird beim Kompilieren festgelegt.
Nicht wirklich. Als welcher User/Gruppe die Scripte ausgeführt werden, steht in der Konfigurationsanweisung SuexecUserGroup user gruppe Das kann man pro vHost festlegen. Die CGI-Scripte müssen dann auch dem angegebenen User/Gruppe gehören. Was beim Kompilieren festgelegt wird, ist der "aufrufende" User, also der User, unter dem Apache läuft. In der Regel musst Du daran nichts ändern.
Blauäugig habe ich suexec2 mal in suexec2-old umbenannt und Apache neu gestartet, erst mal ohne Erfolg. Ich weiß nicht recht, was mich geritten hat, aber ich habe das System dann neu gebootet, Bingo! Danach ging's auf Anhieb.
Hast Du rcapache2 reload oder restart verwendet? (reload reicht definitiv nicht)
Innerhalb von wenigen Minuten waren 3 Perl-Scripte lauffähig modifiziert.
Ja, allerdings laufen die Scripte jetzt als User "wwwrun" und nicht unter dem Benutzer "megabienede" (bzw. dem zur jeweiligen Domain gehörenden User). Das heißt, dass die CGIs auch Dateien anderer Domains ändern können, sofern diese wwwrun gehören (z. B. durch einen Upload per Webformular usw.). Andererseits können die CGIs keine Dateien mehr ändern, die dem User "megabiene" oder anderen Usern gehören, was auch ein Vorteil sein kann. Welche Variante Dir besser gefällt, musst Du wissen.
Wenn jemand eine elegantere Lösung findet freue ich mich über einen Tipp.
Wie in meiner Mail, die ich in diesem Thread am 11.11. schrieb, vorgeschlagen: verschiebe die CGIs nach /srv/www/ - dann müsste suexec funktionieren. Falls nicht, guck mal die von mir in der damals genannten Checkliste nach, an was es noch hängen könnte. Gruß Christian Boltz -- Microsoft gives you Windows but Linux gives you the whole house!
Hallo Christian,
Von: Christian Boltz [mailto:suse@cboltz.de] Gesendet: Samstag, 26. November 2005 23:58
Hallo Rolf, hallo Leute,
Am Samstag, 26. November 2005 04:05 schrieb nineteensixtythree@gmx.de:
vorweg: Packst Du bitte Deinen Realname in den Absender? Obiges liest sich etwas holprig ;-)
Oh, sorry, bereits geändert. Das ist eigentlich nicht meine Art. Habe die Mail von Zuhause aus geschrieben, da war ich beim Einrichten etwas schluderig. Soll nicht mehr vorkommen...
Von: Rolf Scheurer [mailto:linux@scheurer-la.de] [...]
Ich habe auf dem alten Server mit SuSE 7.0 ein von mir minimal modifiziertes formmail.pl (umbenannt in mailmanager.pl) seit 5 Jahren im Einsatz, völlig problemlos. Dieses Script habe auch auf den neuen Server kopiert und es mag zum Verrecken nicht laufen. Ich erhalte die Fehlermeldung: Premature end of script headers: mailmanager.pl [...] Unsicherheit herrschte bei mir, ob die Datei /var/qmail/bin/sendmail das gute alte Sendmail emuliert. [...]
AFAIK ist das der Fall.
Werner Merz hat es im Prinzip erkannt, der Apache ist falsch konfiguriert. Ich habe zwar inzwischen viel über Apache 2 gelernt, aber einige Sachen liegen noch im dunkelen. Apache benötigt die Datei suexec2, mit deren Hilfe man ihm mitteilt, als welcher Benutzer u. welcher Gruppe die Scripts ausgeführt werden sollen (dürfen). Das wird beim Kompilieren festgelegt.
Nicht wirklich. Als welcher User/Gruppe die Scripte ausgeführt werden, steht in der Konfigurationsanweisung SuexecUserGroup user gruppe Das kann man pro vHost festlegen.
Hmm, schreibe mal wieder von daheim und habe den Zettelwus, der bei der Fehlersuche angefallen ist nicht zur Hand. Wenn ich mich recht erinnere musste das beim kompilieren angegeben werden. Es ist natürlich auch möglich, dass ich in meiner Verzeweiflung einen falschen Tipp (aus irgend einem Forum) aufgegriffen habe.
Die CGI-Scripte müssen dann auch dem angegebenen User/Gruppe gehören.
So ist's. Leuchtet ein und wurde mir von Strato ebenso (2x) mitgeteilt. War aber nicht das Problem.
Was beim Kompilieren festgelegt wird, ist der "aufrufende" User, also der User, unter dem Apache läuft. In der Regel musst Du daran nichts ändern.
Blauäugig habe ich suexec2 mal in suexec2-old umbenannt und Apache neu gestartet, erst mal ohne Erfolg. Ich weiß nicht recht, was mich geritten hat, aber ich habe das System dann neu gebootet, Bingo! Danach ging's auf Anhieb.
Hast Du rcapache2 reload oder restart verwendet? (reload reicht definitiv nicht)
Hättest Du gefragt, ob ich restart verwendet habe, so hätte ich bejaht. Durch die Fragestellung bin ich verunsichert, denke aber es war restart.
Innerhalb von wenigen Minuten waren 3 Perl-Scripte lauffähig modifiziert.
Ja, allerdings laufen die Scripte jetzt als User "wwwrun" und nicht unter dem Benutzer "megabienede" (bzw. dem zur jeweiligen Domain gehörenden User).
Ja, sozusagen Apache 1.x kompatibel.
Das heißt, dass die CGIs auch Dateien anderer Domains ändern können, sofern diese wwwrun gehören (z. B. durch einen Upload per Webformular usw.).
Andererseits können die CGIs keine Dateien mehr ändern, die dem User "megabiene" oder anderen Usern gehören, was auch ein Vorteil sein kann.
Welche Variante Dir besser gefällt, musst Du wissen.
Wenn jemand eine elegantere Lösung findet freue ich mich über einen Tipp.
Wie in meiner Mail, die ich in diesem Thread am 11.11. schrieb, vorgeschlagen: verschiebe die CGIs nach /srv/www/ - dann müsste suexec funktionieren.
Das ist so ein Knackpunkt. Auf diese Idee bin ich ich ja auch gekommen. Das lief aber ebenso wenig, wie im User-Verzeichnis. Bevor die Frage kommt: Ja, ich habe auch daran gedacht, den Script-Alias für /cgi-bin/ für den vhost des Users Megabiene rauszunehmen und die Rechte für das Script zu ändern. In server-defaults.conf ist der Scipt-Alias für /srv/www/cgi-bin/ definiert, so dass ich ja die Hoffnung hatte, das Problem so umschiffen zu können. Das hat aber nicht geklappt, muss aber gestehen, dass ich in diesen Part relativ wenig Zeit investiert habe, obwohl mir diese Lösung viel besser gefallen würde. Das wäre noch mal eine Idee, den Hebel hier anzusetzen. Da das Script jetzt funktioniert weiß ich, dass schon mal nicht an einem Fehler im Script hapert. Diese Unsicherheit (bedingt durch ziemlich flache Perl-Kenntnisse) hat mir ein gutes Stück der Motivation bei der Fehlersuche genommen. Mal sehen, vielleicht eine Aufgabe für's Wochenende. Das Wetter ist schlecht genug für so etwas ;-) Vielen Dank für's Mitdenken. Sobald ich was neues (positives) zu vermelden habe, melde ich mich nochmal dazu. Viele Grüße, Rolf Scheurer
Hallo Rolf, hallo Leute, Am Dienstag, 29. November 2005 23:41 schrieb Rolf Scheurer:
Von: Christian Boltz [mailto:suse@cboltz.de]
Am Samstag, 26. November 2005 04:05 schrieb nineteensixtythree@gmx.de:
[CGIs laufen nicht - "command not in docroot" im suexec.log] Aus aktuellem Anlass ein Hinweis vorweg: Mich hat suExec auch gerade kräftig Nerven gekostet, weil es "plötzlich" nicht mehr funktioniert hat - auch mit der Meldung "command not in docroot". Nach einiger Suche bin ich dann darauf gekommen, dass Plesk ein eigenes suexec (mit anderem docroot) mitbringt und /usr/sbin/suexec2 überschreibt. Netterweise geht das aber komplett an der RPM-Datenbank vorbei, sodass beim erstbesten Sicherheitsupdate per YOU eben wieder das suexec mit Docroot /srv/www aktiv ist. Meine CGIs laufen dann auch in /srv/www, weil der Server gleich am Anfang ein Security-Update für Apache abbekommen hatte (und ich wunderte mich die ganze Zeit über die unsinnigen Verzeichnisse ~/cgi-bin, die Plesk anlegt ;-) Vor kurzem habe ich dann Plesk aktualisiert - daraufhin gingen die CGIs in /srv/www plötzlich nicht mehr, weil wieder das Plesk-suexec aktiv war. Die Fortsetzung des Ping-Pong-Spiels beim nächsten Sicherheitsupdate, dem nächsten Plesk-Update, Sicherheitsupdate, ... kann sich wohl jeder denken. Vielleicht hast Du ja mit Deinem ServerAdmin24 ein vergleichbares Problem - rpm -V apache2 und strings /usr/sbin/suexec | grep / sollte das klären. Ach ja: Wer meine Meinung zu Plesk noch nicht kennt, kann einfach mal das Listenarchiv nach "Plesk" in Verbindung mit meinem Namen durchsuchen...
Werner Merz hat es im Prinzip erkannt, der Apache ist falsch konfiguriert. Ich habe zwar inzwischen viel über Apache 2 gelernt, aber einige Sachen liegen noch im dunkelen. Apache benötigt die Datei suexec2, mit deren Hilfe man ihm mitteilt, als welcher Benutzer u. welcher Gruppe die Scripts ausgeführt werden sollen (dürfen). Das wird beim Kompilieren festgelegt.
Nicht wirklich. Als welcher User/Gruppe die Scripte ausgeführt werden, steht in der Konfigurationsanweisung SuexecUserGroup user gruppe Das kann man pro vHost festlegen.
Hmm, schreibe mal wieder von daheim und habe den Zettelwus, der bei der Fehlersuche angefallen ist nicht zur Hand. Wenn ich mich recht erinnere musste das beim kompilieren angegeben werden. Es ist natürlich auch möglich, dass ich in meiner Verzeweiflung einen falschen Tipp (aus irgend einem Forum) aufgegriffen habe.
Beim Kompilieren muss angegeben werden, unter welchem User Apache läuft, sprich: wer suexec überhaupt aufrufen darf. Auch die erlaubten Pfade für CGIs sind ein Compile-Setting. Unter welchem User die CGIs letztenendes laufen, wird über die SuexecUserGroup-Anweisung in der Apache-Config eingestellt. Wäre ja auch nervig, für jede neue Domain bzw. jeden neuen User suexec neu kompilieren zu müssen ;-) [...]
Hast Du rcapache2 reload oder restart verwendet? (reload reicht definitiv nicht)
Hättest Du gefragt, ob ich restart verwendet habe, so hätte ich bejaht. Durch die Fragestellung bin ich verunsichert, denke aber es war restart.
;-)
Innerhalb von wenigen Minuten waren 3 Perl-Scripte lauffähig modifiziert.
Ja, allerdings laufen die Scripte jetzt als User "wwwrun" und nicht unter dem Benutzer "megabienede" (bzw. dem zur jeweiligen Domain gehörenden User).
Ja, sozusagen Apache 1.x kompatibel.
Nö - auch Apache 1.x hatte schon suexec an Bord. [...]
Wie in meiner Mail, die ich in diesem Thread am 11.11. schrieb, vorgeschlagen: verschiebe die CGIs nach /srv/www/ - dann müsste suexec funktionieren.
Das ist so ein Knackpunkt. Auf diese Idee bin ich ich ja auch gekommen. Das lief aber ebenso wenig, wie im User-Verzeichnis. Bevor die Frage kommt: Ja, ich habe auch daran gedacht, den Script-Alias für /cgi-bin/ für den vhost des Users Megabiene rauszunehmen und die Rechte für das Script zu ändern.
Was steht/stand diesmal im suexec.log? Gruß Christian Boltz PS @sig: 60-Stunden-Woche für Plesk? ;-) -- Die Bundesregierung hat beschlossen, daß alle Yast-Programme ab sofort eine 48 Stunden Woche haben müssen. Bei dem was diese Programme an Aufräumarbeit hinterlassen, kann das nur gut sein, um die Arbeitslosenzahlen zu reduzieren. [Emil Stephan in suse-linux]
participants (6)
-
Christian Boltz -
nineteensixtythree＠gmx.de -
Rolf Scheurer
-
Rolf Scheurer -
Sandy Drobic -
Werner Merz