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.

Hybris

riecken.de war seit ges­tern Abend bis heu­te ca. 10:12 Uhr down. Nach ers­ter Ana­ly­se der Kata­stro­phe habe ich get­wit­tert:

riecken.de ist down. Aber so rich­tig. Mor­gen im Lau­fe des Tages :o)…

An der Geschich­te dazu kann man sehr schön sehen, wie man sich im Ser­ver­be­trieb nicht ver­hal­ten soll­te. Ich schrei­be mal das Elend auf:

  1. Die Schul­home­page muss­te mal irgend­wann von Joom­la 2.5.x auf Joom­la 3.x geup­datet wer­den. Um das vor­zu­be­rei­ten, habe ich das mal eben auf mei­nen eige­nen Ser­ver nach­ge­baut, d.h. besag­te Home­page 1:1 kopiert.
  2. Das Update klapp­te nach dem Ent­fer­nen des von einer Agen­tur erstell­ten The­mes und Umschal­tung auf ein Stan­dard­the­me, ließ mich aber wis­sen, dass die PHP-Ver­si­on von Debi­an squee­ze zu alt dafür sei.

Es gab jetzt meh­re­re Mög­lich­kei­ten:

  1. eine neue­re PHP-Ver­si­on aus den Debi­an­back­ports ein­spie­len
  2. es auf einem ande­re Ser­ver mit Debi­an whee­zy noch­mal ver­su­chen
  3. gleich die Gunst der Stun­de nut­zen und den Ser­ver auf whee­zy updaten

Da es schnell und mög­lichst „unat­ten­ded” (ohne Nut­zer­ein­griff von mir) gehen soll­te, war natür­lich Vari­an­te 3 nahe­lie­gend. Eigent­lich macht man vor so einem Ein­griff noch­mal ein Back­up — das geht bei mei­nem Hos­ter sogar beson­ders bequem — es han­del sich um einen KVM-VSer­ver, der mir einen Snapshot erlaubt (Apple hat die­ses uralte Ver­fah­ren aus der Unix­welt kopiert, mit einer groo­vi­gen Ober­flä­che ver­se­hen und nennt es Time­Ma­chi­ne), d.h. ich kann den Zustand des Sys­tems per Klick sichern und spä­ter im Feh­ler­fall wie­der her­stel­len — nur ver­bun­den mit einer kur­zen Down­ti­me.

Och, bei dei­nen letz­ten Debian­up­dates ist noch nie was schief­ge­gan­gen.

Dies­mal schon. Meh­re­re essen­ti­el­le Diens­te lie­fen in nicht auf­lös­ba­re Paket­kon­flik­te und moch­ten nicht mehr star­ten. Außer dem dem fami­liä­ren Mail­sys­tem ging nichts mehr. Auch das soll­te sich noch ändern.

Die gran­dio­se Idee:

Ich siche­re das Sys­tem jeden Tag inkre­men­tell bei mir zu Hau­se über einen rsync-Mecha­nis­mus (genau der dürf­te auch hin­ter Time­Ma­chi­ne ste­cken), d.h. ich kann an jeden Tag der letz­ten drei Mona­te zurück­ge­hen. Also flugs den alten Datei­zu­stand wie­der hin­über­ko­piert. Ergeb­nis: Sys­tem uner­reich­bar und star­tet nicht mehr.

Hm. Eh egal. Der Ser­ver wur­de neu mit Debi­an squee­ze instal­liert und nach­mal eine Rück­si­che­rung pro­biert. Ergeb­nis: Bei VSer­vern klappt das mit der Rück­si­che­rung so offen­bar nicht.

Na dann. Neu­es Debi­an whee­zy Image drauf und auf die har­te Tour nach und nach die wich­tigs­ten Diens­te kon­fi­gu­rie­ren (die Con­fig­da­tei­en gab es ja in der Siche­rung). Mit einem Upload von 6Mbit/s dau­ert die Daten­über­tra­gung nun natür­lich etwas län­ger als die Daten­si­che­rung (100 Mbit/s Down­stream). Ver­schärft wird das dadurch, dass wir imap nut­zen und so ca. 2GB in klei­nen Datei­en brau­chen durch den Pro­to­koll­over­head noch­mal län­ger.

Aber nach ca. 1,5 Stun­den akti­ver Arbeit am PC mit meh­re­ren im Hin­ter­grund lau­fen­den Screen­ses­si­ons für die Kopier­pro­zes­se lau­fen jetzt die wich­tigs­ten Mail- und Web­diens­te wie­der und ich kann jetzt kom­for­ta­bel den Rest Stück für Stück nach­zie­hen. Neben­bei habe ich Debi­an whee­zy als Unter­bau und damit PHP5.4.x — da könn­te ich doch gleich mal eben die Schul­home­page …

Leh­ren

  • Wenn etwas weg ist, merkst du erst sei­ne Wich­tig­keit
  • Nie­mand will ein Back­up, alle wol­len ein Res­to­re
  • Arbeits­pro­zes­se, die man im Job selbst­ver­ständ­lich macht, haben auch ihren Sinn im pri­va­ten Umfeld
  • Die binä­ren Daten­bank­da­tei­en von MySQL5.1 und MySQL5.5 sind zuein­an­der kom­pa­ti­bel

 

Running on lenny…

Pein­lich genug: Durch sources.list-Gemurkse hat­te mein gutes Ser­ver­lein für den Pri­vat­ge­brauch irgend­wie die ver­wund­ba­ren SSH-Keys aus opens­sl nicht kuriert — darf man eigent­lich gar nicht erzäh­len… Das ist dan­kens­wer­ter Wei­se dadurch auf­ge­fal­len, dass ich einen SSL-Key durch eine CA unter­schrei­ben las­sen woll­te. Tja, und http://www.psw.net ver­wei­ger­te dar­auf doch gleich die Annah­me mei­nes Schlüs­sels  (vul­nerable key used), sehr emp­feh­lens­wer­te Fir­ma. Und da dach­te ich mir: Wenn schon, denn schon.

Ergeb­nis:

riecken.de läuft seit eben auf der neu­en, sta­bi­len Debi­an­ver­si­on Len­ny. Ich hat­te noch kurz über­legt, vor­her MyS­QL zu repli­zie­ren und den Stand­by­mail­ser­ver auf Funk­ti­on zu über­prü­fen — aber: no risk, no fun. Ein Back­up-MX wäre viel­leicht ein­mal ein Pro­jekt.

Eine Ant­wort auf pings nach der „reboot”-Eingabe hat doch etwas beru­higt, obwohl das hier kein Pro­duk­tiv­sys­tem ist. Das Back­up lag hier zu Hau­se auf der Plat­te und wäre auch Dank Kabel­deutsch­land recht schnell wie­der online gewe­sen — aber so ist es doch viel bes­ser. Ich mag Debi­an.

End­lich xcache und diver­se ande­re, neue Soft­ware­ver­sio­nen… Neben­bei fällt einem dann auch noch auf, dass poli­cy-weight irgend­wann ama­vis-Expe­ri­men­ten geop­fert wur­de. Der tut jetzt auch wie­der sei­nen Dienst — Post­fix hat aber schon so mit den ein­ge­bau­ten Fil­tern ziem­lich viel Mist weg­ge­fan­gen.