apache2 - perl - qmail - Strato

[Rolf Scheurer]

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 :-)

[Sandy Drobic]

Post by Rolf Scheurer
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem
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?

Post by Rolf Scheurer
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

[Werner Merz]

Post by Sandy Drobic

Post by Rolf Scheurer
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem
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?

Post by Rolf Scheurer
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

[Rolf Scheurer]

Hallo Werner,

-snip-

Post by Werner Merz
Hast Du etwas am Script geändert? (Evtl. den Anführungszeichen, Semikolon
o.ä. irgendwo vergessen.)

Geändert ja, aber das müsste alles stimmen.

Post by Werner Merz
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

[Rolf Scheurer]

Hallo Sandy,

Post by Sandy Drobic

Post by Rolf Scheurer
In dem Script muss das Mailprogramm angegeben werden. Ich stellte dem
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?

Post by Rolf Scheurer
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

[Gunreben, Peter (Peter)]

Rolf,

From: Rolf Scheurer
Sent: Mittwoch, 9. November 2005 10:33
Premature end of script headers: mailmanager.pl

Kommst du ans error_log des apache /var/log/apache2/error_log?
Dort könntest du mehr Infos zu dem Problem finden.

Gruss,

Peter.

[Rolf Scheurer]

Hallo Peter,

Post by Gunreben, Peter (Peter)
Kommst du ans error_log des apache /var/log/apache2/error_log?
Dort könntest du mehr Infos zu dem Problem finden.

Im suexec_log des Apache steht:

11-09 11:55:13]: uid: (1000/megabienede) gid: (60006/60006) cmd:
mailmanager.pl
11-09 11:55:13]: command not in docroot
(/home/m/megabiene.de/public_html/cgi-bin/mailmanager.pl

Die zweite Zeile verwirrt mich doch arg. Wenn mit "command" das Perl-Script
gemeint ist, so ist es definitiv da.


Im error_log steht:

...Premature end of script headers: mailmanager.pl, referer:
http://www.megabiene.de/

Nix Neues also.

M.f.G.
Rolf

[Werner Merz]

Post by Rolf Scheurer
Hallo Peter,

Post by Gunreben, Peter (Peter)
Kommst du ans error_log des apache /var/log/apache2/error_log?
Dort könntest du mehr Infos zu dem Problem finden.

mailmanager.pl
11-09 11:55:13]: command not in docroot
(/home/m/megabiene.de/public_html/cgi-bin/mailmanager.pl
Die zweite Zeile verwirrt mich doch arg. Wenn mit "command" das
Perl-Script gemeint ist, so ist es definitiv da.

Laut:
http://apache-server.com/tutorials/LPsuexec.html
Sieht dies nach einem Konfigurationsfehler des Apache2 aus.

Das Script ist da, aber das ist der falsche Ort, bzw. nicht dort wo Apache2
das Script haben will.

Googel liefert einige Treffer wenn Du mit der Fehlermeldung:
command not in docroot apache2
suchst.

Kannst Du die Konfiguration von Apache ändern? Wenn ja, dann hilft Dir der
obige Link vielleicht weiter.

Gruss
Werner

[Rolf Scheurer]

Hallo Werner,

Post by Werner Merz

Post by Rolf Scheurer
Hallo Peter,

Post by Gunreben, Peter (Peter)
Kommst du ans error_log des apache /var/log/apache2/error_log?
Dort könntest du mehr Infos zu dem Problem finden.

mailmanager.pl
11-09 11:55:13]: command not in docroot
(/home/m/megabiene.de/public_html/cgi-bin/mailmanager.pl
Die zweite Zeile verwirrt mich doch arg. Wenn mit "command" das
Perl-Script gemeint ist, so ist es definitiv da.

http://apache-server.com/tutorials/LPsuexec.html
Sieht dies nach einem Konfigurationsfehler des Apache2 aus.

Sehe ich inzwischen auch so. Über Deinen Link (Danke!) und weiteres Googleln
bin
ich auf eine Spur gestoßen. Ich vermute, dass suexec2 buggy ist. Auch Strato
erzählte
mir, dass bei einem Update ggf. eine Datei überschrieben wurde (s.
original-Posting).
Habe suexec erfolglos neu kompiliert, bin aber nicht sicher ob die Parameter
stimmen.

Post by Werner Merz
Das Script ist da, aber das ist der falsche Ort, bzw. nicht dort wo Apache2
das Script haben will.

Bleibt die Frage, wo es hin muss, bzw. ich Apache klarmache, dass es im
gewünschten Verzeichnis ausgeführt werden soll (und darf). Da ich mit
Apache2
nun wirklich nicht fit bin, ist das nicht so einfach.

Post by Werner Merz
command not in docroot apache2
suchst.
Kannst Du die Konfiguration von Apache ändern? Wenn ja, dann hilft Dir der
obige Link vielleicht weiter.

Ändern kann ich ALLES, habe vollen root-Zugang. Ich muss nur wissen WIE ;-)

Ich habe eben nochmal an die Strato-Leute geschrieben. Mal sehen ob dabei
was
herauskommt. Bei der vielen Googelei habe ich gemerkt, dass ich mit dem
Problem
nicht alleine bin.

Gruß,
Rolf

[Christian Boltz]

Hallo Rolf, hallo Leute,

