OpenLDAP és memberof Multi-Master környezetben

Fórumok

hello

túrom a netet már jó egy hete de nem bírok rájönni miért nem működik a memberof plugin nálam.
Adott egy M-M OpenLDAP 2.4 környezet ahol használni szeretném a 'reverse grouping' megoldást de nem működik.
Az alábbi a configom:

# module{1}, config
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}memberof.la
#
# {1}memberof, {1}bdb, config
dn: olcOverlay={1}memberof,olcDatabase={1}bdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberof
olcMemberOfDN: cn=operator,ou=users,dc=company,dc=example,dc=com

A fura az hogy a maximális loggoláson azt látom h az OpenLDAP engine parsolja a betöltött modult de az overlay-el már nem kezd semmit.

Természetesen a cn=config module lista és overlay megegyezik mindkét oldalon, bár nem replikálódik hanem Conf management van karban tartva.

Nektek van ötletetek hogy ez miért lehet?

UPDATE:
Nos újabb infót találtam:
Entry (cn=test,ou=users,dc=example,dc=com), attribute 'member' not allowed
entry failed schema check: attribute 'member' not allowed

Na de miért?
az alábbi schema-im vannak betöltve:
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: cn={3}collective,cn=schema,cn=config
dn: cn={4}corba,cn=schema,cn=config
dn: cn={5}duaconf,cn=schema,cn=config
dn: cn={6}openldap,cn=schema,cn=config
dn: cn={7}dyngroup,cn=schema,cn=config
dn: cn={8}java,cn=schema,cn=config
dn: cn={9}misc,cn=schema,cn=config
dn: cn={10}nis,cn=schema,cn=config
dn: cn={11}ppolicy,cn=schema,cn=config
dn: cn={12}sudo,cn=schema,cn=config
dn: cn={13}openssh-openldap,cn=schema,cn=config

áááááááááá, 'inetorgperson' a ludas.

Hozzászólások

Hmm, erre a memberOf-ra nekem is szamtalan esetben szuksegem lett volna, de eszembe nem jutott ez a plugin, megirtam az applikaciohoz kezzel a logikat

akkor a többiek hogyan oldották meg a csoport menedzsmentet? hogyan képesek visszakövetni hogy az xy felhasználó melyik csoport tagja elkerülve azt hogy bejárjuk a teljes fát és lekérdezünk minden átkozott csoportot hogy 'helló mond már meg kik a tagjaid...'?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Szerintem ugy, ahogy en: van egy Groups agam, az alatt vannak a csoportok. Annyira rengeteg csoportom nincs, meg azert lehetne meg tovabb osztani alkalmazasok szerint. Igy az atnezendo resz meglehetosen lapos, es keves elemet tartalmaz (<100). Ennyit meg akarmelyik ldap implementacionak illik tudnia.

Mellesleg ahogy neztem ez a memberOf modul valojaban csak egy belso funkcio, ami a felhasznalohoz hozzaad egy attributumot. Ennyi erovel ezt az applikaciombol is meg tudom csinalni, kevesebb szenvedessel. Persze lehet, hogy ez a modul lekoveti ha idokozben megvaltozik a csoport dn-je, vagy a felhasznalo dn-je, de annyira azert nem izgatott fel, hogy le is teszteljem.

Köszi, ez még nekem is jól fog jönni. :)

Miért az intetorgperson séma a ludas? Hozzá volt adva a csoporthoz?

nos félre néztem - egy weboldalon magyarázták h az initorgperson-ban nem lehet memberof attribútum.
nekem a cosne sémára panaszkodott amikor jobban belenéztem de fogalmam sincs miért. Nem értem miért pont azon akarja értelmezni. holnap majd leírom a napló üzenetet és a felhasználó objektumot is.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/