openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#5306) install ladp
by aslang＠ntu.edu.sg 04 Jan '08

04 Jan '08

Full_Name: Linda Ang Version: OpenLDAP: slapd 2.3.35 OS: Ububtu 1.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.69.2.5) I keep having this error: please advice slapadd -l init.ldif /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" slapadd: could not parse entry (line=52) In my init.ldif, I do have line 52, my last line is 51 This is the content of the /etc/ldap/slapd.conf file ######################### /etc/ldap/slapd.conf ######################### # http://homex.subnet.at/~max/ldap/ # # Basic slapd.conf # # 2005.02.08 ZHANG.Guiyu(a)example.com ######################################################################## # Global Directives: # # Features to permit #allow bind_v2 # Schema and objectClass definitions # not all required, if you get errors about missing schema, comment out the missing schema here # some are provided by other packages such as samba include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb #moduleload back_passwd ####################################################################### # Specific Backend Directives for ldbm: # Backend specific directives apply to this backend until another # backend' directive occurs backend bdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs # backend <other> ####################################################################### # Specific Directives for database #1, of type ldbm: # Database specific directives apply to this databasse until another # 'database' directive occurs # # important: use bdb format, other formats like ldbm can cause data corruption database bdb # The base of your directory in database #1 suffix "dc=4g,dc=ntu,dc=edu,dc=sg" rootdn "cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" password-hash {CRYPT} #rootpw {CRYPT}asdfghjkl # # use "/usr/sbin/slappasswd -h {CRYPT}" to create a rootpw-string below rootpw {CRYPT}1zLLT3DU571FM # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only # access to attrs=userPassword,sambaLMPassword,sambaNTPassword by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by anonymous auth by self write by * none access to * by dn="cn=nss,dc=ntu,dc=edu,dc=sg" read by * auth # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. #access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=mail,dc=example,dc=com" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be bdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # #The base of your directory for database #2 #suffix "dc=debian,dc=org" ####################################################################### This is the content of my init.ldif file dn: dc=4g,dc=ntu,dc=edu,dc=sg objectClass: dcObject objectClass: organizationalUnit dc: 4g ou: NTU 4G Lab dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: people dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: staff dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: students dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: visitors dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: linda sn: Ang givenName: Linda cn: Linda Ang displayName: Linda Ang uidNumber: 1000 gidNumber: 10000 userPassword: password gecos: Linda Ang loginShell: /bin/bash homeDirectory: /home/linda shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: linda_yong(a)hotmail.com postalCode: 31000 l: Toulouse o: Example mobile: +65 (0)6 12345678 homePhone: +33 (0)5 12345678 title: System Administrator postalAddress: initials: LA dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg objectClass: posixGroup cn: 4g gidNumber: 10000

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by hyc＠symas.com 03 Jan '08

03 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Full_Name: Jose Marco de la Rosa > Version: 2.3.39 > OS: Kubuntu 7.10 > URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… > Submission from: (NULL) (80.25.122.131) > > > Two overlays that implement dynamic group classes defined with URL attributes > and allowing nesting. > > - The first one is an extension of th overlay expandURL but allowing nesting > > - The second one changes the way groups are constructed in a more powerful way > * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. > * if both are active, some searches don't behave as expacted! > * Specifically, if you turn both overlays on and search for > * 'entries with member=<some member value>' won't work properly > * for one of the overlays (the firstly activated one) Seems there's really no need for the nestedAggregateAttrDN overlay, since that is just a proper subset of a URL. I.e., anywhere you would use a simple DN is just a case of subGroupURL: ldap:///<dn>??base -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by josemarcodelarosa＠gmail.com 03 Jan '08

03 Jan '08

Full_Name: Jose Marco de la Rosa Version: 2.3.39 OS: Kubuntu 7.10 URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… Submission from: (NULL) (80.25.122.131) Two overlays that implement dynamic group classes defined with URL attributes and allowing nesting. - The first one is an extension of th overlay expandURL but allowing nesting - The second one changes the way groups are constructed in a more powerful way Examples of functioning follow for each version and are included in the overlays code archives (.c) The tarball Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz was uploaded to openldap's server and it includes a webpage with further detail in the implementation and configuration of the overlay. Code files are appropriately linked in the web page mentioned (all is included in the tarball: there are no external references in the webpage). Both search and compare operations were implemented I hope you like it... ####################################################### First overlay: nestedAggregateAttrDN: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrDN * nestedAggregateAttrDN <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupDN' * DESC 'DN of a aggregable entry' * SUP distinguishedName ) * * # Classes for using overlay nestedAggregateAttrDN * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedDNGroup' * DESC 'Sample class for nestedAggregateAttrDN (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupDN $ cn $ ou $ o $ description ) ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrDN * # Configure class: subgroupedDNGroup * # Source attribute: subgroupDN * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrDN subgroupedDNGroup subgroupDN member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedDNGroup * subgroupDN: cn=Static1,dc=test * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * * IMPORTANT: this overlay conflicts with nestedAggregateAttrURL. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) */ ####################################################### Second overlay: nestedAggregateAttrURL: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrURL * nestedAggregateAttrURL <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema. You can use * netscape's groupOfURLs, anyway... * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupURL' * DESC 'URL to search for aggregable entries' * SUP labeledURI ) * * # Classes for using overlay nestedAggregateAttrURL * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedURLGroup' * DESC 'Sample class for nestedAggregateAttrURL (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupURL $ cn $ ou $ o $ description ) ) * * attributetype ( IAVANTE_LDAPattributeType:2 * NAME 'subgroupURL' * DESC 'Identifies an URL containing a search for names of subgroups.' * SUP labeledURI ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrURL * # Configure class: subgroupedURLGroup * # Source attribute: memberURL * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrURL subgroupedURLGroup subgroupURL member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///dc=test??one?(cn=Static*) * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) * */

