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=rootI'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......