openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7584) slapd ignores loglevel packets, ber and parse.
by fumiyas＠osstech.co.jp 07 May '13

07 May '13

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) "slapd -s 'packets,ber,parse'" does not send specified log to syslog. slapd ignores "loglevel packets ber parse" in slapd.conf too. "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected.

1 0

(ITS#7583) ldap_init_fd() does not work with LDAP_PROTO_UDP
by stefw＠redhat.com 03 May '13

03 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Submission from: (NULL) (77.3.95.123) The ldap_init_fd() function does not work with UDP sockets (ie: LDAP_PROTO_UDP passed in as the proto argument). Later uses of the LDAP connection returned fail unceremoniously. This patch fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Some test code to exercise and demonstrate the problem. The code does not actually wait for a UDP response, but should exit with a zero return code when successful. http://fedorapeople.org/~stefw/patches/openldap-02/frob-cldap-initfd.c $ gcc -o frob-cldap-initfd -Wall -lldap -llber frob-cldap-initfd.c $ ./frob-cldap-initfd frob-cldap-initfd: ldap_search_ext: -1 The above result occurs before the patch is applied.

1 0

(ITS#7582) Access to uninitialized memory when sending cldap packet
by stefw＠redhat.com 02 May '13

02 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Submission from: (NULL) (77.3.95.123) When sending a cldap (UDP) packet, like a search request, uninitialized memory is accessed. This shows up in valgrind like this: ==31445== Conditional jump or move depends on uninitialised value(s) ==31445== at 0x36632244E6: ldap_send_server_request (request.c:377) ==31445== by 0x36632247C2: ldap_send_initial_request (request.c:166) ==31445== by 0x36632142F8: ldap_pvt_search (search.c:128) ==31445== by 0x366321454F: ldap_search_ext (search.c:69) ==31445== by 0x400838: main (in /data/projects/openldap/frob-cldap-search) ==31445== This is due to parsing the resulting packet to pull out a requestDN. UDP packets have different BER layout, and therefore the assumptions made when parsing the outgoing request are invalid. It does not seem necessary to track the request DN for UDP packets. The linked patch disables this code path for UDP packets. Patch which fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Test code for the issue: http://fedorapeople.org/~stefw/patches/openldap-01/frob-cldap-search.c Note that the test code doesn't detect the issue on its own (or do anything useful). Use valgrind to detect the issue: $ gcc -o frob-cldap-search -Wall -lldap -llber frob-cldap-search.c $ valgrind ./frob-cldap-search

1 0

(ITS#7581) adding meta backend in cn=config with ldapadd / ldapmodify
by dcoutadeur＠linagora.com 02 May '13

02 May '13

Full_Name: dcoutadeur Version: 2.4.35 / git OS: openSuse 11.3 x86_64 URL: Submission from: (NULL) (80.67.162.201) I apologize in advance if this is not considered as a bug, but I thought this ticket should help the community anyway... The problem is that it seems impossible to add meta backend in cn=config thanks to ldapadd / ldapmodify clients. I thought the major interest for cn=config was precisely to let administrators change the configuration in a remote way, but maybe new database configuration is an exception ? Here are the technical elements : Content of meta.ldif : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com debug information in slapd, after the command : ldapadd -H "ldap://localhost:389" -D "cn=config" -W -f meta.ldif 518220f1 conn=1002 op=1 ADD dn="olcDatabase={2}meta,cn=config" 518220f1 meta_back_db_open: no targets defined 518220f1 backend_startup_one (type=meta, suffix="dc=foo,dc=com"): bi_db_open failed! (1) 518220f1 olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=com)! However, I can add this entry via slapadd : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbOnErr: continue olcDbPseudoRootBindDefer: TRUE olcDbSingleConn: FALSE olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbBindTimeout: 100000 olcDbCancel: abandon olcDbChaseReferrals: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbNretries: 10 olcDbProtocolVersion: 3 olcDbRebindAsUser: FALSE olcDbSessionTrackingRequest: FALSE olcDbTFSupport: no structuralObjectClass: olcMetaConfig entryUUID: cf8afa3a-a284-4ac8-b60e-9431b0807ed4 creatorsName: cn=config createTimestamp: 20130430162302Z entryCSN: 20130430162302.509672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130430162302Z The fact is I don't have a metatarget configuration, because this is a subentry of olcDatabase={2}meta,cn=config, thus I must add the latter entry first. Also notice that I can't do a slapadd with just the meta configuration. (the ldif above). If I do this, I have an error : slapadd: could not add entry dn="olcDatabase={2}meta,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed I had to make a backup of the full configuration, and then add the meta configuration and import the resulting file.

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Re, and here are more details w/ backtrace after installing slapd-dbg : 517f9323 bdb_modify_internal: 0x000002fd: cn=g1,ou=groups,dc=example,dc=org Breakpoint 1, modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 41 in ../../../../servers/slapd/mods.c (gdb) p *mod $10 = {sm_desc = 0x7ffff832bb20, sm_values = 0x7ffff8765760, sm_nvalues = 0x7ffff87da8c0, sm_numvals = 1, sm_op = 0, sm_flags = 1, sm_type = {bv_len = 6, bv_val = 0x7ffff82ee5c0 "member"}} (gdb) p *(mod->sm_values) $11 = {bv_len = 0, bv_val = 0x0} (gdb) bt #0 modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 #1 0x00007ffff32110fb in hdb_modify_internal (op=op@entry=0x7ffff0f50ca0, tid=0x7ffff82db2d0, modlist=<optimized out>, e=e@entry=0x7ffff0f507e0, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at modify.c:137 #2 0x00007ffff3211df3 in hdb_modify (op=0x7ffff0f50ca0, rs=0x7ffff0f50c30) at modify.c:638 #3 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50ca0, rs=0x7ffff0f50c30, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #4 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50ca0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #5 0x00007ffff2be53e7 in autogroup_add_members_from_filter (op=op@entry=0x7ffff82da400, e=<optimized out>, age=0x7ffff82f8ef0, agf=agf@entry=0x7ffff87daea0, modify=modify@entry=1) at autogroup.c:519 #6 0x00007ffff2be5b00 in autogroup_add_group (op=op@entry=0x7ffff82da400, agi=agi@entry=0x7ffff832b8c0, agd=agd@entry=0x7ffff832b910, e=0x7ffff8503b98, e@entry=0x0, ndn=ndn@entry=0x7ffff82da438, scan=scan@entry=1, modify=modify@entry=1) at autogroup.c:667 #7 0x00007ffff2be6c91 in autogroup_response (op=0x7ffff82da400, rs=<optimized out>) at autogroup.c:1213 #8 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #9 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #10 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #11 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #12 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at modify.c:749 #13 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82da400, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #14 0x00007ffff7f8031b in over_op_func (op=0x7ffff82da400, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #15 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #16 0x00007ffff7f2c42d in do_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #17 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82da400) at ../../../../servers/slapd/connection.c:1150 #18 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 So sm_values looks empty at that point... Note that i've also tried with the default groupOfNames/member objects, instead of posixGroup/memberOf. Same symptoms. -- Landry Breuil

1 0

(ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Full_Name: Landry Breuil Version: 2.4.31 OS: Debian sid URL: Submission from: (NULL) (194.214.164.50) using slapd 2.4.31 on debian sid (with cn=config), i have an abort triggered by the following configuration : I'm using autogroup module/overlay to automatically generate posixGroup objects from various filters on my ou=people branch : dn: cn=SV_REVIEWER,ou=groups,dc=example,dc=org objectClass: labeledURIObject objectClass: posixGroup gidNumber: 10 labeledURI: ldap:///ou=people,dc=example,dc=org?uid?one?(&(objectClass=inetOrgPerson)(o=myorg)) So far, that works fine. Problem is, with that configuration i'm getting memberUid values containing only uid attributes. Now that i want to use memberOf overlay to get the reverse membership, i realize that i need my posixGroup to have DN-valued memberUid attrs. I tried using a labeledURI specifying that i want a DN returned : labeledURI: ldap:///ou=people,dc=example,dc=org?dn?one?(&(objectClass=inetOrgPerson)(o=myorg)) This errors out in autogroup_add_group after parsing the filter with : 517e6bc0 autogroup_add_group: unable to find AttributeDescription "dn". That, i can understand - a dn is not an attribute per se. Tried using a labeledURI without attr specification (as, from what i understand unless mistaken, should return the object, or its dn ?) labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) But this results in the following assertion (w/ debug trace) : 517e70d5 ==> autogroup_add_group <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> ldap_url_parse_ext(ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg))) 517e70d5 >>> dnPrettyNormal: <ou=people,dc=example,dc=org> 517e70d5 <<< dnPrettyNormal: <ou=people,dc=example,dc=org>, <ou=people,dc=example,dc=org> put_filter: "(&(objectClass=inetOrgPerson)(o=myorg))" put_filter: AND put_filter_list "(objectClass=inetOrgPerson)(o=myorg)" put_filter: "(objectClass=inetOrgPerson)" put_filter: simple put_simple_filter: "objectClass=inetOrgPerson" put_filter: "(o=myorg)" put_filter: simple put_simple_filter: "o=myorg" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: 517e70d5 ==> autogroup_add_members_from_filter <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> 517e70d5 => hdb_search 517e70d5 bdb_dn2entry("ou=people,dc=example,dc=org") 517e70d5 search_candidates: base="ou=people,dc=example,dc=org" (0x00000005) scope=1 517e70d5 => hdb_dn2idl("ou=people,dc=example,dc=org") 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read: failed (-30987) 517e70d5 <= bdb_equality_candidates: id=0, first=0, last=0 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read 738 candidates 517e70d5 <= bdb_equality_candidates: id=738, first=6, last=763 517e70d5 => bdb_equality_candidates (o) 517e70d5 <= bdb_equality_candidates: (o) not indexed 517e70d5 bdb_search_candidates: id=437 first=6 last=763 517e70d5 ==> autogroup_member_search_modify_cb <uid=user1,ou=people,dc=example,dc=org> 517e70d5 ==> autogroup_member_search_modify_cb <uid=user2,ou=people,dc=example,dc=org> 517e70d5 hdb_search: 288 does not match filter .... 517e70d5 hdb_search: 762 does not match filter 517e70d5 hdb_search: 763 does not match filter 517e70d5 send_ldap_result: conn=1000 op=8 p=3 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_entry_get: rc=0 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_modify_internal: 0x000002e0: cn=SV_REVIEWER,ou=groups,dc=example,dc=org slapd: ../../../../servers/slapd/mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed. How can i achieve the desired setup ? Fix autogroup to allow asking for a dn, or try to see why slapd blows in modify_add_values when not asking for a specific attribute ?

1 0

Re: (ITS#7579) back-sql does not update DIT when DB is updated
by masarati＠aero.polimi.it 29 Apr '13

29 Apr '13

On 04/29/2013 02:33 PM, mail(a)benjamin-behringer.de wrote: > Full_Name: Benjamin Behringer > Version: 2.4.35 > OS: Ubuntu 12.04 64bit > URL: > Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) > > > Hi, > > I'm using OpenLDAP and back-sql to make the information, stored in a MySQL > Database, available over LDAP (for Authentication purposes). Unfortunately, when > I insert or update an entry in the Database, the DIT is not updated. In > contrast, a delete on the ldap_entries table will cause slapd to reflect the DB > change in the DIT. The issue only occurs, when the DIT has already been loaded, > and the subtree you will make the change to has already been read at least once. > If you restart slapd, the changes are reflected. > > Software Versions: > > Distribution: Ubuntu 12.04 64bit > MySQL: 5.5.31-0ubuntu0.12.04.1 > OpenLDAP: 2.4.35 > libmyodbc: 5.2.4 > unixodbc: 2.3.0-2ubuntu1 > > Here are > > a sample configuration file: > http://pastebin.de/34104 > > odbc config files: > http://pastebin.de/34103 > > sample db script: > http://pastebin.de/34101 > > and insert script: > http://pastebin.de/34102 > > Is there a patch, workaround, anything? There is no caching of the contents of ldap_entries in back-sql; maybe some caching at the odbc level? p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7579) back-sql does not update DIT when DB is updated
by mail＠benjamin-behringer.de 29 Apr '13

29 Apr '13

Full_Name: Benjamin Behringer Version: 2.4.35 OS: Ubuntu 12.04 64bit URL: Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) Hi, I'm using OpenLDAP and back-sql to make the information, stored in a MySQL Database, available over LDAP (for Authentication purposes). Unfortunately, when I insert or update an entry in the Database, the DIT is not updated. In contrast, a delete on the ldap_entries table will cause slapd to reflect the DB change in the DIT. The issue only occurs, when the DIT has already been loaded, and the subtree you will make the change to has already been read at least once. If you restart slapd, the changes are reflected. Software Versions: Distribution: Ubuntu 12.04 64bit MySQL: 5.5.31-0ubuntu0.12.04.1 OpenLDAP: 2.4.35 libmyodbc: 5.2.4 unixodbc: 2.3.0-2ubuntu1 Here are a sample configuration file: http://pastebin.de/34104 odbc config files: http://pastebin.de/34103 sample db script: http://pastebin.de/34101 and insert script: http://pastebin.de/34102 Is there a patch, workaround, anything? Regards

1 0

Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 28 Apr '13

28 Apr '13

juergen.sprenger(a)swisscom.com wrote: > Full_Name: Juergen Sprenger > Version: 2.4.35 > OS: Gentoo Base System release 2.1, Kernel 3.7.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.5.238.18) > > > mdb dereference aliases problem. A fix for this is now in git master, please test, thanks. commit fb537d747c6fd43e08986e99b1fe7781660feaf3 > > I use aliases to keep information about a person who has multiple accounts > consistent over all accounts and avoid redundancy, example: > > dn: uid=joe,ou=Account,dc=its,dc=scom > objectClass: alias > objectClass: extensibleObject > uid: joe > aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom > structuralObjectClass: alias > > When using hdb as backend for slapd everything works fine, and user are > authenticated properly: > # running 'getent passwd' with hdb backend: > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 > text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 > err=0 nentries=656 text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection > lost) > > When using mdb as backend with same directory content, users are no longer > authenticated, search returns nentries=0: > > # running 'getent passwd' with mdb backend: > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 > text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 > err=0 text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection > lost) > > Both setups have identical md5sum of slapcat output, so directory content can be > assumed identical in my opinion. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7567) Alias dereferencing slowness
by hyc＠symas.com 28 Apr '13

28 Apr '13

luca.scamoni(a)gruppopa.it wrote: > Full_Name: Luca Scamoni > Version: 2.4.35 > OS: Linux > URL: ftp://www.sys-net.it/alias-deref-ITS2.tar.gz > Submission from: (NULL) (78.134.117.13) > > > Investigating alias dereferencing slowness on a customer production system I > came upon a suspect behaviour with back-hdb/bdb. > It seems that slapd, when dereferencing, instead of looking for the exact > aliased DN, starts scanning more entries than needed (at least this is what I > can tell looking to the logs set to log anything) > On the customer system, with over 700,000 entries, the time taken to perform a > simple search with alias dereferencing for a single entry, takes as much as > performing a full ldapsearch of the entire ldap tree. > To reproduce I created a small testcase (that I can't upload because there's no > space left on ftp.openldap.org/incoming). The test case contains also the log > and the operations performed on test data to show the issue. > I tested with openldap 2.4.23, 2.4.31 and 2.4.35. The issue is present in all > versions but seems to manifest itself only with back-bdb/hdb. Back-mdb seems not > to show the issue (even looking at the logs) but right now, moving to back-mdb > is not something the customer is ready to take. I would not recommend switching to back-mdb at this time, see ITS#7577. Alias dereferencing is broken in a few cases in back-mdb. Meanwhile, in back-bdb/hdb, it also depends on whether you're searching with Deref set to Finding, Searching or Always. Deref/Finding works in all 3 backends (bdb/hdb/mdb). (Deref/Searching in back-mdb was mainly broken by the patches in ITS#7473.) When Deref is set to Searching/Always, the backend must find every alias within the target search scope and dereference them. This deref can potentially expand the scope of the search, e.g. if the alias points to a completely different subtree. If you have a lot of aliases in the tree, this is likely going to be very slow. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs