LDAP meta directory

Czasem jest potrzeba spięcia dwóch, lub kilku LDAPów z tymi samymi suffixami w jeden katalog lub postawienia tzw. proxy. Moje pierwsze próby spięcia dwóch katalogów polegały na zrobieniu replikacji z dwóch różnych źródeł. To rozwiązanie ma jednak pewne wady. Po pierwsze, żeby działała replikacja syncprov, to środowisko musi być jednolite, czyli wszystkie serwery źródłowe i ldap proxy, a właściwie replika muszą być oparte na OpenLDAP. Po drugie, zaobserwowałem, że takie środowisko jest niestabilne, ze względu na wspomniane już wcześniej problemy z replikacją w OpenLDAP. Przy dużej ilości wpisów po prostu niektóre zmiany nie były odwzorowane poprawnie w replikach.

Kiedy zdecydowałem się w końcu na przeniesienie tej większej części katalogu (ok. 48 tys. entry) do serwera OpenDJ, zostałem zmuszony do poszukiwania innego rozwiązania aby zapewnić dostęp do całego drzewa danych. Ponieważ w samym OpenDJ nie znalazłem właściwego rozwiązania, a instalacja DSEE czy Oracle Virtual Directory, które ponoć jest najlepszym 'zawodowym proxy’ nie wchodziła w grę, postanowiłem poszukać rozwiązania w OpenLDAP.

Replikacja nie wchodziła tutaj w grę, bo każdy z serwerów robi to na swój sposób, OpenDJ na przykład używa do tego całkiem osobnego portu 8989. Jest jednak coś, co łączy wszystkie serwery LDAP niezależnie od implementacji. Na porcie 389 powinny odpowiadać na zapytania w standardzie LDAPv3. Moje poszukiwania poszły więc w tym kierunku i znalazłem coś takiego jak backend ldap (back-ldap). Konfiguracja nie jest skomplikowana, należy włączyć moduł back_ldap.la i wstawić kilka linii do konfiguracji, np.:

modulepath      /usr/lib/ldap
moduleload      back_ldap.la
# inne potrzebne rzeczy, schematy itd.
database        ldap
suffix          "dc=example,dc=com"
#rootdn
uri             ldap://192.168.1.10/ ldap://192.168.1.20/

Ale to nie jest to, o co mi chodziło. To zadziała tak, że na zapytanie odpowie pierwszy serwer z listy, dopiero jeśli on będzie niedostępny, to pytanie pójdzie do kolejnego i ten, który odpowie zostanie przesunięty na początek listy (zgodnie z dokumentacją). Dobre, ale w przypadku kiedy serwery mają taką samą zawartość. Mi jednak chodziło o połączenie serwerów z różnymi danymi w tym samym DIT. Przyjrzyjmy się więc backendowi meta (back_meta).

Z dokumentacji backendów wynika, że to może być właściwe rozwiązanie, jednak sekcja konfiguracji jest bardzo uboga, gdyż zawiera jedno słowo: LATER. Trzeba było więc poszukać na własną rękę. Okazało się, że konfiguracja, podobnie jak w poprzednim przypadku, nie jest zbyt skomplikowana:

# Load dynamic backend modules:
modulepath      /usr/lib/ldap
moduleload      back_ldap.la
moduleload      back_meta.la
# other useful things

access to dn.base=""
        by * read

access to dn.base="cn=Subschema" 
        by * read

include  /etc/ldap/acl.conf

database meta
suffix  "dc=example,dc=com"
uri     "ldap://192.168.1.10/dc=example,dc=com"
uri     "ldap://192.168.1.20/dc=example,dc=com"
lastmod off

Oczywiście trzeba też pamiętać o wgraniu odpowiednich schematów. Nawet jak Metakatalog ruszy bez tego, to nie będzie potrafił zwrócić wyniku zapytania do klienta, bo nie będzie znał atrybutów, które są w serwerach źródłowych.

Warto też zrobić odpowiednie ACLe, tutaj są dołączane z osobnego pliku. Można jeszcze podać kilka parametrów, takich jak rootdn, rootpw. Można też podać różne fragmenty DIT w URI, np.:

database meta
suffix  "dc=example,dc=com"
uri     "ldap://192.168.1.10/ou=org-1,dc=example,dc=com"
uri     "ldap://192.168.1.20/ou=org-2,dc=example,dc=com"
lastmod off

Ale osobiście tego nie testowałem, więc nie będę tego opisywał.