Apache: .exe CGI-Script unter Windows

[Philipp Hasenfratz]

Halihallo alle

Ich würde bei einem Windows-Apachen gerne .exe als CGI-Scripts
betreiben. Hierzu habe ich den cgi-script Handler mit der
Extension .exe erweitert:

AddHandler cgi-script .exe

Nun bekomme ich in der error_log folgende Einträge, aus denen ich
noch nicht schlau werde:

[Sun Jan 04 14:01:50 2004] [error] [client 127.0.0.10] (OS 5)Zugriff verweigert  : couldn't create child process: 720005: test.exe
[Sun Jan 04 14:01:50 2004] [error] [client 127.0.0.10] (OS 5)Zugriff verweigert  : couldn't spawn child process: D:/Intranet/cgi-bin/test.exe

Kann mir jemand sagen, warum ich einen "Zugriff verweigert"
bekomme? - Woran kann das liegen? - Ich wüsste nicht, warum der
Zugriff verweigert sein soll, zumal das Script auf der Konsole durch
und durch richtig funktioniert, ohne Fehler, mit Header etc.
vollständig funktional, nur über HTTP bekomme ich einen 500-er mit
genannten error_log Einträgen.

Viele Grüsse

Philipp

[Christoph Schnauß]

hallo,

AddHandler cgi-script .exe

Das ist ok, und damit sollte es auch klappen (tut es bei mir jedenfalls).

Zugriff verweigert  : couldn't spawn child process: D:/Intranet/cgi-bin/test.exe

Das kann unterschiedliche Gründe haben. Die beiden wichtigsten:
1. liegt denn dein cgi-bin tatsächlich in D:/Intranet/cgi-bin/test.exe, das heißt, gibt es einen Eintrag ScriptAlias /cgi-bin/ "D:/Intranet/cgi-bin/" ?
2. Hast du deinen Apache nach den Veränderungen in der httpd.conf neu gestartet?

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Das kann unterschiedliche Gründe haben. Die beiden wichtigsten:

1. liegt denn dein cgi-bin tatsächlich in D:/Intranet/cgi-bin/test.exe, das heißt, gibt es einen Eintrag ScriptAlias /cgi-bin/ "D:/Intranet/cgi-bin/" ?
2. Hast du deinen Apache nach den Veränderungen in der httpd.conf neu gestartet?

Ich muss leider beides bejahen. Das Script ist an entsprechender
Stelle vorhanden und ich habe den Apachen nach konfigurieren
restarted.

Auch wenn es wahrscheinlich nix damit zu tun hat, meine httpd.conf:
<VirtualHost 127.0.0.10>
   Options INCLUDES +ExecCGI
   DirectoryIndex index.cgi index.pl index.shtml index.html
   ServerName www.a1.test
   ServerAlias a1.test *.a1.test
   ServerAdmin [e-mail]
   ScriptAlias /cgi-bin "D:/Intranet/a1/cgi-bin/"
   DocumentRoot d:/Intranet/a1
   ErrorLog logs/a1_test_errors.txt
   TransferLog logs/a1_test_log.txt
</VirtualHost>

Im letzten Posting stand d:/Intranet/cgi-bin/... Ist aber schon so,
dass sich das Web inklusive cgi-bin unter ./Intranet/a1 befindet.
Die Verzeichnisangaben sind gefaket (auch wenn es nichts ausmachen
würde).

Ein Perl-Script im selben Verzeichnis läuft prima.

Danke für deine Hilfe.

Viele Grüsse

Philipp

[Christoph Schnauß]

hallo Philipp,

<VirtualHost 127.0.0.10>
   Options INCLUDES +ExecCGI

Wenn du deine EXE nicht als CGI ausführen kannst, ist es vielleicht klüger, das erstmal nicht über einen virtuellen host, sondern über den "main"-Server zu probieren. Wenns damit klappt, kannst du den virtuellen host wieder aktivieren. Versuchs probeweise auch mal mit einer 192.168-er IP und nicht mit der 127. Sonst scheint an deinem virtuellen host nix verkehrt, meine sehen auch nicht wesentlich anders aus  -  und da funktioniert es.

Im letzten Posting stand d:/Intranet/cgi-bin/... Ist aber schon so,
dass sich das Web inklusive cgi-bin unter ./Intranet/a1 befindet.

Hauptsache, du kennst dich mit deinen Pfaden aus ;-) Ob du die hier genauso postest, wie sie in Gebrauch sind, ist schnurz, solange man sieht, daß man dir nicht erst die Apache-Doku vorhalten muß.

