Posts Tagged ‘Apache’

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

Dienstag, 26. Oktober 2010

Darf ein Web-Entwickler seine geliebte Scripting-Sprache aufgeben?

How do you hire a programmer if you’re not one yourself? Some things to look for …

1. How opinionated are they?

Ask them about a juicy programming topic (e.g. Ruby or Python?). The tone and reasoning of the answer will reveal a lot. In our recent podcast on programming, Jeff said, “When people have strong opinions about things — when they can talk at length about something — it’s a good indication that they’re passionate about it.”

Quelle: How to hire a programmer when you’re not a programmer – (37signals)

Genau dies habe ich letzte Woche erlebt. Ich auf der Seite des Programmierers, auf der anderen Seite ein Headhunter, der für ein „internationales“ Unternehmen in Zürich einen Web-Entwickler suchte. Er war über Xing an meine Kontaktangaben gelangt.

Auf die Frage, ob ich Erfahrung in ASP.NET hätte, erwiderte ich ein klares Nein, um anzufügen, dass ich das letzte Mal im Jahr 2000 ASP programmiert hätte. ASP war damals mein erster Einstieg in webbasierte Scriptingsprachen. Innert weniger Monate wurde ich dann aber äusserst rasch auf die gute Seite der Macht gezogen — und entwickelte fortan auf den LAMP-Stack aufbauend.

Der Headhunter hakte nach: Ob ich es mir denn vorstellen könne, ASP.NET zu erlernen? Darauf erwirderte ich ein klares und dezidiertes „Nein“. Ich, der Mac OS X/Linux-Fan, der plötzlich in Visual Studio rumeiert? Das wäre wie wenn ein Kommunist zur SD überlaufen würde. Oder ein Wechselstromverfechter ins Camp der Gleichstromfreaks übertreten würde.

Ich habe mich noch ein/zwei Male gefragt, ob ich wirklich die richtige Antwort gegeben habe — doch mit obiger Bemerkung von Seiten der Web-Entwicklerprofis bin ich ein für allemal sicher, dass ich mich richtig entschieden habe.

Tags: , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 10. Juni 2008

Apache 1.3, MySQL 5 und PHP 5 unter Mac OS X auf UTF-8 trimmen

Mittlerweile habe auch ich den AMP-Stack auf meinem MacBook installiert und entwickle damit Web-Applikationen. Damit es bezüglich den Zeichensätzen koscher zu und her geht, musste ich folgende zwei Anpassungen an der Konfiguration vornehmen:

Apache 1.3

(Ich verwende aus Faulheit den mit Tiger mitgelieferten Apache – leider halt noch nicht 2.x)

In der /etc/httpd/httpd.conf wird mit folgendem Befehl eingestellt, dass im Header der HTTP-Antwort UTF-8 als Zeichensatz angegeben wird:

AddDefaultCharset UTF-8

MySQL

In der /etc/my.cnf

init-connect='SET NAMES utf8'

Bei jeder Verbindungsaufnahme (bspw. mysql_connect() via PHP) wird der Zeichensatz der ausgelieferten Daten damit auf UTF-8 geschaltet.

Selbstverständlich muss man aber immer noch aufpassen, in welchem Zeichensatz man Datenbank-Dumps exportiert und wieder einspielt …

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 23. November 2007

Apache 2.2 gegen LDAP authentifizieren

Die meisten werden es kennen: Wo man sich auch immer in der IT-Landschaft bewegt benötigt man Zugangsdaten. Vielerorts sind diese noch nicht vereinheitlicht (Stichwort Single-Sign-On, Kerberos etc.) – Administratoren wie Endbenutzer müssen sich eine Vielzahl von Benutzernamen und Passwörtern merken, um der täglichen Arbeit nachzugehen.

Wenn wie bei mir auf der Arbeit hingegen bereits ein von einer anderen Einheit betriebenes LDAP-Verzeichnis besteht, kann man dieses bei der Bewirtschaftung von Web-Applikationen zur Benutzer-Authentifizierung und -Authorisierung hinzuziehen.

In der hier vorliegenden Anleitung erläutere ich, wie Web-Verzeichnis gegen unbefugten Zugriff geschützt werden. Zum Einsatz kommen Debian und Apache 2.2 – ich gehe davon aus, dass beides bereits ordnungsgemäss installiert und konfiguriert wurde.

OpenLDAP & Hilfsprogramme installieren

Als erstes installiert man OpenLDAP sowie die ldap-utils mit einigen nützlichen Hilfsprogrammen:

apt-get install slapd
apt-get install ldap-utils

OpenLDAP lässt man aber unkonfiguriert, denn ein aktiver LDAP-Server befindet sich ja bereits im Netzwerk und versieht seinen Dienst.

Anschliessend passt man die Konfiguration von OpenLDAP an:

$ cat /etc/ldap/ldap.conf
BASE            o=org,c=ch
URI             ldaps://ldap.domain.tld
TLS_CACERTDIR   /etc/ldap/cacerts
TLS_REQCERT     never

SSL-Zertifikate

In unserem Falle reichte es, in /etc/ldap einen Symlink auf /etc/ssl/certs einzurichten. Der LDAP-Server verwendet ein Standard-Zertifikat von CyberTrust, welches bei Debian schon von Beginn weg dabei ist (?).

Bei einer frischen Debian-Installation (4.0r3) existiert dieses Verzeichnis nicht; Zertifikate sind auf dem System standardmässig keine vorhanden. Zuerst gilt es nun also, das Zertifikat des Servers herauszufinden:

openssl s_client -connect ldap.domain.tld:636 -showcerts

Anhand dieser Angaben sucht man über Google nach dem „<anbieter> global root“ des Anbieters (bspw. Cybertrust) und gelangt so normalerweise sofort zu den gesuchten Information. In meinem Fall war es:

ct_root.pem

Dieses Zertifikat laden wir uns herunter und legen es im Verzeichnis /etc/ldap/cacerts ab.

Anstelle in der ldap.conf explizit ein Zertifikat anzugeben, überlassen wir es OpenLDAP, das richtige Ding zu eruiren. Das klappt natürlich nur, wenn der Sysadmin des LDAP-Servers nicht selbst ein Zertifikat gebastelt hat.

Testlauf

Um zu überprüfen, ob OpenLDAP korrekt konfiguriert wurde, lässt man eine erste Abfrage laufen:

$ ldapsearch -x "uid=maeby"
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: uid=maeby
# requesting: ALL
#

# maeby, suborg, org, ch
dn: ...
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ...
objectClass: ...
objectClass: ...
uid: maeby
shadowFlag: 1
description: temporary staff account, imported from domain
homeDirectory: /home/maeby
uidNumber: 0001
gidNumber: 0010
cn: Mario Aeby
loginShell: /bin/bash

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Wenn dies klappt, geht es zum nächsten Schritt:

Apache 2.2 konfigurieren

Als erstes aktiviert man die zwei LDAP-Module:

$ cd /etc/apache2/mods-enabled
ln -s ../mods-available/ldap.load
ln -s ../mods-available/authnz_ldap.load

Es empfiehlt sich, einen LDAP-Cache einzurichten. Im selben Verzeichnis (/etc/apache2/mods-enabled) erstellt man deshalb eine Datei ldap.conf mit folgendem Inhalt:

$ cat /etc/apache2/mods-enabled/ldap.conf
# Enable the LDAP connection pool and shared
# memory cache. Enable the LDAP cache status
# handler. Requires mod_ldap and mod_auth_ldap

LDAPSharedCacheSize 2000000
LDAPCacheEntries 1024
LDAPCacheTTL 28800
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 28800

# specify shared memory file, to activate cache
LDAPSharedCacheFile /var/cache/apache2/ldap.cache

Web-Verzeichnisse schützen

Das Vorgehen ist ähnlich zu einer Authentifikation über eine htpasswd-Datei, abgesehen davon dass man einige andere Befehle einsetzt:

$ cat .htaccess
AuthType Basic
AuthName Test

AuthLDAPURL "ldaps://ldap.domain.tld/o=org,c=ch?uid"
AuthzLDAPAuthoritative on

AuthBasicProvider ldap

Require ldap-user maeby bgates sjobs

Anstelle Benutzer kann man auch Gruppen spezifizieren – oder gar spezielle Filter mitgeben, die erfüllt sein müssen.

Tags: ,
Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 4. Mai 2007

Wenn Smarty nicht schreiben will

Vor kurzem erhielt ich bei der Installation einer PHP-Web-Applikation folgende Fehlermeldung in die error.log geschrieben:

[client 0.0.0.0] PHP Warning:  Smarty error: problem creating directory "/var/webs/smarty/templates_c/%%778/%%778656331" in /var/webs/smarty/Smarty.class.php on line 589, referer: http://www.server.tld/
[client 0.0.0.0] PHP Warning:  Smarty error: problem writing '/var/webs/smarty/templates_c/%%778/%%778656331/error.tpl.php.' in /var/webs/smarty/Smarty.class.php on line 589, referer: http://www.server.tld/

Obwohl ich die Berechtigungen des übergeordneten Verzeichnisses auf rwxrwxrwx (chmod 777) gesetzt hatte, weigerte sich Smarty resp. PHP, einen neuen Unterordner zu erstellen.

Nach einigen Pröbeleien und Google-Suchen fand ich dann doch noch eine einleuchte Antwort auf die Ursache des Problems:

A: This is the problem with your hosting provider. The directories which are created by php modules, have 644 permissions by default. You cannot fix it.

Quelle: Smarty error

Am selben Ort ist ein Workaround beschrieben. Man bearbeite inc/smarty.inc.php und ändere folgende Konfigurationsvariable:

$this->use_sub_dirs = false;

Voilà! Nun funkioniert auch UCCASS 1.8.1 auf meinem Server.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen