perl-Verzeichnis wird nicht angezeigt
Helge Rex
- webserver
Hallo zusammen,
Server: SuSE Linux 7.2
Apache: 1.3.19
ich habe mir die ZIP-Datei mit der aktualisierten SelfHTML-Doku heruntergeladen und auf meinem privaten Webserver entpackt.
Fast alle Teile der Doku werden korrekt angezeigt, nur der perl-Teil will nicht. Stattdessen erhalte ich bei jeder Datei aus dem perl-Verzeichnis Fehler "404 - file not found".
Nachdem ich das Verzeichnis in "perle" umbenannt habe, wurde mir die Doku angezeigt. Da ich dafür aber die restliche Doku anpassen müßte, habe ich das wieder rückgängig gemacht.
In der Config meines WebServers steht folgendes drin:
<IfModule mod_perl.c>
ScriptAlias /perl/ "/usr/local/httpd/cgi-bin/"
ScriptAlias /cgi-perl/ "/usr/local/httpd/cgi-bin/"
</IfModule>
Aus diesem Grund werden alle Dateien, die ich aus dem perl-Verzeichnis sehen möchte, im benannten cgi-bin-Verzeichnis gesucht. Daher kommt wohl Fehler 404.
Ein Auskommentieren dieses ScripAlias mit anschließendem Neustart des WebServers bringt gar nichts, ich erhalte nun jedoch Fehler "403 - Forbidden".
Mit weiterhin auskommentiertem ScriptAlias habe ich in der Config zum VirtualHost ein Alias gesetzt:
Alias /perl/ "/public/selfhtml/perl/"
Aber auch das bringt mir ein 403 ein.
Dann habe ich das perl-Verzeichnis wieder auf "perle" geändert und den Alias entsprechend geändert:
Alias /perl/ "/public/selfhtml/perle/"
Ergebnis : Fehler 403
Jetzt stehe ich da und weiß nicht, was ich noch tun kann, um mir die perl-Doku anzuschauen.
Das Verzeichnis möchte ich ungern umbenennen und die gesamte Doku entsprechend anpassen, da ich das bei späteren Updates wieder machen müßte.
Wer kann mir einen Tipp geben, was ich noch tun könnte?
Danke im Voraus und schöne Ostertage
Helge
hallo,
Server: SuSE Linux 7.2
Apache: 1.3.19
Beides ein bißchen sehr alt, da solltest du bei Gelegenheit etwas Neues aufspielen.
Fast alle Teile der Doku werden korrekt angezeigt, nur der perl-Teil will nicht. Stattdessen erhalte ich bei jeder Datei aus dem perl-Verzeichnis Fehler "404 - file not found".
Das kann so nicht korrekt sein. Die Dateien in diesem Verzeichnis sind ebensolche Dateien wie alle anderen, nämlich HTML. Mit deinem cgi-bin haben sie nichts zu tun.
Wahrscheinlich meinst du das, was du online jeweils unter "Anzeigebeispiel - so siehts aus" zu sehen bekommst. Da mußt du nur richtig lesen, daß dort auch steht: "Zum Aufruf des Scripts ist eine Internet-Verbindung erforderlich". Die Scripts, die von diesem Verweis aufgerufen werden, gehören nicht zum "Lieferumfang", die hast du ganz einfach nicht (es sei denn, du baust sie dir selber nach, was du natürlich tun kannst). Also ist die 404er-Meldung schon völlig korrekt.
Grüße aus Berlin
Christoph S.
hallo,
Server: SuSE Linux 7.2
Apache: 1.3.19Beides ein bißchen sehr alt, da solltest du bei Gelegenheit etwas Neues aufspielen.
Irgendwann mal, wenn der P166 die Grätsche macht. :-)
Fast alle Teile der Doku werden korrekt angezeigt, nur der perl-Teil will nicht. Stattdessen erhalte ich bei jeder Datei aus dem perl-Verzeichnis Fehler "404 - file not found".
Das kann so nicht korrekt sein. Die Dateien in diesem Verzeichnis sind ebensolche Dateien wie alle anderen, nämlich HTML. Mit deinem cgi-bin haben sie nichts zu tun.
Wahrscheinlich meinst du das, was du online jeweils unter "Anzeigebeispiel - so siehts aus" zu sehen bekommst. Da mußt du nur richtig lesen, daß dort auch steht: "Zum Aufruf des Scripts ist eine Internet-Verbindung erforderlich". Die Scripts, die von diesem Verweis aufgerufen werden, gehören nicht zum "Lieferumfang", die hast du ganz einfach nicht (es sei denn, du baust sie dir selber nach, was du natürlich tun kannst). Also ist die 404er-Meldung schon völlig korrekt.
Nein, das meine ich nicht.
Ich schaue mir die Sytanx-Seite an (Datei "/navigation/syntax.htm") und wähle oben "Perl" aus. Auf dieser Seite wird zu "/navigation/syntax.htm#perl" gesprungen. Egal welchen Link (bis auf die horizontal ausgerichteten Buchstaben direkt unter "Perl") ich nun anclicke, es erscheint immer besagte Fehlermeldung.
Grüße aus Berlin
Grüße aus der heimlichen Hauptstadt Deutschlands,
Helge
hallo,
Ich schaue mir die Sytanx-Seite an (Datei "/navigation/syntax.htm") und wähle oben "Perl" aus.
Das kann ich nicht ganz nachvollziehen. Bei mir ist der (offline-)Pfad "file:///tutorials/selfhtml81/navigation/syntax.htm"
Auf dieser Seite wird zu "/navigation/syntax.htm#perl" gesprungen.
Nein. Sondern zu "file:///tutorials/selfhtml81/navigation/syntax.htm#perl".
Egal welchen Link (bis auf die horizontal ausgerichteten Buchstaben direkt unter "Perl") ich nun anclicke, es erscheint immer besagte Fehlermeldung.
Das ist nicht nachvollziehbar. Bei mir gibts solche Fehler nicht, egal, auf welchem System ich bin und ob ich es über einen lokalen Webserver aufrufe oder nicht. Tut mir leid - aber ich war im Redaktionsteam auch derjenige, der genau diese Verweise auf dieser Seite gesetzt hat, ich sollte es also wirklich wissen.
Schau mal nach, ob das ZIP-Archiv, das du dir gezogen hast, nicht eventuell defekt ist. Mehr kann ich dir leider nicht sagen.
Grüße aus Berlin
Christoph S.
Ich schaue mir die Sytanx-Seite an (Datei "/navigation/syntax.htm") und wähle oben "Perl" aus.
Das kann ich nicht ganz nachvollziehen. Bei mir ist der (offline-)Pfad "file:///tutorials/selfhtml81/navigation/syntax.htm"
Du redest vom FileServer, ich vom Webserver.
URL ist "http://selfhtml.private/navigation/syntax.htm"
Und wenn ich hier jetzt z. B. das Intro der Perl-Doku anclicke, wird die URL "http://selfhtml.private/perl/intro.htm" aufgerufen. Und genau hier erhalte ich je nach Config 404 oder 403, aber niemals 200.
Gruß
Helge
hi,
Du redest vom FileServer, ich vom Webserver.
Du hast nicht richtig gelesen. Ich habe geschrieben: " egal, auf welchem System ich bin und ob ich es über einen lokalen Webserver aufrufe oder nicht"
URL ist "http://selfhtml.private/navigation/syntax.htm"
Und wenn ich hier jetzt z. B. das Intro der Perl-Doku anclicke, wird die URL "http://selfhtml.private/perl/intro.htm" aufgerufen. Und genau hier erhalte ich je nach Config 404 oder 403, aber niemals 200.
Und _genau das_ läßt sich bei mir nicht nachvollziehen bzw. nachbauen. Außerdem müßte es ja auch, wenn das ein allgemeiner Fehler in der Doku wäre, in der online-Fassung so sein. Das ist aber nicht der Fall. Andererseits gibts auf der Syntax-Seite nur wenige Verweise zu Ankern auf /perl/intro.htm.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Außerdem müßte es ja auch, wenn das ein allgemeiner Fehler in der Doku wäre, in der online-Fassung so sein.
Es geht Helge doch nicht um ein mögliches oder gar allgemeines Problem in SELFHTML, sondern um ein Problem in der lokalen VHost Konfiguration seines Apachen. Etwas, daß auch nicht auf dem SELFHTML-Servern reproduzierbar ist.
Bitte Christoph, gewöhn' Dir doch endlich mal an, etwas gründlicher zu lesen und nicht so vorschnell zu posten.
Tim
hallo,
Es geht Helge doch nicht um ein mögliches oder gar allgemeines Problem in SELFHTML, sondern um ein Problem in der lokalen VHost Konfiguration seines Apachen.
Von einem virtuellen Host hat er noch gar nichts weiter geschrieben, bis auf die kurze Erwähnung, daß es einen gibt. Das einzige, was da stimmen muß, ist das DocumentRoot, Script-Aliase oder andere Aliase für irgendwelches Perl-Zeugs sind völlig überflüssig und eher hinderlich. Es liegen ja keine Scripts darin, solange man nicht selber welche dazu erfindet.
Bitte Christoph, gewöhn' Dir doch endlich mal an, etwas gründlicher zu lesen
Ich denke, das hätte ich getan. Was schwer verständlich wäre, wäre eine Kontruktion, bei der einzig das Perl-Kapitel über einen eigenen virtuellen host angesprochen werden soll (kann man allerdings machen). Die beiden Script-Alias, die angelegt wurden, sind völlig uninteressant, da es im Perl-Kapitel ja auch nur HTML-Seiten gibt, abgesehen davon, daß sie mit einem vHost auch nichts zu tun haben und für mod_perl angelegt wurden. Ein weiterer Alias ist für /perl/ vergeben, aber auch der ist uninteressant. Das Ganze beruht auf dem Mißverständnis, daß er glaubt, ausgerechnet für das Perl-Kapitel irgendwelche Aliase erfinden zu müssen. Das ist nicht der Fall. Die Dateien in diesem Kapitel sind genausolche Dateien wie die in allen anderen Kapiteln, wenn man da mit irgendwelchen Alias- oder Script-Alias-Geschichten drauflosgeht, erreicht man das Gegenteil von dem, was gewünscht ist.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
irgendwie finde ich es erstaunlich, auf was für unterschiedliche Ergebnisse beim Lesen der Beiträge des OPs kommen. Ich skizziere Dir mal meinen Gedankengang beim Lesen seines Problems:
In seinem ersten Posting schreibt er dieses:
Er hat SELFHTML auf seinem Webserver installiert, nur Dateien aus dem Verzeichnis Perl kriegt er 404s, dies aber nicht, wenn er das Verzeichnis umbenennt. Er führt das Problem darauf zurück, daß er ein weiteres Script-Alias für /perl/ angelegt hat.
Ich schließe daraus, daß er SELFHTML offenbar im Root seines privaten Webservers installiert hat, sonst würde das ScriptAlias für /perl/ ja nicht wirksam werden.
Weiter schreibt er:
»Mit weiterhin auskommentiertem ScriptAlias habe ich in der Config zum VirtualHost ein Alias gesetzt. Alias /perl/ "/public/selfhtml/perl/"«
Aha. SELFHTML befindet sich in einem eigenen Virtual Host. Offenbar ist die ScriptAlias-Direktive von oben offenbar global, aus irgendwelchen Gründen will er die dort nicht weg und in einen eigenen VHost tun. Ich kenne seine restliche Webserverkonfiguration ja nicht. Er versucht hier mit auskommentiertem ScriptAlias herauszufinden, ob er das Verzeichnis /perl/ erst mal so zum Laufen kriegt. Wenn sein ScriptAlias auf /perl/ deaktiviert ist, ist das eigentlich unnötig, aber ich unterstelle ihm hier mal Debugging oder Rumspielen zum eigenen Verständnis. Jetzt kommt aber unerwarteterweise anstatt den erwarteten SELFHTML-Dateien ein 403, auch wenn er es mit einem umbenannten Verzeichnis macht. Und der unerwartete, unverständliche 403 ist seine eigentliche Frage.
In seinem zweiten Posting präzisiert er Dir, daß es ihm nicht um mögliche Anzeigebeispiele des Perl-Kapitels, sondern um alle Seiten des Perl-Kapitels geht, im dritten nennt er Dir die URL des Virtual Hosts, aus der sich rauslesen lässt, daß SELFHTML tatsächlich auf Root-Ebene installiert ist.
Das ist in etwa mein Gedankengang beim Lesen. Ich kapiere jetzt nicht, wie Du auf folgende Vermutungen kommen kannst.
Ich denke, das hätte ich getan. Was schwer verständlich wäre, wäre eine Kontruktion, bei der einzig das Perl-Kapitel über einen eigenen virtuellen host angesprochen werden soll (kann man allerdings machen).
Was er ja nicht tut, er hat nur einen VHost für SELFHTML unter selfhtml.private eingerichtet.
Die beiden Script-Alias, die angelegt wurden, sind völlig uninteressant, da es im Perl-Kapitel ja auch nur HTML-Seiten gibt, abgesehen davon, daß sie mit einem vHost auch nichts zu tun haben und für mod_perl angelegt wurden.
Die ScriptAliase leiten seine Aufrufe von selfhtml.private/perl/ aber eben von SELFHTMLs Perl-Teil weg zu /usr/local/httpd/cgi-bin/ - es geht nicht um irgendwelche CGI-Skripte sondern um die HTML-Dateien des Perl-Teils von SELFHTML, die bei ihm wegen des ScriptAlias natürlich nicht angezeigt werden.
Ein weiterer Alias ist für /perl/ vergeben, aber auch der ist uninteressant.
Nö. Wenn Du Dir Deinen Apachen so konfigurierst, daß SELFHTML bei Dir lokal unter http://selfhtml.christoph-schnauss.local/ liegt und Dir aus was für Gründen ein Alias oder ScriptAlias für /perl/ woanders aber eben nicht zu dem korrekten Verzeichnis im Dateisystem zeigt, ist das für Dich doch sicherlich nicht uninteressant, nicht? ;)
Das Ganze beruht auf dem Mißverständnis, daß er glaubt, ausgerechnet für das Perl-Kapitel irgendwelche Aliase erfinden zu müssen.
Ich an seiner Stelle würde einfach die ScriptAlias-Direktive auf /perl/ aus der Webserver-Konfiguration rausschmeißen oder sie zumindest in den VHost verfrachten, in dem sie gebraucht wird. Oder aber wenn er das aus was für Gründen auch immer nicht machen will und doch die Alias-Variante nutzen will, darauf achten, daß sein /public/selfhtml/perl/ auch von DocumentRoot oder <Directory> erfasst ist; das scheint mir nach meinem Schnellschuß inzwischen das Problem zu sein.
Aber ich verstehe immer noch nicht, wie Du auf Deine anderen Interpretationen kommst, Helge hatte doch relativ klar geschrieben. Ich will natürlich nicht ausschließen, daß ich gerade der Holzkopf bin, erläuterst Du mir mal Deinen Gedankengang?
Tim
hallo Tim,
In seinem ersten Posting schreibt er
Dinge, die ich so gedeutet habe, als wolle er im "perl"-Kapitel irgendwelche Scripts für die Anzeigebespiele ausführen lassen. Diese Scripts gibt es auf dem SELF-Server, aber sie gehören nicht zum Inhalt des ZIP-Archivs. Daher habe ich _zunächst_ nur darauf Bezug genommen.
In seinem zweiten Posting präzisiert er Dir, daß es ihm nicht um mögliche Anzeigebeispiele des Perl-Kapitels, sondern um alle Seiten des Perl-Kapitels geht
Ja, aber mit Pfaden, die nicht korrekt sein können. Ich habe gesagt, daß ich das nicht nachvollziehen kann und auf den offline-Pfad (ohne Webserver) verwiesen, mit dem sich herausfinden läßt, ob die Dateien vorhanden sind - sind sie tatsächlich nicht vorhanden, wärs eine fehlerhafte ZIP gewesen. Und auch das habe ich angesprochen. Sind sie vorhanden, muß man sich die Konstruktion des vHost genauer ankucken. Und so weit waren wir noch nicht.
im dritten nennt er Dir die URL des Virtual Hosts, aus der sich rauslesen lässt, daß SELFHTML tatsächlich auf Root-Ebene installiert ist.
Aber nicht, ob mod_perl überhaupt vorhanden ist. Es gehört nicht zum Lieferumfang des Apache, man muß es gesondert downloaden. Du hast recht, daß ich danach hätte fragen sollen (obwohl das wahrscheinlich wegen der Angaben in seinem ersten posting der Fall ist). Die Script-Alias können nur bei geladenem Modul mod_perl überhaupt wirksam werden wegen des Containers, in den sie eingeschlossen sind, der Alias "/perl/" hat eine andere Wirkung, die aber bei der angegebenen URL uninteressant sein müßte. Daher habe ich nochmal an beide Aufrufmöglichkeiten (mit und ohne Webserver) erinnert.
Grüße aus Berlin
Christoph S.
Hallo Helge,
Alias /perl/ "/public/selfhtml/perle/"
In der Dokumentation zum Apachen 1.3 steht zur Direktive Alias folgender Zusatz:
»Note that if you include a trailing / on the url-path then the server will require a trailing / in order to expand the alias. That is, if you use Alias /icons/ /usr/local/apache/icons/ then the url /icons will not be aliased.«
Das heißt, wenn man an ein Verzeichnis hinten einen Schrägstrich dran packt, der Alias nicht wirksam wird. Ich kann mir gut vorstellen, daß das der Grund für Deine 403s ist.
Tim
hallo Tim,
Das heißt, wenn man an ein Verzeichnis hinten einen Schrägstrich dran packt, der Alias nicht wirksam wird.
Nein, das heißt es nicht. Es betrifft den Aufruf in der Adreßzeile eines Browsers. Wenn es den "trailing slash" im Alias gibt, muß auch ein Verzeichnis mit so einem Slash aufgerufen werden. Aber wenn du nicht ein Verzeichnis, sondern eine ganz bestimmte Datei mit ihrem Namen aufrufst, ist das Ganze uninteressant.
Apache würde im übrigen gar nicht erst starten, wenn der Alias selbst fehlkonfiguriert wäre (da bin ich mir allerdings bei einem so alten Apache nicht mehr ganz sicher).
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Nein, das heißt es nicht. Es betrifft den Aufruf in der Adreßzeile eines Browsers.
Das stimmt, da war ich zu vorschnell. Tschuldigung.
Apache würde im übrigen gar nicht erst starten, wenn der Alias selbst fehlkonfiguriert wäre (da bin ich mir allerdings bei einem so alten Apache nicht mehr ganz sicher).
Ich habe das gerade mal mit dem von Apple mitgelieferten Apache 1.3.33 ausprobiert - er startet problemlos, schreibt nur entsprechende Fehlermeldungen ins error.log.
Tja, woran kann Helges Problem nun liegen? Ich würde ja anhand der 403 vermuten, daß sein Verzeichnis /public/selfhtml/perl/ nicht von DocumentRoot oder einem <Directory> abgedeckt wird. Aber darüber hat er nichts geschrieben und muß das selber nachgucken.
Tim
hallo Tim,
Apache würde im übrigen gar nicht erst starten, wenn der Alias selbst fehlkonfiguriert wäre
Ich habe das gerade mal mit dem von Apple mitgelieferten Apache 1.3.33 ausprobiert - er startet problemlos, schreibt nur entsprechende Fehlermeldungen ins error.log.
Ahja, ich habe grade keinen 1.3.x am Laufen. 2.0.53 unter Windows startet (bei mir) nicht mit fehlerhafter Syntax. Aber wenns einen log-Eintrag gibt, ist ja auch gut.
Tja, woran kann Helges Problem nun liegen? Ich würde ja anhand der 403 vermuten, daß sein Verzeichnis /public/selfhtml/perl/ nicht von DocumentRoot oder einem <Directory> abgedeckt wird. Aber darüber hat er nichts geschrieben und muß das selber nachgucken.
/public/selfhtml ist schon ein gut gewählter Ort für einen virtuellen Host. Nur bedarf es da keinerlei Basteleien mit irgendwelchen Alias, die eigens für "perl" erfunden werden. Man könnte einen Alias "selfhtml" brauchen, wenn _kein_ virtueller Host eingerichtet ist und /public/selfhtml _nicht_ innerhalb des DocumentRoot liegt.
Darüber hinaus sind die beiden Script-Alias, die im OP genannt wurden, in einen Container
<IfModule mod_perl.c>
gepackt worden und verweisen auf ein cgi-bin. mod_perl ist aber nicht das, was man _zwingend_ für die Ausführung von CGI-Scripts benötigt. Und die Aussage "Aus diesem Grund werden alle Dateien, die ich aus dem perl-Verzeichnis sehen möchte, im benannten cgi-bin-Verzeichnis gesucht" zeigt bzw. läßt vermuten, daß er sich der Problematik eines solchen Alias bewußt sein könnte - diese Aussage _kann_ für einen Alias "/perl/ '/usr/local/httpd/cgi-bin/'" zutreffend sein. Der Versuch, ein
Alias "/perl/ '/public/selfhtml/perl/'"
einzurichten, hätte dann eigentlich kein Problem darstellen dürfen, obwohl auch dieser Alias völlig überflüssig ist. Da die Alias-Konstruktion in der im OP genannten Form aber für den 404er eigentlich nicht verantwortlich sein dürfte, bin ich nicht sofort darauf eingegangen.
Das Ganze beruht auf dem grundlegenden Mißverständnis, daß für ein Verzeichnis, das "perl" heißt, auch noch irgendwas konfiguriert werden müßte. Das ist jedoch nicht der Fall, solange dort keine ausführbaren Scripts abgelegt werden sollen. Und SELFHTML enthält keine ausführbaren Script.
Wichtig ist allerdings der Hinweis darauf, daß man ins log schauen sollte. Das habe ich versäumt, anzugeben.
Als "Kontrolle" wäre es dann noch durchaus zulässig und wünschenswert, nachzuschauen, ob dieselben mißlichen Umstände auch ohne einen Aufruf über den Webserver vorkommen.
Grüße aus Berlin
Christoph S.
hallo Tim,
Apache würde im übrigen gar nicht erst starten, wenn der Alias selbst fehlkonfiguriert wäre
Ich habe das gerade mal mit dem von Apple mitgelieferten Apache 1.3.33 ausprobiert - er startet problemlos, schreibt nur entsprechende Fehlermeldungen ins error.log.Ahja, ich habe grade keinen 1.3.x am Laufen. 2.0.53 unter Windows startet (bei mir) nicht mit fehlerhafter Syntax. Aber wenns einen log-Eintrag gibt, ist ja auch gut.
Mein Apache startet nicht, wenn der Alias falsch ist. Von daher kann ich das eigentlich ausschließen.
Tja, woran kann Helges Problem nun liegen? Ich würde ja anhand der 403 vermuten, daß sein Verzeichnis /public/selfhtml/perl/ nicht von DocumentRoot oder einem <Directory> abgedeckt wird. Aber darüber hat er nichts geschrieben und muß das selber nachgucken.
/public/selfhtml ist schon ein gut gewählter Ort für einen virtuellen Host.
Die Config für meinen selfhtml-Host sieht so aus:
<VirtualHost 192.168.0.200>
ServerName selfhtml.private
ServerAlias selfhtml
DocumentRoot /public/selfhtml
SetEnvIf Host selfhtml.private selfhtml_host_self
CustomLog /var/log/httpd/loghost_selfhtml common env=selfhtml_host_self
</VirtualHost>
Bis auf das Perl-Verzeichnis funktionieren damit alle Dokumente.
Der Perl-Alias steht in der httpd.conf, ist also für alle VirtualHosts gleich.
Das Ganze beruht auf dem grundlegenden Mißverständnis, daß für ein Verzeichnis, das "perl" heißt, auch noch irgendwas konfiguriert werden müßte. Das ist jedoch nicht der Fall, solange dort keine ausführbaren Scripts abgelegt werden sollen. Und SELFHTML enthält keine ausführbaren Script.
Ich ging davon aus, daß ich die Doku out-of-the-box ans Laufen bekäme. Da nur der Perl-Teil nicht funktioniert, ist bei mir wohl irgendetwas falsch konfiguriert.
Das, was aus meiner Sicht damit zusammenhängen könnte, habe ich kontrolliert. Aber offensichtlich habe ich etwas übersehen, und jetzt bräuchte ich nur einen Tipp, wo ich suchen muß.
Wichtig ist allerdings der Hinweis darauf, daß man ins log schauen sollte. Das habe ich versäumt, anzugeben.
[Sun Mar 27 11:16:54 2005] [error] access to /public/selfhtml/perl/intro.htm failed for 192.168.0.2, reason: file permission deny server execution
Als "Kontrolle" wäre es dann noch durchaus zulässig und wünschenswert, nachzuschauen, ob dieselben mißlichen Umstände auch ohne einen Aufruf über den Webserver vorkommen.
Per smb eingebunden und im TotalCommander ausgewählt kann ich die Doku einsehen.
Gruß
Helge
Hallo zusammen,
ich habe mich jetzt nochmal mit der httpd.conf beschäftigt und habe dabei den Knackpunkt gefunden.
Ich habe jetzt diese Zeile auskommentiert:
ScriptAlias /perl/ "/usr/local/httpd/cgi-bin/"
Weiter unten in der httpd.conf steht dann noch folgendes, was ich zuerst übersehen hatte:
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
</Location>
Nachdem ich diese Zeilen ebenfalls auskommentiert habe, komme ich per WebServer an die Perl-Doko heran.
Offensichtlich war der Location-Block für den 403 verantwortlich, da Apache versucht hatte, die Doku auszuführen.
Ich bedanke mich für das Interesse und die Hilfestellungen.
Gruß aus Köln
Helge