Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remote server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as local *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p.
moved from Incoming to Software Enhancements
changed notes
Hi Pierangelo, I want to override the objectclass of a remote server to extend it with the attribute posixAccount This works but when I search on the attribute objectclass=* the only result giving me back i the ones with the local defined objectclass. Is it this issue? If so, can we do something about it? is here an easy fix? Thanks Wouter
patch welcome
Hi, I have a similar issue with search on translucent overlay : I override ObjectClass with posixAccount. I set translucent with : olcTranslucentLocal: uidNumber olcTranslucentLocal: gidNumber olcTranslucentLocal: homeDirectory olcTranslucentLocal: loginShell olcTranslucentLocal: mailAlternateAddress olcTranslucentLocal: memberUid olcTranslucentLocal: objectClass It works except when I search with filter like this : "(&(loginShell=/bin/bash)(sn=Smith))". On the remote backend, the search is : SRCH base="uid=dupont,ou=people,dc=u-bordeaux,dc=fr" scope=0 deref=0 filter="(objectClass=*) SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000146 nentries=1 text=" which is a entry contains loginShell=/bin/bash. It seems that when a composed filter with local and remote attributes returns many results from local (loginShell), the search on remote would apply for each dn founds but translucent fails on the first (because second part of filter is not verified (sn=Smith)).