----- "Aaron Richton" richton@nbcs.rutgers.edu wrote:
On Fri, 25 Jul 2008, Guillaume Rousse wrote:
First, using a distinct database doesn't allow to provide a virtual
view
from a branch in my original database to another branch in the same database. Meaning, I can't have ou=telephony,dc=myprefix a virtual
view
of ou=users,dc=myprefix, I need to use a distinct prefix.
Have you tried declaring the ou=telephony,dc=myprefix back-relay subordinate to dc=myprefix back-$END?
I was about to reply the same, but you anticipated me :)
I've tried the above, and it works as expected as soon as the "relay" statement is omitted. In fact, it requires the superior database to already exist. Probably, that test should either be relaxed or moved to db_open().
With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like
rwm-map attribute telephoneNumber homePhone rwm-map attribute * telephoneNumber
so that real homePhone is mapped to virtual telephoneNumber, and real telephoneNumber is hidden. Unfortunately, this seems to result in a "double mapping" for telephoneNumber. I need to look at the logic of mapping, since what Guillaume wants to do seems to make sense, so it should be allowed. As per the reason of hiding everything not working, it's related to the fact that hiding everything does not allow "objectClass" to be returned, which causes the search filter to fail because the objectClass is not present. Unfortunately, the objectClass attribute cannot be mapped, so it cannot be explicitly preserved by adding
rwm-map attribute objectClass *
I recommend he files an ITS for each of those two issues.
Third, this solution doesn't work currently when trying to sync the appliance users from ldap. From ldap log, it seems some
specific
control is not supported with relay backend:
I think you'd be better served by syncing the real data, and configuring the back-relay/slapo-rwm identically across your slaves so as to give
consistent results.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
----- "Pierangelo Masarati" ando@sys-net.it wrote:
----- "Aaron Richton" richton@nbcs.rutgers.edu wrote:
With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like
rwm-map attribute telephoneNumber homePhone rwm-map attribute * telephoneNumber
Sorry for the noise. Actually, after re-reading few times slapo-rwm man page, I realized that
rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber
works as intended, and does exactly what you need.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati a écrit :
----- "Pierangelo Masarati" ando@sys-net.it wrote:
----- "Aaron Richton" richton@nbcs.rutgers.edu wrote:
With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like
rwm-map attribute telephoneNumber homePhone rwm-map attribute * telephoneNumber
Sorry for the noise. Actually, after re-reading few times slapo-rwm man page, I realized that
rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber
works as intended, and does exactly what you need.
Meaning mapping homePhone to telephoneNumber, and hidding real telephoneNumber, right. But it doesn't mask other attributes, so I guess there is still an issue for not being able to preserve objectClass attribute when masking all other ones. Am I correct ?
Guillaume Rousse wrote:
Sorry for the noise. Actually, after re-reading few times slapo-rwm man page, I realized that rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber
works as intended, and does exactly what you need.
Meaning mapping homePhone to telephoneNumber, and hidding real telephoneNumber, right.
But it doesn't mask other attributes, so I guess there is still an issue for not being able to preserve objectClass attribute when masking all other ones. Am I correct ?
Well, now objectClass does no longer need to be mapped, so disabling all attrs does no longer affect objectClass (ITS#5647, in 2.4.12, about to be released).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati a écrit :
----- "Aaron Richton" richton@nbcs.rutgers.edu wrote:
On Fri, 25 Jul 2008, Guillaume Rousse wrote:
First, using a distinct database doesn't allow to provide a virtual
view
from a branch in my original database to another branch in the same database. Meaning, I can't have ou=telephony,dc=myprefix a virtual
view
of ou=users,dc=myprefix, I need to use a distinct prefix.
Have you tried declaring the ou=telephony,dc=myprefix back-relay subordinate to dc=myprefix back-$END?
I was about to reply the same, but you anticipated me :)
I've tried the above, and it works as expected as soon as the "relay" statement is omitted. In fact, it requires the superior database to already exist. Probably, that test should either be relaxed or moved to db_open().
Actually, subordinate is not really needed, just declaring the inner database before the other is OK: database relay suffix "ou=telephony,dc=myprefix" overlay rwm rwm-suffixmassage "ou=users,dc=myprefix"
database bdb suffix "dc=myprefix"
Making the first one subordinate to the second has the unwanted side-effect of having all requests for user starting from top-level suffix (example: ldapvi --user '(uid=foo)' now return two users instead of one, so I'd likely avoid it.
openldap-software@openldap.org
-
Guillaume Rousse -
Pierangelo Masarati