Ein Perl-Script im selben Verzeichnis läuft prima.

Gut. Dann ist dein Apache höchstwahrscheinlich korrekt eingestellt. Es wäre noch nachzuschauen, was deine test.exe machen soll. Wenn du großen Wert darauf legst, kann ich dir (per mail dann) mal eine kleine EXE schicken, die bei mir auf verscheidenen Windows-Rechnern (98 und XP) als CGI-Anwendung über Apache gut funktioniert und nichts anderes macht, als die Umgebungsvariablen auszulesen.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Wenn du deine EXE nicht als CGI ausführen kannst, ist es vielleicht klüger, das erstmal nicht über einen virtuellen host, sondern über den "main"-Server zu probieren. Wenns damit klappt, kannst du den virtuellen host wieder aktivieren. Versuchs probeweise auch mal mit einer 192.168-er IP und nicht mit der 127. Sonst scheint an deinem virtuellen host nix verkehrt, meine sehen auch nicht wesentlich anders aus  -  und da funktioniert es.

Aller durchprobiert, auch wenn ich glaube, dass es daran nicht
liegen kann (was ich jetzt bestätigen kann). Der 500-er bleibt bei
jeder Konfiguration bestehen, egal von welcher IP.

Hauptsache, du kennst dich mit deinen Pfaden aus ;-) Ob du die hier genauso postest, wie sie in Gebrauch sind, ist schnurz, solange man sieht, daß man dir nicht erst die Apache-Doku vorhalten muß.

Ach ja, auch wenn man mir vielleicht mal die Doku vorhalten muss, so
verstehe ich es doch mit Bearbeiten-Ersetzen umzugehen :-)

Ein Perl-Script im selben Verzeichnis läuft prima.
Gut. Dann ist dein Apache höchstwahrscheinlich korrekt eingestellt. Es wäre noch nachzuschauen, was deine test.exe machen soll.

Versucht habe ich es mit einem einfachen

#include <stdio.h>
#include <stdlib.h>

int main(void) {
  printf("Content-Type: text/plain\015\012\015\012");
  printf("Hello World");
}

über ein ähnliches Programm, dass ebenfalls die Environment-Daten
per **environ einliest. Wie gesagt: Beide funktionieren ohne
Probleme auf der Konsole, an den .exe's liegt es definitiv nicht.

Wenn du großen Wert darauf legst, kann ich dir (per mail dann) mal eine kleine EXE schicken, die bei mir auf verscheidenen Windows-Rechnern (98 und XP) als CGI-Anwendung über Apache gut funktioniert und nichts anderes macht, als die Umgebungsvariablen auszulesen.

Danke für den Vorschlag, aber ein Problem mit der .exe per se kann
ich wirklich 100%-ig ausschliessen. Ich vermute den Fehler bei der
Rechtevergabe, wie Alexander sie vorbrachte. Nur weiss ich noch
nicht, wie ich dies diesem verflixten Betriebssystem beibringen
kann :-)

Viele Grüsse

Philipp

[Christoph Schnauß]

hallo Philipp,

Ich vermute den Fehler bei der Rechtevergabe, wie Alexander sie vorbrachte.

Da bin ich nicht so sicher. Ich habe zu meiner eigenen Orientierung eben mal einen neuen Benutzer angelegt mit einem Namen, den es auf meinem System (WinXP) noch nie gab - ohne Administratorrechte. Den ganzen Rechner runtergefahren, neu gebootet, mich als dieser Benutzer angemeldet.
Der Apache startet ebenfalls, da er ja ein Hintergrunddienst ist (SYSTEM). Sowohl mit mozilla wie mit Opera 7.22 und dem IE funktioniert meine EXE über die Eingabe http://localhost/cgi-bin/testcgi.exe.

Da ich keine Fehlermeldungen habe, bin ich mir mit dem nächsten Vorschlag nicht ganz sicher: In der Computerverwaltung kannst du dir die Ereignisanzeige aufrufen. Produziert irgendein Programm oder eine Anwendung Fehler, so müßte dort auch was zu finden sein  -  ich habe da nichts, aber ich habe auch keine Prgrammfehler. Schau mal nach, schaden kanns ja nix, auch wenns vielleicht nichts nutzt.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Da ich keine Fehlermeldungen habe, bin ich mir mit dem nächsten Vorschlag nicht ganz sicher: In der Computerverwaltung kannst du dir die Ereignisanzeige aufrufen. Produziert irgendein Programm oder eine Anwendung Fehler, so müßte dort auch was zu finden sein  -  ich habe da nichts, aber ich habe auch keine Prgrammfehler. Schau mal nach, schaden kanns ja nix, auch wenns vielleicht nichts nutzt.

