OpenLDAP telepítése (Wheezy)
Ebben a leírásban az OpenLDAP szervert "általános használatra" telepítjük. Directory backend sokféle célra használható; pl. adatbázis háttérként fájlszerver, levelező szerver vagy hálózatvezérlő számára, vagy akár általános single sign-on authentikációs címtár megvalósításaként. Mindezekhez az OpenLDAP egy adatbázis réteget biztosít, melynek telepítése és beállítása bizonyos mértékig független a konkrét felhasználástól.
Az LDAP elméleti alapjairól ld. ezt a wikilapot: LDAP alapok
Tartalomjegyzék
- 1 Telepítés
- 2 Beállítások
- 3 Replikáció
- 4 Karbantartási feladatok
- 5 Irodalom
Telepítés
A házirend szerint telepített és beállított szervergépre az OpenLDAP szervert (slapd) Debian csomagból telepítjük:
apt-get install slapd ldap-utils # + unixodbc(!) + könyvtárak
A telepítő kér egy jelszót az LDAP adminisztrátor (valójában az első, felhasználói címtár adminisztrátora) számára. Relatív erős, véletlen jelszót pl. a
pwgen -n -s -c 12 1
paranccsal generálhatunk. A csomagtelepítést követően a /usr partíciót írhatóan csatoljuk újra:
mount -o remount,rw /usr
és töltsük le, majd könyvtárhelyesen tömörítsük ki a legutóbbi kiadású openldap-addons.tgz csomagot! A csomag jelenleg a következőket biztosítja:
- openldap-dump script az OpenLDAP szerver konfigurációjának és felhasználói adatbázisainak mentésére;
- a fenti scriptet napi egyszeri alkalommal lefuttató cronjob.
A telepítést követően csatoljuk vissza a /usr partíciót read-only módban:
mount -o remount /usr
Beállítások
Egy OpenLDAP szerver több, egymástól független DIT alfát megvalósító címtárat kezelhet, és az adatbázis-kezelésre különböző backendeket használhat. A telepítő két címtárat hoz létre:
- egy konfigurációs címtárat (database #0) az LDAP szerver saját beállításai számára, LDIF backenddel;
- egy általános célú, felhasználói címtárat (database #1) HDB (hierarchical database, a Berkeley database módosítása) backenddel, amelynek gyökere egy Organisation osztályú csomópont lesz dn: dc=MYDOMAIN, dc=ORG azonosítóval (a használt domain nevet a hostname -d kimenetéből véve), és amelyben egyetlen gyermek elem van, az LDAP adminisztrátort reprezentáló simpleSecurityObject, organizationalRole osztályú dn: cn=admin, dc=MYDOMAIN, dc=ORG azonosítójú elem.
Ebben a leírásban elsősorban az LDAP szerver saját beállításaival foglalkozunk, a felhasználói címtárat egyelőre békén hagyjuk.
Kezelőfelület
Az OpenLDAP jelenlegi verziójában a slapd konfigurációja már nem a /etc/ldap/slapd.conf beállító állományban található, hanem egy LDIF backend-ű LDAP adatbázisban (ez a "nullás" adatbázis, amely logikailag a cn=config base DN alatt érhető el, fizikailag a /etc/ldap/slapd.d alatti könyvtárszerkezet *.ldif állományaiban lakik - ezekre az állományokra a fájlrendszerben csak az openldap:openldap Linux felhasználónak és csoportnak van írási és olvasási joga). A telepítő ezt az adatbázist (címtárat) automatikusan létrehozza és kezdeti értékekkel is feltölti.
Az adatbázisban tartott konfiguráció lehetővé teszi, hogy alkalmas LDAP klienssel (akár grafikus felületen, táveléréssel), a szervergépre történő konzolos belépés nélkül is lehessen módosítani az LDAP kiszolgáló beállításait (amennyiben a beállítás nem igényli a slapd újraindítását), de a konfigurációs adatbázist kezelhetjük és módosíthatjuk hagyományosabb módon, parancssori eszközökkel is.
Parancssoros kezelés
Ebben a leírásban az LDAP szerver konfigurációját parancssorból, root-ként fogjuk elvégezni, nagyjából úgy, mintha a /etc/ldap/slapd állományban szerkesztenénk; csak nem szövegszerkesztőt használunk, hanem LDAP kezelő segédprogramokat.
A csomagból telepített OpenLDAP konfigurációs adatbázisában szerepel az alábbi ACL bejegyzés:
dn: olcDatabase={0}config,cn=config [...] olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break [...]
amely teljes írási-olvasási hozzáférést biztosít ehhez az adatbázishoz a root (uid=0, gid=0) Linux felhasználónak. Emiatt a root-ként kiadott
ldapsearch -b "cn=config" -QY EXTERNAL -H ldapi:/// [...] # Keresés a cn=config adatbázisban (Linux felhasználóként authentikálva) ldapadd -QY EXTERNAL -H ldapi:/// -f [...] # Hozzáadás adatbázishoz (Linux felhasználóként authentikálva) ldapmodify -QY EXTERNAL -H ldapi:/// -f [...] # Módosítás adatbázisban (Linux felhasználóként authentikálva) ldapdelete -QY EXTERNAL -H ldapi:/// -f [...] # Törlés adatbázisból (Linux felhasználóként authentikálva)
parancsok minden külön jelszókérés nélkül lefutnak. Példaképpen a teljes konfigurációt (LDIF formában, kommentek nélkül - ld. -LLL paraméter) az alábbi paranccsal listázhatjuk ki:
ldapsearch -b "" -s base + -LLL -QY EXTERNAL -H ldapi:/// | less # Root DSE (dn=""), minden attribútum ldapsearch -b "cn=config" -LLL -QY EXTERNAL -H ldapi:/// | less # Konfigurációs adatbázis
A parancssoros kezelésre ezeket a segédprogramokat úgy fogjuk használni, hogy a konkrét módosításokat egy-egy ideiglenes LDIF állományban írjuk le, és a szükséges add/modify/delete parancsot root-ként, ezzel az ideiglenes állománnyal, mint -f [...] paraméterrel fogjuk meghívni. Ügyeljünk az alábbi formázási szabályokra:
- az LDIF állománynak nem szabad üres sorral kezdődnie;
- az állományon belül az elválasztóként alkalmazott üres sor új objektumot kezd (így egy LDIF-fel több objektum is módosítható);
- a sor elején egyetlen "-"-et tartalmazó elválasztó sor ugyanazon objektum többszörös adatmódosítását jelzi;
- a sor eleji egyetlen(!) space folytatósort jelöl.
Grafikus kezelőfelület
Ez a rész kihagyható, ha nem kívánjuk távolról, grafikus kezelőfelületen konfigurálni magát az LDAP szervert (a grafikus felület kényelmesebb lehet a manuálisan megírt LDIF-ek használatánál). Ez a rész a felhasználói címtárak (amelyeket az LDAP szerver szolgáltatni fog) esetleges távelérésére nem vonatkozik, azt később fogjuk beállítani.
A címtár(ak), így a konfigurációs adatbázis adatainak kezelése elvégezhető különböző grafikus felületet nyújtó kliensprogramokkal is (ingyenes és szabad szoftver LDAP kliensek pl. Windows alatt az LDAPAdmin, Linux desktop környezetben a GQ client vagy a LUMA). Mivel a szervergépen grafikus felület nincsen, ezeket távoli kliensgépen fogjuk futtatni, és az LDAP szerverhez valamilyen (TCP/IP) távelérést engedélyezünk.
TCP/IP account beállítása
Mivel a parancssori kezelésnél említett hozzáférés a root Linux felhasználó számára TCP/IP-n nem engedélyezett, szükséges valamilyen, a cn=config címtárhoz teljes hozzáférést biztosító authentikáció. Telepítéskor ugyan létrejön az erre alkalmas cn=admin,cn=config LDAP adatbázis account:
dn: olcDatabase={0}config,cn=config [...] olcRootDN: cn=admin,cn=config
azonban alapértelmezésben nincs hozzá jelszó beállítva. Készítsünk egy random jelszót (szöveges és SSHA hash formában) pl. az alábbi parancsokkal:
PW=$(pwgen -n -s -c 12 1); echo $PW; slappasswd -s $PW -h {SSHA}; PW= # Nem kerül a history-ba, csak a képernyőre :-) tCVXD2E63mmH {SSHA}M4Zoa7pJd06DZm0L4Ke5tPloC0a+MSsA
Jegyezzük fel a szöveges jelszót, majd egy ideiglenes LDIF állományban írjuk elő ennek használatát a {0}config,cn=config adatbázis root jelszavaként (ügyeljünk a generált hash pontos bemásolására (NE használjuk a példa adatait!):
mcedit /root/tmp/ldap-mod.ldif dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}M4Z[...]SsA
Hajtassuk végre a módosítást és ellenőrizzük, hogy bekerült-e a konfigurációs adatbázisba:
ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif # Ellenőrzés: olcRootPw szerepel, értéke a hash ldapsearch -b "cn=config" -LLL -QY EXTERNAL -H ldapi:/// -s one "olcDatabase={0}config" # Ha sikeres, ez már nem kell rm /root/tmp/ldap-mod.ldif
Ezután már TCP/IP protokollal is tudunk lekérdezéseket futtatni. Próbaképpen ismételjük meg a fenti lekérdezést a localhoston, TCP/IP protokollal és az imént beállított authentikációval:
ldapsearch -b "cn=config" -LLL -D "cn=admin,cn=config" -W -h localhost -s one "olcDatabase={0}config"
A feljegyzett jelszó begépelése után az előzővel megegyező eredményt kell látnunk. A fenti típusú TCP/IP lekérdezéseket a root-tól különböző Linux felhasználók is sikeresen végre tudják hajtani, akár táveléréssel is.
Távelérés beállítása
A táveléréshez védett belhálózat esetén a tűzfalon engedélyezzük a titkosítatlan LDAP forgalmat, egyébként állítsunk be valamilyen védett, titkosított hozzáférést. A grafikus kliensen a kapcsolódás paramétereit az alábbiak szerint állítsuk be:
base DN: cn=config felhasználó: cn=admin,cn=config jelszó: A fentebb beállított jelszó szöveges formában
Siker esetén az alábbiakhoz hasonló képernyőképeket kaphatunk (rákattintva teljes méretű):
Naplózás beállítása
A konfigurációs adatbázisban a naplózás szintjét (olcLogLevel) emeljük none-ról stats-ra. Ehhez készítsünk egy LDIF állományt:
mcedit /root/tmp/ldap-mod.ldif dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: stats
Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):
ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(cn=config)" olcLogLevel dn: cn=config olcLogLevel: stats rm /root/tmp/ldap-mod.ldif
Megjegyzés: a slapd tevékenységének naplózása általában nem szükséges (a monitorozást másképpen oldjuk meg), de hasznos lehet hibakutatás esetén. Üzemszerű használat esetén a terjedelmes logolás a teljesítményt leronthatja (mint pl. a mysqld esetén), így production környezetben a naplózást a beüzemelés után kikapcsolhatjuk.
Alapértelmezésben a slapd üzenetei a logcheck által ellenőrzött /var/log/syslog-ba mennek - ezt célszerű megváltoztatni, és a slapd számára külön logot definiálni. Ehhez szerkesszük meg a /etc/syslog-ng/syslog-ng.conf állományt, és írjunk elő egy külön destination-t az LDAP szerver által használt local4 facility naplózására:
-rw-r--r-- root root /etc/syslog-ng/syslog-ng.conf [...] ############## # Destinations ############## [...] # OpenLDAP slapd separate logging destination d_ldap { file ("/var/log/ldap/slapd.log" owner(root) group(adm)); }; [...] ############## # Filters ############## [...] # OpenLDAP slapd separate logging filter f_ldap { facility(local4); }; [...] ############# # Log paths ############# [...] # OpenLDAP slapd separate logging log { source(s_src); filter(f_ldap); destination(d_ldap); flags(final); }; [...]
Készítsük el az új logok könyvtárát:
mkdir -m 750 /var/log/ldap
és a változtatásokat a syslog-ng és a slapd újraindításával érvényesítsük:
/etc/init.d/syslog-ng restart; /etc/init.d/slapd restart; tail -f /var/log/ldap/slapd.log
Láthatjuk, hogy az LDAP szerver újraindításáról már csak az új logba került bejegyzés. Gondoskodjunk az új log(ok) rotálásáról:
-rw-r--r-- /etc/logrotate.d/ldap /var/log/ldap/*.log { daily rotate 7 compress missingok create 0640 root adm }
Logcheck módosítások
Az OpenLDAP futása során normálisan is keletkező logsorokat érdemes kivenni a logcheck kimenetéből.
- DIGEST-MD5 common mech free üzenetek
Egy hiba miatt a localhost-ról, root-ként kiadott lekérdezéseink a fenti hibasort írják a /var/log/auth.log-ba; ezeket érdemes teljesen kiszűrni:
touch /etc/logcheck/ignore.d.server/openldap-addons chown root:logcheck /etc/logcheck/ignore.d.server/openldap-addons chmod 640 /etc/logcheck/ignore.d.server/openldap-addons mcedit /etc/logcheck/ignore.d.server/openldap-addons
-rw-r----- root logcheck /etc/logcheck/ignore.d.server/openldap-addons ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ ldap[[:alnum:]]+:( \[ *[[:digit:]]+\.[[:digit:]]+\])? DIGEST-MD5 common mech free ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ slap[[:alnum:]]+:( \[ *[[:digit:]]+\.[[:digit:]]+\])? DIGEST-MD5 common mech free
TODO!
A slapd bejegyzése a Tiger által ismert démonok közé
A slapd-nek állandóan futnia kell, valamint jogosan figyel a 389-es és (SSL esetén) a 636-os tcp portokon. Mindezek ellenőrzésére az alábbi módosításokat jegyezzük be a /etc/tiger/tigerrc állományba:
-rw------- root root /etc/tiger/tigerrc [...] Tiger_Listening_ValidUsers='[...]|openldap' [...] Tiger_Listening_ValidProcs='[...]|slapd' [...] Tiger_Running_Procs='[...] /usr/sbin/slapd'
Az LDAP lekérdezések átengedése a bástyagép tűzfalán
Ha az OpenLDAP szerver csak helyi (localhost) használatban van, illetve ha minden lekérdezés SSH tunnelen vagy VPN-en keresztül történik, akkor az LDAP forgalmat külön nem kell a bástyagép tűzfalán átengedni. Ha közvetlen LDAP forgalom szükséges, akkor azt mind a bejövő, mind a kimenő szabályok között engedélyezzük az érintett zóna (általában a trusted belhálózat - trs) felé:
-rw-r----- root root /etc/shorewall/rules [...] # RULES HANDLING INCOMING CONNECTIONS [...] # Public services [...] #LDAP/ACCEPT trs fw LDAPS/ACCEPT trs fw [...] # RULES HANDLING OUTBOUND CONNECTION [...] #LDAP/ACCEPT fw trs LDAPS/ACCEPT fw trs [...]
A beállítást a tűzfal újraindításával érvényesítsük:
invoke-rc.d shorewall restart
Titkosított hozzáférés
Tekintettel arra, hogy az LDAP alapértelmezésben titkosítatlan kommunikációt használ, a localhoston kívüli hozzáféréseket ajánlatos titkosított csatornán lebonyolítani. Ennek egyik módja a forgalom SSH tunnelezése - ez a megoldás az alkalmazástól lényegében független -, a másik lehetőség az alkalmazásszintű TLS/SSL titkosítás és az ldaps protokoll (TCP: 636) használata.
- Az SSH tunnel a szerver oldalon kényelmesebb (mert az LDAP beállításokkal, kulcsgenerálással, stb. nem kell külön foglalkozni) és kicsit biztonságosabb, mert a tunnel kiépítéséhez (azaz ahhoz, hogy egyáltalán eljusson a szolgáltatásig) a kliensnek kulccsal kell rendelkeznie - kulcs hiányában még esetleges OpenLDAP exploitokkal sem lehet megtámadni a szolgáltatást. A kliens használata azonban kényelmetlenebb, mert valamilyen külső alkalmazással kell megnyitni és fenntartani a tunnelt.
- Az LDAPs használata esetén szükség van szerver oldali kulcsgenerálásra (és -frissítésre), viszont a kliensen külső alkalmazást futtatni nem kell, a titkosítás az LDAP démon és kliens "belügye".
Interneten keresztüli hozzáférésre illetve adminisztrációra inkább az SSH-tunnelt érdemes használni (véd az exploitok ellen), valamelyest védett helyi hálózati lekérdezésekre az LDAPs protokollt (gyorsabb, kliens oldalon egyszerűbb, de mégsem lehallgatható). Titkosítatlan LDAP lekérdezést csak a localhoston vagy teljesen izolált hálózat (pl. elzárt helységben közvetlenül összekötött szervergépek) esetén, illetve izolált környezetben történő tesztelésnél engedélyezzünk.
LDAPs szolgáltatás beállítása
Ez a rész kihagyható, ha nem használunk LDAPs szolgáltatást!
A kiszolgáló hitelesítéséhez szükségünk lesz egy (self-signed) kiszolgáló tanúsítványra. Ehhez lépjünk be egy átmeneti könyvtárba (pl. /root/tmp) és adjuk ki az alábbi parancsokat:
cd /root/tmp export DAYS=360 FQHN="FULLY.QUALIFIED.HOSTNAME" echo $FQHN $DAYS # Biztos, ami biztos :-) openssl genrsa -out $FQHN.key 1024 # Private key chmod 600 $FQHN.key openssl req -new -key $FQHN.key -out $FQHN.csr # Aláírandó tanúsítvány - töltsük ki az alábbiak szerint: # Country Name (2 letter code) [AU]:HU # State or Province Name (full name) [Some-State]:Budapest # Locality Name (eg, city) []:Budapest # Organization Name (eg, company) [Internet Widgits Pty Ltd]:MY COMPANY # Organizational Unit Name (eg, section) []:Directory Services # Common Name (eg, YOUR name) []:FULLY.QUALIFIED.HOSTNAME # Email Address []:sysadmin@MYDOMAIN # Extra attributumok üresen hagyhatóak. openssl x509 -req -days $DAYS -in $FQHN.csr -signkey $FQHN.key -out $FQHN.crt # Írassuk alá mv $FQHN.crt $FQHN.pem # Nevezzük át
A kitöltésnél ügyeljünk arra, hogy a FQHN egyezzen meg a tanúsítvány Common Name mezejével! Ezzel létrehoztunk egy egy évig érvényes self-signed tanúsítványt. Adjuk ezt az openldap user és group tulajdonába és másoljuk a /etc/ldap könyvtárba:
chown openldap:openldap $FQHN.pem; cp $FQHN.pem /etc/ldap/$FQHN.pem chown openldap:openldap $FQHN.key; cp $FQHN.key /etc/ldap/$FQHN.key # Ezek már nem kellenek rm $FQHN.csr $FQHN.key $FQHN.pem
Írjuk elő a slapd számára a tanúsítvány használatát - ehhez készítsünk egy LDIF állományt a cn=config objektum számára:
mcedit /root/tmp/ldap-mod.ldif dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/FQHN.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/FQHN.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/FQHN.key
Figyelem: ne felejtsük el a FQHN behelyettesítését!
Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):
ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))" | less rm /root/tmp/ldap-mod.ldif
Írjuk elő továbbá, hogy a slapd titkosítás nélkül csak a localhoston figyeljen (TCP:389), minden más forrás felől csak titkosítva (TCP:636 illetve Un*x socketként):
-rw-r--r-- root root /etc/default/slapd [...] SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" #SLAPD_SERVICES="ldap:/// ldapi:///" [...]
A beállításokat a slapd újraindításával érvényesítsük:
invoke-rc.d slapd restart
és ellenőrizzük a figyelést:
netstat -tanu | grep -e "\(:389\|:636\)" tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN tcp6 0 0 :::636 :::* LISTEN
Ellenőrizzük a TLS/SSL kapcsolódást az alábbi paranccsal, amely sikeres kapcsolódás esetén megjeleníti többek között a szervertanúsítvány adatait is:
openssl s_client -connect localhost:636 -showcerts CONNECTED(00000003) [...] Verify return code: 18 (self signed certificate)
Klienssel kapcsolódás - nem megy...
SSH tunnelezés előkészítése
Ez a rész kihagyható, ha nem használunk SSH tunnelezést!
Tunnelezés esetén a kapcsolódás előtt a kliens authentikál a szerveren (többlet biztonság), az adatforgalmat a tunnel védi a lehallgatás ellen, és a tűzfal beállításokat sem kell módosítani, mert a forgalom az egyébként engedélyezett SSH porton keresztül halad.
A tunnelt kizárólag kulccsal (PPK authentikációval) fogjuk megnyitni az openldap helyi (Linux rendszer-) felhasználó nevében; ehhez készítsük elő az elfogadott publikus kulcsokat tároló állományt:
mkdir -m 700 /var/lib/ldap/.ssh chown openldap:openldap /var/lib/ldap/.ssh touch /var/lib/ldap/.ssh/authorized_keys2 chown openldap:openldap /var/lib/ldap/.ssh/authorized_keys2 chmod 400 /var/lib/ldap/.ssh/authorized_keys2 chattr +i /var/lib/ldap/.ssh/authorized_keys2
A távoli hozzáférést egy grafikus LDAP klienssel felszerelt, a telepítés alatti szervert SSH-n elérő gépen ki is próbálhatjuk. Ehhez készítsünk egy (lehetőleg erős jelszóval védett) DSA kulcspárt, és a publikus kulcsot (az immutable bit átmeneti levétele után) másoljuk a /var/lib/ldap/.ssh/authorized_keys2 állományba.
Szükség esetén (pl. PuttyGen által készített kulcsnál) a kulcsot konvertáljuk OpenSSH formátumba:
ssh-keygen -i -f putty_kulcs >openssh_kulcs.pub
A kulcs elején helyezzük el az alábbi korlátozásokat:
-r-------- openldap openldap /var/lib/ldap/.ssh/authorized_keys2 [...]from="IP.IP.IP.IP",command="/bin/false",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,permitopen="127.0.0.1:389",permitopen="localhost:389" ssh-dss AAAA[...] opcionalis_comment
Ezzel a kulcs használatát a 389-es port továbbítására korlátoztuk. A from korlátozás elhagyható, ha a kliens számára nincs állandó IP címünk.
Nyissuk meg a kliensgépen a tunnelt egy helyi port (pl: local:10389) és a távoli hoston a localhost:389 összerendelésével, ezután tesztképpen a
telnet localhost 10389 # vagy amelyik portot megadtuk
paranccsal kapcsolódhatunk az LDAP szerverhez, illetve a grafikus kliensprogramban szerverként a localhost:10389 megadásával a címtárban valódi LDAP műveleteket végezhetünk.
Sikeres teszt esetén ne felejtsük el visszazárni a /var/lib/ldap/.ssh/authorized_keys2 állományt:
chattr +i /var/lib/ldap/.ssh/authorized_keys2
Monitorozás
Az OpenLDAP szerver rendelkezik egy olyan modullal (monitor backend, back_monitor), amelyik lehetővé teszi a használati statisztikák és teljesítményadatok gyűjtését és lekérdezését; ezen kívül figyelhetjük közvetlenül a backend adatbázis teljesítménymutatóit illetve a vonatkozó TCP/IP kapcsolatok paramétereit. Mindezeket alkalmas Munin pluginokkal tehetjük áttekinthetővé.
A monitor használatához:
- be kell töltenünk a back_monitor modult;
- engedélyeznünk kell a monitor adatbázist;
- célszerű létrehozni egy, a monitor adatbázishoz dedikáltan hozzáférő auditor felhasználót.
TODO!
A monitor modul betöltése
Készítsünk egy LDIF állományt, amely a konfigurációs adatbázisban előírja a modul betöltését:
mcedit /root/tmp/ldap-add.ldif # Load monitoring backend module dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/ldap olcModuleLoad: back_monitor
Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):
ldapadd -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-add.ldif ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(objectClass=olcModuleList))" | less rm /root/tmp/ldap-add.ldif
A monitor adatbázis elkészítése
A monitor adatbázis nem valódi címtár, hanem egy frontend, amely az OpenLDAP szerver aktuális állapotjelzőit címtár formában prezentálja, így ehhez az adatbázishoz csak olvasható hozzáférést lehet kiadni. Meggondolandó, hogy az OpenLDAP szerver állapotába betekintést engedünk-e mindenkinek, aki egyébként képes lekérdezést futtatni ezen a szerveren, vagy korlátozzuk ezt a lehetőséget. Ebben a leírásban csak a root Linux felhasználónak és egy speciális, jelszóval védett LDAP adatbázis accountnak (cn=auditor,cn=monitor) fogunk ilyen jogosultságot kiadni. Ez utóbbi számára készítsünk egy random jelszót (szöveges és SSHA hash formában) pl. az alábbi parancsokkal:
PW=$(pwgen -n -s -c 12 1); echo $PW; slappasswd -s $PW -h {SSHA}; PW= # Nem kerül a history-ba, csak a képernyőre :-) WVDPZLYJL8NY {SSHA}+OjMch4VxNcORw4iljLt1ZUdroIiNzos
Jegyezzük fel a szöveges jelszót, majd készítsünk egy LDIF állományt, amely létrehozza az adatbázist és beállítja a fenti jogosultságokat. Ügyeljünk a generált hash pontos bemásolására (NE használjuk a példa adatait!):
mcedit /root/tmp/ldap-add.ldif # Create monitoring database dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: monitor # Actually commented: read access to everyone - use with caution! #olcAccess: to dn.base="" by * read # Full (technically r/o) access for Linux root olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break # Full (technically r/o) access for an LDAP account. RootDN: cn=auditor,cn=monitor RootPW: {SSHA}+Qj[...]zos
Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):
ldapadd -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-add.ldif ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase=monitor)" rm /root/tmp/ldap-add.ldif
Monitor gyorsteszt
Az alábbi lekérdezések megfelelően authentikálva terjedelmes monitor kimenetet, névtelenül pedig hibaüzenetet eredményeznek.
ldapsearch -LLL -QY EXTERNAL -H ldapi:/// -b "cn=monitor" + "*" | less # root Linux felhasználóként ldapsearch -LLL -D "cn=auditor,cn=monitor" -W -h localhost -b "cn=monitor" + "*" | less # megfelelő LDAP database accounttal, jelszóval ldapsearch -LLL -x -h localhost -b "cn=monitor" + "*" # anonym lekérdezésre: No such object
Megjegyzés: amennyiben a konfigurációs adatbázis (pl.grafikus felületen történő) távelérését állítottuk be, ugyanezen a kapcsolaton keresztül a monitor távlekérdezése is megvalósítható az alábbi beállításokkal:
base DN: cn=monitor felhasználó: cn=auditor,cn=monitor jelszó: A fentebb beállított jelszó szöveges formában
Munin beállítása a monitor adatbázishoz
A Munin működéséhez szükségesek a libnet-ldap-perl és munin-plugins-extra csomagok:
apt-get install libnet-ldap-perl munin-plugins-extra # ha még nem lennének telepítve
A Munin plugin bekapcsolásához linkeljük a munin-plugins-extra csomaggal települő slapd_ plugint, és másoljuk át a hozzá tartozó beállító állományt:
ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_statistics_bytes ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_connections ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_operations ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_waiters
A Munin számára hozzáférést kell adnunk a monitor adatbázishoz. A szükséges adatokat egy beállító állományban adjuk meg a /etc/munin/plugin-conf.d könyvtárban. Mivel ez az állomány jelszót tartalmaz, a könyvtárban szokásos jogosultságokat szigorítva csak a munin group számára tesszük olvashatóvá:
touch /etc/munin/plugin-conf.d/slapd chown root:munin /etc/munin/munin/plugin-conf.d/slapd chmod 640 /etc/munin/plugin-conf.d/slapd mcedit /etc/munin/plugin-conf.d/slapd
Állítsuk be a lekérdezésre jogosult LDAP database account paramétereit:
-rw-r----- root munin /etc/munin/plugin-conf.d/slapd [slapd_*] env.binddn cn=auditor,cn=monitor env.bindpw SZÖVEGES_JELSZÓ
majd indítsuk újra a munin-node-ot:
invoke-rc.d munin-node restart
Gyorstesztként a szokásos módon, telnet-tel ellenőrizzük a telepített pluginok lekérdezhetőségét.
A Berkeley adatbázis backend monitorozása
TODO!
TCP/IP kapcsolatok monitorozása
TODO!
OpenLDAP mentés beállítása
Jelenleg az OpenLDAP mentéseket a helyi gépen készített, időzített (ldapsearch illetve slapcat alapú) LDIF dumpokkal valósítjuk meg, szükség szerint ezeket távoli gépekre Amanda taskok viszik el (természetesen bármilyen más file backup rendszer is használható). A mentések a teljes konfigurációt (a frontend és monitor adatbázisok kivételével) és a teljes felhasználói adattartalmat felölelik, napi rendszerességgel, automatizálva készülnek (a Debian ettől függetlenül menti a /var/lib/ldap könyvtárat is, ez azonban bináris formátum; pl. költöztetés esetén az LDIF talán jobban használható).
A mentéshez szükséges scriptet és cronjobot az openldap-addons tarball-lal már telepítettük, illetve létrehoztuk a /var/backups/openldap könyvtárat is. A napi mentés tesztképpen történő lefuttatásához (root-ként) adjuk ki az alábbi parancsot:
/usr/local/sbin/openldap_dump /var/backups/openldap >>/var/log/ldap/openldap-dump.log 2>&1
és ellenőrizzük, hogy a /var/backups/openldap könyvtárban létrejött-e a mentés, illetve nézzünk bele a /var/log/ldap/openldap-dump.log naplóba is.
Az openldap_dump script használható egyes (sorszámukkal hivatkozott) adatbázisok (root-ként végzett) manuális lementésére is, pl. az alábbi parancsok:
cd /root/tmp # Munkakönyvtár openldap_dump 0 . # Konfigurációs adatbázis openldap_dump 1 . # Az első felhasználói címtár
külön-külön mentik a konfigurációs adatbázist (database #0) és az első felhasználói címtárat (database #1) az aktuális munkakönyvtárba. A script minden adatbázisról két dumpot is megkísérel elkészíteni: egyet a slapcat használatával az erre alkalmas adatbázisok esetén (bdb vagy hdb backend-űek, illetve a konfigurációs adatbázis), egyet pedig az ldapsearch használatával (ha a database suffix meg van adva). Ha egyik metódus sem használható, nem készül dump, és figyelmeztetést kapunk.
Replikáció
Master szerepkör beállítása
Slave szerepkör beállítása
Karbantartási feladatok
Irodalom
- LDAP bevezető, elmélet (Gluon, 2006.)
- LDAP for Rocket Scientists (ebook in HTML)
- Az LDAP szerver- és kliens oldali vizsgálata (diplomamunka, 2007.)
- LDAP Schema Design (white paper, 2005.)
- OpenLDAP Software Administrator's Guide
- OpenLDAP Provider on Debian Squeeze (OpenLDAP 2.4.23 LDAP-enabled configuration)
- OpenLDAP using OLC (cn=config) (LDAP for Rocket Scientists)
- Samba PDC+LDAP+PAM/NSS Debian Lennyn (HUP Wiki)
- OpenLDAP under Ubuntu Linux Lucid Lynx 10.04 (OpenLDAP 2.4.23 LDAP-enabled configuration)
- Linuxvilág, Jászberényi József esettanulmánya I. és II. (2006. Debian Sarge)
- Ubuntu OpenLDAP Server Guide (magyarul)
- LDAPifying Applications