nicht angemeldet
Apache lässt mich nicht auf Munin zugreifen
Moin,
ich habe heute Munin auf meinem Server installiert. Die Konfiguration habe ich größtenteils so gelassen; ich habe nur noch hinzugefügt, dass ich bei allen Warnungen und kritischen Meldungen per Mail gewarnt werde.
Soweit scheint auch alles zu funktionieren, ich habe nur das Problem, dass mein Apache mich nicht auf das Verzeichnis zugreifen lässt. Ich habe die Gruppe des Verzeichnisses, in dem die Weboberfläche des Munin liegt auf www-data geändert aber es geht trotzdem nicht. Fehlermeldung 403 des Apache (standardseite kommt). Folgendes ist noch zu sagen: Trotz, dass ich eine Basic-Authentication eingestellt habe, werde ich nicht zum Login aufgefordert. Die Fehlerseite kommt sofort...
Hier ein paar Infos:
httpd.conf (Auszug)
<VirtualHost *:443>
ServerName munin.themisterunknown.de
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache_all.pem
DocumentRoot /var/cache/munin/www
<Directory />
AuthType Basic
AuthName "Munin - restricted access"
AuthUserFile /var/www/.htpasswd
Require valid-user
</Directory>
</VirtualHost>
Ordner /var/cache/munin/www:
root@themisterunknown:/var/cache/munin/www# ls -la
total 44
drwxr-xr-x 4 munin www-data 4096 Feb 7 21:55 .
drwxr-xr-x 3 root root 4096 Feb 7 21:29 ..
drwxrwxr-x 3 munin munin 4096 Feb 7 21:55 de
-rw-r--r-- 1 munin www-data 2555 Feb 7 21:35 definitions.html
-rw-r--r-- 1 munin www-data 2046 Feb 7 21:35 favicon.ico
-rw-rw-r-- 1 munin www-data 2330 Feb 7 22:00 index.html
drwxrwxr-x 3 munin www-data 4096 Feb 7 21:35 localdomain
-rw-r--r-- 1 munin www-data 1407 Feb 7 21:35 logo-h.png
-rw-r--r-- 1 munin www-data 393 Feb 7 21:35 logo.png
-rw-r--r-- 1 munin www-data 5351 Feb 7 21:35 style.css
root@themisterunknown:/var/cache/munin/www#
Apache Error-Log:
[Thu Feb 07 21:54:15 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:15 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:16 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/index.html
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
[Thu Feb 07 21:54:17 2013] [error] [client 93.196.182.121] client denied by server configuration: /var/cache/munin/www/favicon.ico
Die Fehlermeldung ist relativ nichtssagend. Theoretisch hätte der Zugriff sogar klappen sollen, wenn ich die Berechtigungsgruppe nicht auf www-data geändert hätte, da ja die Others auch lesen können. Mit der Konfiguration des Munin dürfte das ja prinzipiell nichts zu tun haben. Trotzdem hier die Infos:
munin.conf
includedir /etc/munin/munin-conf.d
contacts me
contact.me.command mail -s "Munin notification" marco@themisterunknown.de
contact.me.always_send warning critical
[localhost.localdomain]
address 127.0.0.1
use_node_name yes
munin-node.conf
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
background 1
setsid 1
user root
group root
ignore_file ~$
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$
allow ^127\.0\.0\.1$
host *
port 4949
Kann mich jemand erleuchten?
Grüße Marco
--
Ich spreche Spaghetticode - fließend.
Ich spreche Spaghetticode - fließend.
-
Tach!
DocumentRoot /var/cache/munin/www
<Directory />Das passt nicht zusammen. <Directory> bezieht sich auf den Pfad im System, nicht nur ab DocumentRoot. Und üblicherweise ist an anderer Stelle ein Deny from all auf / gelegt.
Ordner /var/cache/munin/www:
Warum liegt das Zeug im Cache-Ordner? Das gehört dort nicht hin und ist unter /var/www besser aufgehoben.
dedlfix.
-
Moin,
DocumentRoot /var/cache/munin/www
<Directory />
Das passt nicht zusammen. <Directory> bezieht sich auf den Pfad im System, nicht nur ab DocumentRoot. Und üblicherweise ist an anderer Stelle ein Deny from all auf / gelegt.Tatsächlich? Hm. Bei 2 anderen Subdomains habe ich das genauso gelöst und es funktionierte. Beispiel:
<VirtualHost *:443> ServerName webmail.themisterunknown.de SSLEngine On SSLCertificateFile /etc/apache2/ssl/apache_all.pem DocumentRoot /usr/share/roundcube <Directory /> AuthType Basic AuthName "Webmail - restricted access" AuthUserFile /var/www/.htpasswd Require valid-user </Directory> </VirtualHost> <VirtualHost *:443> ServerName proxy.themisterunknown.de SSLEngine On SSLCertificateFile /etc/apache2/ssl/apache_all.pem DocumentRoot /usr/share/nph-proxy <Directory /> AuthType Basic AuthName "Webproxy service - valid users only" AuthUserFile /var/www/.htpasswd Require valid-user AddHandler cgi-script .cgi DirectoryIndex nph-proxy.cgi Options +ExecCGI </Directory> </VirtualHost>Auf das "echte" Wurzelverzeichnis kann die Directory-Direktive nicht zutreffen, da man ja auf der normalen Seite auch ein Passwort eingeben müsste, oder sehe ich das falsch?
Ich habe jetzt aber mal probiert in die Directory-Direktive den absoluten Pfad anzugeben; leider funktioniert das auch nicht. Nach der Meldung über ein ungeprüftes Zertifikat lande ich direkt auf der 403er Fehlerseite des Apachen.
Warum liegt das Zeug im Cache-Ordner? Das gehört dort nicht hin und ist unter /var/www besser aufgehoben.
Hm, das Zeug liegt in der neusten Version standardmäßig dort. Ich werde das aber mal lieber woanders hinpacken.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.-
Tach!
Das passt nicht zusammen. <Directory> bezieht sich auf den Pfad im System, nicht nur ab DocumentRoot.
Tatsächlich? Hm. Bei 2 anderen Subdomains habe ich das genauso gelöst und es funktionierte.Mir wäre es egal, aufgrund welchen Zufalls deine Konfiguration so funktioniert. Fakt ist, dass Directory einen absoluten Pfad verlangt und / die Dateisystemwurzel darstellt. Warum das geht, will ich nicht zu erklären versuchen, ohne die Gesamtkonfiguration zu kennen. Aber das wäre müßig, die Konfiguration muss sowieso korrigiert werden.
Warum liegt das Zeug im Cache-Ordner? Das gehört dort nicht hin und ist unter /var/www besser aufgehoben.
Hm, das Zeug liegt in der neusten Version standardmäßig dort. Ich werde das aber mal lieber woanders hinpacken.Echt? Was ist das für eine Linux-Distribution?
dedlfix.
-
Tach,
Mir wäre es egal, aufgrund welchen Zufalls deine Konfiguration so funktioniert. Fakt ist, dass Directory einen absoluten Pfad verlangt und / die Dateisystemwurzel darstellt.
naja, da alles andere unterhalb von / ist, muss es ja funktionieren, solange es nicht wieder überschrieben wird; auch wenn diese Art der Konfiguration problematisch ist.
Warum liegt das Zeug im Cache-Ordner? Das gehört dort nicht hin und ist unter /var/www besser aufgehoben.
Hm, das Zeug liegt in der neusten Version standardmäßig dort. Ich werde das aber mal lieber woanders hinpacken.Echt? Was ist das für eine Linux-Distribution?
Debian und es ist auch definitiv nicht falsch; die Daten, die dort liegen sind die Seiten und Bilder, die aus den Roh-Daten erzeugt werden und wiederherstellbar sind (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA). Neuere munin-Installationen (noch nicht nachgeschaut, aber die in Wheezy sollte das schon können), erzeugen die Files auch tatsächlich erst beim Zugriff und cachen sie dann.
mfg
Woodfighter -
Moin,
Mir wäre es egal, aufgrund welchen Zufalls deine Konfiguration so funktioniert. Fakt ist, dass Directory einen absoluten Pfad verlangt und / die Dateisystemwurzel darstellt. Warum das geht, will ich nicht zu erklären versuchen, ohne die Gesamtkonfiguration zu kennen. Aber das wäre müßig, die Konfiguration muss sowieso korrigiert werden.
Ok, ich ändere das.
Allerdings bringt mich das nur einen kleinen Schritt der Lösung näher. Die Frage ist immer noch, warum ich nicht auf Munin zugreifen kann... Das Dateisystem ist es nicht, die Berechtigungen reichen aus. Es muss irgendwo am Apache hapern.Hm, das Zeug liegt in der neusten Version standardmäßig dort. Ich werde das aber mal lieber woanders hinpacken.
Echt? Was ist das für eine Linux-Distribution?Immer noch Ubuntu 12.04 LTS. Ich bin am Überlegen ob ich das nochmal wechsle oder ob ich jetzt einfach dabei bleibe.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.-
Tach!
Allerdings bringt mich das nur einen kleinen Schritt der Lösung näher. Die Frage ist immer noch, warum ich nicht auf Munin zugreifen kann... Das Dateisystem ist es nicht, die Berechtigungen reichen aus. Es muss irgendwo am Apache hapern.
Munin produziert HTML-Dateien und Grafiken. Nur auf dieses Ergebnis musst du zugreifen. Die Munin-Konfiguration als solche ist für das Problem ziemlich uninteressant. Der Apache hat also ein Problem seitens der Konfiguration oder den Dateiberechtigungen, auf alle Dateien zuzugreifen, die er benötigt. Vielleicht ist es ja deine .htpasswd. Was ist, wenn du den Zugriffsschutz zum Probieren mal komplett weglässt?
dedlfix.
-
-
-
-
-
-
Tach,
httpd.conf (Auszug)
hast du mal in /etc/apache2/conf.d/munin* geschaut, ob dir die Standardkonfiguration dazwischenfunkt? IIRC, steht da ein „Allow from localhost 127.0.0.0/8 ::1“ drin.
mfg
Woodfighter-
Moin,
hast du mal in /etc/apache2/conf.d/munin* geschaut, ob dir die Standardkonfiguration dazwischenfunkt? IIRC, steht da ein „Allow from localhost 127.0.0.0/8 ::1“ drin.
Die munin.conf ist im Ausgangsposting komplett zu sehen. das Verzeichnis /etc/munin/munin-conf.d ist leer. Auch die munin-node.conf ist komplett im Ausgangsposting komplett. Dort steht etwas von allow ^127.0.0.1$ allerdings habe ich gelesen, dass das nur eine Einstellung ist, von wo aus man auf den Node zugreifen kann; da solle das korrekt sein. Der Munin greift auf den Node ja nur lokal zu. Der Zugriff auf die Weboberfläche sollte ja davon unahängig sein; zumal ja eigentlich ausschließlich der Apache für das Ausliefern der Weboberfläche zuständig sein sollte.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.-
Tach,
hast du mal in /etc/apache2/conf.d/munin* geschaut, ob dir die Standardkonfiguration dazwischenfunkt? IIRC, steht da ein „Allow from localhost 127.0.0.0/8 ::1“ drin.
Die munin.conf ist im Ausgangsposting komplett zu sehen.
das ist nicht die Datei, deren Pfad, ich angegeben habe.
das Verzeichnis /etc/munin/munin-conf.d ist leer. Auch die munin-node.conf ist komplett im Ausgangsposting komplett. Dort steht etwas von allow ^127.0.0.1$ allerdings habe ich gelesen, dass das nur eine Einstellung ist, von wo aus man auf den Node zugreifen kann; da solle das korrekt sein.
ja
mfg
Woodfighter-
Moin,
das ist nicht die Datei, deren Pfad, ich angegeben habe.
Vielen Dank, ich konnte das Problem mit einem einfachen
unlink /etc/apache2/conf.d/muninlösen.Allerdings habe entweder ich ein gewaltiges Verständnisproblem, oder ihr liegt in einer Sache falsch: Directory im VirtualHost-Kontext bezieht sich nicht aufs Dateisystem des realen Servers, sondern auf das DocumentRoot des VirtualHosts.
Ich habe nämlich unabhängig davon, dass es sowieso noch nicht funktioniert hatte, die Konfiguration so geändert:<VirtualHost *:443> ... <Directory /var/cache/munin/www> AuthType Basic ... </Directory> </VirtualHost>Nachdem ich die Standardkonfiguration ausgeschlossen habe, konnte ich auf die Oberfläche zugreifen, musste mich aber _nicht_ einloggen.
Nachdem ich testweise nochmal meine erste Variante probiert habe:<VirtualHost *:443> ... <Directory /> AuthType Basic ... </Directory> </VirtualHost>muss ich auch Login-Daten eingeben, bevor ich die Oberfläche zu Gesicht kriege.
Gibt es dafür eine Erklärung? Ich habe nochmal genau die Apache-Doku gelesen. Weder in der englischen, noch in der deutschen steht konkret das Verhalten von Directory im VirtualHost-Kontext beschrieben. Ich würde aber einen Besen fressen, wenn ich unrecht hätte.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.-
Tach,
Gibt es dafür eine Erklärung? Ich habe nochmal genau die Apache-Doku gelesen. Weder in der englischen, noch in der deutschen steht konkret das Verhalten von Directory im VirtualHost-Kontext beschrieben. Ich würde aber einen Besen fressen, wenn ich unrecht hätte.
Der VirtualHost-Kontext ändert nichts an der Arbeitsweise der Directory-Direktive, außer dass die Config nur innerhalb dieses Hosts greift; ich würde vermuten, du hast nicht das getestet, was du behauptest, da es nicht reproduzierbar ist.
mfg
Woodfighter-
Moin,
der arme Besen -.-
Merke: Ich werde alles 12 mal nachprüfen, bevor ich versuche Experten zu widerlegen.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.
-
-
Tach!
Vielen Dank, ich konnte das Problem mit einem einfachen
unlink /etc/apache2/conf.d/muninlösen.Dann war dort das Directory spezifischer definiert und dessen Allow/Deny hat deinen externen Zugriff verhindert.
Allerdings habe entweder ich ein gewaltiges Verständnisproblem, oder ihr liegt in einer Sache falsch: Directory im VirtualHost-Kontext bezieht sich nicht aufs Dateisystem des realen Servers, sondern auf das DocumentRoot des VirtualHosts.
Dann läge auch das Handbuch falsch. Und das wäre ebenfalls technisch unsinnig/ungünstig. Man kann ja mit Alias durchaus auch auf Bereiche außerhalb des DocumentRoot verweisen. Wenn <Directory> vom Docroot ausginge, könnte man diese Bereiche nicht konfigurieren. Oder wie soll der Apache erraten, ob man mal den vollen Pfad und mal den relativen meint?
Ich habe nochmal genau die Apache-Doku gelesen. Weder in der englischen, noch in der deutschen steht konkret das Verhalten von Directory im VirtualHost-Kontext beschrieben. Ich würde aber einen Besen fressen, wenn ich unrecht hätte.
Guten Appetit. Wenn etwas nicht im Detail beschrieben ist, muss man davon ausgehen, dass es keine Abweichung vom Standard gibt - besonders bei einem so gut dokumentierten System wie dem Apachen.
dedlfix.
-
-
-
-