Danke auch für diese mögliche Usache. Leider auch negativ. Es stehen keine Warnungen/Fehler in der Ereignisanzeige. :-(

Viele Grüsse

Philipp

[Alexander Foken]

Moin Moin !

Zusatzfrage zum Posting von CS: Hat der User, unter dem der Apache läuft (das ist nicht unbedingt Dein Account!), das Recht, die EXE-Dateien auszuführen?

OS 5 bedeutet, daß der Apache versucht hat, die EXE auszuführen, Windows aber Fehler 5 (Access denied) gemeldet hat. Außer Zugriffsrechten gibt es auch noch Sharing als mögliche Ursache, sprich: ein anderer Prozess (Compiler) hat die Datei gerade gesperrt. Das könnte auch für irgendwelche DLLs gelten.

Und die EXE-Dateien müssen Konsolenanwendungen sein, weil der Apache normalerweise keinen Zugriff auf den Desktop hat und deswegen auch kein Fenster öffnen kann (so ein Programm hängt einfach).

Benutzt Du NT/2000/XP oder 95/98/ME als Untersatz für den Apachen?

Alexander

[Philipp Hasenfratz]

Halihallo Alexander

Zusatzfrage zum Posting von CS: Hat der User, unter dem der Apache läuft (das ist nicht unbedingt Dein Account!), das Recht, die EXE-Dateien auszuführen?

Läuft unter "System". Hm, ich kenne mich mit der Windows-
Rechtevergabe kaum aus, aber SYSTEM sollte doch auf alles Zugriff
haben, oder?

OS 5 bedeutet, daß der Apache versucht hat, die EXE auszuführen, Windows aber Fehler 5 (Access denied) gemeldet hat. Außer Zugriffsrechten gibt es auch noch Sharing als mögliche Ursache, sprich: ein anderer Prozess (Compiler) hat die Datei gerade gesperrt. Das könnte auch für irgendwelche DLLs gelten.

Es handelt sich erstmal um ein wirklich simples C-Programm, das
schon vorher compiliert wurde (keine laufende Kompilierung) und
keinen Zugriff auf andere Ressourcen nimmt. Es wird von keinem
anderen Prozess verwendet.

Und die EXE-Dateien müssen Konsolenanwendungen sein, weil der Apache normalerweise keinen Zugriff auf den Desktop hat und deswegen auch kein Fenster öffnen kann (so ein Programm hängt einfach).

Es ist eine Konsolenanwendung.

Benutzt Du NT/2000/XP oder 95/98/ME als Untersatz für den Apachen?

WinXP.

Danke für die möglichen Ursachen.

Viele Grüsse

Philipp

[Alexander Foken]

Moin Moin !

Zusatzfrage zum Posting von CS: Hat der User, unter dem der Apache läuft (das ist nicht unbedingt Dein Account!), das Recht, die EXE-Dateien auszuführen?

Läuft unter "System". Hm, ich kenne mich mit der Windows-
Rechtevergabe kaum aus, aber SYSTEM sollte doch auf alles Zugriff
haben, oder?

Irgendwie manchmal ja, manchmal nein ...
So ganz habe ich das auch noch nicht verstanden.

Probier mal aus, die EXE aus einem Perl-Script heraus aufzurufen, das vom Apachen gestartet wird:

#!perl
system "D:\path\to\simplecgi.exe";

oder

#!perl
use CGI::Carp qw(fatalsToBrowser);
open PIPE,"D:\path\to\simplecgi.exe|" or die $!;
print while <PIPE>;
close PIPE;

oder

#!perl
print D:\\path\\to\\simplecgi.exe;

(Alles mehr oder weniger equivalent, simplecgi.exe sollte nicht von STDIN lesen - da kommt nämlich nichts.)

simplecgi.c sieht ungefähr so aus:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
  printf("%s","Content-type:text/plain\r\n\r\nHello World\n");
  return 0;
}

Wenn's aus Perl läuft und direkt nicht, dann hast Du "ein echtes Problem"(TM) ;-)

Oh ja, und benutze keine auf .EXE endende URL im IE, das Theater mit IE und MIME Types solltest Du ja kennen. Workaround für IE: Als URL http://localhost/cgi-bin/simplecgi.exe/stupidIE.txt benutzen.

Alexander

[Philipp Hasenfratz]

Halihallo Alexander

Probier mal aus, die EXE aus einem Perl-Script heraus aufzurufen, das vom Apachen gestartet wird:

Wenn man mit den Varianten von dir die test.exe entweder über
Backticks oder Pipes einliest würde man vermuten, dass die .exe
einfach gar nix ausgibt (so sieht es aus). In Wahrheit vermute ich,
dass auch der perl-Interpreter ein Access Denied bekommt und die
Skalare einfach mit undef besetzt.

#!perl
system "D:\path\to\simplecgi.exe";

500-er, da keine Header (denn von test.exe wird nix geliefert).

#!perl
use CGI::Carp qw(fatalsToBrowser);
open PIPE,"D:\path\to\simplecgi.exe|" or die $!;
print while <PIPE>;
close PIPE;

ebenfalls nix.

#!perl
print D:\\path\\to\\simplecgi.exe;

ebenfalls nix.

(Alles mehr oder weniger equivalent, simplecgi.exe sollte nicht von STDIN lesen - da kommt nämlich nichts.)

Klar.

simplecgi.c sieht ungefähr so aus:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
  printf("%s","Content-type:text/plain\r\n\r\nHello World\n");
  return 0;
}

ebenfalls nix (im HTTP-Kontext). Hatte ich schon ausprobiert.

---- zusammenfassend ----

Versuche ich die Executable über Pipes, Backticks, ... allgemein IPC
einzulesen, dann funktioniert das alles wunderbar von der Konsole
aus (getestet!) aber keines funktioniert im HTTP-Umfeld (Apache).
Also: Von Apache starten => Geht net. Von Konsole starten => alles
wie gewünscht und erwartet.
Der Verdacht liegt nahe, dass SYSTEM einfach keinen Zugriff darauf
hat, der USER jedoch schon.

Ich werde nachher den Computer neu starten, wer weiss, welche
versteckten Schutzmechanismen Windows noch aktiv hat, die eigentlich
schon lange nicht mehr gebraucht werden. Vielleicht hat es ja nicht
gemerkt, dass ich schon lange nicht mehr editiere... Obwohl,
die .exe habe ich seit Start _nie_ angefasst. Aber die Erfahrung mit
Windows leert eines: "Rebooten ist nie falsch."

---- /zusammenfassend ----

Wenn's aus Perl läuft und direkt nicht, dann hast Du "ein echtes Problem"(TM) ;-)

Nun ja, es funktioniert auch aus Perl aus nicht und dennoch habe ich "ein echtes Problem"(TM) :-)

Oh ja, und benutze keine auf .EXE endende URL im IE, das Theater mit IE und MIME Types solltest Du ja kennen. Workaround für IE: Als URL http://localhost/cgi-bin/simplecgi.exe/stupidIE.txt benutzen.

Nun ich sage es jetzt mal so: Ich wünschte er hätte wenigstens ein
Problem, denn _dieses_ wüsste ich ja zu lösen :-(

Viele Grüsse

Philipp

[Alexander Foken]

Moin Moin !

Halihallo Alexander

Probier mal aus, die EXE aus einem Perl-Script heraus aufzurufen, das vom Apachen gestartet wird:

Wenn man mit den Varianten von dir die test.exe entweder über
Backticks oder Pipes einliest würde man vermuten, dass die .exe
einfach gar nix ausgibt (so sieht es aus). In Wahrheit vermute ich,
dass auch der perl-Interpreter ein Access Denied bekommt und die
Skalare einfach mit undef besetzt.

Lassen wir das Vermuten mal sein:

#!perl
$|=1; # unbuffered output
print "Content-type:text/plain\r\n\r\n";
print "Starte EXE ...\n";
$rv=system("D:\path\to\simplecgi.exe");
print "Ende EXE. Ergebnisse: wait result=$rv, exit codes=$?\n";

Das sollte auf jeden Fall etwas ausgeben, $rv sollte 0 sein, exit code eigentlich auch.

Aus perlfunc#system:

The return value is the exit status of the program as returned by the wait call. To get the actual exit value divide by 256. See also exec. This is not what you want to use to capture the output from a command, for that you should use merely backticks or qx//, as described in perlop/```STRING`''. Return value of -1 indicates a failure to start the program (inspect $! for the reason).

You can check all the failure possibilities by inspecting $? like this:

$exit_value  = $? >> 8;
$signal_num  = $? & 127;
$dumped_core = $? & 128;

Aber die Erfahrung mit
Windows leert eines: "Rebooten ist nie falsch."

Standard-Spruch, wenn wieder hilfesuchende Kollegen Entwickler und Supporter verwechseln: "Reboot tut immer gut" -- und beschäftigt den Kollegen eine Weile. ;-)

