[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd-meta

Il 10/03/2016 14:45, Dirk Kastens ha scritto:



     dn: olcDatabase={3}meta,cn=config
     objectClass: olcDatabaseConfig
     objectClass: olcMetaConfig
     olcDatabase: {3}meta
     olcSuffix: dc=loc1,dc=root
     olcSuffix: dc=loc2,dc=root
     olcSuffix: dc=loc3,dc=root


I've never used meta backend, but the above doesn't look valid to me
(multiple suffixes).  The man page shows a single suffix, with URI
directives for additional representations of the DB.
Indeed, you can only have one olcSuffix. This is the suffix under which your source URIs will be presented. I'm running a meta backend with the following configuration:
I have two source servers, first and second. Both have a subtree ou=people,ou=mydomain. The trees are combined on the meta server under the new suffix ou=newsuffix,dc=mydomain as ou=apeople and ou=bpeople. 

[OMISSIS]

Hope this helps.


Thank you very much Dirk.
I tried *several* configurations and OpenLDAP versions (i.e. 2.4.44-ltb) without success. I will try to explain all of them but, at this point, I can only think to a bug in the slapd-meta module. 
I kindly ask to the list where I am supposed to file the bug report.
First step has been the removal of the whole OpenLDAP installation/configuration/DB and setup of the 2.4.44-ltb version. This has been done in order to avoid any mistake I could have performed while manually compiling OpenLDAP. Following that, I configured a minimal slapd with the meta database only and a single target, in order to exclude any possible configuration error deriving from the other HDB DIT previously contained.
I tested everything using "ldapsearch" and sniffing the communication between the servers with Wireshark. The result is pretty bizarre. Now, when I directly interrogate the target server with ldapsearch I correctly obtain the answers to the performed queries, e.g.:
ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server1.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)" 

    # extended LDIF
    #
    # LDAPv3
    # base <ou=users,dc=server1,dc=xxxx> with scope subtree
    # filter: (uid=john)
    # requesting: ALL
    #

    dn: uid=john,ou=users,dc=server1,dc=xxxx
    objectClass: inetOrgPerson
    objectClass: posixAccount
    uid: john
    sn: Doe
    givenName: John
    cn: John Doe
    displayName: John Doe
    uidNumber: 1000
    gidNumber: 10000
    gecos: John Doe
    loginShell: /bin/bash
    homeDirectory: /home/john
    mail: john.doe@example.com
    postalCode: 31000
    l: aaaaa
    o: ddddd
    mobile: +33 (0)6 xx xx xx xx
    homePhone: +33 (0)5 xx xx xx xx
    title: System Administrator
    postalAddress:
    initials: JD

    # search result
    search: 2
    result: 0 Success

    # numResponses: 2
    # numEntries: 1
If I try to interrogate the meta-enabled server, instead, it correctly connects to the target server, it performs the query, *the target server answers correctly to the slapd-meta server* with the same data set of the first ldapsearch (sniffed with Wireshark) but I obtain *no answer*, i.e.:
ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server0.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)" 

    # extended LDIF
    #
    # LDAPv3
    # base <ou=users,dc=server1,dc=xxxx> with scope subtree
    # filter: (uid=john)
    # requesting: ALL
    #

    # search result
    search: 2
    result: 0 Success

    # numResponses: 1
so the proxy server is not forwarding to the "ldapsearch" client the obtained data. 


Following are the performed configurations.
First slapd-meta configuration tried is this:

    dn: olcDatabase={1}meta,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcMetaConfig
    olcDatabase: {1}meta
    olcSuffix: dc=xxxx

    dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config
    olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx";
    objectClass: olcMetaTargetConfig
    olcMetaSub: {0}uri
olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no
so, as suggested by Dirk and as clearly stated in the manual, using as "olcSuffix" a "common" naming context and "attaching" the target tree as subtree, without any suffix massaging.
After this test I tried enabling the RWM overlay over the meta database and configuring suffix massaging, i.e.: 

    dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config
    objectClass: olcOverlayConfig
    objectClass: olcRwmConfig
    olcOverlay: {0}rwm
    olcRwmRewrite: rwm-rewriteEngine "on"

    dn: olcDatabase={1}meta,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcMetaConfig
    olcDatabase: {1}meta
    olcSuffix: dc=xxxx

    dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config
    olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx";
olcDbRewrite: {0}suffixmassage "dc=server1,dc=xxxx" "dc=server1,dc=xxxx" 
    objectClass: olcMetaTargetConfig
    olcMetaSub: {0}uri
olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no
Last battery of tests, I tried to use the same "olcSuffix" I was trying to get from the target server, i.e. "dc=server1,dc=xxxx", with and without RWM massaging.
Results for all of the tests stayed the same, if I directly query the target server I obtain the correct answer; as soon as I query the meta server it is unable to forward to the client the data received from the target...... 




--
Fr3ddie
/fr3ddie@fr3ddie.it <mailto:fr3ddie@fr3ddie.it>/