Apache Berechtigungen

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