Wenn's aus Perl läuft und direkt nicht, dann hast Du "ein echtes Problem"(TM) ;-)

Nun ja, es funktioniert auch aus Perl aus nicht und dennoch habe ich "ein echtes Problem"(TM) :-)

Aber ein Perl-Hello-World-CGI funktioniert definitiv?

#!perl
print "Content-type:text/plain\r\n\r\nHello World\n";

Probier's einfach mal aus, ich vermute schleichende Betriebsblindheit ... ;-)

Alexander

[Philipp Hasenfratz]

Halihallo Alexander, Christoph, milky

Probier mal aus, die EXE aus einem Perl-Script heraus aufzurufen, das vom Apachen gestartet wird:
Wenn man mit den Varianten von dir die test.exe entweder über
Backticks oder Pipes einliest würde man vermuten, dass die .exe
einfach gar nix ausgibt (so sieht es aus). In Wahrheit vermute ich,
dass auch der perl-Interpreter ein Access Denied bekommt und die
Skalare einfach mit undef besetzt.
Lassen wir das Vermuten mal sein:

Ah, ein wissenschaftliches Vorgehen, gut :-)

#!perl
$|=1; # unbuffered output
print "Content-type:text/plain\r\n\r\n";
print "Starte EXE ...\n";
$rv=system("D:\path\to\simplecgi.exe");
print "Ende EXE. Ergebnisse: wait result=$rv, exit codes=$?\n";

Das sollte auf jeden Fall etwas ausgeben, $rv sollte 0 sein, exit code eigentlich auch.

So ist es denn auch in meinem Fall:
------
Starte EXE ...
Ende EXE. Ergebnisse: wait result=0, exit codes=0
------

Habe auch versucht den Namen mal auf etwas anderes zu setzen und
schwups springen der exit code und $rv auf 255. Also bin ich schon
mal fähig den Dateinamen richtig einzugeben (Betriebsblindheit, wäre
ja gut möglich).

Wenn's aus Perl läuft und direkt nicht, dann hast Du "ein echtes Problem"(TM) ;-)
Nun ja, es funktioniert auch aus Perl aus nicht und dennoch habe ich "ein echtes Problem"(TM) :-)

Aber ein Perl-Hello-World-CGI funktioniert definitiv?

Oh und wie sie das schön tun :-)
Sogar ganze Applikationen unter demselben Virtual Host... :-(

Probier's einfach mal aus, ich vermute schleichende Betriebsblindheit ... ;-)

Glaube ich langsam auch... Zum Teufel mit dem Scheiss, aber echt! -
So, dass musste jetzt mal raus. Ich sag euch: Wenns an XP liegt,
dann.. dann verlange ich die Scheidung, jawohl, die SCHEIDUNG! - Ich
verlasse dich, du WinXP! - Als ob ich es nicht schon lange... Egal!
Mein Schatz, wir wollen es haben. Mein Schatz... Manno, so
schlimm stehts nun schon um mich, sprechend wie Gollum. Vergiftet
durch das Fenster des Bösen.

ARGH! . . . . ..... _______________   :-)) ne! Anders rum :-((

Und falls es wirklich ich gewesen bin - Betriebsblindheit -, dann,
ja dann... öm? ... Geht das Leben weiter... *seufz* :-))

Ich glaube ich sollte dies für heute einfach mal so lassen und
morgen zu frischer Tat ermutigt, weitermachen.

Ich bedanke mich bei allen für die vielen guten Vorschläge und
möglichen Ursachen!

Viele Grüsse

Philipp

[Christoph Schnauß]

hallo Philipp,

ich vermute schleichende Betriebsblindheit ... ;-)
Glaube ich langsam auch...

Du erlaubst, daß ich das jetzt bloß zitiere und nicht weiter kommentiere *g*

Wenns an XP liegt, dann.. dann verlange ich die Scheidung

Nana, wer wird denn schon beim kleinsten Ehekrach an Scheidung denken. Sowas gehört einfach zu einer guten Beziehung. Außerdem: an WinXP kanns eigentlich nicht liegen. Auch wenn es bisher keiner explizit so ausgesagt hat: du müßtest aus den Antworten herauslesen können, daß das, was du gerne möchtest, durchaus gut und problemlos funktionieren kann.
BTW: mir fällt grade auf, daß du nicht angegeben hast, welche Apache-Version du fährst.

Ich glaube ich sollte dies für heute einfach mal so lassen und
morgen zu frischer Tat ermutigt, weitermachen.

