Posts Tagged ‘Apache’

Donnerstag, 20. Juli 2017

Apache nervt mit Warnmeldungen, dass das DAV-Modul bereits geladen sei

Seit Jahr und Tag nerve ich mich ab Log-Zeilen in der folgenden Form, welche im syslog und in E-Mail-Nachrichten zu cron-Jobs auftauchen:

[Mon Jul 17 06:25:06.171427 2017] [so:warn] [pid 724] AH01574: module dav_module is already loaded, skipping

Und zwar immer dann, wenn Apache 2.4 neu gestartet wird (bspw. mittels apache2ctl graceful).

Lustigerweise findet sich im Netz keine Lösung des Problems — ein Novum, das mich daran zweifeln lässt, ob neben mir überhaupt noch jemand mit diesem nervigen Problem zu kämpfen hat.

Ich habe bereits mehrere Anläufe genommen, um im Netz eine Lösung zu dem Problem zu finden. Doch erst beim gefühlten Dutzendsten Versuch fand ich tief versteckt in den Google-Resultaten dann doch noch die Lösung:

# error at apache2 startup
    AH01574: module dav_module is already loaded, skipping
# solution; edit /etc/apache2/mods-available/dav.load
    <IfModule !mod_dav.c>
        LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
    </IfModule>

Quelle: adrhc’s blog (ACHTUNG: Zertifikatsfehler!)

Geniale Idee des Kollegen aus Rumänien (der TLD nach zu urteilen): Indem man den Inhalt der Datei /etc/apache2/mods-available/dav.load in eine IfModule-Abfrage packt, verhindert man, dass mod_dav ein zweites Mal geladen wird.

Seither ist Ruhe.

Was ich hingegen immer noch nicht weiss: Wo mod_dav zum ersten Mal geladen wird. Ich fand keine zweite Lade-Anweisung irgendwo in den Konfigurationsdateien unterhalb von /etc/apache2.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 27. August 2016

PHP-Fehlermeldungen ausser E_DEPRECATED loggen

Unter Apache (.htaccess oder VirtualHost-Konfiguration) stellt man dies folgendermassen ein:

...
php_value error_reporting 24575
...

Den ersten Hinweis lieferte How to disable deprecated messages in Joomla?. Doch die dort angegebene Konstante (22527) ist überholt, weil PHP 7 neue Fehlerkonstanten mitbringt, welche noch hinzuaddiert werden müssen.

Hierfür habe ich mich der Liste unter Error Handling — Predefined Constants bedient, und

32767 - 8192 = 24575

berechnet.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 24. Februar 2016

Eine interne Smokeping-Installation über Apache Reverse Proxy verfügbar machen

Heute morgen (US Pacific-Zeit) habe ich mir einige Minuten Zeit genommen, um eine Smokeping-Installation auf dem Linux-Server (nennen wir ihn BETA) in meiner Wohnung in Bern über einen Linux-Server im Elternhaus in Neuenegg zugänglich zu machen. Nur der Apache 2.4 Web-Server auf dem Linux-Server im Elternhaus (nennen wir ihn ALPHA) ist öffentlich aus dem Internet zugänglich.

Wenn Smokeping auf einem bestehenden Server bereits installiert, konfiguriert und aufrufbar ist, ist dieses Vorhaben äusserst simpel:

Als erstes laden wir auf ALPHA die benötigten zwei Proxy-Module:

# cd /etc/apache2/mods-enabled
# ln -s ../mods-available/proxy.conf .
# ln -s ../mods-available/proxy_http.conf .

Weiter erstellen wir ebenfalls auf ALPHA einen virtuellen Host mit folgenden Angaben:

<VirtualHost *:80>
	ServerName smokeping-beta.bern.homeip.net
	ServerAdmin info@eMeidi.com
	
	ProxyPass	/	http://10.1.2.3/
	
	<Location />
		AuthName		"Eyes Only"
		AuthType 		Digest
		AuthUserFile		/etc/apache2/auth/users.digest
		AuthDigestProvider	file
		AuthDigestDomain	/
		
		Require			valid-user
	</Location>
</VirtualHost>

Diese Angaben legen wir unter /etc/apache2/sites-available ab und nennen die Datei beispielsweise smokeping-bern. Schlussendlich aktivieren wir diese folgendermassen:

# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/smokeping-bern

Anschliessend starten wir auf ALPHA den Web-Server neu:

# apache2ctl graceful