1 0

Re: (ITS#5281) doc contribution - set examples - following references
by ando＠sys-net.it 02 Jan '08

02 Jan '08

andreas(a)mandriva.com.br wrote: > On Wed, Jan 02, 2008 at 02:53:06PM +0000, Gavin Henry wrote: >> It's up for discussion if the ACL discussion in the current config sections >> of the admin guide should stay there or be moved out into their own. > > I think the ACLs should be moved to their own section, like the man > pages already have done. We have a man page for slapd.conf and another > specific one for the ACLs (slapd.access) ... but that was done essentially because ACL configuration amounts to ~30% of the total slapd.conf man page, but 90% of ACL documentation belongs to configuration. So it's not yet clear where they should be located in the Admin Guide. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5281) doc contribution - set examples - following references
by andreas＠mandriva.com.br 02 Jan '08

02 Jan '08

On Wed, Jan 02, 2008 at 02:53:06PM +0000, Gavin Henry wrote: > It's up for discussion if the ACL discussion in the current config sections > of the admin guide should stay there or be moved out into their own. I think the ACLs should be moved to their own section, like the man pages already have done. We have a man page for slapd.conf and another specific one for the ACLs (slapd.access)

1 0

Re: (ITS#5304) bug in source code: libldap/extended.c ?
by ando＠sys-net.it 02 Jan '08

02 Jan '08

I've patched it differently in HEAD (rev. 1.44); please check. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Correction to suggested fix: I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); if (resdata != NULL) ber_bvfree( resdata ); return ld->ld_errno; }

1 0

(ITS#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Full_Name: Mark Funkenhauser Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.16.247.2) Looking at libldap/extended.c, rev 1.43, function ldap_parse_intermediate(), at line 374, the code is written as: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { rc = LDAP_DECODING_ERROR; goto free_and_return; } I think there's a problem here. 1) rc is defined to be a ber_tag_t type, which is not suitable for assignment to an LDAP_*_ERROR error code. ber_tag_t is an unsigned type, and LDAP_DECODING_ERROR is a negative number. 2) The use of LDAP_DECODING_ERROR here implies there is an error. I would have thought this function should be returning this error code using "return ld->ld_errno". Jumping to "free_and_return" is not the way to return an error. 3) the "goto free_and_return" is a jump to code to handle a successful return from this function. Assigning any value to rc before this "goto" becomes a no-op because the code after "free_and_return" does not use rc. I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); return ld->ld_errno; }

1 0

Re: (ITS#5281) doc contribution - set examples - following references
by ghenry＠OpenLDAP.org 02 Jan '08

02 Jan '08

andreas(a)mandriva.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.4.6 > OS: Linux > URL: http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > Submission from: (NULL) (200.140.247.99) > > > http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > > Documentation contribution with further examples regarding the usage of sets in > ACLs. This time, using a user/manager/secretary/group example. > > These files are derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not subject > to any license of Mandriva. > I, Andreas Hasenack, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > Thanks for this Andreas. I'll be working on a sets section in the ACL section shortly. It's up for discussion if the ACL discussion in the current config sections of the admin guide should stay there or be moved out into their own. More later. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5303) idlcache problem with new entries
by hyc＠symas.com 31 Dec '07

31 Dec '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.39 > OS: NA > URL: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > Submission from: (NULL) (76.21.80.71) > > > While testing heavy account provisioning using multiple threads to create > accounts in an OpenLDAP server, we discovered that the idl cache fails to > properly update, making searches for successfully added accounts fail to find > them. Setting the idlcachesize to zero resolved the search problem, indicating > an issue inside the idl cache code. This is a dup of ITS#5086, fixed in HEAD. Please test... > Zimbra bug is here: > > http://bugzilla.zimbra.com/show_bug.cgi?id=22933 > > > Description: > ============ > - OpenLDAP build: openldap-2.3.39 > - 20 concurrent threads are ADDing (distinct) entries in a loop under a > common base DN. > - It seems intermittently upon DB_LOCK_DEADLOCK errors, the integrity of > indexes are broken > for a period of time even after the ADD returns a good code(err=0). > Search filtered on an indexed > attribute of the newly ADDed entry cannot be found. If the same query is > done again later, it > did find the entry. > - This seems to happen only after "many" DB_LOCK_DEADLOCK errors. The > search failure usually happens > after 20 to 80 iterations into the loop, while the deadlock error would > start happening since earlier > iterations. > > Notes on info in attached slapd.log: > ==================================== > 1. The described test started on line 996. > > 2. Line 25510 shows the ADD > Dec 20 14:45:51 phoebe slapd[209]: conn=2235 op=1 ADD > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > > 3. Line 25542 shows the ADD was successful > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=1 RESULT tag=105 err=0 > text= > > This entry should contain (among other attributes): > objectClass: zimbraAccount > zimbraId: be0b628b-b8d1-4fce-99cd-7b7f6864149a > > 4. Line 25549 - 25550 shows the search on that zimbraId returned 0 entry: > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > 5. Later, the same search(as in 3) was attempted. Line 25756 - 25757 shows the > same query did find one entry this time: > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SEARCH RESULT tag=101 > err=0 nentries=1 text= > > 6. As shown in the log, there was no MOD or anything on DN > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > between 3 and 4. > > 7. Other info: > - zimbraId is an indexed attribute. see slapd.conf. > - Note, the test stops when it encounters the first failed search after a > successful create. > > > > slapd.conf and slapd.log files are on the OpenLDAP ftp server as: > ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > > > > -- -- Howard Chu Chief Architect, 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