OpenLDAP 2.4 mit qmail-Schema

In eige­ner Sache: Hm – die Fall­hö­he zum vor­an­ge­hen­den Arti­kel ist schon krass… Erst eher Lyri­sches, dann pro­fan Tech­ni­sches, aber nun denn…

Vor­ge­schich­te

Unser Schul­ser­ver migriert zur Zeit auf leis­tungs­fä­hi­ge­re Hard­ware: Hetz­ner bie­tet die Vor­se­rie zu den aktu­el­len Model­len zur Zeit ohne Ein­rich­tungs­ge­bühr an. Inte­gra­ler Bestand­teil mei­nes Set­ups ist dabei OpenLDAP (Das Pen­dant bei Klein­weich Fens­ter heißt Acti­ve­Di­rec­to­ry – ist aber im Prin­zip eine LDAP-Imple­men­tie­rung). So braucht jeder nur ein Pass­wort für alle Diens­te, die die Schu­le zur Zeit anbie­tet. Prin­zi­pi­ell ist das alles mög­lich, was mit LDAP spricht – und etwas ande­res kommt mir eh nicht auf die Plat­te. Mood­le, Maha­ra, Word­Press, Egroup­ware, Elgg, Media­Wi­ki usw. spre­chen zumin­dest alle­samt LDAP wie auch unser Mailsystem.

Es lag nahe, bei dem Umzug gleich auch die Ser­ver­soft­ware auf eine aktu­el­le­ren Stand zu brin­gen: Bis­her nutz­te ich Ubun­tu 8.04 LTS (Har­dy Heron) mit drei von­ein­an­der getrenn­ten vir­tu­el­len Maschi­nen (eine für die Home­page, eine für Mood­le & Co. und eine zum Spie­le für die inter­es­sier­ten Kol­le­gin­nen und Kollegen.

Das Set­up war Mist, weil sich drei (mit der domU sogar vier) unter­schied­li­che Maschi­nen schwer war­ten und sichern las­sen. Außer­dem ver­schluck­te sich der Hyper­vi­sor stets, wenn mehr als zwei CPU-Ker­ne zu vir­tua­li­sie­ren waren, sodass effek­tiv nur ein Kern nutz­bar wur­de.  Daher schwen­ke ich nun um auf Ubun­tu 10.04 LTS (Lucid) und fas­se die vir­tu­el­len Maschi­nen zu einer zusam­men – dann gibt es auch etwas mehr Power, wenn­gleich auch spä­te­re Erzie­hungs­maß­nah­men hin zur Nut­zung von FTPS und eine stren­ge­re Poli­cy für den Zugriff von Kol­le­gen auf den Ser­ver auf Fileebene.

Der Kampf

Lucid kommt mit OpenLDAP 2.4 daher. Neu ist vor allem, dass slapd nun sei­ne sämt­li­chen Kon­fi­gu­ra­ti­ons­da­ten in einem sepa­ra­ten LDAP-Baum spei­chert und neu ist vor allem, dass das ent­spre­chen­de Paket in Lucid nur sehr mager vor­kon­fi­gu­riert ist – z.B. ist ledig­lich das core-Sche­ma inte­griert. Ich brau­che für mei­nen LDAP jedoch zusätz­lich fol­gen­de Sche­men: cosi­ne, inet­org­per­son, qmail. Die Sche­men müs­sen in die Daten­bank. Freund­li­cher­wei­se lie­fert Lucid eine Rei­he von Sche­men mit:

lda­padd ‑Y EXTERNAL ‑H ldapi:/// ‑f /etc/ldap/schema/cosine.ldif
lda­padd ‑Y EXTERNAL ‑H ldapi:/// ‑f /etc/ldap/schema/inetorgperson.ldif

… auf der Kom­man­do­zei­le lösen schon­mal die ers­ten zwei Pro­ble­me. Das qmail-Sche­ma ist ein beson­de­rer Kan­di­dat. Es wird nicht mit­ge­lie­fert und ist auch im Web (noch?) nicht für Debi­an­de­ri­va­te zu fin­den, sodass ich die alte Sche­ma­da­tei  aus Har­dy erst kon­ver­tie­ren muss­te. Da ich so gelit­ten habe – Feh­ler­aus­ga­ben lesen und Intui­ti­on waren hier als Kern­kom­pe­ten­zen gefragt, prä­sen­tie­re ich hier ein­fach das End­ergeb­nis in Form einer impor­tier­ba­ren LDIF- Datei: qmail.ldif. Das Attri­but mail­Host ließ sich jedoch nicht zur Mit­ar­beit mit OpenLDAP 2.4 über­re­den – ich brau­che es nicht und ver­mu­te, dass mit dem Seri­al da etwas nicht stimmt. Ein beherztes

lda­padd ‑Y EXTERNAL ‑H ldapi:/// ‑f /etc/ldap/schema/qmail.ldif

füg­te dann das Sche­ma hin­zu. Dann braucht es einen Admi­n­ac­count für OpenLDAP – also frü­her war das leich­ter, heu­te müs­sen auch die­se Daten in Lucid per LDIF impor­tiert wer­den – der  Lucid-Instal­ler fragt nichts ab, son­dern hin­ter­lässt eine Instal­la­ti­on der 1000 Fragezeichen:

# Load dyna­mic backend modules
dn: cn=module,cn=config
object­Class: olcModuleList
cn: module
olc­Mo­dule­path: /usr/lib/ldap
olc­Mo­du­lel­oad: back_hdb

# Data­ba­se settings
dn: olcDatabase=hdb,cn=config
object­Class: olcDatabaseConfig
object­Class: olcHdbConfig
olcDa­ta­ba­se: {1}hdb
olc­Suf­fix: dc=schule,dc=tld
olcDbDi­rec­to­ry: /var/lib/ldap
olcRootDN: cn=admin,dc=schu­le,dc=tld
olcRootPW: secret
olcDbCon­fig: set_cachesize 0 2097152 0
olcDbCon­fig: set_lk_max_objects 1500
olcDbCon­fig: set_lk_max_locks 1500
olcDbCon­fig: set_lk_max_lockers 1500
olcDb­In­dex: object­Class eq
olcLast­Mod: TRUE
olcDb­Check­point: 512 30
olc­Ac­cess: to attrs=userPassword by dn=„cn=admin,dc=schule,dc=tld“ wri­te by anony­mous auth by self wri­te by * none
olc­Ac­cess: to attrs=shadowLastChange by self wri­te by * read
olc­Ac­cess: to dn.base=““ by * read
olc­Ac­cess: to * by dn=„cn=admin,dc=schule,dc=tld“ wri­te by * read

„schu­le“, „tld“ und „secret“ sind an die eige­nen Bedürf­nis­se anzu­pas­sen. Die Datei dann als TXT unter dem Namen create_database.ldif spei­chern. Unten wer­den die Berech­ti­gun­gen für den Zugriff „so wie frü­her“ gesetzt, d.h. z.B. Mood­le kann die rele­van­ten Daten per Anony­mous Bind (ja, der LDAP-Port ist an local­host gebun­den) aus­le­sen ohne das Pass­wort eines Bin­du­sers im Klar­text durch die Gegend zu pus­ten. Mit

lda­padd ‑Y EXTERNAL ‑H ldapi:/// ‑f create_database.ldif

geht es dann ab in den LDAP-Baum. Im nächs­ten Schritt muss die­se Daten­bank noch initia­li­siert wer­den. Das geht – man erkennt eine gewis­se Kon­se­quenz – wie­der über eine LDIF-Datei:

# Crea­te top-level object in domain
dn: dc=schule,dc=tld
object­Class: top
object­Class: dcObject
object­class: organization
o: Schu­le Organization
dc: schule
descrip­ti­on: LDAP Example

# Admin user.
dn: cn=admin,dc=schule,dc=tld
object­Class: simpleSecurityObject
object­Class: organizationalRole
cn: admin
descrip­ti­on: LDAP administrator
user­Pass­word: secret

Die­se Datei spei­chert man z.B. unter populate.ldif. Jetzt wird es ein wenig anders, da wir direkt an der Wur­zel­da­ten­bank mit slapd her­um­pfu­schen wol­len und er uns das nur mit einem ech­ten Bind tun lässt – brav:

lda­padd ‑x ‑D cn=admin,dc=schule,dc=tld ‑W ‑f populate.ldif

Er fragt uns dann nach dem Pass­wort („secret“) aus der create_database.ldif. Wenn wir es im geben, ist danach alles so wie unter frü­he­ren slapd-Ver­sio­nen mit einer schlich­ten Kon­fi­gu­ra­ti­ons­da­tei statt eines config-Baumes.

phplda­pad­min

phplda­pad­min ist zwar fei­ge, aber kann hübsch zur Kon­trol­le dar­über ver­wen­det wer­den, was man wie­der ein­mal mit sei­nen Kom­man­do­zei­len­scrip­ten zum Befül­len des LDAP ver­bockt hat. Das Tool beherrscht noch nicht den Zugriff auf den Kon­fi­gu­ra­ti­ons­baum (was doof ist). Des­we­gen müs­sen wir ihm den ver­meint­li­chen Wur­zel­baum in sei­ner config.php unterschieben:

/*********************************************/
/* Defi­ne your LDAP ser­vers in this section */
/*********************************************/

$ser­vers = new Datastore();

/* $servers->NewServer(‚ldap_pla‘) must be cal­led befo­re each new LDAP server
declaration. */
$servers->newServer(‚ldap_pla‘);

/* A con­ve­ni­ent name that will appear in the tree view­er and throughout
phpLDA­Pad­min to iden­ti­fy this LDAP ser­ver to users. */
$servers->setValue(’server‘,’name‘,‚Schulname‘);

/* Examp­les:
‚ldap.example.com‘,
‚ldaps://ldap.example.com/‘,
‚ldapi://%2fusr%local%2fvar%2frun%2fldapi‘
(Unix socket at /usr/local/var/run/ldap) */
$servers->setValue(’server‘,‚host‘,‚127.0.0.1‘);

/* The port your LDAP ser­ver lis­tens on (no quo­tes). 389 is standard. */
// $servers->setValue(’server‘,‚port‘,389);

/* Array of base DNs of your LDAP ser­ver. Lea­ve this blank to have phpLDAPadmin
auto-detect it for you. */
$servers->setValue(’server‘,‚base‘,array(‚dc=schule,dc=tld‘));

$servers->setValue(‚login‘,‚bind_id‘,‚cn=admin,dc=schule,dc=tld‘);

Dann ist alles wie frü­her – zumin­dest bei mir. Auf jeden Fall soll­ten Tools wie phplda­pad­min und phpmy­ad­min spä­ter immer mit http-auth (z.B. .htac­cess) ver­ram­melt werden.

Ich grüb­le jetzt dar­an her­um, die Mai­l­an­ga­ben mit unter den cn’s der Per­so­nen im LDAP zu ver­wal­ten – bis­her lagen die in getrenn­ten Unter­bäu­men. Die qmail-Attri­bu­te sind schließ­lich von inet­org­per­son abge­lei­tet. Hübsch wäre ja auch, wenn man sich eige­ne Mai­la­lia­se und ‑wei­ter­lei­tun­gen set­zen könn­te. Dum­mer­wei­se wird unser Ser­verldap nicht vom Schull­dap repli­ziert, son­dern der Daten­aus­tausch erfolgt ein­mal täg­lich via LDIF, weil ich wirk­lich nur not­wen­di­ge Daten unser SuS im Netz sehen woll­te. Die zusätz­li­chen User­da­ten aus dem Web müss­te man also aus z.B. einer sepa­ra­ten Daten­bank gewin­nen oder ich lei­te einen Unter­baum aus dem bestehen­den ab… Mal schau­en – das läuft ja schon alles per Script.

This work by Maik Riecken is licen­sed under a Crea­ti­ve Com­mons Attri­bu­ti­on-Non­Com­mer­cial-ShareA­li­ke 4.0 International