Damit Smokeping in der Folge sauber mit allen relativen Pfaden funktioniert, aber auch die Bilder (RRDtool-Graphen) angezeigt werden, rufe ich die Web-Site auf einem beliebigen Computer mit Internetverbindung folgendermassen auf:

http://smokeping-beta.bern.homeip.net/smokeping/smokeping.cgi

WICHTIG: Damit nur authentifizierte Personen auf diesen Reverse Proxy zugreifen können, schütze ich den gesamten Virtual Host mit Benutzernamen und Passwort. Dies ist deshalb auch wichtig, weil meine Konfiguration alle Anfragen auf den Virtual Host an den anderen Server weiterleitet — habe ich in anderen Unterverzeichnissen noch andere Applikationen laufen, wären diese ebenfalls über den Reverse Proxy ansprechbar. Das ist nicht schön, aber momentan als Quick & Dirty-Lösung akzeptabel.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 21. Januar 2016

smokeping auf einem Raspberry Pi installieren

Gestern habe ich einen verstaubten Raspberry Pi 1 aus meinem Endlager für obsolete IT-Hardware gerettet und ihn als arpwatch-Überwachungsstation aufgesetzt. Auf dem Gerät läuft folgendes Debian:

Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux

Etwas später stiess ich in Vorbereitung auf meinen Wechsel von upc cablecom zu Fiber7 auf den Artikel Fiber7 performance, in welchem Michael Stapelberg aufzeigt, wie sich die Latenz seiner Internetverbindung nach dem Wechsel von Swisscom auf Fiber7 verbessert hat.

Gedacht — getan: So etwas benötige ich natürlich auch, um meinen bevorstehenden Providerwechsel mit harten Fakten zu untermauern — wobei, ehrlich gesagt, ist mir die Latenz nicht so wichtig (bin kein Gamer), sondern viel mehr der vierfache Durchsatz und die symmetrische Down- und Upload-Geschwindigkeit zum selben Preis wie beim Kabelriesen.

Nichtsdestotrotz installierte ich mir also das Softwarepaket smokeping und seine Dependencies, wie das berühmte rrdtool aus dem Hause Oetiker:

# apt-get update
...
# apt-get upgrade
...
# apt-get install smokeping

Es wurde zwar alles nett installiert, doch konnte ich danach noch nicht auf die Web-Oberfläche unter http://localhost/smokeping/smokeping.cgi zugreifen. Unter einem x86-64 Debian war das nach der Installation automatisch möglich.

Zuerst wohl mal den Apache starten, dachte ich mir:

# /etc/init.d/apache2 start

Der Web-Server kam hoch, zeigte unter http://localhost/ die obligate Startseite an, doch unter dem Smokeping-Link kam ich statt der Smokeping-Oberfläche nur einen HTTP 403er zu Gesicht (mangels Screenshot und Text-Kopie mittels Auszug aus dem Apache error.log unter /var/log/apache2/):

...
[Wed Jan 20 22:52:59.338858 2016] [authz_core:error] [pid 2706:tid 3036673072] [client 10.0.1.101:56967] AH01630: client denied by server configuration: /usr/lib/cgi-bin/smokeping.cgi
...

Oookey … da ich smokeping auch noch auf einem „richtigen“ Linux-Server im Elternhaus laufen hatte, kopierte ich kurzerhand dessen VirtualHost-Konfiguration auf den Raspberry Pi (natürlich als Symlink auf conf-available):

# cat /etc/apache2/conf-enabled/smokeping.conf 
ScriptAlias /smokeping/smokeping.cgi /usr/lib/cgi-bin/smokeping.cgi
Alias /smokeping /usr/share/smokeping/www

<Directory "/usr/share/smokeping/www">
    Options FollowSymLinks
</Directory>

<Directory "/usr/lib/cgi-bin/">
    Options FollowSymLinks
    Require all granted
</Directory>

Noch ein …

# apache2ctl graceful

… und der 403er war weg. Das smokeping-GUI wurde aber weiterhin nicht angezeigt, sondern nur der Inhalt des CGI-Scripts im Klartext:

#!/bin/sh

exec /usr/share/smokeping/smokeping.cgi /etc/smokeping/config

Was zur Hölle … ? Doch auch diesem Fehlverhalten schaffte ich nach 15 Minuten googlen, Artikel lesen und pröbeln den Garaus: Ein simples

# a2enmod cgi

Via: Perl Apache : Perl script displayed as plain text

reichte aus, und plötzlich führte Apache das CGI-Script aus. Halleluja!

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Installing mod_bwshare on Debian Linux running Apache 2.0.x

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

