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(a)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(a)fr3ddie.it <mailto:fr3ddie@fr3ddie.it>/