Apache Berechtigungen

[Dr.Ma-Busen]

Moin!

Folgendes Problem.

Ich habe hier WinXP und Linux (Suse), auf beiden habe ich den Apache als Server eingerichtet, läuft auch alles wunder bar. So und damit ich nicht immer die Daten Synchronesieren muß habe ich die Server so konfiguriert das beide den Selben Ordner als DocuentRoot haben. Der liegt logischerweise auf einer FAT Partition, da Win ja nicht in der Lage ist Linux Partitionen zu lesen. Wie gesagt klappt wunderbar, bis auf das ausführen von CGI- Scripten, wenn ich die aufrufe bekomme ich immer einen 500 Error und in der Error log steht dann folgendes:
[Wed Jul 07 21:51:11 2004] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Wed Jul 07 21:51:11 2004] [error] [client 127.0.0.1] (13)Permission denied: exec of '/windows/D/Server/Html/docmabusen/index.cgi' failed

Wenn ich mir die Berechtigungen anschaue dann steht da folgendes:
Eigentümer:
Benutzer: root
Gruppe:useres

Zugangsberechtigungen:
Benutzer: rwx
Gruppe: rwx
Sonstige: rx

Eigentlich müsste der Apache bzw. der Perlinterpreter doch darauf zugreifen können oder??
Als normaler Benutzer kann ich ja auf die Dateien zugreifen und sie Bearbeiten, aber warum der Apache oder der Perlinterpreter nicht???
Habe ja auch schon den Server unter verschiedenen Benutzer laufen lassen, aber immer mit dem selben Ergebnis

Ändern kann ich die Rechte als root auch nicht.

Liegt das Problem überhaupt bei den Berechtigungen oder liegt es wo anders (Serverkonfiguration) ich habe in der Konfiguration nur die Pfade angepasst.

Ach ja, fast vergessen, wenn ich den Ordner von der FAT Partition in den Ordner auf die Linux Partition kopieren dann geht das ganze.

Na ja, vielleicht weis ja einer von euch wo dran es liegt bzw. liegen könnte.

MfG
Dr. Ma-Busen

[Christoph Schnauß]

hallo,

Ich habe hier WinXP und Linux (Suse), [...] habe ich die Server so konfiguriert das beide den Selben Ordner als DocuentRoot haben.

Gut, das habe ich auch so gemacht.

klappt wunderbar, bis auf das ausführen von CGI- Scripten, wenn ich die aufrufe bekomme ich immer einen 500 Error

Auf beiden Plattformen? Oder klappt das unter Windows und dann unter SuSE nicht?

und in der Error log steht dann folgendes:
[Wed Jul 07 21:51:11 2004] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Wed Jul 07 21:51:11 2004] [error] [client 127.0.0.1] (13)Permission denied: exec of '/windows/D/Server/Html/docmabusen/index.cgi' failed

Dein cgi-bin muß mit deinem DocumentRoot überhaupt nichts zu tun haben. Das entsprechende Verzeichnis muß natürlich in der httpd.conf freigegeben werden.

Im übrigen: welche Apache-Version hast du auf welcher Plattform laufen?

Wenn ich mir die Berechtigungen anschaue dann

...sieht das völlig korrekt aus.

Liegt das Problem überhaupt bei den Berechtigungen oder liegt es wo anders (Serverkonfiguration)

Mit Sicherheit ist die Konfiguration dran schuld, weil:

wenn ich den Ordner von der FAT Partition in den Ordner auf die Linux Partition kopieren dann geht das ganze.

Das ist ein deutlicher Hinweis auf einen Fehler in deiner httpd.conf.

Grüße aus Berlin

Christoph S.

[Tom]

Hello,

ich denke, dass ich da gleiche Problem auch schon mal vorgetragen habe und es konnte, trotz einiger guter Hinweise, niemand helfen. Das müsste noch unter "Author:tom Perl Rechte" zu finden sein. Würde mich auch riesig freuen, es endlich lösen zu können.

Ich hatte damals die Knoten zwischen den Owner, Group und Other-Rechten festgestellt. Der Perl-Interpreter scheint da irgendwelche ulkigen Schnitt- und Vereiningungsmengen zu bilden, die ich trotz guter Anleitungen nicht nachvollziehen konnte.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

ich habe meinen zweiten Thread zu dem Thema wiedergefunden:
http://forum.de.selfhtml.org/archiv/2004/4/79630/#m461998

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Dr.Ma-Busen]

Hallo

Auf beiden Plattformen? Oder klappt das unter Windows und dann unter SuSE nicht?

Nein nur bei SuSE geht es nicht.

Dein cgi-bin muß mit deinem DocumentRoot überhaupt nichts zu tun haben. Das entsprechende Verzeichnis muß natürlich in der httpd.conf freigegeben werden.

Ich habe das bei Win so eingerichtet das ich CGI- Scripte im ganzen DocumentRoot ausführen kann. Hatte ich bei Suse auch so vor.

Im übrigen: welche Apache-Version hast du auf welcher Plattform laufen?

Auf beiden läuft die 2.0.49. Ich hatte gestern auch mal die 2.0.50 mir installiert (auf suse), aber da hatte ich das Problem auch

Mit Sicherheit ist die Konfiguration dran schuld, weil...

Gut dann werde ich da mal weiter suchen, habe jetzt mod_perl im verdacht.

Habe mal die beiden Serverkonfigurationen in ein zip gepackt:
http://de.geocities.com/d_woestefeld/stuff/conf.html

MfG
Dr. Ma-Busen

[Tom]

Hello,

Gut dann werde ich da mal weiter suchen, habe jetzt mod_perl im verdacht.

das hatte ich auch in Verdacht, aber daran lag es wohl nicht, zumindest nicht direkt feststellbar.

Bevor Dundas also weiter verfplgst, wäre es nett, wenn Du mal eine ganz simple Einrichtung für den Perl-User machst. Also _nicht_ Mitglied in zusätzlichen Gruppen etc. Dann geht es nämlich meistens. Erst wenn vermeintlich zusätzliche Rechte hinzukommen, geht plötzlich nix mehr.

Mein Übungs-Apache ist noch ein 1.3.27

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christoph Schnauß]

hi,

Nein nur bei SuSE geht es nicht.

Aha, dachte ich mir beinahe.

Ich habe das bei Win so eingerichtet das ich CGI- Scripte im ganzen DocumentRoot ausführen kann. Hatte ich bei Suse auch so vor.

Laß es lieber vorläufig. Es kommt erstmal darauf an, daß du deine cgi-Scripts ansprechen kannst, wenn das funktioniert, kannst du weiterwurschteln.

Auf beiden läuft die 2.0.49. Ich hatte gestern auch mal die 2.0.50 mir installiert (auf suse), aber da hatte ich das Problem auch

Das wirst du versionsunabhängig haben, da irgendwas mit deinen Pfadangaben nicht stimmt. Leider ist die log-Meldung "premature end ..." ein bißchen irreführend. Script-Header können gar nicht erst ausgelesen werden, da das Script nicht gefunden wird, daher gibts auch ein "unerwartetes Ende".

Im übrigen kannst du die 2.0.50 ruhig drauflassen. Da warst du allerdings sehr fix, das entsprechende RPM-Paket gibts erst seit vorgestern auf dem SuSE-FTP-Server. Apache 2.0.50 ist lediglich sowas wie ein "bugfix" für die 2.0.49, siehe changelog

habe jetzt mod_perl im verdacht.

unberechtigterweise. Es wäre vorerst zu empfehlen, mod_perl ganz wegzulassen. Das ist dafür gut, daß du PERL-Code direkt in Webseiten einbetten kannst und hat mit deinem CGI-Problem nichts zu tun. In der Liste mit den LoadModule-Anweisungen muß aber unbedingt mod_cgi aktiviert sein.

Habe mal die beiden Serverkonfigurationen in ein zip gepackt:
http://de.geocities.com/d_woestefeld/stuff/conf.html

öhm, ja ... nette Idee, aber ich habe keine Lust, mir ein ZIP zu ziehen und auszupacken. Wenn du Webspace hast, kannst du doch die Teile der Konfiguration, an denen du den Fehler vermutest, als Textdateien raufladen.

Die SuSE hat seit Apache 2.0.48 ein zwar interessantes, aber auch etwas schwieriges Konzewpt für den Umgang mit der httpd.conf eingeführt, das hast du ja gesehen. Du kannst, wenn du mit der Zerstückelung, die die SuSE vorgenommen hat, nicht klarkommen solltest, dir aber auch eine "alte" httpd.conf vornehmen und die dann gewissermaßen "in einem Stück" durcharbeiten. Eine Vorlage liegt in /usr/share/doc/packages/apache2 und heißt httpd.conf.default