Recently, I noticed msnbot was spamming my whole upload bandwidth because it seemed to create a complete dump of my photo gallery – several image requests within a minute! After some googling I discovered several Apache modules which promise to get rid of such bots running amok (although there are some concerns about artificially prolonging download times for leechers – beware!). I finally decided to go on with mod_bwshare. In a temporary „dust of war“, I got the wrong impression that I needed to upgrade to Apache 2.0.x to be able to get a precompiled .deb. Well, haha! There isn’t a debian package available right now. Well, okey, at least I’m running the newest Apache now, although I had to

apt-get remove apache
dpkg-reconfigure php4
dpkg-reconfigure php4-mysql
dpkg-reconfigure php4-curl
dpkg-reconfigure php4-imap
dpkg-reconfigure php4-gd

to get back to my „touched working system“ and make PHP aware of Apache 2. Be aware: Everything starts with untouched config files, so make sure you enable error logging in PHP again. Especially if you’re a web-dev like I am, you know about usefulness of

error_reporting = E_ALL

Okey, now straight back to the task. Since all this stuff is open source, we could at least give it a try with compiling and stuff (honestly, I just now enough about compiling to completly havoc a system, but I was a lucky guy in this case). So download the source files:

cd /tmp
wget http://www.topology.org/src/bwshare/bwshare-0.1.3.zip
unzip bwshare-0.1.3.zip

So, there we had’em now, hundreds of lines of codes. As stated on the developers homepage itself, running

cd src/modules/bwshare
apxs2 -c mod_bwshare.c
apxs2 -i mod_bwshare.la

Should do the trick. Nada, first we needed the developer package:

apt-get install apache2-dev

Once again:

apxs2 -c mod_bwshare.c
apxs2 -i mod_bwshare.la

A lot of warnings were displayed, but finally, I read

...
chmod 644 /usr/lib/apache2/modules/mod_bwshare.so

After having succesfully compiled mod_bwshare, I had to create two text-files in /etc/apache2/mods-available/

bwshare.load
bwshare.conf

and pasted the following contents:

LoadModule bwshare_module /usr/lib/apache2/modules/mod_bwshare.so
# Some bandwidth control parameters.
BW_tx1cred_rate         2
BW_tx1debt_max          10
BW_tx2cred_rate         1000
BW_tx2debt_max          1000000

<Location /bwshare-info>
SetHandler bwshare-info
</Location>

<Location /bwshare-trace>
SetHandler bwshare-trace
</Location>
</IfModule>

