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