stimmt deine mail-Adresse? Dann habe ich noch eine Information für dich, die leider noch nicht im Forum gepostet werden kann.

Grüße aus Berlin

Christoph S.

[Dr.Ma-Busen]

hallo,

Im übrigen kannst du die 2.0.50 ruhig drauflassen. Da warst du allerdings sehr fix, das entsprechende RPM-Paket gibts erst seit vorgestern auf dem SuSE-FTP-Server. Apache 2.0.50 ist lediglich sowas wie ein "bugfix" für die 2.0.49, siehe changelog

Ui ein rpm, gar nicht dran gedacht bei Suse zu schauen, habe mir den Source von Apache.org geholt und installiert. Habe die 2.0.50 nur zufällig dort gefunden, hatte da eigentlich nach einer evt. Lösung gesucht.

Die SuSE hat seit Apache 2.0.48 ein zwar interessantes, aber auch etwas....

Ja, auch schon festgestellt, ne gute idee eignetlich das alles aufzuteilen, aber auch irgendwie etwas unübersichtlich finde ich.

stimmt deine mail-Adresse? Dann habe ich noch eine Information für dich, die leider noch nicht im Forum gepostet werden kann.

Ja, die E-Mail Addy stimmt

Nagut, dann werde ich mal  mod_perl ganz verbannen. Und mal mit den muster etwas rum Spielen.

MfG

[Christoph Schnauß]

hi,

so, ich hab mir dein ZIP doch mal angeschaut. In meinen Augen liegt dein Fehler darin, daß du an /etc/apache2/uid.conf herumgespielt hast. Laß das lieber so, wie es die Suse vorformuliert hat, wenn du noch einen weiteren user dazutun willst, steckst du den als neuen user in die Gruppe "www".

habe mir den Source von Apache.org geholt und installiert

lobenswert, allerdings gerade für die SuSE leider nicht zu empfehlen, da die zuviel an ihren Systemeinstellungen herummurksen und man auf ein paar Dinge extrem achten muß. Außerdem hast du das "SuSE-Konzept" der httpd.conf beibehalten, was du in einem solchen Fall (mit selber kompiliertem Apache) nicht tun solltest.

Ja, die E-Mail Addy stimmt

Gut, dann hast du eine mail von mir bereits erhalten.

Es gibt noch etwas: Der Pfad "windows/D/..." entsteht, wenn du bei der Installation der SuSE den Partitionierungsvorschlag von YaST unverändert übernimmst. Ich halte Mountpoints dieser Art nicht für sehr sinnvoll, und außerdem fabriziert die SuSE dabei gleich zwei Einträge:
"windows/D/..."
"windows/d/..."
Das gibt Konflikte, wenn beide Mountpoints auf dasselbe /dev/hdxx zeigen. Schreibe dir deine /etc/fstab lieber neu und lege dir bessere Mountpoints an. Beibehalten werden kann allerdings
 "users,gid=users,umask=0002,iocharset=utf8 0 0"
weil damit unter anderem auch ein paar "Rechte" bestimmt werden. "umask" ist dabei enorm wichtig, Näheres dazu bitte in "man fstab" nachlesen (könntest du sogar in deutscher Sprache haben).

Grüße aus Berlin

Christoph S.

[Dr. Ma-Busen]

hi

so, ich hab mir dein ZIP doch mal angeschaut. In meinen Augen liegt dein Fehler darin, daß du an /etc/apache2/uid.conf herumgespielt hast....

Das habe ich mitlerweile wieder geänder, auf den wert von suse (wwwrun www)

... Außerdem hast du das "SuSE-Konzept" der httpd.conf beibehalten, was du in einem solchen Fall (mit selber kompiliertem Apache) nicht tun solltest.

Ne ne, das konzept von Suse hatte ich nicht genutzt sonder die httpd.conf aus dem Ordner /usr/local/apache2/conf/ (hoffe mal das ich mich an den Pfad richtig erinnert habe :) )
Habe nur wider den 2.0.49 von der Suse CD drauf, weil der beim Booten gestartet wurde und der selbst erstllte noch nicht und da ich noch nicht weis wo man das eintragen muss damit der beim Boote gestartet wird habe ich halt den anderen wieder installiert. Muss an dieser stelle sage das ich jetzt gerade mal 1 woche richtig mit Linux arbeite.

Gut, dann hast du eine mail von mir bereits erhalten.

