virtual view strategies: replying differently to different clients

[Guillaume Rousse <Guillaume.Rousse@inria.fr>]

Hello list.

We're using some braindead appliance that insist on having internal 
telephone numbers in LDAP, whereas we need to also store external 
numbers (external prefix + internal number) for other purposes.

I didn't found any way to dynamically alter the content of the
telephonenumber attribute when asked by the client (filtering the
prefix on the fly), so I quickly opted to store the information twice:
the short and the long number.

The appliance doesn't allow to select which attribute to use, it
always use the first value from telephoneNumber attribute. So the
current solution is to store both values in this attribute, and use the
valsort overlay to always have the short number first. However, this
rely on client being aware of the trick, and using to the second value
when several are available, whereas we'd prefer to do the trick server-side.

I then tried to use different attributes (homePhone vs telephoneNumber)
to store those different values, and use attribute mapping to reply with
the expected value depending on the client. I had a quick look at rwm
overlay, but attribute mapping seems to be global only, not for a given
client only. On Buchan's suggestion, I tried relay backend instead, so
as to only remap attributes values using a specific context.

This seems the correct strategies, however I'm facing a few issues.
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.

Second, trying the solution at the end of slapo-rwm man page to only map
some attributes and exclude others is actually filtering too much. As
soon as I use 'map attribute *' to exclude unmapped attributes, I can't
list entries anymore. Adding the pseudo-attributes 'entry' to mapped
attributes, which is documented as needed for research operation in
slapd.access man page, doesn't help. So I had to ressort to ACLs instead
to exclude unwanted attribute.

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:

Jul 22 13:46:12 etoile slapd[10826]: conn=3 fd=23 ACCEPT from
IP=193.55.250.9:37225 (IP=0.0.0.0:389)
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND
dn="cn=callmanager,ou=roles,cn=telephony" method=128
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND
dn="cn=callmanager,ou=roles,dc=msr-inria,dc=inria,dc=fr" mech=SIMPLE ssf=0
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 RESULT tag=97 err=0 text=
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH
base="ou=users,cn=telephony" scope=2 deref=3
filter="(objectClass=inetOrgPerson)"
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH attr=uid givenname
initials sn manager departmentnumber telephonenumber mail title
homephone mobile pager
Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SEARCH RESULT tag=101
err=12 nentries=0 text=critical control unavailable in context

When using a different loglevel, the only critical control requested is
1.2.840.113556.1.4.319, pagedControl. However, the client request for it
seems to succeed:

Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls
Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls:
oid="2.16.840.1.113730.3.4.2" (noncritical)
Jul 22 13:48:10 etoile slapd[11317]: <= get_ctrls: n=1 rc=0 err=""

My wild guess is that the control doesn't survive the context switch
from the original base (dc=msr-inria,dc=inria,dc=fr) to the virtual base
(cn=telephony). Should I report this as a bug, or am I misunderstanding ?

I'm using openldap 2.4.11, and here is the virtual base configuration,
if that matters:
database                relay
suffix                  "cn=telephony"
relay                   "dc=msr-inria,dc=inria,dc=fr"
overlay                 rwm
rwm-suffixmassage       "dc=msr-inria,dc=inria,dc=fr"

access to dn.subtree="cn=telephony"
    attrs=userPassword
    by anonymous ssf=56 auth
    by anonymous peername.ip=193.55.250.9 auth
    by * none

access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*)
    attrs=entry,objectClass,telephoneNumber,uid,givenName,sn,manager,mail
    by * read

access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*)
    by * none

map attribute telephoneNumber homePhone
map attribute telephoneNumber


Any hint welcome, either on the solution choice, or on the selected
solution troubles.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62