Zwischendurch bitte erst offline gehen, dann defragmentieren und alles auskehren und dann Netzstecker am Rechner ziehen.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Wenns an XP liegt, dann.. dann verlange ich die Scheidung
Nana, wer wird denn schon beim kleinsten Ehekrach an Scheidung denken. Sowas gehört einfach zu einer guten Beziehung.

Ja, du hast recht. Ich habe schon immer gesagt: Ich habe
nicht die beste Frau, aber dafür sicher die Zweitbeste. :-)
(nein, ich bin nicht verheiratet)

Außerdem: an WinXP kanns eigentlich nicht liegen. Auch wenn es bisher keiner explizit so ausgesagt hat: du müßtest aus den Antworten herauslesen können, daß das, was du gerne möchtest, durchaus gut und problemlos funktionieren kann.

Richtig.

BTW: mir fällt grade auf, daß du nicht angegeben hast, welche Apache-Version du fährst.

This is Apache/2.0.44 (Win32) PHP/4.3.0 Server at 192.168.0.8 Port 80

Ich glaube ich sollte dies für heute einfach mal so lassen und
morgen zu frischer Tat ermutigt, weitermachen.
Zwischendurch bitte erst offline gehen, dann defragmentieren und alles auskehren und dann Netzstecker am Rechner ziehen.

So wirds gemacht. Trotzdem erst morgen, denn für heute Abend ist noch
etwas anderes geplant.

Moraloffizier Christoph hat gut gesprochen :-)

Viele Grüsse und allen eine gute Nacht

Philipp

PS: Wer spricht denn da von aufgeben? - Ich will doch nur eine
andere ... ... Betriebssystem. :-))

[Christoph Schnauß]

hi Philipp,

This is Apache/2.0.44 (Win32) PHP/4.3.0 Server at 192.168.0.8 Port 80

Oh. Schluck. Wirf ihn weg. Der ist nicht genügend "stable" und verursacht genau den Kram, den du so beklagst. Hole dir dafür mindestens 2.0.45 (der ist "stable"), besser aber den derzeit jüngsten, also 2.0.48. Der verlangt dann wenigstens konsequent, daß deine virtuellen hosts auch in deiner "hosts"-Datei stehen müssen (2.0.44 verlangt das noch nicht zwingend)  -  aus gutem Grund. Die httpd.conf kannst du ohne Änderung von 2.0.44 nach 2.0.48 übernehmen, und mehr brauchst du bei einem "Serverupgrade" ja auch nicht zu machen.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Oh. Schluck. Wirf ihn weg. Der ist nicht genügend "stable" und verursacht genau den Kram, den du so beklagst. Hole dir dafür mindestens 2.0.45 (der ist "stable"), besser aber den derzeit jüngsten, also 2.0.48. Der verlangt dann wenigstens konsequent, daß deine virtuellen hosts auch in deiner "hosts"-Datei stehen müssen (2.0.44 verlangt das noch nicht zwingend)  -  aus gutem Grund. Die httpd.conf kannst du ohne Änderung von 2.0.44 nach 2.0.48 übernehmen, und mehr brauchst du bei einem "Serverupgrade" ja auch nicht zu machen.

Öm, so einfach ging das nicht, habe jetzt eine halbe Stunde damit
verbracht dieses Ding wieder in Schuss zu bringen. Aber nun ist der
2.0.48 drauf und das alte Problem (nachdem ich ca. 10 neue gelöst
habe, juhu *g*) bleibt bestehen. Ich habe es nochmals versucht, der
(5) Access Denied Fehler kommt noch immer (wenn ich nochmals kurz
eine Vermutung anstellen darf: es steht (OS 5) Access Denied, somit
vom OS generiert, ggf. eben wegen SYSTEM-Account). Egal, hauptsache
ist: Fehler kommt leider immer noch...

Ach ja, approppos Fehler:
</archiv/2003/9/56501/#m315836> ist auch beim 2.0.48 immer noch
existent :-)   Das Problem kam mir nur gerade wieder in den Sinn und
das musste ich ganz kurz nochmals nachprüfen.

Viele Grüsse

Philipp

[milky]

Hey,

Hast du es schonmal mit .cgi.exe probiert? Unter Win müssen Scripte und
Programme doch über zwei unterschiedliche Schnittstellen gestartet werden,
vielleicht liegt's ja daran(?)

Und läuft das Programm auch wirklich, wenn du es unter Apache startest, d.h.
hast du schon versucht, es behelfsweise aus einem anderen (script-) .cgi
heraus zu starten?  - So ließe sich zumindest herausbekommen, ob hier
wirklich irgendwelche Zugriffsrechte für die EXE schuld sind.