vorweg: formmail.pl ist (war?) "berühmt" für seine Sicherheit. Bist Du
sicher, dass Du das einsetzen willst? (Es kann durchaus sein, dass
aktuelle Versionen sicher sind - ich habe schon lange nicht mehr
nachgesehen.)

Post by Werner Merz

Post by Rolf Scheurer
mailmanager.pl
11-09 11:55:13]: command not in docroot
(/home/m/megabiene.de/public_html/cgi-bin/mailmanager.pl

Aha - das erinnert mich daran, dass ich mich auch schon mit so einem
Problem rumgeplagt habe ;-)

[...]

Ich vermute, dass suexec2 buggy ist. Auch Strato erzählte
mir, dass bei einem Update ggf. eine Datei überschrieben wurde (s.
original-Posting).

Quatsch mit Soße ;-)

Qmail ist übrigens auch unschuldig an Deinem Problem ;-)

Post by Werner Merz
Das Script ist da, aber das ist der falsche Ort, bzw. nicht dort wo
Apache2 das Script haben will.

Bleibt die Frage, wo es hin muss, bzw. ich Apache klarmache, dass es
im gewünschten Verzeichnis ausgeführt werden soll (und darf). Da ich
mit Apache2 nun wirklich nicht fit bin, ist das nicht so einfach.

Ich vermute, Du hast in /srv/www/ oder /srv/www/htdocs/ mehr Glück ;-)

Hintergrund: suExec macht beim Start diverse Sicherheitsprüfungen [1],
darunter auch die Prüfung des Pfads.
Allerdings meint "docroot" in diesem Fall nicht das in der httpd.conf
pro vHost gesetzte DocumentRoot, sondern IIRC die compile-time-Option
HTTPD_ROOT (abzufragen mit apache2ctrl -V).

Ach ja: Ich habe auf dem von mir betreuten Server inzwischen ein paar
mount --bind im Einsatz, damit man auch per FTP [2] trotz chroot an die
CGIs kommt.

Die Alternative ist der Verzicht auf suExec - dann läuft das CGI eben
als wwwrun, dafür aber in einem beliebigen Verzeichnis.


Gruß

Christian Boltz

[1] http://localhost/manual/suexec.html bei installiertem Apache-Manual,
ansonsten online nachsehen.

[2] Zur Sicherheit von FTP muss ich hoffentlich nichts sagen. Es gibt
aber leider noch zu viele Leute, die nix anderes wollen :-/
--

Es steht dir frei, dich auch auszutragen, damit du von Idioten wie
David, Thorsten, Bernd, ... nicht weiter belästigt wirst.

Und ich gehöre da nicht mehr dazu?
[> Matthias Houdek und Florian Gross in suse-linux]

[n***@gmx.de]

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

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.
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.
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
---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
drwx---r-x 2 megabienede www 4096 Nov 9 09:43 cgi-bin/
-rwx---r-x 1 megabienede www 22868 Nov 9 09:43 mailmanager.pl*
In dem Script muss das Mailprogramm angegeben werden. Ich
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

[Christian Boltz]

Hallo Rolf, hallo Leute,

Am Samstag, 26. November 2005 04:05 schrieb nineteensixtythree-***@public.gmane.org:

vorweg: Packst Du bitte Deinen Realname in den Absender? Obiges liest
sich etwas holprig ;-)
[...]

Post by n***@gmx.de

Post by Rolf Scheurer
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

[...]

Post by n***@gmx.de
Unsicherheit herrschte bei mir, ob die Datei /var/qmail/bin/sendmail
das gute alte Sendmail emuliert. [...]

AFAIK ist das der Fall.

Post by n***@gmx.de
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.

Post by n***@gmx.de
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)

Post by n***@gmx.de
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.

Post by n***@gmx.de
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

[Rolf Scheurer]

Hallo Christian,

Gesendet: Samstag, 26. November 2005 23:58
Hallo Rolf, hallo Leute,
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...

[...]

Post by n***@gmx.de

Post by Rolf Scheurer
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

Post by n***@gmx.de

Post by Rolf Scheurer
Verrecken nicht laufen. Ich erhalte die
Fehlermeldung: Premature end of script headers: mailmanager.pl

[...]

Post by n***@gmx.de
Unsicherheit herrschte bei mir, ob die Datei

/var/qmail/bin/sendmail

Post by n***@gmx.de
das gute alte Sendmail emuliert. [...]

AFAIK ist das der Fall.

Post by n***@gmx.de
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

Post by n***@gmx.de
suexec2, mit deren Hilfe man ihm mitteilt, als welcher Benutzer u.
welcher Gruppe die Scripts ausgeführt werden sollen

(dürfen). Das wird

Post by n***@gmx.de
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.

Post by n***@gmx.de
Blauäugig habe ich suexec2 mal in suexec2-old umbenannt und

Apache neu

Post by n***@gmx.de
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.

Post by n***@gmx.de
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.

Post by n***@gmx.de
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

[Christian Boltz]

Hallo Rolf, hallo Leute,

Post by Rolf Scheurer

Post by Christian Boltz
Am Samstag, 26. November 2005 04:05 schrieb

[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...

Post by Rolf Scheurer

Post by Christian Boltz

Post by n***@gmx.de
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 ;-)

[...]

Post by Rolf Scheurer

Post by Christian Boltz
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.

;-)

Post by Rolf Scheurer

Post by Christian Boltz

Post by n***@gmx.de
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.

[...]

Post by Rolf Scheurer

Post by Christian Boltz
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]