virtuelle Webserver (Apache 2.0)

[Eric]

Guten Morgen an alle im Forum,

ich habe ein Problem mit dem DocumentRoot bzw. Access(Apache 2.0).
Ich habe meine namensbasierten virtuellen Webserver wie folgt in die httpd.conf eingetragen:
:
:
:
NameVirtualHost 192.168.10.2

<VirtualHost 192.168.10.2>
#    ServerAdmin [e-mail]
     DocumentRoot /www/net/eric_php
     ServerName www.eric-php.de
#    ErrorLog logs/dummy-host.example.com-error_log
#    CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>

<VirtualHost 192.168.10.2>
#    ServerAdmin [e-mail]
     DocumentRoot /www/net/inet
     ServerName www.inet.de
#    ErrorLog logs/dummy-host.example.com-error_log
#    CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>
:
:
:

Weiterhin habe ich die ServerNamen im DNS, sowie in die Datei "hosts" eingetragen...

Nun mein Problem:
Gebe ich im Browser www.inet.de ein, verbietet er den Zugriff auf den Server (Forbidden: You don`t have permission to access on this server). Das komische ist, dass bei www.eric-php.de alles funktioniert, obwohl beide DocumentRoot auf den Ordner "net" verweisen.

Ich komme an dieser Stelle nicht weiter...

Vielen Dank im Voraus...

Gruß Eric

[André Laugks]

Hallo!

<VirtualHost 192.168.10.2>
     DocumentRoot /www/net/eric_php
</VirtualHost>

<VirtualHost 192.168.10.2>
     DocumentRoot /www/net/inet
</VirtualHost>

Das komische ist, dass bei www.eric-php.de alles funktioniert, obwohl beide DocumentRoot auf den Ordner "net" verweisen.

Sicher? Einmal ist das Document-Root /www/net/eric_php und das andere mal /www/net/inet.

MfG, André Laugks

[Eric]

Hi,

Ist schon richtig, dass es nicht genau dasselbe Verzeichnis ist, aber beide ("eric_php" und "inet")liegen beide im Ordner "net".
Ich habe aber in keinster Weise irgendwelche Berechtigungen vergeben und trotzdem wird der Zugriff verboten...

Trotzdem Danke

Gruß Eric

[André Laugks]

Hallo!

Ist schon richtig, dass es nicht genau dasselbe Verzeichnis ist, aber beide ("eric_php" und "inet")liegen beide im Ordner "net".
Ich habe aber in keinster Weise irgendwelche Berechtigungen vergeben und trotzdem wird der Zugriff verboten...

Ja, die liegen beide in net, aber beide habe ein unterschiedliches Document-Root. Liegen den in  "/www/net/inet/" Seiten bzw. Dateien. Liegt dort eine index-Datei?

MfG, André Laugks

[Eric]

Ja, die liegen beide in net, aber beide habe ein unterschiedliches Document-Root. Liegen den in  "/www/net/inet/" Seiten bzw. Dateien. Liegt dort eine index-Datei?

Also im Ordner "inet" liegen keine Index-Dateien.

Gruß Erri

[André Laugks]

Hallo!

Also im Ordner "inet" liegen keine Index-Dateien.

Dann pack da mal was rein...

MfG, André Laugks

[André Laugks]

Dann pack da mal was rein...

Eine index.html oder index.php. Kommt aber auch drauf an, welche Datei(en) Du bei DirectoryIndex angegeben hast.

MfG, André Laugks

[Eric]

Dann pack da mal was rein...

Ich hab zwar was reingepackt, aber es funtzt trotzdem nicht

Eine index.html oder index.php. Kommt aber auch drauf an, welche Datei(en) Du bei DirectoryIndex angegeben hast.

Ich habe .html und .php erlaubt

[Sönke Tesch]

Ja, die liegen beide in net, aber beide habe ein unterschiedliches Document-Root. Liegen den in  "/www/net/inet/" Seiten bzw. Dateien. Liegt dort eine index-Datei?

Also im Ordner "inet" liegen keine Index-Dateien.

Der Server kann ein Verzeichnis nicht anzeigen, wenn Du es ihm nicht erlaubst (options +indexes).

Weiterhin hat es absolut überhaupt nichts zu sagen, daß beide DocumentRoot-Verzeichnisse unterhalb von /www/net/ liegen. Sie liegen genauso gut unterhalb von / - und das ist standardmäßig gesperrt. Prüfe also, ob Du /inet oder alternativ /net explizit freigegeben hast.

Gruß,
  soenk.e

[Eric]

Hi soenk.e

vielen Dank

Der Server kann ein Verzeichnis nicht anzeigen, wenn Du es ihm nicht erlaubst (options +indexes).

Wo finde ich (options +indexes)?
Ebenfalls in der httpd.conf?

Gruß Erri

[Christoph Schnauß]

hallo Eric,

Wo finde ich (options +indexes)?

Lies dir bitte mal http://httpd.apache.org/docs-2.0/mod/core.html#options durch.

Ebenfalls in der httpd.conf?

In den verschiedenen Containern innerhalb der httpd.conf können "Options" notiert werden.

Grüße aus Berlin

Christoph S.

[Eric]

Hi Christoph,

vielen Dank für deine Hilfe..

Wo finde ich (options +indexes)?
Lies dir bitte mal http://httpd.apache.org/docs-2.0/mod/core.html#options durch.

Dies hat funktioniert...
Ich hab folgendes geändert:
von...

<Directory />
    Options FollowSymLinks
    AllowOverride all
</Directory>

auf...
<Directory />
    Options All
    AllowOverride all
</Directory>

Gruß Eric

[Christoph Schnauß]

hallo Eric,

Dies hat funktioniert...

Gut, das ist ein Anfang.

<Directory />
    Options All
    AllowOverride all
</Directory>

Mit "AllowOverride" solltest du dich nochmals beschäftigen. Man muß sehr gute Gründe haben, wenn man hier "all" einsetzen möchte, normalerweise sollte das auf "none" stehen, sonst kann es sehr unangenehme Überraschungen geben.

Grüße aus Berlin

Christoph S.

[Eric]

Hi Christoph,

Mit "AllowOverride" solltest du dich nochmals beschäftigen. Man muß sehr gute Gründe haben, wenn man hier "all" einsetzen möchte, normalerweise sollte das auf "none" stehen, sonst kann es sehr unangenehme Überraschungen geben.

Die Option "AllowOverride" muss doch aber bei auf "all" gesetzt sein, weil ich, wenn mein Server mal funtzt :-), .htaccess-Dateien verwende und diese beachtet werden sollen

Gruß Eric

[Christoph Schnauß]

hallo Eric,

Die Option "AllowOverride" muss doch aber bei auf "all" gesetzt sein, weil ich, wenn mein Server mal funtzt :-), .htaccess-Dateien verwende und diese beachtet werden sollen

Richtig, der Einsatz von .htacces ist ein solcher "sehr guter Grund", wie ich gesagt habe.
Aber <Directory>-Container gibt es nicht nur für virtuelle hosts.

Es hängt ein bißchen davon ab, was dein Apache können soll und wie er eingesetzt wird. Dient er dir als "produktiver Server", auf dessen virtuelle hosts auch "von außen" zugegriffen werden soll, ist es richtig, die Möglichkeit von .htacces-Dateien vorzusehen.
Willst du ihn aber "bloß" lokal verwenden, um ein paar Scripts vor dem Hochladen durchzutesten, sind .htaccess in der Regel nicht nötig.

Grüße aus Berlin

Christoph S.

[Michael Schröpl]

Hi Eric,

Die Option "AllowOverride" muss doch aber bei auf "all" gesetzt sein, weil ich, wenn mein Server mal funtzt :-), .htaccess-Dateien verwende und diese beachtet werden sollen

das ist so pauschal nicht richtig.

Lies http://aktuell.de.selfhtml.org/artikel/server/htaccess-faq/#a6
bzw. http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride
und überlege Dir _sehr_ genau, wieviel Du freischalten willst und was nicht.

Viele Grüße
      Michael

[Sönke Tesch]

<Directory />
    Options FollowSymLinks
    AllowOverride all
</Directory>

Bitte tu' Dir selbst einen Gefallen und verwende Freigaben nur dort, wo sie auch gebraucht werden. Oder möchtest Du wirklich Deinen gesamten Rechner dem Rest der Welt zur Verfügung stellen? Nein? Dann benutze "<directory /www/net/inet/>" und dergleichen.

Gruß,
  soenk.e

[Christoph Schnauß]

hallo Sönke,

Bitte tu' Dir selbst einen Gefallen und verwende Freigaben nur dort, wo sie auch gebraucht werden.

Ich nehme an, daß er hier keinen Container innerhalb eines virtual host meint  -  falls doch, hättest du vollkommen recht.

Aber für den "main server" gilt durchaus:

First, we configure the "default" to be a very restrictive set of

features.

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>
Und _da_ ist dann "AllowOverride" zwingend auf "none" zu aetzen, sonst wirds ja nix mit "very restrictive".

benutze "<directory /www/net/inet/>" und dergleichen.

Wenn lediglich ein paar Optionen festgelegt werden sollen, kann man das auch in <VirtualHost *> selbst notieren und braucht keinen Container dafür.

Grüße aus Berlin

Christoph S.

[Michael Schröpl]

Hallo Christoph,

Aber für den "main server" gilt durchaus:

First, we configure the "default" to be a very restrictive set of

features.

das Problem ist, daß die nachfolgende Konfiguration zwar sinnvoll ist, aber nicht mit dem Kommentar "restriktiv" übereinstimmt.

<Directory />
    Options FollowSymLinks

Dies ist ein "Performance-Booster".
Er bewirkt, daß Apache nicht prüfen muß, ob ein Eintrag (Datei, Verzeichnis, ...) ein symbolic link ist. Dadurch wäre sonst jeder Zugriff langsamer geworden.

AllowOverride None

Das ist ebenfalls ein "Performance-Booster".
Er deaktiviert die Verwendung von .htaccess-Dateien im gesamten Verzeichnisbaum (diese muß also für Teilbäume wieder explizit freigeschaltet werden) und erspart dem Apache, bei jedem Zugriff sämtliche übergeordneten Verzeichnisse ab "/" nach solchen Dateien zu durchsuchen (denn der Defaultwert dieser Direktive ist "All"!).

Nichts von beidem macht die Sache "restriktiver" (im Sinn von Sicherheit). Insbesondere würde ein Mapping von "/" auf einen URL (an anderer Stelle) dadurch in keinster Weise verhindert.

Viele Grüße
      Michael

[Christoph Schnauß]

hallo Michael,

Options FollowSymLinks
Dies ist ein "Performance-Booster".
Er bewirkt, daß Apache nicht prüfen muß, ob ein Eintrag (Datei, Verzeichnis, ...) ein symbolic link ist. Dadurch wäre sonst jeder Zugriff langsamer geworden.

Das ist mir bekannt. Ich habe das bisher immer als Begründung verstanden, eventuell in <VirtualHost *> dann eben "-FollowSymLinks" zu notieren  -  bei Bedarf.
Im übrigen sind Konfigurationen für <Directory /> bei Windows-Installationen unwirksam (nur zur Vollständigkeit, weil die meisten Apache-Anfragen darauf abzielen), was oft übersehen wird.

AllowOverride None
Das ist ebenfalls ein "Performance-Booster".
Er deaktiviert die Verwendung von .htaccess-Dateien im gesamten Verzeichnisbaum (diese muß also für Teilbäume wieder explizit freigeschaltet werden) und erspart dem Apache, bei jedem Zugriff sämtliche übergeordneten Verzeichnisse ab "/" nach solchen Dateien zu durchsuchen (denn der Defaultwert dieser Direktive ist "All"!).

Wegen dieses Defaultwertes wird ja hier "none" vorgeschlagen. Wenn hier bereits "all" steht, braucht in <VirtualHost *> gar kein "AllowOverride" mehr notiert werden  -  es sei denn, man möchte .htaccess mit "none" wieder untersagen.
Man kann natürlich, wenn man mit seinem Apache etwas Anderes vorhat und einigermaßen weiß, was man tut, <Directory /> fast beliebig konfigurieren und noch wesentlich mehr Einträge vornehmen. Für einen lokalen "Testserver" ohne virtuelle Hosts kann das durchaus Sinn machen.

Nichts von beidem macht die Sache "restriktiver" (im Sinn von Sicherheit). Insbesondere würde ein Mapping von "/" auf einen URL (an anderer Stelle) dadurch in keinster Weise verhindert.

Ich bin schon ewig lange am Herumknabbern, wie dieses "restrictive" hier zu verstehen ist. "Im Sinn von Sicherheit" ist es gewiß nicht zu interpretieren, der wichtigste Effekt besteht im möglichen Performancegewinn, so weit stimmen wir völlig überein.

Grüße aus Berlin

Christoph S.

[Henner]

Im übrigen sind Konfigurationen für <Directory /> bei Windows-Installationen unwirksam (nur zur Vollständigkeit, weil die meisten Apache-Anfragen darauf abzielen), was oft übersehen wird.

Verbreite bitte keinen Unsinn. Danke.

H.

[Christoph Schnauß]

hallo Henner,

Verbreite bitte keinen Unsinn.

Es wäre aufschlußreicher, wenn du sagen würdest, was dir nun grade als "Unsinn" erschienen ist, und vielleicht  -  damit ich es verstehe  -  warum du das so bezeichnest.

Grüße aus Berlin

Christoph S.

[Henner]

Verbreite bitte keinen Unsinn.
Es wäre aufschlußreicher, wenn du sagen würdest, was dir nun grade als "Unsinn" erschienen ist,

Das hast du erfolgreich aus dem Zitat gestrichen. Soll ich es dir nochmal vorlesen? Gut:

Im übrigen sind Konfigurationen für <Directory /> bei Windows-Installationen unwirksam (nur zur Vollständigkeit, weil die meisten Apache-Anfragen darauf abzielen), was oft übersehen wird.

und vielleicht  -  damit ich es verstehe  -  warum du das so bezeichnest.

Es ist falsch. War das hinreichend verständlich?

H.

[Christoph Schnauß]

hallo Henner,

Ich mache mal was, was ich sonst nie tun würde:

Verbreite bitte keinen Unsinn.
Es wäre aufschlußreicher, wenn du sagen würdest, was dir nun grade als "Unsinn" erschienen ist,
Das hast du erfolgreich aus dem Zitat gestrichen. Soll ich es dir nochmal vorlesen? Gut:

Im übrigen sind Konfigurationen für <Directory /> bei Windows-Installationen unwirksam (nur zur Vollständigkeit, weil die meisten Apache-Anfragen darauf abzielen), was oft übersehen wird.
und vielleicht  -  damit ich es verstehe  -  warum du das so bezeichnest.
Es ist falsch. War das hinreichend verständlich?

Nein.

Es gibt gelegentlich Gründe, wenn ich etwas aussage. Möchtest du diese Gründe ebenfalls vorgelesen bekommen?

Grüße aus Berlin

Christoph S.

[Henner]

Es gibt gelegentlich Gründe, wenn ich etwas aussage. Möchtest du diese Gründe ebenfalls vorgelesen bekommen?

Lieber nicht. Es reicht, wenn du aufhörst, bewusst Falschinformationen zu verbreiten.

HTH & HAND

H.

[Christoph Schnauß]

okok, Henner,

Es reicht, wenn du aufhörst, bewusst Falschinformationen zu verbreiten.

Dann erkläre doch mal schnell, wo du auf einem Windows-System ein Verzeichnis / findest.

Grüße aus Berlin

Christoph S.

[Henner]

Dann erkläre doch mal schnell, wo du auf einem Windows-System ein Verzeichnis / findest.

Ich glaube, das bringt nichts. Die Frage zeigt, dass du das Problem nicht im Ansatz begriffen hast. Ich erkläre es mal lieber langsam:

(1) Die Antwort auf deine Frage ist uninteressant. Es gibt z.B. auch kein Verzeichnis "C:/Programme/Apache Group/" unter Windows. Klingelts langsam? Nein? Macht nichts, es geht noch weiter:

(2) Was passiert also? Die Verzeichnisnamen werden vom Apache zunächst mal _interpretiert_ und dann bei Bedarf in einen echten Pfad oder Teile davon umgewandelt. Ist das verständlich? Wenn ja, gehts weiter mit:

(3) Was folgern wir daraus? Eine Pfadangabe, wie etwa bei <Directory /> wird _interpretiert_. Und zwar in diesem speziellen Falle, dass sie auf alle Dateinamen matcht, wie unter Unix auch.

Und was lernen wir daraus? Du solltest zumindest die Sachen mal ausprobieren, die du postest. Falschinformationen zu verbreiten, passiert hin und wieder. Wenn man den Fehler aber mitgeteilt bekommt und danach bewusst darauf besteht, die Fehlinformation weiterzupflegen und sie nicht einmal zu überdenken, ist das einfach nur dumm.

H.

[Christoph Schnauß]

hallo,

Dann erkläre doch mal schnell, wo du auf einem Windows-System ein Verzeichnis / findest.
Ich glaube, das bringt nichts.

Was du glaubst, ist weniger von Interesse.

Die Frage zeigt, dass du das Problem nicht im Ansatz begriffen hast.

Richtig. Ich habe auch nicht ansatzweise begriffen, was dir hier plötzlich als Problem erscheint.

(1) Die Antwort auf deine Frage ist uninteressant.

Vielleicht für dich. Wenn ich eine Frage stelle, bin ich schon daran interessiert, eine Antwort zu bekommen.

Es gibt z.B. auch kein Verzeichnis "C:/Programme/Apache Group/" unter Windows.

Bei mir tatsächlich nicht, bei mir gibt es _überhaupt_ kein Verzeichnis "C:\Programme". Aber die Apache-Dokumentation führt einen solchen Verzeichnisnamen ganz unbekümmert auf, zum Beispiel in http://httpd.apache.org/docs-2.0/platform/windows.html. Ich bin überzeugt davon, daß die Apache Group selbst keine fehlerhaften Angaben in ihre Dokumentation aufnimmt.

(3) Eine Pfadangabe, wie etwa bei <Directory /> wird _interpretiert_.

Das ist richtig.

Und zwar in diesem speziellen Falle, dass sie auf alle Dateinamen matcht, wie unter Unix auch.

Und das ist in dieser Form nicht korrekt. Unter UNIX ist / das Wurzelverzeichnis, root. Ein "root" in vergleichbarem Sinn existiert für Windows-Systeme nicht.

Und was lernen wir daraus? Du solltest zumindest die Sachen mal ausprobieren, die du postest. Falschinformationen zu verbreiten, passiert hin und wieder. Wenn man den Fehler aber mitgeteilt bekommt und danach bewusst darauf besteht, die Fehlinformation weiterzupflegen und sie nicht einmal zu überdenken, ist das einfach nur dumm.

Diese Aussage halte ich im Augenblick eher für etwas, was du überdenken solltest. Der Apache beschäftigt mich schon einige Jahre  -  viel Zeit und Gelegenheit, tatsächlich auszuprobieren, wovon ich gelegentlich rede.

Grüße aus Berlin

Christoph S.

[Henner]

Dann erkläre doch mal schnell, wo du auf einem Windows-System ein Verzeichnis / findest.
Ich glaube, das bringt nichts.
Was du glaubst, ist weniger von Interesse.

Aha, gut. Ich dachte, es interessierte dich.

Die Frage zeigt, dass du das Problem nicht im Ansatz begriffen hast.
Richtig.

Danke.

Ich habe auch nicht ansatzweise begriffen, was dir hier plötzlich als Problem erscheint.

Das auch :-(

(1) Die Antwort auf deine Frage ist uninteressant.
Vielleicht für dich. Wenn ich eine Frage stelle, bin ich schon daran interessiert, eine Antwort zu bekommen.

Hast du ja auch bekommen ...

Es gibt z.B. auch kein Verzeichnis "C:/Programme/Apache Group/" unter Windows.
Bei mir tatsächlich nicht, bei mir gibt es _überhaupt_ kein Verzeichnis "C:\Programme".

Vergleiche mal die Richtung der Schrägstriche, dann merkst du vielleicht, dass deine Antwort mit dem Sinn meiner Aussage nicht viel zu tun hat.

Aber die Apache-Dokumentation führt einen solchen Verzeichnisnamen ganz unbekümmert auf, zum Beispiel in http://httpd.apache.org/docs-2.0/platform/windows.html. Ich bin überzeugt davon, daß die Apache Group selbst keine fehlerhaften Angaben in ihre Dokumentation aufnimmt.

Auf der angegebenen Seite findet sich kein einziges Beispiel für Angaben in einer Konfigurationsdatei, bei dem Pfade mit Backslashes verwendet werden. Was willst du mir also sagen?

(3) Eine Pfadangabe, wie etwa bei <Directory /> wird _interpretiert_.
Das ist richtig.

Na wenigstens etwas.

Und zwar in diesem speziellen Falle, dass sie auf alle Dateinamen matcht, wie unter Unix auch.
Und das ist in dieser Form nicht korrekt.

Das ist eine offensichtliche Lüge. Jeder kann ausprobieren, dass diese deine Aussage nicht stimmt, du auch. Warum tust du es nicht einfach mal?

Unter UNIX ist / das Wurzelverzeichnis, root. Ein "root" in vergleichbarem Sinn existiert für Windows-Systeme nicht.

Das hatten wir schon festgestellt. Und ebenso, dass es uninteressant ist, weil die Pfade von Windows gar nicht interpretiert werden, sondern _vom Apache_. Und der weiss was damit anzufangen.

Der Apache beschäftigt mich schon einige Jahre  -  viel Zeit und Gelegenheit, tatsächlich auszuprobieren, wovon ich gelegentlich rede.

Schade um die schöne Zeit. Vielleicht solltest du dich mal mit dem Apache beschäftigen und nicht umgekehrt.

H.

[Christoph Schnauß]

hallo,

Es gibt z.B. auch kein Verzeichnis "C:/Programme/Apache Group/" unter Windows.
Bei mir tatsächlich nicht, bei mir gibt es _überhaupt_ kein Verzeichnis "C:\Programme".
Vergleiche mal die Richtung der Schrägstriche

Du sprichst explizit von "Verzeichnis ... unter Windows", und dafür sind Backslashes zwingend anzugeben. Ich war großmütig genug, darüber hinwegzusehen, daß du dich offenkundig vertippt hattest und habe lediglich in meiner Antwort die korrekte Schreibweise mit Backslashes _unter Windows_ verwendet. Daß der Backslash _in der httpd.conf_ für Pfadangaben nicht verwendet werden darf, steht doch nun wirklich außer Frage.

Auf der angegebenen Seite findet sich kein einziges Beispiel für Angaben in einer Konfigurationsdatei

Dir ging es eben noch um ein "Verzeichnis unter Windows", und jetzt wechselst du zu einer gänzlich anderen Sache und sprichst plötzlich von Backslashes in einer Konfigurationsdatei. Die Angabe für ein Verzeichnis "Apache Group" gibt es an der angegebenen Stelle sehr wohl.

Und zwar in diesem speziellen Falle, dass sie auf alle Dateinamen matcht, wie unter Unix auch.
Und das ist in dieser Form nicht korrekt.
Das ist eine offensichtliche Lüge.

Achte auf deine Wortwahl.

Jeder kann ausprobieren, dass diese deine Aussage nicht stimmt, du auch.

Jeder dürfte nachvollziehen können, daß meine Aussage "in dieser Form nicht korrekt" zutrifft.

Falls du allerdings auf das anspielst, was mit 'If the filenames you specify for many of the server's control files begin with "/" (or "drive:/" for Win32), the server will use that explicit path. If the filenames do *not* begin with "/", the value of ServerRoot is prepended -- so "logs/foo.log" with ServerRoot set to "D:/Apache" will be interpreted by the server as "D:/Apache/logs/foo.log"' beschrieben wird, hättest du das ruhig auch so angeben können.

Unter UNIX ist / das Wurzelverzeichnis, root. Ein "root" in vergleichbarem Sinn existiert für Windows-Systeme nicht.
Das hatten wir schon festgestellt. Und ebenso, dass es uninteressant ist

Daß dies uninteressant sei, hattest du festgestellt, ich nicht.

weil die Pfade von Windows gar nicht interpretiert werden

Windows "interpretiert" keine Pfade, sondern befolgt sie, falls sie korrekt angegeben werden.

sondern _vom Apache_. Und der weiss was damit anzufangen.

Ohne die Kenntnis einiger wichtiger Pfade würde er gar nicht starten. Daß er aber auf einem Windows-Rechner kein root-Verzeichnis "/" finden _kann_, wohl aber z.B. "C:/", war meine Aussage, womit wir wieder beim Anfang angekommen wären.
Worüber streitest du eigentlich? Und wo findest du eine "bewußte Falschaussage"?

Grüße aus Berlin

Christoph S.

[Henner]

Es gibt z.B. auch kein Verzeichnis "C:/Programme/Apache Group/" unter Windows.
Bei mir tatsächlich nicht, bei mir gibt es _überhaupt_ kein Verzeichnis "C:\Programme".
Vergleiche mal die Richtung der Schrägstriche
Du sprichst explizit von "Verzeichnis ... unter Windows",

Christoph, du scheinst gerade den Faden zu verlieren. Ich erkläre dir nochmal den Ablauf:

(1) du behauptest, <Directory /> ... </Directory> hat unter Windows keinen Effekt.

(2) Ich widerspreche, dass das Unsinn sei.

(3) diverses Blablah.

(4) Du fragst mich, wo denn unter Windows ein Pfad "/" zu finden sei.

*Wer* bitte hat explizit von Windows-Pfaden gesprochen?

Und wo findest du eine "bewußte Falschaussage"?

(1) du behauptest, <Directory /> ... </Directory> hat unter Windows keinen Effekt.

Wenn du nicht in der Lage bist, einer Diskussion zu folgen, war es wahrscheinlich keine bewusste Falschaussage. Die Lüge nehme ich demnach zurück und beantrage dafür eine Merkbefreiung für dich.

H.

[Michael Schröpl]

Hallo Christoph,

Unter UNIX ist / das Wurzelverzeichnis, root. Ein "root" in vergleichbarem Sinn existiert für Windows-Systeme nicht.
Das hatten wir schon festgestellt. Und ebenso, dass es uninteressant ist
Daß dies uninteressant sei, hattest du festgestellt, ich nicht.

dann hole dies sofort nach.

Mache Dir eine Kopie Deiner httpd.conf unter Windows, entferne sämtliche Laufwerksbuchstaben, speichere sie und starte mit dieser Datei den Apache neu.

Vermutlich wirst Du nach wenigen Minuten begriffen haben, wieso es egal ist, daß es unter Windows nicht _ein_ "Root-Verzeichnis" gibt (sondern eines pro Laufwerk) und was der Apache aus solchen Pfaden macht (nämlich das Naheliegende).

Probiere es aus, statt auf Deiner falschen Aussage zu beharren. Die Apache Group ist weitaus weniger dumm, als Du ihr unterstellst.

Viele Grüße
      Michael

[Christoph Schnauß]

hi Michael,

Mache Dir eine Kopie Deiner httpd.conf unter Windows, entferne sämtliche Laufwerksbuchstaben, speichere sie und starte mit dieser Datei den Apache neu.

Ich kenne den möglichen Effekt, den du wohl meinst (funktioniert bloß bei mir nicht). Für mich selbst (was für andere nicht im selben Maß gelten muß) ist es sinnvoller, die Laufwerksbuchstaben beizubehalten, da ServerRoot, DocumentRoot und virtuelle hosts auf jeweils unterschiedlichen Partitionen bzw. Platten liegen. Konkret:
  ServerRoot "D:/Apache"
  DocumentRoot "I:/root"
Ich kann völlig problemlos auch
  ServerRoot "/Apache"
angeben (also ohne Laufwerksbuchstabe). Was allerdings nicht funktioniert (brauche ich auch nicht erklären), ist
  ServerRoot "/"
Falls ich _dann_ aber auch noch
  DocumentRoot "/root"
schreibe, sucht er natürlich auf D: nach einem Verzeichnis "root" und findet es nicht, weil es das nicht gibt. Liegen alle benötigten Verzeichnisse auf einer Partition, ist die Angabe eines Laufwerksbuchstabens in der Tat uninteressant und allenfalls ein Zugeständnis an Lesegewohnheiten.

Vermutlich wirst Du nach wenigen Minuten begriffen haben, wieso es egal ist, daß es unter Windows nicht _ein_ "Root-Verzeichnis" gibt (sondern eines pro Laufwerk)

In der Klammer formulierst du das Entscheidende, was übrigens auch den Hintergrund für meine Anmerkung gab.

und was der Apache aus solchen Pfaden macht (nämlich das Naheliegende).

Vermutlich ist mir das bereits seit ein paar Jahren ziemlich klar, und wenn ich mich richtig erinnere, verdanke ich die entsprechenden Hinweise dem Forum.

Probiere es aus, statt auf Deiner falschen Aussage zu beharren.

Du wirst mir zugestehen, daß ich bereits sehr vieles ausprobiert haben dürfte. Allerdings wird mir erst durch das, was du in der Klammer eben formuliert hattest, klar, worauf Henner wohl insistiert hat: Sofern alles auf einer Partition liegt, wäre meine Aussage tatsächlich zweifelhaft  -  wenngleich auch noch lange keine "bewußte Falschaussage" oder gar "Lüge". Wenn ich bei der oben angegebenen Konstruktion (D: als Installationsort des Apache)
  <Directory />
     Options FollowSymLinks
     AllowOverride None
  </Directory>
vorgebe, bekomme ich trotz vorhandenen Alias für D: tatsächlich einen Error 403, falls ich auf den Alias zugreifen möchte, obwohl in der httpd.conf zusätzlich eben
  Alias /programme "D:"
  <Directory "D:">
      Options +Indexes FollowSymLinks
      AllowOverride None
      Order allow,deny
      Allow from all
  </Directory>
steht. Wenn ich nun (unsinnigerweise) <Directory /> folgendermaßen vollknalle:
  <Directory />
      Options Indexes FollowSymLinks MultiViews IncludesNoExec ExecCGI
      AddOutputFilter Includes html
      AllowOverride None
      Order allow,deny
      Allow from all
  </Directory>
bekomme ich wieder das Verzeichnislisting (da ist  -  bei mir  -  noch wesentlich mehr enthalten als bloß das bißchen Apache) und ich brauche eigentlich gar keinen Alias mehr extra.

ABER: trotz
  <Directory />
     Options FollowSymLinks
     AllowOverride None
  </Directory>
ist mein DocumentRoot auch ohne Alias für Laufwerk I: zugänglich, einschließlich Verzeichnislisting (das sind ein paar), und gleiches gilt für diverse virtuelle hosts auf Laufwerk H:. Selbst dann, wenn ich nicht nchmals gesondert
  <Directory "I:/root">
      ...
  </Directory>
festlege. Selbstverständlich bekomme ich auch C: vollständig gelistet. "Apache tut das Naheliegende" hast du formuliert, Henner meinte wohl das gleiche mit dem Insistieren darauf, daß er Pfade "interpretiert". Das "Naheliegende" bedeutet bei meiner Konstruktion: <Directory /> meint Laufwerk D:, aber _ausschließlich_ dieses Laufwerk, das das "root-Laufwerk" für die ausführende Datei apache.exe ist. _Alle anderen_ vorhandenen Laufwerke bleiben davon völlig unberührt.
Insofern ist meine Aussage also durchaus nicht "falsch", sondern allenfalls "nicht genug belegt".

Zu dieser Ausprobiererei war ich übrigens erst ab Apache 2.0.x gezwungen, mit 1.3.x war das (unter Windows) irrelevant.

Ich hoffe, du liest jetzt

Unter UNIX ist / das Wurzelverzeichnis, root. Ein "root" in vergleichbarem Sinn existiert für Windows-Systeme nicht.
Das hatten wir schon festgestellt. Und ebenso, dass es uninteressant ist
Daß dies uninteressant sei, hattest du festgestellt, ich nicht.
dann hole dies sofort nach.

nochmals nach, und bittest mich nicht erneut, die zitierte Feststellung nachzuholen.

Die Apache Group ist weitaus weniger dumm, als Du ihr unterstellst.

bitte, Michael: solche Sätze hast _du_ doch wirklich nicht nötig.

Grüße aus Berlin

Christoph S.

[Henner]

Ich kenne den möglichen Effekt, den du wohl meinst (funktioniert bloß bei mir nicht). [...]

Du hast es immer noch nicht begriffen. Wir reden von exakt der folgenden Anweisungsfolge

<Directory />

beliebig

</Directory>

So. Du behaupte(te?)st, die Anweisungen, die ich hier durch "#beliebig" ersetzt habe, seien [unter Windows] wirkungslos. Ich entgegne(te bereits mehrfach), dass genau das Gegenteil der Fall ist. Diese Anweisungen werden für _jeden Request_ ausgeführt, egal auf welchem Laufwerk sich die angefragte Datei befindet (und werden dann später u.U. von spezifischeren Direktiven überschrieben) -- der gleiche Effekt, wie auf einem Unix-System also.

Das ist übrigens schon so, seit der Apache auf Windows portiert wurde.

H.

[Christoph Schnauß]

hi,

Du hast es immer noch nicht begriffen.

Und du hast jetzt wahrscheinlich nicht genau genug gelesen.

Wir reden von exakt der folgenden Anweisungsfolge
<Directory />

beliebig

</Directory>

Das tun wir.

Du behaupte(te?)st, die Anweisungen, die ich hier durch "#beliebig" ersetzt habe, seien [unter Windows] wirkungslos.

Warum ich das behaupte(te), habe ich dargelegt.

Grüße aus Berlin

Christoph S.

[Henner]

Wir reden von exakt der folgenden Anweisungsfolge
<Directory />

beliebig

</Directory>
Das tun wir.
Du behaupte(te?)st, die Anweisungen, die ich hier durch "#beliebig" ersetzt habe, seien [unter Windows] wirkungslos.
Warum ich das behaupte(te), habe ich dargelegt.

Du meinst folgendes?

Das "Naheliegende" bedeutet bei meiner Konstruktion: <Directory /> meint Laufwerk D:, aber _ausschließlich_ dieses Laufwerk, das das "root-Laufwerk" für die ausführende Datei apache.exe ist. _Alle anderen_ vorhandenen Laufwerke bleiben davon völlig unberührt. Insofern ist meine Aussage also durchaus nicht "falsch", sondern allenfalls "nicht genug belegt".

Dass das nach wie vor im direkten Widerspruch zu meiner Aussage [die du mal wieder erfolgreich aus dem Zitat gelöscht hast] steht, ist dir aber klar, oder?
Auch wenn dich das nicht interessiert - ich glaube, du willst deinen Fehler einfach nicht eingestehen. Gut, sei's drum, für mich ist hier jedenfalls EOD.

H.

[Michael Schröpl]

Hi Christoph,

Die Apache Group ist weitaus weniger dumm, als Du ihr unterstellst.
bitte, Michael: solche Sätze hast _du_ doch wirklich nicht nötig.

Deine Beiträge in diesem Thread hier lesen sich für mich so, als würde die Apache Group Direktiven unterstützen, die keine Wirkung haben. (Wäre Deine Behauptung nämlich wahr, dann müßte der Apache Pfadangaben ohne Laufwerk unter Windows dringend als Syntaxfehler behandeln!) Dabei haben sie sehr wohl eine Wirkung - die Du verleugnest, und dies nach wiederholtem Hinweis.
Hinzu kommt, daß der von Dir abgestrittene Konfigurationsfall (alles auf einer Partition) auch noch der Installations-Default ist, also Dein eigenes Szenario ein "konstruiertes" (wenngleich sinnvolles) ist, aus dem Du dann falsche Behauptungen über alle übrigen Szenarien ableitest.
Irgendwann kann dann auch ich nicht mehr umhin, Dir dabei Realitätsferne und Beratungsresistenz zu unterstellen - zumal ich gestern in diesem Forum mindestens vier oder fünf weitere Behauptungen von Dir in Sachen Apache korrigieren mußte (in anderen Threads).

Du bist erst vor ein paar Tagen kritisiert worden, daß Du einerseits jedes Wort eines Fragestellers auf die Goldwaage legst (was ich auch tue), gleichzeitig aber mit Deinen eigenen Formulierungen ziemlich schlampig umgehst (was Du Dir genau dann eben nicht leisten kannst). Dieser Kritik schließe ich mich hiermit ausdrücklich an: Du warst schon mal deutlich sorgfältiger in Deinen Postings.

Viele Grüße
      Michael

[Eric]

Da habe ich ja eine Diskussion ausgelöst *ggg*
War eigentlich unbeabsichtigt...

Egal, wer von euch beiden Recht hat, mir hat Christoph sehr geholfen...

Gruß Eric

[Christoph Schnauß]

hallo Eric,

ich habe ein Problem mit dem DocumentRoot bzw. Access(Apache 2.0).

Was sagen denn deine Serverlogs zu deinem "Problem" ?

NameVirtualHost 192.168.10.2

hast du mal mit "ifconfig" auf der Konsole nachgeschaut, ob diese IP existiert?

Deine virtuellen hosts sehen auf den ersten blick zwar ein bißchen schmal, aber korrekt aus. Ob du in ihnen unterschiedliche "DocumentRoot"-Verzeichnisse definieren kannst, ist unter anderem davon abhängig, was weiter oben im zweiten Abschnitt ("main server configuration") der httpd.conf als "DocumentRoot" eingetragen wurde. Bei deinen Angaben _muß_ dort stehen
  DocumentRoot "/www/net"
Hast dort etwas anderes vorgegeben, müßtest du noch Aliasnamen für /www/net/eric_php und /www/net/inet vergeben.

Weiterhin habe ich die ServerNamen im DNS, sowie in die Datei "hosts" eingetragen...

Sind denn auch die Module geladen, mit denen virtuelle Hosts überhaupt angesprochen werden können (Kannst du dir bei entsprechender Konfiguration mit http://localhost/server-info anzeigen lassen)?

Ich komme an dieser Stelle nicht weiter...

Die Dokumentation unter http://httpd.apache.org/docs-2.0/vhosts/name-based.html sollte dir weiterhelfen können.

Grüße aus Berlin

Christoph S.