Dein Problem scheint überdies nichts mit dem .exe zu tun zu haben:
http://www.experts-exchange.com/Web/Web_Servers/Apache/Q_20766907.html

MsF,
milky

[Alexander Foken]

Moin Moin !

Hast du es schonmal mit .cgi.exe probiert? Unter Win müssen Scripte und
Programme doch über zwei unterschiedliche Schnittstellen gestartet werden,
vielleicht liegt's ja daran(?)

Dein Problem scheint überdies nichts mit dem .exe zu tun zu haben:
http://www.experts-exchange.com/Web/Web_Servers/Apache/Q_20766907.html

Dort wird nur Apaches Verhalten, wahlweise die Registry oder die "Shebang"-Zeile eines Scriptes zu benutzen, um den Script-Interpreter zu finden, beschrieben.

Dies könnte allerdings ein Weg sein. Für EXE-Dateien muß der Apache in der Registry nachsehen (denn das sie selbst ihr "Interpreter" sind, steht nicht drin), es sei denn, das ist hardcoded im Apache-Code. Also "ScriptInterpreterSource Registry" einschalten, Philipp!

Alexander

[Christoph Schnauß]

hallo Alexander,

Dies könnte allerdings ein Weg sein. Für EXE-Dateien muß der Apache in der Registry nachsehen (denn das sie selbst ihr "Interpreter" sind, steht nicht drin), es sei denn, das ist hardcoded im Apache-Code. Also "ScriptInterpreterSource Registry" einschalten, Philipp!

Das ist nicht ganz korrekt. "ScriptInterpreterSource Registry" hat Auswirkungen darauf, wo der Apache zuerst nachschaut, falls ein Scriptinterpreter benötigt wird. Wird der Pfad zum PERL-Interpreter in der registry gefunden, wird gar keine shebang mehr benötigt. Mit EXE's hat das aber nichts zu tun, ich habs eben mal schnell durchprobiert. EXE's sind per se ausführbar (Scripts nicht) und benötigen keinen gesonderten "Interpreter".

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo zusammen

Euch dreien, Christoph, Alexander und milky nochmals vielen Dank für
eure Geduld und die zahlreichen Vorschläge.

Ich habe das Problem mal nach "news:alt.apache.configuration"
portiert. Mal sehen ob dort noch weitere Vorschläge kommen.

Viele Grüsse und Danke!

Philipp

[Christoph Schnauß]

hallo Philipp,

Ich habe das Problem mal nach "news:alt.apache.configuration"
portiert. Mal sehen ob dort noch weitere Vorschläge kommen.

Das bleibt dir zu wünschen. Die Jungs dort sind gut. Aber mir ist etwas aufgefallen. In deinem Beitrag dort in dieser NG zitierst du deine Fehlermeldung:

[Mon Jan 05 13:29:00 2004] [error] [client 127.0.0.1] (OS 5)Access denied  : couldn't create child process: 720005: env.exe

Und in [pref:t=68109&m=390498] hast du geschrieben:

This is Apache/2.0.44 (Win32) PHP/4.3.0 Server at 192.168.0.8 Port 80

Fällt dir was auf, wenn du die IP-Angaben vergleichst?

Grüße aus Berlin

Christoph S.

[Alexander Foken]

Moin Moin !

Aber mir ist etwas aufgefallen. In deinem Beitrag dort in dieser NG zitierst du deine Fehlermeldung:

[Mon Jan 05 13:29:00 2004] [error] [client 127.0.0.1] (OS 5)Access denied  : couldn't create child process: 720005: env.exe

Und in [pref:t=68109&m=390498] hast du geschrieben:

This is Apache/2.0.44 (Win32) PHP/4.3.0 Server at 192.168.0.8 Port 80

Fällt dir was auf, wenn du die IP-Angaben vergleichst?

So lange Philipp Name-based Virtual Hosts benutzt, macht das eigentlich nichts, wenn er über localhost geht und den Resolver (hosts-Datei bzw. DNS) richtig konfiguriert hat.

(blätter, blätter)

Er benutzt u.a. 127.0.0.10 (nicht .1) - das ist zwar auch localhost, aber eben eine andere Adresse. (Wer auch immer auf die abstruse Idee gekommen ist, für Localhost mal eben ein Class-A-Netz mit 2^24 Adressen aufzumachen - hier hilft es mal.)

Aber Du hast recht, wenn Philipp über das 192.168er-Netz auf den Apachen zugreift, greift die Virtual Host Definition für 127.0.0.10 nicht.

Alexander