That was it (if you got that far, you surely know now what comes next – putting symlinks in mods-enabled/ and doing a

apache2ctl graceful

(Thanks to our solaris master Aeschlimann at the University for the graceful hint some time ago – greetz).

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 7. Oktober 2013

Apache liefert ungefähr richtige Dateinamen aus

Ungefähr einmal im Jahr konfiguriere ich unter einer Mac OS X-Installation den lokalen Web-Server, um auf dem Gerät Web-Applikationen zu entwickeln. Und bei jedem Mal vergesse ich in der Regel, dass unter Mac OS X das Apache-Modul mod_negotiation installiert ist, welches spätestens bei der Verwendung von mod_rewrite zu komischem Verhalten führt.

Beispiel: Ich rufe im Browser die URL http://localhost/article/132 auf, welche eigentlich mittels mod_rewrite auf index.php umgeleitet werden sollte. Habe ich im DocumentRoot des Web-Servers aber dummerweise ein Script namens article.php rumliegen, wird Apache die Rewrite-Regeln nicht beachten und stattdessen article.php aufrufen.

Unter Mac OS X könnte man nun rabiaterweise einfach das Laden von mod_negotiation verhindern. Leider führt das zu neuen Problemen und Fehlermeldungen, welche ich hier aus Zeitgründen nicht ausführen möchte, weshalb man stattdessen die mod_negotiation-Funktionalität in der VirtualHost-Konfiguration für das DocumentRoot und alle darunterliegenden Verzeichnisse deaktiviert:

...
Options -Multiviews
...

Und gut is …

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 15. August 2013

libapache2-svn unter Apache 2.4 zum Laufen bringen

Da führt man zu Monatsbeginn auf dem heimischen Linux-Server vor lauter Blödheit ein

# apt-get dist-upgrade

durch und sieht sich plötzlich mit Apache 2.4 konfrontiert.

Nachdem man die Zugriffsprobleme mit IP- und Host-basierten Regeln in allen .htaccess-Dateien behoben hat, realisiert man erst, dass der Web-Server nicht starten will, weil das DAV-Modul „svn“ nicht mehr gefunden wird:

Unknown DAV provider: svn

Was zum Geier?

Die Ursache des Problems ist rasch gefunden: Das Paket libapache2-svn hat eine Abhängigkeit vom Paket apache2.2-common, doch mit Apache 2.4 hat letzteres Paket seine Daseinsberechtigung verloren und ist folglich nicht mehr auf dem System vorhanden. Zu allem Unglück hinzu unterstützt Subversion in der Debian-Version 1.6.17dfsg-4+deb7u3 Apache 2.4 gar nicht.

Nach längerem Herumsuchen im Internet komme ich zum Schluss, dass wirklich nichts an der auf Stackoverflow herumgebotenen Lösung vorbeiführt: Ich muss Subversion doch tatsächlich in der derzeit aktuellen Version 1.7.9 (Debian: 1.7.9-1+nmu3) aus der Quelle kompilieren und danach auf dem System installieren. Diese Version kennt und unterstützt Apache 2.4.

Nachfolgend eine rudimentäre Anleitung, welche sich an den Stackoverflow-Artikel anlehnt.

Anleitung

Zuerst benötigen wir folgende Pakete, um Subversion gegen das aktuell installierte Apache 2.4 kompilieren zu können:

# apt-get install apache2-dev
# apt-get build-dep subversion

Bei mir war anschliessend noch manuell die Installation von folgendem Paket nötig:

# apt-get install libserf1 libserf-dev

Jetzt geht es an das Herunterladen des Subversion-Quellcodes:

$ cd /tmp
$ apt-get source --compile subversion
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
... (Ctrl+C)

Richtig gelesen: Während das Teil vor sich hinkompilieren will, bricht man die Durchführung mittels Ctrl+C ab. Denn zuerst sind noch einige kleinere Anpassungen an den Kompilierungseinstellungen nötig, damit man am Ende nicht nur mit Subversion, sondern auch mit einem Paket libapache2-svn dasteht.

In /tmp/subversion-1.7.9/debian/rules ändert man dazu folgenden Wert:

ENABLE_APACHE        := yes

Und in /tmp/subversion-1.7.9/debian/control fügt man zuunterst folgenden Text ein:

...

Package: libapache2-svn
Section: httpd
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: db5.1-util
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Schlussendlich startet man die Kompiliererei erneut, verzichtet dieses Mal aber mit dem Attribut DEB_BUILD_CONFIG, dass nach der Kompilierung stundenlang Tests durchgeführt werden, diese scheitern und man nach dem Warten auf Godot ohne .deb-Pakete dasteht (via DEB_BUILD_OPTIONS=nocheck):

$ cd /tmp/subversion-1.7.9/
$ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -b -uc

Anschliessend installiert man die folgenden drei Pakete:

# dpkg -i /tmp/libsvn1_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/libapache2-svn_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/subversion_1.7.9-1+nmu3_i386.deb

Schlussendlich muss man in Apache unter /etc/apache2/mods-enabled noch die folgenden Module aus /etc/apache2/mods-available symlinken, wenn sie nicht schon dort sind:

  • authz_svn.load
  • dav_svn.conf
  • dav_svn.load

Dann noch das obligate …

# /etc/init.d/apache2 restart

… und gut is!

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 6. März 2013

Wenn Subversion zwar updaten, aber nicht committen kann

Heute habe ich eines meiner Web-Projekte aktualisiert. Ich arbeitete dabei direkt auf dem produktiven Web-Server. Ein svn up klappte problemlos. Doch als ich die direkt auf dem Server neu erstellte robots.txt in das Repository einchecken wolle, kam es zu folgender Fehlermeldung:

$ svn ci -m "robots.txt fehlte"
svn: Commit failed (details follow):
svn: At least one property change failed; repository is unchanged
svn: Server sent unexpected return value (400 Bad Request) in response to PROPPATCH request for '//!svn/wbl/56ef405d-3812-4a6b-a62d-edae457cb0b0/1057'

Die Log-Daten meines Apache-Servers, welcher mittels WebDAV auch den Zugang zum SVN-Repository bereitstellt, vermeldeten folgendes:

access.log:

...
[SOURCE IP] - - [06/Mar/2013:20:08:56 +0100] "OPTIONS /repository HTTP/1.1" 401 772 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "OPTIONS /repository HTTP/1.1" 200 1039 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "PROPFIND /repository HTTP/1.1" 207 741 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "MKACTIVITY /!svn/act/74bcecab-e942-418b-84e4-822ad8581d59 HTTP/1.1" 201 758 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "CHECKOUT /!svn/vcc/default HTTP/1.1" 201 777 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "PROPPATCH //!svn/wbl/74bcecab-e942-418b-84e4-822ad8581d59/1058 HTTP/1.1" 400 478 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "DELETE /!svn/act/74bcecab-e942-418b-84e4-822ad8581d59 HTTP/1.1" 204 302 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
...

error.log:

[Wed Mar 06 19:48:10 2013] [error] [client [SOURCE IP]] Digest: uri mismatch -  does not match request-uri 

Unterwegs vom Produktionssystem zum Repository-Server kam es zu einem Problem, in welchem die Domain meines Servers aus der Request-URI entfernt wurde. Ich muss hierbei noch erwähnen, dass zwischen den beiden Servern ein (nicht transparenter) Proxy-Server mit Squid werkelt. Inwiefern dieser Server in den Vorgang gepfuscht hat, kann ich nicht sagen.

Nach langem Pröbeln habe ich es irgendwie hingekriegt. Die Lösung des Problems erscheint mir immer noch mysteriös — aber so sei es wohl manchmal halt: Nachdem ich einerseits folgende zwei Konfigurationsdateien umbenannt …

  • /etc/subversion/servers
  • ~/.subversion/servers

… und andererseits den Inhalt des Verzeichnisses

~/.subversion/auth/

komplett gelöscht hatte, klappte es mit dem Commit plötzlich problemlos.

Eine Vermutung habe ich: Da ich mich seit mehr als einem Jahr nicht mehr auf dem Server eingeloggt hatte, könnten unter auth noch Überreste der damals verwendeten HTTP Basic-Authentifizierung gespeichert gewesen sein. Mittlerweile bin ich auf HTTP Digest-Authentifizierung umgestiegen, um Passwörter im schlimmsten Fall nicht mehr im Klartext über ein öffentliches WiFi zu jagen. Indiz dafür ist, dass ich heute nach der Löschaktion gefragt wurde, ob ich das Passwort im Klartext auf dem Server speichern möchte (was ich abgelehnt habe).

Oder aber eine oder beide Konfigurationsdateien enthielten eine Option, welche die Übertragung der Informationen störte — bspw. der hardkodierte Proxy. Wieso die HTTP-Verbindung zum Repository-Server auch nach der Umbenennung der zwei Konfigurationsdateien weiter funktionierte, ist und bleibt schleierhaft. Wobei, jetzt kommt mir in den Sinn, dass die Admins dieses Netzwerks kurz vor meinem Weggang planten, einen transparenten Proxy einzurichten … Das könnte die Lösung sein.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 12. Februar 2012

Apache kann den FQDN des Servers nicht festlegen

Seit Jahren ärgere ich mich damit herum, dass meine Cron-Logs jedes Wochenende mit folgendem Fehler aufwarten:

apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.0.101 for ServerName

Diese Meldung taucht auch auf, wenn ich den Server mit apache2ctl graceful respektive apache2ctl restart neu starte.

Heute nun habe ich mich endlich des Problems angenommen und teile die Lösung gerne mit der ganzen Online-Welt.

Der vom lokalen BIND (DNS-Server) geliefert Hostname meines Web-Servers lautete wie folgt:

$ host 192.168.0.101
101.0.168.192.in-addr.arpa domain name pointer alpha.emeidi.local.

In meiner /etc/hosts stand aber nur folgendes:

127.0.0.1	localhost

192.168.0.101	ALPHA
...

Nach einigem Googlen wechselte ich die Zeile beginnend mit 192.168.0.101 folgendermassen aus:

192.168.0.101	ALPHA ALPHA.emeidi.local mad4you.homeip.net

Und siehe da, ab sofort kann Apache den Fully Qualified Domain Name des Servers selber erraten.

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Mai 2011

LDAP-Authentifizierung unter Apache funktioniert nach dem Upgrade auf Debian Squeeze nicht mehr

Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.

Symptom

Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.

Apache die exakte Fehlermeldung entlocken

Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:

...
#LogLevel warn
LogLevel debug
...

Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:

...
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
...

Das Kernproblem

Eine Google-Suche führte mich auf die richtige Spur:

To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.

Quelle: Bug#620398: Apache LDAP/S Authentication Causes

Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?

Wer bürgt für die Verschlüsselung?

Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:

$ openssl s_client -connect ldap.domain.tld:636 -showcerts
depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld
  i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x
GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp
...

Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.

Gebt mir das Rootzertifikat!

Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.

Installation des Zertifikats auf dem Server

Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).

Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:

...
LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem
...

Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen