OpenLDAP ab 2.4 installieren und einrichten

Vorweg

Mir ist kei­ne Quel­le im Netz bekannt, die die Ein­rich­tung von OpenLDAP wirk­lich umfas­send dar­stellt — schon gar nicht auf Deutsch. Die­se Infor­ma­tio­nen hier sind aus allen mög­li­chen Ecken zusam­men­ge­klaubt — selbst die meis­ten Bücher zu OpenLDAP emp­fin­de ich als sehr wenig hilf­reich.

Grundinstallation

Hin­weis: domain.tld muss man natür­lich immer an den eige­nen openLDAP anpas­sen.

Zuerst instal­lie­ren wir die Bina­ries, in Debi­an und sei­nen Abkömm­lin­gen (Ubun­tu, Mint etc.) z.B. so:

1
apt-get install slapd ldap-utils

Die Instal­la­ti­ons­rou­ti­ne von Debi­an legt dabei nur eine sehr rudi­men­tä­re Kon­fi­gu­ra­ti­on an, sodass etwas Nach­ar­beit von­nö­ten ist. Bei ande­ren Dis­tri­bu­tio­nen ken­ne ich mich nicht so gut aus. Ein

1
dpkg-reconfigure slapd

ermög­licht uns hier die Ein­ga­be einer kor­rek­ten Basis-DN (auf die muss unser SSL-Zer­ti­fi­kat aus­ge­stellt sein), meist sowas wie

  • dc=domain, dc=tld

und zusätz­lich defi­nie­ren wir dabei ein Root­pass­wort für den LDAP-User

  • cn=admin,dc=domain,dc=de

.

Handling von OpenLDAP

Ab Debi­an Squee­ze spei­chert der OpenLDAP-Ser­ver sei­ne Kon­fi­gu­ra­ti­on in einem inter­nen LDAP-Baum und nicht mehr in einem Kon­fi­gu­ra­ti­ons­file. Das macht die Pfle­ge auf den ers­ten Blick erheb­lich auf­wän­di­ger, weil man an die­sen Baum in der Stan­dard­kon­fi­gu­ra­ti­on nur umständ­lich über Kon­so­len­tools her­an­kommt. Zudem kann eine feh­ler­haf­te Daten­bank dazu füh­ren, dass der OpenLDAP nach einer Kon­fi­gu­ra­ti­ons­än­de­rung gar nicht mehr hoch­kommt.
Nur der Root­be­nut­zer des Sys­tems kommt immer auch direkt an die Daten. Man kann sich die bestehen­den Inhalt nur als root anzei­gen las­sen mit:

1
ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

Neue Ein­trä­ge kön­nen über *.ldif-Files hin­zu­ge­fügt wer­den:

1
ldapmodify/ldapadd -Y EXTERNAL -H ldapi:/// -f
Hinweis zu Ubuntu 14.04 LTS

Der Instal­ler setzt den Account­na­men für den Benut­zer mit Zugriff auf den cn=config-Baum stan­dard­mä­ßig auf: cn=admin,dc=domain,dc=tld. Dann macht man Befol­gen die­ser Anlei­tung ein lan­ges Gesicht. Um das auf den Stan­dard zu ändern, benö­tigt man nur für Ubun­tu 14.04 LTS noch eine klei­ne Ände­rung (change_admin.ldif):

1
2
3
4
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,cn=config

Obli­ga­to­risch:

1
ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f change_admin.ldif

Sicherheit

OpenLDAP-Verbindungen per TLS absichern

Vor­weg: Hier kann ganz viel schief­ge­hen, obwohl ich die­ses Kapi­tel mit am wich­tigs­ten fin­de. Wenn OpenLDAP aus irgend­wel­chen Grün­den die Zer­ti­fi­kat­files nicht frisst, kann man mit der Kon­fi­gu­ra­ti­on von vor­ne begin­nen oder man hat vor­her ein Back­up der alten Daten­bank gemacht. Des­we­gen über­sprin­ge ich die­sen Schritt ger­ne und bin­de den OpenLDAP ein­fach nicht an öffent­lich erreich­ba­re Netz­werk­de­vices. Wenn man das machen muss, führt aus Daten­schutz­grün­den aber kein Weg an die­ser Pro­ze­dur hier vor­bei. LDAP ist genau wie FTP ein Klar­text­pro­to­koll, dass ohne Trans­port­ver­schlüs­se­lung auf dem gesam­ten Daten­weg offen­liegt und gera­de in WLAN-Umge­bun­gen sehr leicht belauscht wer­den kann.
Gene­rell gibt es zwei Mög­lich­kei­ten, wie man an kos­ten­lo­se Zer­ti­fi­ka­te kom­men kann. Wosign oder StartS­SL. Es gibt diver­se Tuto­ri­als im Netz zur Nut­zung die­ser Diens­te. Von Let­sen­crypt wür­de ich im Kon­text von OpenLDAP eher abra­ten. StartS­SL und WoSign sind mitt­ler­wei­le Geschich­te. Wenn es kos­ten­los sein soll, führt kein Weg an let­sen­crypt vor­bei. Man muss dann dafür sor­gen, dass OpenLDAP nach jedem Cert­up­date neu gestar­tet wird, also alle drei Mona­te min­des­tens.

Man hat am Ende des Zer­ti­fi­zie­rungs­pro­zes­ses in der Regel drei Datei­en vor­lie­gen:

  1. domain.tld-crt.pem (ent­hält das Zer­ti­fi­kat)
  2. domain.tld-key.pem (ent­hält den pri­va­ten Schlüs­sel)
  3. ca_chain.pem (ent­hält die Zer­ti­fi­zie­rungs­chain der CA)

domain.tld ist dabei der Wur­zel­baum des openLDAP. Ich habe die Datei­en nach /etc/ldap/ssl gelegt. Bes­ser auf­ho­ben sind sie in /etc/ssl/cert — dann muss slapd Lese­rech­te dort bekom­men.

Fol­gen­de Datei (tls_ldap.ldif) anle­gen:

1
2
3
4
5
6
7
8
9
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/domain.tld-crt.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/domain.tld-key.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ca_chain.pem

… und über die Kon­so­le ein­spie­len:

1
ldapadd -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

oder auch

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

Ich bin zusätz­lich ein Freund davon, siche­re Ver­bin­dun­gen zu erzwin­gen. Cli­ents, die das nicht wol­len oder kön­nen, sol­len bit­te drau­ßen­blei­ben.

Fol­gen­de Datei (force_tls.ldif) anle­gen:

1
2
3
4
dn: olcDatabase={1}hdb,cn=config
changetype:  modify
add: olcSecurity
olcSecurity: tls=1

Und wie­der ein­spie­len:

1
ldapadd -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

oder auch

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

Jetzt noch in /etc/default/slapd nach­schau­en, ob die Ser­vices stim­men (ldaps über Port 639 gilt als ver­al­tet und soll­te nicht mehr ver­wen­det wer­den). In der Regel steht da so etwas:

1
SLAPD_SERVICES="ldap://0.0.0.0:389/ ldapi:///"

Wenn man meh­re­re NICs besitzt, kann man natür­lich statt 0.0.0.0 auch die IP einer spe­zi­fi­schen Netz­werk­kar­te ange­ben oder den OpenLDAP nur an local­host (127.0.0.1) bin­den.

Ein

1
service slapd restart

bringt Auf­klä­rung, ob das Gan­ze funk­tio­niert hat. Theo­re­tisch ist das nicht not­wen­dig, da OpenLDAP durch das neue Ver­fah­ren ohne Kon­fi­gu­ra­ti­ons­da­tei qua­si live im Betrieb gepatcht wird. Jetzt soll­te der OpenLDAP Ver­bin­dun­gen von außen nur noch ver­schlüs­selt akzep­tie­ren. Von der Kon­so­le aus ( ldapi:/// ) klappt das nach wie vor auch nor­mal. Wir ver­trau­en uns ja schon selbst.

Bruteforce erschweren

Ein offe­ner LDAP-Ser­ver ist anfäl­lig für bru­te-force Atta­cken — zumal gera­de im Schul­be­reich vie­le unsi­che­re Pass­wör­ter im Umlauf sein dürf­ten. Durch das ppolicy.schema kann man z.B. nach eini­gen fehl­ge­schla­ge­nen Log­ins den Account für eine Wei­le auto­ma­tisch sper­ren. openLDAP bringt das dafür not­wen­di­ge Sche­ma in /etc/ldap/schema/ppolicy.ldif schon mit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
dn: cn=ppolicy,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: ppolicy
olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY
  objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
olcAttributeTypes: {1}( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {2}( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {3}( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {4}( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {5}( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {6}( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUA
 LITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {7}( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthNLimit' EQ
 UALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {8}( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY b
 ooleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {9}( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' E
 QUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {10}( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {11}( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInter
 val' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
 )
olcAttributeTypes: {12}( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {13}( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange'
 EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {14}( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {15}( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' DESC 'L
 oadable module that instantiates "check_password() function' EQUALITY caseExa
 ctIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top
  AUXILIARY MAY pwdCheckModule )
olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXI
 LIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheck
 Quality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $
  pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange
  $ pwdAllowUserChange $ pwdSafeModify ) )

Ein­ge­spielt wird das Sche­ma mit:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f ppolicy.ldif

Das Sche­ma ppolicy.ldif selbst defi­niert nur Objek­te für das ent­spre­chen­de Modul, was jetzt noch gela­den wer­den muss, wofür wir eine Datei policy_module.ldif mit fol­gen­dem Inhalt anle­gen:

1
2
3
4
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

Und das alte Spiel:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_module.ldif

Jetzt brau­chen wir noch eine Abla­ge (policy_context.ldif) für die ver­schie­de­nen Regel­sät­ze:

1
2
3
4
dn: ou=policies,dc=domain,dc=tld
objectClass: organizationalUnit
objectClass: top
ou: policies
1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_context.ldif

Und als nächs­tes eine Default-Poli­cy (default_policy.ldif):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
dn: cn=default,ou=policies,dc=domain,dc=tld
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: 2.5.4.35
pwdMaxAge: 15552000
pwdInHistory: 3
pwdMinLength: 6
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE

In die­sen Bei­spiel wird nach drei fehl­ge­schla­ge­nen Log­in­ver­su­chen ( pwd­Max­Fail­u­re: 3 ) das Log­in für 1800 Sekun­den ( pwd­Lock­out­Du­ra­ti­on: 1800 ) gesperrt. Das soll­te kleb­rig genug sein.

Muss ich es noch schrei­ben?

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f default_policy.ldif

Da OpenLDAP ja so fluffig und intui­tiv ist, brau­chen wir jetzt noch ein Over­lay (policy_overlay.ldif), dass dem OpenLDAP sagt, dass statt des nor­ma­len Log­in­hand­lings jetzt immer auch die Default-Poli­cy gel­ten soll:

1
2
3
4
5
6
7
dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=tld
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE

Ihr wisst, was jetzt kommt:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_overlay.ldif

Damit hät­ten wir grund­sätz­lich ver­schlüs­sel­te Ver­bin­dun­gen erzwun­gen und zusätz­lich Bru­teforce-Angrif­fe erschwert. Bleibt noch eines zu tun:

Anonymous-Bind verbieten

Stan­dard­mä­ßig erlaubt openLDAP einen soge­nann­te anony­mous bind, d.h. man erhält lesend Zugriff auch ohne die Ein­ga­be eines Pass­wor­tes. Die­se lesen­de Zugriff ist sehr ein­ge­schränkt, z.B. gibt es kei­nen Zugriff auf bestimm­te Objekt­klas­sen oder gar Pass­wort­hash­es. Mir ist die Vor­stel­lung trotz­dem nicht geheu­er, dass sich u.a. Nut­zer­na­men auf die­sem Weg aus­le­sen las­sen. Daher ver­wen­de ich für den lesen­den Zugriff einen sepa­ra­ten User, der sich mit Pass­wort authen­ti­fi­zie­ren muss, ansons­ten aber nicht mehr Rech­te als beim anony­mous bind hat. Des­we­gen unter­bin­den wir das mit einer neu­en Datei noanonymous.ldif:

1
2
3
4
5
6
7
dn: olcDatabase={1}hdb,cn=config
add: olcRequires
olcRequires: authc
 
dn: olcDatabase={-1}frontend,cn=config
add: olcRequires
olcRequires: authc

Und jetzt kommt etwas ande­res, weil wir einen bereits bestehen­den Daten­bank­ein­trag aktua­li­sie­ren:

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f noanonymous.ldif

Nach dem Ein­spie­len der letz­ten Ände­rung hat man ohne Authen­ti­fi­zie­rung auch über die Kon­so­le kei­nen Zugriff mehr auf den Haupt­baum des OpenLDAP (dc=domain, dc=tld) — die war bis­her auch sowas wie „anonym” aus Sicht des LDAP. Man muss dann aus­wei­chen auf eine ande­re Befehls­zei­le (cn=config ist davon nicht betrof­fen):

1
ldapadd -x -D cn=admin,dc=domain,dc=tld -W -f

Danach wird man zur Ein­ga­be des Admin­pass­wor­tes auf­ge­for­dert und kann so den Haupt­baum beschrei­ben und ver­än­dern.

Optionale Arbeiten

Performancetuning

Die­se Datei ( index.ldif )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq

ein­spie­len mit

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f index.ldif
Benutzer für die Administration von cn=config einrichten

Wenn man sauch den cn=config-Baum auch über kom­for­ta­ble­re Front­ends wie phplda­p­ad­min oder LAM ver­wal­ten möch­te, muss man das Objekt cn=admin, cn=config noch um wei­te­re Ein­trä­ge ergän­zen. Zunächst erzeu­gen wir uns über die Kon­so­le ein Pass­wort:

1
slappasswd -h {SSHA}

Wir erhal­ten einen Hash zurück, den wir in die Zwi­schen­ab­la­ge kopie­ren. Jetzt erstell­ten wir ein ldif-File (manager.ldif):

1
2
3
4
5
6
7
8
9
10
11
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}
 
# auskommentieren, wenn wir den Zugriff von root  auf cn=config 
# ohne Passwort sperren wollen. Sollte als Fallback besser erhalten bleiben
 
#dn: olcDatabase={0}config,cn=config
#changetype: modify
#delete: olcAccess
1
ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f manager.ldif

Wenn wir jetzt in phplda­p­ad­min (ab Ver­si­on 1.2.2) oder lam als Base-DN cn=config ver­wen­den und als Log­in cn=admin, cn=config, kön­nen wir cn=config auch gra­fisch ver­wal­ten.

Quel­le: https://wiki.debian.org/PhpLdapAdmin

War doch ganz einfach oder?

OpenLDAP ist extrem sper­rig, aber eine her­vor­ra­gen­de Authen­ti­fi­zie­rungs­mög­lich­keit, da im Gegen­satz zu Daten­bank­sys­te­men die Struk­tur hoch­gra­dig stan­dar­di­siert sowie mus­ter­gül­tig objekt­ori­en­tiert ist und sich OpenLDAP so recht schnell in belie­bi­ge Anwen­dun­gen inte­grie­ren lässt — fast alle ernst­zu­neh­men­den Online­tools unter­stüt­zen die Authen­ti­fi­zie­rung über LDAP. OpenLDAP dien­te nicht umsonst nicht als Vor­la­ge für die LDAP-Funk­tio­nen von Samba4 — weil es eben so sper­rig ist.

Etherpad, nochmal Etherpad

Lighttpd ver­mit­telt jetzt den Kon­takt zu unse­rem Ether­pad, das nur nur unter local­host zu errei­chen ist:

$HTTP[„host”] =~ „^(.+\.)?etherpad.schuldomain.tld” {

auth.require = ( „” => ( „method” => „basic”,
„realm” => „Ether­pad — Log­in mit Schul­netz­werk­da­ten”,
„requi­re” => „valid-user” )
)

proxy.server = (
„” => (
„ether­pad” => (
„host” => „127.0.0.1”,
„port” => 9000,
„fix-redi­rects” => 1
)
)
)

}

Mit­tels HTTP_AUTH, dass gegen den LDAP läuft, ist das Sys­tem nur Netz­werk­nut­zern der Schu­le zugäng­lich (auth.require-Sektion). Das Proxy­mo­dul von lighttpd (proxy.server-Sektion) sorgt dann dafür, dass der Brow­ser ohne Port­an­ga­be direkt auf die Pads zugrei­fen kann und dafür, dass die Sub­do­mains für die Team­si­tes funk­tio­nie­ren.

Ich habe die Pads für ein Web­quest zur Regel­fin­dung zur Getrennt- und Zusam­men­schrei­bung in Klas­se 9 ein­ge­setzt. Im ers­ten Teil der Dop­pel­stun­de haben wir eine Regel für eine Zusam­men­set­zung (Adjek­tiv + Verb) anhand von Mate­ri­al selbst erar­bei­tet und for­ma­le Kri­te­ri­en fest­ge­legt. Im zwei­ten Teil der Dop­pel­stun­de habe ich je einer Grup­pe einen Aspekt (z.B. Schrei­bung von Tages­zei­ten) zuge­wie­sen, ein paar hilf­rei­che Sei­ten ver­linkt und kol­la­bo­ra­tiv eige­ne Regel­for­mu­lie­run­gen im Pad erar­bei­ten las­sen.  Die Auf­ga­ben­stel­lung und die Links befan­den sich in einem Mood­le­kurs.

Am Fol­ge­tag haben wir die Ergeb­nis­se — dies­mal auf Tot­holz aus­ge­druckt — bespro­chen und anhand der Regeln, die sicher for­mu­liert waren, klei­ne Übungs­sätz mit gehäuf­ten Schwie­rig­kei­ten zur Getrennt- und Zusam­men­schrei­bung erson­nen. Die­se Metho­dik war zumut­bar, weil das The­ma für die Klas­se ein „Wie­der­ho­lungs­fall” ist, es also mehr um eine Reak­tua­li­sie­rung ging.

Ether­pad ver­brauch­te bei 15 akti­ven Cli­ents ca. 200MB RAM und etwa 9% CPU-Zeit — beschau­lich…

Der neue Schulserver

In der letz­ten Woche habe ich mich mit der Kon­fi­gu­ra­ti­on unse­res neu­en Schul­ser­vers abge­müht — im Spe­zi­el­len mit dem Mail­ser­ver. Ich kon­fi­gu­rie­re Mail­ser­ver in etwa so ger­ne wie ich zum Zahn­arzt gehe, weil die Bies­ter recht ver­trackt und kom­plex sind. Außer­dem wird der Mail­ser­ver zuneh­mend dienst­lich genutzt, d.h. auch für die inter­ne Kom­mu­ni­ka­ti­on unter Lehr­kräf­ten, muss also eini­ger­ma­ßen zuver­läs­sig funk­tio­nie­ren. Es sieht all­mäh­lich end­lich gut aus. Was macht unse­ren Mail­ser­ver so beson­ders ver­trackt?

  1. Es ist ein Viren­fil­ter inte­griert, zur Zeit cla­mav. Die­ser prüft sowohl Mails, die von außen hin­ein­kom­men, als auch sol­che, die unse­re Schü­ler und Lehr­kräf­te ein­lie­fern. So gelangt der Virus vom schlecht gewar­te­ten Schü­ler-PC nicht in eine ande­re Mail­box, son­dern kommt ein­fach mit einem aus­sa­ge­kräf­ti­gen Ver­merk zurück.
  2. Es ist ein Spam­fil­ter inte­griert, zur Zeit spa­m­as­sas­sin. Die­ser mar­kiert alles Ver­däch­ti­ge mit einem „*** SPAM ***” im Betreff, sodass der Nut­zer frei fil­tern kann. Schwie­rig ist, dass es das auch bei Mails tut, die KuK oder SuS ein­lie­fern und wenn die­se z.B. an die gan­ze Klas­se sen­den, erhö­hen die zusätz­li­chen Emp­fän­ger den SpamS­core doch beträcht­lich. Da muss man etwas trick­sen.
  3. Wir set­zen auf dem Ser­ver LDAP als zen­tra­le Authen­ti­fi­zie­rungs­me­tho­de ein. Man muss sowohl post­fix als MTA als auch SASL (sas­lau­thd) dazu über­re­den, mit dem LDAP zu kom­mu­ni­zie­ren. Letz­te­res ist nicht ganz ein­fach — aber jetzt kön­nen Mails sowohl lokal als auch via E-Mail­cli­ent ein­ge­lie­fert wer­den.
  4. Als Web­mail­ober­flä­che wird Round­cu­be zum Ein­satz kom­men — sehr auf­ge­räumt und fast wie Out­look…

Nach­dem die­se inte­gra­le Geschich­te end­lich läuft, kann ich mich um Schman­kerl wie SMTP-SSL, IMAP-SSL  (POP3 wer­de ich nicht mehr anbie­ten…) und WEB-SSL küm­mern, um damit anzu­bie­ten, alle unse­re Diens­te auch ver­schlüs­selt zu nut­zen. Dank Level-2-Zer­ti­fi­zie­rung kann ich mir jetzt Zer­ti­fi­ka­te signie­ren las­sen bis der Arzt kommt.

Dann steht die Karos­se­rie und die bun­te Hül­le kann dar­über gezo­gen wer­den (Mood­le, Maha­ra, Wor­d­Press­MU, Frox­lor…). Aber das ist im Prin­zip Kin­der­ka­cke…

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 Active­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, Wor­d­Press, Egroup­ware, Elgg, Media­Wi­ki usw. spre­chen zumin­dest alle­samt LDAP wie auch unser Mail­sys­tem.

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 Kol­le­gen.

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 Filee­be­ne.

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­or­g­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

Wei­ter­le­sen

MME — Moodle Mail Essentials

Aus Mood­le­sys­te­men wer­den vie­le Mails ver­schickt:

  • Mails bei neu­en Foren­bei­trä­gen
  • Mails nach Benutz­er­re­gis­trie­run­gen
  • Mails für den Admin nach Back­u­pläu­fen
  • usw.

Je nach Grö­ße des Mood­le­sys­tems kön­nen das sehr vie­le Mails sein — z.B. wenn der Admin im Nach­rich­ten­fo­rum eine neue Nach­richt schreibt und alle Nut­zer des Sys­tems die­ses Forum abon­niert haben. Oft macht man dabei am Anfang die Erfah­rung, dass ein Teil die­ser Mails nicht ankommt. Dar­an ist sehr oft mit­nich­ten Mood­le schuld. Eini­ge Anbie­ter schie­ben zusätz­lich die Schuld auf Free­mail­diens­te, bei denen die Mails „aus uner­find­li­chen Grün­den” im Spam­ord­ner lan­den wür­den. Die Grün­de sind in den sel­tens­ten Fäl­len uner­find­lich, son­dern las­sen sich durch eine Ana­ly­se der betref­fen­den Mail sehr leicht ermit­teln. Es gibt also Aspek­te des Mail­pro­blems, die der Mood­le­ad­min lösen kann und es gibt Aspek­te, die nur der Pro­vi­der zu rich­ten ver­mag.

Wei­ter­le­sen

1 2