[Christoph Schnauß]

hallo Alexander,

So lange Philipp Name-based Virtual Hosts benutzt, macht das eigentlich nichts, wenn er über localhost geht und den Resolver (hosts-Datei bzw. DNS) richtig konfiguriert hat.

_Prinzipiell_ richtig. Nur: wenn man an irgendeiner Stelle Probleme hat, sollte man versuchen, alle _möglichen_ anderen Konfliktstellen erstmal auszuschließen.

Er benutzt u.a. 127.0.0.10 (nicht .1) - das ist zwar auch localhost, aber eben eine andere Adresse.

Hm. Es wird dir kaum entgangen sein, daß ich erhebliche Vorbehalte gegenüber der 127 als Sammeladresse für virtualhosts habe (ist im Archiv zu finden). Das ist teilweise bestimmt nicht nötig, die 127 _kann_ durchaus auch für virthosts funktionieren. Aber: "solange man ... (siehe oben)" ;-)

Aber Du hast recht, wenn Philipp über das 192.168er-Netz auf den Apachen zugreift, greift die Virtual Host Definition für 127.0.0.10 nicht.

Das reizt mich jetzt mal. Ich werde meinen ausgezeichnet funktionierenden Apache 2.0.48 mal so umstellen, daß meine virthosts auf 127 zugreifen (obwohl der Rechner eine 192.168.0.1 hat) und den ganzen Kram durchspielen.

Das Problem, das ich in diesem Thread habe, ist: ich habe zwar mehrfach "couldn't spawn child process" in meinen logs vorgefunden, aber noch nie in Zusammenhang mit dem von Philipp geschilderten Problem. Auch dieses ominöse (OS 5) im error_log habe ich noch nie gehabt, und die Apache-Doku sagt dazu nix. Ich werde jetzt mal was ganz Kurioses machen, und eine EXE auf meinen unter FreeBSD laufenden Apache ins cgi-bin schubsen. Vielleicht kriege ich eine vergleichbare Fehlermeldung.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

This is Apache/2.0.44 (Win32) PHP/4.3.0 Server at 192.168.0.8 Port 80
Fällt dir was auf, wenn du die IP-Angaben vergleichst?

Du hast recht, ich sollte darauf achten einen Testcase wirklich
unverändert durchzuziehen, denn es kann gut vorkommen, dass so
Fehlschlüsse entstehen.

Gut, in diesem Beispiel jetzt spielt es (IMHO) keine Rolle, ich habe
es wirklich genug oft mit allen Varianten durchgespielt und die
Konfiguration ist des weiteren nicht grossartig anders. Dennoch ist
der Einwand völlig richtig.

Falls eine Lösung/Kommentar kommen sollte, was bisher nicht geschah,
werde ich ihn hier der vollständigkeits halber posten (und
übersetzen, huch...)

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

Dank der Hilfe von Christoph ist es nun möglich einen Grossteil des
Puzzles zu lösen. Er konnte den Fehler bei sich durch meine
httpd.conf und .exe Datei reproduzieren. Dabei handelte es sich
weder um eine Fehlkonfiguration in der httpd.conf, noch um ein
Fehler zwischen Apachen und WinXP. Der Fehler lag - und das hatte
ich niemals vermutet - an der .exe File selber. Auf der Konsole als
normaler Benutzer lief das Programm wie erwartet. Aber unter den
Rechten/Account von SYSTEM scheint das Programm eine
Schutzverletzung (?) bei XP auszulösen, was mit OS 5 Access Denied
quittiert wird. Nun, Christophs .exe Datei läuft auf seinem wie
meinem System völlig sauber. Demnach halte ich es entweder für ein
Problem von DJGPP mit WinXP SYSTEM Account, oder ein Problem
zwischen DJGPP und Apachen unter SYSTEM-Berechtigung.

Jetzt weiss ich endlich an was das liegt (.exe selber) und kann
weitere "Studies" daran anknüpfen. Das Raten hat nun ein Ende :-)
Für mich heisst das nun: Anderen Compiler suchen, oder ggf. neue
DJGPP-Version besorgen.

--- currently running: ---
H:\Dokumente und Einstellungen\Philipp>gpp -v
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.31/specs
Configured with: /devel/gnu/gcc/3.3/gnu/gcc-3.31/configure i586-pc-msdosdjgpp --
prefix=/dev/env/DJDIR --disable-nls
Thread model: single
gcc version 3.3.1
---

Vielen Dank Christoph für die Zeit, die Ausdauer und des Puzzles
(fast) letztes Element!

Viele Grüsse

Philipp