Andrey Ivanov wrote:
Hi,
I am testing the 389 latest git version. There is one thing i have noticed concerning Outlook browsing of LDAP and VLV indexes. Though i think the change has happened already some time ago, in one of the previous versions.
Can you confirm the last version that this worked in? I suspect this had something to do with my matching rule changes in 1.2.6. The goal is that it should work the same way as before, so this is definitely a bug.
To make the LDAP Outlook browsing work correctly i've always used the steps described in the doc (http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Creating_Indexe...) :
dn: cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: Outlook Browse objectClass: top objectClass: vlvsearch vlvBase: ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu vlvFilter: (&(mail=*)(cn=*)) vlvScope: 2
dn: cn=Outlook Browse Index,cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn= plugins,cn=config cn: Outlook Browse Index objectClass: top objectClass: vlvindex vlvEnabled: 1 vlvSort: cn
This creates a VLV index, sorts the entries by cn and shows them in Outlook : [24/Aug/2010:16:42:19 +0200] conn=24 op=2 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber" [24/Aug/2010:16:42:19 +0200] conn=24 op=2 SORT cn [24/Aug/2010:16:42:19 +0200] conn=24 op=2 VLV 0:0:xac 7860:8001 (0) [24/Aug/2010:16:42:19 +0200] conn=24 op=2 RESULT err=0 tag=101 nentries=1 etime=0.009000 [24/Aug/2010:16:42:19 +0200] conn=24 op=3 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber" [24/Aug/2010:16:42:19 +0200] conn=24 op=3 SORT cn [24/Aug/2010:16:42:19 +0200] conn=24 op=3 VLV 0:27:7859:8001 7860:8001 (0) [24/Aug/2010:16:42:19 +0200] conn=24 op=3 RESULT err=0 tag=101 nentries=28 etime=0.019000
In (relatively old) previous versions of the server the sorting took into account the accentuated letters (like é, for example). The CNs with these letters were sorted correctly (that is, é after d and before f). So the entries were sorted by VLV like this :
... Tdo Not Ten Toys Tén Toys <<<-- Tfk Nev Tgl Mu ... Tzzz Too Uart New ...
With the recent versions the server orders the CN strictly according to ASCII (i think) :
... Tdo Not Ten Toys Tfk Nev Tgl Mu ... Tzzz Too Tén Toys <<<-- Uart New ...
That is, all the diacritical letters appear after "z".
I have looked into the vlv#outlookbrowseindex.db4 file by dbscan and the order corresponds exactly to what Outlook shows.
The questions are : -whether it is how it should work and -how do i revert to the old server behavior.
The sorting with collation (that is, smth like my $sort_control = Net::LDAP::Control::Sort -> new( order => "cn:2.16.840.1.113730.3.3.2.18.1.6", critical => 1) ) works perfectly (i.e. é is after d and before f).
I've tried several ideas to return to the old behavior :
*) i've tried to add collation rules to vlv index entries but putting the value of the attribute vlvSort to "cn:2.16.840.1.113730.3.3.2.18.1.6" or to "cn:fr" does not work either. Instead of changing the sorting order it produces some strange contents in the index vlv#outlookbrowseindex.db4 file.
**) then i thought that maybe i should change the cn index ordering and i have added "nsMatchingRule: 2.16.840.1.113730.3.3.2.18.1" to the cn indexes in dse.ldif. However reindexing does not actually change the order (even after reindexing by smth explicit like db2index -n userRoot -t cn:eq,pres,sub:2.16.840.1.113730.3.3.2.18.1 ) in the index .db4 files.
Any ideas/suggestions?
Andrey Ivanov tel +33-(0)1-69-33-99-24 fax +33-(0)1-69-33-99-55
Direction des Systemes d'Information Ecole Polytechnique 91128 Palaiseau CEDEX France
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users