Ja die habe ich bekommen, Danke. Werde mir das im laufe des Abendes/Nacht noch durchlesen

... Ich halte Mountpoints dieser Art nicht für sehr sinnvoll, und außerdem fabriziert die SuSE dabei gleich zwei Einträge:
"windows/D/..."
"windows/d/..."

Also bei mir sind nur zwei da D und C klein d und c sind bei mir links auf D und C. Aber ich werde mir das gelegenheit ändern.

Werde mir jetzt mal die httpd.conf ganz löschen und langsam neu auf bauen, was etwas dauern kann, melde mich dann wieder.

MfG
Dr. Ma-Busen

[Dr.Ma-Busen]

N'abend :/

Werde mir jetzt mal die httpd.conf ganz löschen und langsam neu auf bauen, was etwas dauern kann, melde mich dann wieder.

So, dass habe ich jetzt gemacht und hier ist nun der Bericht:

Also, ich habe die httpd.conf jetzt selber zuammen gebastelt und es geht wenn ich als DocumentRoot den Ordner auf der Lin Partition angebe. Aber es liefen nicht alle Perl Scripte. Bekam immer noch einen 500 Error, aber als ich in die error_log geschaut habe stand da nichts mehr von Zugriff verweigert, sondern eine menge Fehler meldungen, Syntaxfehler. Was aber eigentlich nicht sein dürfte, da die Scripte unter Win ja laufen und auf dem Webspace ja auch ohne Fehler. Ein Script was Fehler verusacht hat, ist das Beispiel aus selfHTML mit den man alle Umgebungsvariabeln ausgeben kann. Bis ich hinter "/usr/bin/perl" die Option -w geschrieben habe da lief es dann wieder, ohne die Option -w gab es einen 500 Error und in der error_log stand dann > (2)No such file or directory: exec of.. <

So, und wenn ich bei den Script dann das modul "use strict" ohne die Option -w einbinde steht in der error_log > Can't open perl script "\r": No such file or directory < mit der option -w geht es aber wieder.

So, und als ich mir dann mal ein andere Script betrachtet habe fand ich folgenden Quelltext dort drin:
$wert =~ s/ &Ouml;/g;
$wert =~ s//&uuml;/g;
$wert =~ s/ &Uuml;/g;
$wert =~ s/ &auml;/g;
$wert =~ s/ &Auml;/g;
$wert =~ s/ &szlig;/g;

Dabei habe ich das so nie geschrieben, da fehlt noch fast überall ein /

Und in der error_log steht dann dazu noch:
...Unrecognized character \xEF at /srv/ww...

Dann habe ich Win mal gestartet und mir das Script angeschaut ganau die selben zeilen und da war alles in Ordnung.

Zu erwähnen ist auch noch, dass ich das Script mit den Umgebungs variablen, was auf der Lin Partition lief auf die Win Partition kopiert habe, habe die Pfade in der httpd.conf angepasst und da lief es dann wieder nicht. In der log stand da dann wieder Zugriff verweigert :/

Meine Schlussvolgerung: Irgendetwas, hm... wie nennt sich das jetzt noch mal, glaube Zeichentabelle, stimmt nicht.

Ich könnte ja die Scripte anpassen, bwz. die Fehler beseitigen, aber wer garantiert mir das es nur bei den Scripte ist und nicht auch noch bei andere, Dateien?

Na ja, ich hoffe mal das das auch der grund ist warum die Scripte nicht laufen wenn der DocumentRoot auf der Win Partiton liegt

So, bleibt zum Schluss noch die Frage: Wie kan ich das Problem beseitigen???

In meiner fstab steht bei den parametern für die win platten:
iocharset=utf8 0 0

Schätze mal das ist der Zeichen satz

Was auch noch zu erwähnen wäre ist. Die beiden Win Partitionen ware vorher NTFS, da NTFS ja noch nicht so sicher sein soll unter Linux habe ich die mit Partition Magic in FAT32 zurück konvertiert.

MfG
Dr. Ma-Busen

[Christoph Schnauß]

morgens,

na gut, dann wolln wir nochmal:

Also, ich habe die httpd.conf jetzt selber zuammen gebastelt und es geht wenn ich als DocumentRoot den Ordner auf der Lin Partition angebe.

"Selber zusammenbasteln" ist schonmal sehr gut. Aber dein DocumentRoot sollte doch auf einer Partition liegen, auf die beide Systeme Zugriff haben.

Aber es liefen nicht alle Perl Scripte. Bekam immer noch einen 500 Error, aber als ich in die error_log geschaut habe stand da nichts mehr von Zugriff verweigert, sondern eine menge Fehler meldungen, Syntaxfehler.

Das stand zu vermuten.

Was aber eigentlich nicht sein dürfte, da die Scripte unter Win ja laufen

Doch, doch, genau das hast du eigentlich sogar vorprogrammiert, nur nachweisen kann mans dir erst dann, wenn du mal so ein PERL-Script postest, das unter Windows funktioniert und unter SuSE nicht. Das hat mit der "shebang" zu tun. In deiner Windows-httpd.conf hast du festgelegt:

<Directory "D:/Server/Html">
    ScriptInterpreterSource registry-strict
...

Und _das_ dürfte das Problem mit deinen PERL-Scripts sein. Bitte nochmal in der Apache-Doku nachlesen, was "ScriptInterpreterSource" bedeutet.

Bis ich hinter "/usr/bin/perl" die Option -w geschrieben habe

Die solltest du _grundsätzlich_ dort hineinschreiben, solange du am Konfigurieren und Ausprobieren bist.

So, und wenn ich bei den Script dann das modul "use strict" ohne die Option -w einbinde steht in der error_log > Can't open perl script "\r": No such file or directory

Dazu solltest du bitte das "Script" auch posten. Und nicht vergessen: dieses "r" entsteht dadurch, daß du dein PERL-Script möglicherweise in Notepad geschrieben und im "PC-Format" gespeichert hast.

So, und als ich mir dann mal ein andere Script betrachtet habe fand ich folgenden Quelltext dort drin:
$wert =~ s/ &Ouml;/g;
$wert =~ s//&uuml;/g;
Dabei habe ich das so nie geschrieben, da fehlt noch fast überall ein /

Nicht nur das, sondern:

...Unrecognized character \xEF at /srv/ww...

Das gehört ebenfalls dazu. Beschäftige dich bitte mit der unterschiedlichen Behandlung von Zeilentrennern, Vorschüben, Tabulatoren usw. in Textdateien, wenn sie von LINUX oder WINDOWS erstellt/bearbeitet werden.

Dann habe ich Win mal gestartet und mir das Script angeschaut ganau die selben zeilen und da war alles in Ordnung.

Windows kann keine "nichtdruckbaren Zeichen" erkennen, solange sie "windows-konform" sind. Benutze als Texteditor beispielsweise Textpad (http://www.textpad.com, der kann dir auch auf Windows Textdateien im "UNIX-Format" abspeichern.

Zu erwähnen ist auch noch, dass ich das Script mit den Umgebungs variablen, was auf der Lin Partition lief auf die Win Partition kopiert habe

Völlig unwirksam und überflüssig.

In der log stand da dann wieder Zugriff verweigert :/

Die Begründung könnte dir inzwischen selber einfallen.

Irgendetwas, glaube Zeichentabelle, stimmt nicht.

Tatsächlich stimmt etwas nicht. Aber mit irgendeiner Zeichentabelle hat das nix zu tun.

So, bleibt zum Schluss noch die Frage: Wie kan ich das Problem beseitigen?

Indem du auf den beiden Plattformen unterschiedliche Scripts einsetzt.

In meiner fstab steht bei den parametern für die win platten:
iocharset=utf8 0 0 Schätze mal das ist der Zeichen satz

Jaein. Bitte "man fstab" nachlesen.

da NTFS ja noch nicht so sicher sein soll unter Linux habe ich die mit Partition Magic in FAT32 zurück konvertiert.

NTFS ist ziemlich sicher, und welches System darauf zuzugreifen versucht, ist völlig wurscht. Das Problem, daß die LINUX-Distributionen sehr lange Zeit damit nicht zurechtkamen, liegt darin, daß Microsoft seine Sourcen nicht freigegeben hat und demzufolge die LINUX-Entwickler nicht wußten, wie sie darauf zugreifen könnten. Das hat sich inzwischen einigermaßen gelegt, und insbesondere die SuSE kann neuerdings sehr gut mit NTFS-Partitionen umgehen (seit SuSE LINUX 8.3), sowohl mit lesendem wie auch mit schreibendem Zugriff.

Es ist aber grundsätzlich richtig, wenn du dein gemeinsames DocumentRoot auf einer FAT32-Partition ablegst.

Grüße aus Berlin

Christoph S.

[Dr.Ma-Busen]

morgens,

Jo, guten morgen... ui schon so früh? ich muss glaube mal ins Bett *G

"Selber zusammenbasteln" ist schonmal sehr gut. Aber dein DocumentRoot sollte doch auf einer Partition liegen, auf die beide Systeme Zugriff haben.

Tut er im grunde ja. Nur habe ich erstmal den DocumentRoot auf die Lin Partition gelegt, und als der Server dann lief habe ich den geändert auf die Win Partition

Was aber eigentlich nicht sein dürfte, da die Scripte unter Win ja laufen

Doch, doch, .... Das hat mit der "shebang" zu tun. In deiner Windows-httpd.conf hast du festgelegt..

Die shebang ist in alle Scripte gleich und zwar "/usr/bin/perl" Weil auf den Webspace auf den ich die Sachen habe genau der selbe Pfad zu Perl ist wie bei mir. Übrigends der Webspace ist laut Umgebungsvariablen ein Suse Server mit einen 1.3.x Apache.

Und das Script mit den Variablen was ich in meiner Beschreibung des öffteren verwendet hatte findest du hier
http://de.selfhtml.org/cgiperl/intro/umgebungsvariablen.htm#allgemeines

Das habe ich gerade auch noch mal von der Seite kopiert und als cgi Script abgespeichert und aufgerufen. Mit der Option -w wird es ausgeführt, ohne die Option gibt es den schon mal beschriebenen 500 Error. Ich habe auch in der Konsole das Script gestartet und mit den Qulltext angeschaut den es zurück gibt. Egal ob mit oder ohne -w, der Qulltest ist in Ordung, keine Warnung oder der gleichen vom interpreter dabei. Und wie gesagt auf dem Webspace läuft das ja auch ohne Fehler.

.... Bitte nochmal in der Apache-Doku nachlesen, was "ScriptInterpreterSource" bedeutet.

Also laut Doku und dieversen Seiten sagt ScriptInterpreterSource das der Apche nach dem Pfad zu Perl in der Registrierung suchen soll.
Und das habe ich damals deshalb eingebaut damit ich ja nicht immer wenn ich die Scripte auf den Webspace lade die shebang ändern muss.
Hatte deswegen ja schon mal hier im Forum gepostet weil das mit ScriptInterpreterSource nicht so recht laufen wollte.
Siehe hier: http://forum.de.selfhtml.org/archiv/2004/2/72937/#m419961

Dazu solltest du bitte das "Script" auch posten. Und nicht vergessen: dieses "r" entsteht dadurch, daß du dein PERL-Script möglicherweise in Notepad geschrieben und im "PC-Format" gespeichert hast.

Geschrieben habe ich meine Scripte bis jetzt alle mit EditPlus, aber muss ja nicht bedeute das er es nicht im UNIX- Format gespeichert hat

Nicht nur das, sondern:

...Unrecognized character \xEF at /srv/ww...

Das gehört ebenfalls dazu. Beschäftige dich bitte mit der unterschiedlichen Behandlung von Zeilentrennern, Vorschüben, Tabulatoren usw. in Textdateien, wenn sie von LINUX oder WINDOWS erstellt/bearbeitet werden.

Mach ich noch mal, aber es ist mit schon bekannt das bei den Steuerzeichen unterschiede zwischen den system gibt, besonderst beim Zeilenumbruch. Deswegen gibt es ja auch die Option ASCII Modus bei den FTP Clients

Dann habe ich Win mal gestartet und mir das Script angeschaut ganau die selben zeilen und da war alles in Ordnung.

Windows kann keine "nichtdruckbaren Zeichen" erkennen, solange sie "windows-konform" sind. Benutze als Texteditor beispielsweise Textpad (http://www.textpad.com, der kann dir auch auf Windows Textdateien im "UNIX-Format" abspeichern.

Es handelt sich dabei ja dabei nicht um "nichtdruckbare Zeichen" sondern es sind Umlaute. Textpad werde ich mir mal anschauen.

Zu erwähnen ist auch noch, dass ich das Script mit den Umgebungs variablen, was auf der Lin Partition lief auf die Win Partition kopiert habe

Völlig unwirksam und überflüssig.

Vielleicht habe ich mich hier nicht richtig ausgedrückt. Ich wollte sagen das ich das Script von der Lin Partition auf die Win Partition kopiert habe und den Doc.Root geändert habe. Und nicht Win gestartet habe um zu Testen. Falls es jetzt so rüber gekomen ist

In der log stand da dann wieder Zugriff verweigert :/

Die Begründung könnte dir inzwischen selber einfallen.

Entweder bin ich zu Müde oder ich begreife es nicht. Wenn ich die Begründung wüsste dann wäre ich ja schon ein stück weiter.

So, bleibt zum Schluss noch die Frage: Wie kan ich das Problem beseitigen?

Indem du auf den beiden Plattformen unterschiedliche Scripts einsetzt.

Das will ich ja ebend nicht, ich will unter beiden System an ein und dem selben Script arbeite OHNE die jedes mal zu kopieren, das kann doch nicht so schwer sein oder??

MfG
Dr. Ma-Busen

[Christoph Schnauß]

hallo,

Und das Script mit den Variablen was ich in meiner Beschreibung des öffteren verwendet hatte findest du hier
http://de.selfhtml.org/cgiperl/intro/umgebungsvariablen.htm#allgemeines
Das habe ich gerade auch noch mal von der Seite kopiert und als cgi Script abgespeichert und aufgerufen. Mit der Option -w wird es ausgeführt, ohne die Option gibt es den schon mal beschriebenen 500 Error.

Ich habs mir eben auch mal auf einer SuSE ins cgi-bin geladen. Den von dir beschriebenen Fehler erhalte ich nur dann, wenn die Ausführungsrechte nicht stimmen, und dann allerdings unabhängig davon, ob -w gesetzt ist oder nicht. Hast du dein (kopiertes) Script denn auf "ausführbar" gesetzt?

Grüße aus Berlin

Christoph S.

[Dr.Ma-Busen]

Mahlzeit!

Ich habs mir eben auch mal auf einer SuSE ins cgi-bin geladen. Den von dir beschriebenen Fehler erhalte ich nur dann, wenn die Ausführungsrechte nicht stimmen, und dann allerdings unabhängig davon, ob -w gesetzt ist oder nicht. Hast du dein (kopiertes) Script denn auf "ausführbar" gesetzt?

Ja, da war ich wohl schon etwas zu müde und habe einfach den Code in die alte Datei Kopiert und nicht dran gedacht das sich dadurch die Informationen über den Verwendeten Zeichensatz und das Format im Dateikopf nicht ändern.

So, ich habe mittlerweile mal ein Paar CGI- Scripte unter Win mit Textpad umkonvertiert, also in Unixformat und mit der Zeichenkodierung UTF-8 abgespeichert.

Dann habe ich unter SuSE die Scripte mal in den Ordner /srv/www/htdocs auf der Lin Partition kopiert und den Doc.Root auf das Verzeichnis gelegt. Und dort erst mal alles zum laufen gebracht. Nachdem das alles lief und die Scipte sich auch ausführen liesen, Habe ich den Doc.Root auf des Verzeichnis auf der Win Partition gelegt in dem die "Konvertierten" Scripte liegen. Aber da habe ich jetzt wieder das Selbe Problem wie in mein ausgangsposting beschrieben. Also 500er Error mit den eintrag in der Log (13)Permission denied: exec of.....

Du hast in deinem 1. antwortsposting geschrieben das du das auch so hast, also dein Server unter SuSE und Win auch einen gemeinsamen Doc.Root haben, oder??

Kannst du mir mal deine httpd.conf zukommen lassen von dem Apache auf der SuSE, dann kann ich mir das mal anschauen und Probieren ob es bei mir dann läuft mit der Konfiguration. Wäre sehr nett.

MfG
Dr. Ma-Busen

[Dr. Ma-Busen]

Moin Moin !!

Kannst du mir mal deine httpd.conf zukommen lassen von dem Apache auf der SuSE, dann kann ich mir das mal anschauen und Probieren ob es bei mir dann läuft mit der Konfiguration. Wäre sehr nett.

So, glaube das ist jetzt nicht mehr nötig, ich habe es endlich geschafft *stolzaufdieschulterklopftundgrinsdwiehonigkuchenpferd* *GG
Nach den ich in meine fstab bei den mount optionen für die FAT Partitionen die option exec hinzu gefügt habe geht es nun endlich :)

Na ja, dann Bedanke ich mich mal an dieser stelle für deine deine Hilfe.

MfG
Dr. Ma-Busen