- openldap-bugs - openldap.org

(ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 05 Aug '09

05 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.235.224.133) Querying back monitor to examine the values of the various caches reports the entry cache as empty: # Frontend, Databases, Monitor dn: cn=Frontend,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: frontend monitorIsShadow: FALSE namingContexts: readOnly: FALSE olmBDBEntryCache: 0 olmBDBDNCache: 592 olmBDBIDLCache: 502 olmDbDirectory: /opt/zimbra/data/ldap/hdb/db/ entryDN: cn=Frontend,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

masarati(a)aero.polimi.it wrote: > I'll look at your links later. I assume you mean libdb-4.6; is it > patched with official Oracle patches? > > p. > Yes, it is libdb-4.6.21 provided by Debian . I am not sure for the patches from Oracle. I ecounter the same corruption problem with libdb-4.7.25 and also with older verstions. luben

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

karavelov wrote: > First, thanks for the suggestions. > I have updated my config file and you could find it here: > > http://purgatory.spnet.net/~karavelov/slapd.conf.clean > > But the problem I have desctribed still persist. You could find a log here: > > http://purgatory.spnet.net/~karavelov/faillog > > the logging is set to: trace stats stats2 pcache (I believe that 0x1000 > is pcache) > > It consists of 3 parts: > > 1. First query for "justillusion.net", it is not in the cache. It hits > the SQL database and is reported to be > stored in dbd cache > 2. Some seconds later the same query fails > 3. An analogous query succeed > > I could cut more form the log file if somebody needs it. > > I do not think that the fails depend on the data being stored (no > NULLs). Some different records get corrupted > and I do not see nothing common that could be the cause of the > corruption. Just in differend times, differend > records get corrupted. > > This is slapd-2.4.17 + patch from head (back-sql/search.c), libdbd-4.6 I'll look at your links later. I assume you mean libdb-4.6; is it patched with official Oracle patches? p.

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

First, thanks for the suggestions. I have updated my config file and you could find it here: http://purgatory.spnet.net/~karavelov/slapd.conf.clean But the problem I have desctribed still persist. You could find a log here: http://purgatory.spnet.net/~karavelov/faillog the logging is set to: trace stats stats2 pcache (I believe that 0x1000 is pcache) It consists of 3 parts: 1. First query for "justillusion.net", it is not in the cache. It hits the SQL database and is reported to be stored in dbd cache 2. Some seconds later the same query fails 3. An analogous query succeed I could cut more form the log file if somebody needs it. I do not think that the fails depend on the data being stored (no NULLs). Some different records get corrupted and I do not see nothing common that could be the cause of the corruption. Just in differend times, differend records get corrupted. This is slapd-2.4.17 + patch from head (back-sql/search.c), libdbd-4.6 Thanks in advance

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 05 Aug '09

05 Aug '09

--=-797W8K2OMmXVapcbJp3G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > [Resending because I forgot the ITS number in the subject] >=20 > I have a simple prototype that on add/modrdn populates/maintains an > attribute (rdnValue) with the distinguished values of the naming > attributes of the RDN. While doing this, it also checks for uniqueness o= f > the rdnValue value within siblings. >=20 > You can find it here > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.= c> >=20 > Please test and comment. I hope it does what intended. Can you please remind me in a few days if I don't get to this? I'm keen to try it out, but I'm also busy with other things, so liable to forget. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-797W8K2OMmXVapcbJp3G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKeXCFz4A8Wyi0NrsRAnciAJ0W4oCBgFTi9hZ9kRZhYV2HVhYY5QCfb5pG YmV71t4D3eYdAPwunBt5clU= =ZZGj -----END PGP SIGNATURE----- --=-797W8K2OMmXVapcbJp3G--

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

I see a few configuration issues that may be related to the problem you describe. See below for details. > karavelov(a)spnet.net wrote: >> This is a multi-part message in MIME format. >> --------------000408020401050805090402 >> > The attachment did't work. So here is the conf file: You should provide an URI to data you want to share. You can upload data to OpenLDAP's public FTP site. > # This is the main slapd configuration file. See slapd.conf(5) for more > # info on the configuration options. > > ####################################################################### > # Global Directives: > > # Schema and objectClass definitions > 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/mailrouter.schema > > # 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/slapd.args > > # Read slapd.conf(5) for possible values > loglevel 4864 ^^^ This is equivalent to 0x100 + 0x200 + 0x1000, which means stats, stats2 and an undefined log level. > # Where the dynamically loaded modules are stored > modulepath /usr/lib/ldap > moduleload back_bdb > moduleload back_sql > moduleload pcache > > # The maximum number of entries that is returned for a search operation > sizelimit 500 > > # The tool-threads parameter sets the actual amount of cpu's that is used > # for indexing. > tool-threads 8 > threads 2 This may be nonsense. The default is 16 threads, and you should not use less unless you know what you're doing. Slapo-pcache uses internal threads for cache maintenance; slapd may need to use other threads for internal purposes. Setting threads to 2 you risk starvation as soon as multiple internal tasks need to be done at the same time. > # 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 dn.subtree="dc=hosting,dc=spnet,dc=net" > by dn="cn=nss,dc=ldapaccess" read > > > access to * > by * auth > > # LDIF for bind creditials > database ldif > suffix "dc=ldapaccess" > rootdn "dc=ldapaccess" > directory "/etc/ldap/ldif" > rootpw some-secret > #readonly on > > ####################################################################### > ## sql database definitions > ######################################################################## > # > database sql > suffix "dc=spnet,dc=net" > rootdn "cn=admin,dc=spnet,dc=net" > rootpw bind-secret > dbname ISP > dbuser ldap > dbpasswd sql-secret > aliasing_quote \" > subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" > # actiualy it is read only db - it is never used > insentry_stmt "INSERT INTO ldap_entries > (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" > upper_func UPPER > has_ldapinfo_dn_ru no > > ########## > # chache > ########## > overlay pcache > proxycache bdb 67108864 2 16384 60 Are you seriously going to cache up to 67M entries in a database with 16MB of Berkeley DB cache? (see below) > proxyAttrset 0 cn uid uidNumber gidNumber loginShell homeDirectory > userPassword description gecos memberUid dc spamassassin > proxyAttrset 1 spamassassin uid cn userPassword dc mailMessageStore > mailQuota uidNumber gidNumber mailAliasedName > > proxytemplate (&(objectClass=)(uidNumber=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(gidNumber=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(uid=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(memberUid=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) > 0 3600 3600 > proxytemplate (&(objectClass=)(dc=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(cn=)) > 0 3600 3600 > proxytemplate (objectClass=) > 0 3600 3600 > proxytemplate (uid=) > 0 3600 3600 > proxytemplate (cn=) > 0 3600 3600 > proxytemplate (dc=) > 0 3600 3600 > > > proxytemplate (&(objectClass=)(uidNumber=)) > 1 600 300 > proxytemplate (&(objectClass=)(gidNumber=)) > 1 600 300 > proxytemplate (&(objectClass=)(uid=)) > 1 600 300 > proxytemplate (&(objectClass=)(dc=)) > 1 600 300 > proxytemplate (&(objectClass=)(cn=)) > 1 600 300 > proxytemplate (objectClass=) > 1 600 300 > proxytemplate (uid=) > 1 600 300 > proxytemplate (cn=) > 1 600 300 I hope line wraps are related to cut'n'paste in the mailer. Continuation lines need to start with a blank in slapd.conf > > # dbd backend config > > directory /var/tmp/ > > index objectClass eq > index uid eq > index uidNumber eq > index gidNumber eq > index memberUid eq > index dc pres,eq,sub > index cn pres,eq,sub > > checkpoint 128 60 > cachesize 163840 > idlcachesize 163840 > dirtyread ^^^ you shouldn't use this parameter if you look for search result consistency > dbconfig set_cachesize 0 16777216 1 as mentioned earlier, this value makes little sense, since a 16MB cache is going to perform poorly as soon as your database is less than minimal. Read Berkeley DB documentation for details about the meaning of this configuration. A sane starting value, also depending on the amount of RAM of your system, is 256MB. > dbconfig set_lg_regionmax 262144 > dbconfig set_lg_bsize 2097152 In conclusion, there is nothing blatantly wrong, but some tuning might improve your configuration. As per the issue you're complaining about, you should investigate it a little further, before we can determine whether it's caused by a bug in the software and, in case, track it. For example, you should determine whether it repeats with a given data set, and possibly provide logs at stats, stats2, pcache level of a malfunctioning event. p.

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 04 Aug '09

04 Aug '09

karavelov(a)spnet.net wrote: > This is a multi-part message in MIME format. > --------------000408020401050805090402 > The attachment did't work. So here is the conf file: # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Schema and objectClass definitions 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/mailrouter.schema # 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/slapd.args # Read slapd.conf(5) for possible values loglevel 4864 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload back_sql moduleload pcache # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 8 threads 2 # 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 dn.subtree="dc=hosting,dc=spnet,dc=net" by dn="cn=nss,dc=ldapaccess" read access to * by * auth # LDIF for bind creditials database ldif suffix "dc=ldapaccess" rootdn "dc=ldapaccess" directory "/etc/ldap/ldif" rootpw some-secret #readonly on ####################################################################### ## sql database definitions ######################################################################## # database sql suffix "dc=spnet,dc=net" rootdn "cn=admin,dc=spnet,dc=net" rootpw bind-secret dbname ISP dbuser ldap dbpasswd sql-secret aliasing_quote \" subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" # actiualy it is read only db - it is never used insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no ########## # chache ########## overlay pcache proxycache bdb 67108864 2 16384 60 proxyAttrset 0 cn uid uidNumber gidNumber loginShell homeDirectory userPassword description gecos memberUid dc spamassassin proxyAttrset 1 spamassassin uid cn userPassword dc mailMessageStore mailQuota uidNumber gidNumber mailAliasedName proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 3600 proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 3600 proxytemplate (&(objectClass=)(uid=)) 0 3600 3600 proxytemplate (&(objectClass=)(memberUid=)) 0 3600 3600 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 3600 3600 proxytemplate (&(objectClass=)(dc=)) 0 3600 3600 proxytemplate (&(objectClass=)(cn=)) 0 3600 3600 proxytemplate (objectClass=) 0 3600 3600 proxytemplate (uid=) 0 3600 3600 proxytemplate (cn=) 0 3600 3600 proxytemplate (dc=) 0 3600 3600 proxytemplate (&(objectClass=)(uidNumber=)) 1 600 300 proxytemplate (&(objectClass=)(gidNumber=)) 1 600 300 proxytemplate (&(objectClass=)(uid=)) 1 600 300 proxytemplate (&(objectClass=)(dc=)) 1 600 300 proxytemplate (&(objectClass=)(cn=)) 1 600 300 proxytemplate (objectClass=) 1 600 300 proxytemplate (uid=) 1 600 300 proxytemplate (cn=) 1 600 300 # dbd backend config directory /var/tmp/ index objectClass eq index uid eq index uidNumber eq index gidNumber eq index memberUid eq index dc pres,eq,sub index cn pres,eq,sub checkpoint 128 60 cachesize 163840 idlcachesize 163840 dirtyread dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 04 Aug '09

04 Aug '09

This is a multi-part message in MIME format. --------------000408020401050805090402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit karavelov(a)spnet.net wrote: > Full_Name: Luben Karavelov > Version: 2.4.11-CVS-HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.34.104.18) > Attached is the current configuration file (cleaned from sensitive info). The queries that exhibit the cache corruption are like: ldapsearch -h work -vLx -D "cn=nss,dc=ldapaccess" -w bind-secret -s one -b "dc=HOSTING,dc=SPNET,dc=NET" "(&(objectClass=mailDomain)(dc=example.com))" spamassassin I have saved some corrupted cache databases. I could answer questions about them. --------------000408020401050805090402 Content-Type: text/plain; name="slapd.conf.clean" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="slapd.conf.clean" IyBUaGlzIGlzIHRoZSBtYWluIHNsYXBkIGNvbmZpZ3VyYXRpb24gZmlsZS4gU2VlIHNsYXBk LmNvbmYoNSkgZm9yIG1vcmUKIyBpbmZvIG9uIHRoZSBjb25maWd1cmF0aW9uIG9wdGlvbnMu CgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwojIEdsb2JhbCBEaXJlY3RpdmVzOgoKIyBTY2hlbWEgYW5k IG9iamVjdENsYXNzIGRlZmluaXRpb25zCmluY2x1ZGUgICAgICAgICAvZXRjL2xkYXAvc2No ZW1hL2NvcmUuc2NoZW1hCmluY2x1ZGUgICAgICAgICAvZXRjL2xkYXAvc2NoZW1hL2Nvc2lu ZS5zY2hlbWEKaW5jbHVkZSAgICAgICAgIC9ldGMvbGRhcC9zY2hlbWEvbmlzLnNjaGVtYQpp bmNsdWRlICAgICAgICAgL2V0Yy9sZGFwL3NjaGVtYS9pbmV0b3JncGVyc29uLnNjaGVtYQpp bmNsdWRlICAgICAgICAgL2V0Yy9sZGFwL3NjaGVtYS9tYWlscm91dGVyLnNjaGVtYQoKIyBX aGVyZSB0aGUgcGlkIGZpbGUgaXMgcHV0LiBUaGUgaW5pdC5kIHNjcmlwdAojIHdpbGwgbm90 IHN0b3AgdGhlIHNlcnZlciBpZiB5b3UgY2hhbmdlIHRoaXMuCnBpZGZpbGUgICAgICAgICAv dmFyL3J1bi9zbGFwZC9zbGFwZC5waWQKCiMgTGlzdCBvZiBhcmd1bWVudHMgdGhhdCB3ZXJl IHBhc3NlZCB0byB0aGUgc2VydmVyCmFyZ3NmaWxlICAgICAgICAvdmFyL3J1bi9zbGFwZC9z bGFwZC5hcmdzCgojIFJlYWQgc2xhcGQuY29uZig1KSBmb3IgcG9zc2libGUgdmFsdWVzCmxv Z2xldmVsICAgIDQ4NjQKCiMgV2hlcmUgdGhlIGR5bmFtaWNhbGx5IGxvYWRlZCBtb2R1bGVz IGFyZSBzdG9yZWQKbW9kdWxlcGF0aAkvdXNyL2xpYi9sZGFwCm1vZHVsZWxvYWQJYmFja19i ZGIKbW9kdWxlbG9hZAliYWNrX3NxbAptb2R1bGVsb2FkCXBjYWNoZQoKIyBUaGUgbWF4aW11 bSBudW1iZXIgb2YgZW50cmllcyB0aGF0IGlzIHJldHVybmVkIGZvciBhIHNlYXJjaCBvcGVy YXRpb24Kc2l6ZWxpbWl0IDUwMAoKIyBUaGUgdG9vbC10aHJlYWRzIHBhcmFtZXRlciBzZXRz IHRoZSBhY3R1YWwgYW1vdW50IG9mIGNwdSdzIHRoYXQgaXMgdXNlZAojIGZvciBpbmRleGlu Zy4KdG9vbC10aHJlYWRzIDgKdGhyZWFkcyAyCgojIEVuc3VyZSByZWFkIGFjY2VzcyB0byB0 aGUgYmFzZSBmb3IgdGhpbmdzIGxpa2UKIyBzdXBwb3J0ZWRTQVNMTWVjaGFuaXNtcy4gIFdp dGhvdXQgdGhpcyB5b3UgbWF5CiMgaGF2ZSBwcm9ibGVtcyB3aXRoIFNBU0wgbm90IGtub3dp bmcgd2hhdAojIG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJsZSBhbmQgdGhlIGxpa2UuCiMgTm90 ZSB0aGF0IHRoaXMgaXMgY292ZXJlZCBieSB0aGUgJ2FjY2VzcyB0byAqJwojIEFDTCBiZWxv dyB0b28gYnV0IGlmIHlvdSBjaGFuZ2UgdGhhdCBhcyBwZW9wbGUKIyBhcmUgd29udCB0byBk byB5b3UnbGwgc3RpbGwgbmVlZCB0aGlzIGlmIHlvdQojIHdhbnQgU0FTTCAoYW5kIHBvc3Np YmxlIG90aGVyIHRoaW5ncykgdG8gd29yayAKIyBoYXBwaWx5LgphY2Nlc3MgdG8gZG4uYmFz ZT0iIiBieSAqIHJlYWQKCiMgVGhlIGFkbWluIGRuIGhhcyBmdWxsIHdyaXRlIGFjY2Vzcywg ZXZlcnlvbmUgZWxzZQojIGNhbiByZWFkIGV2ZXJ5dGhpbmcuCgphY2Nlc3MgdG8gZG4uc3Vi dHJlZT0iZGM9aG9zdGluZyxkYz1zcG5ldCxkYz1uZXQiCiAgICAgICBieSBkbj0iY249bnNz LGRjPWxkYXBhY2Nlc3MiIHJlYWQKCgphY2Nlc3MgdG8gKgogICAgICAgYnkgKiBhdXRoCgoj IExESUYgZm9yIGJpbmQgY3JlZGl0aWFscwpkYXRhYmFzZSBsZGlmCnN1ZmZpeCAgICAgICJk Yz1sZGFwYWNjZXNzIgpyb290ZG4gICAgICAiZGM9bGRhcGFjY2VzcyIKZGlyZWN0b3J5CSIv ZXRjL2xkYXAvbGRpZiIKcm9vdHB3ICAgICAgc29tZS1zZWNyZXQKI3JlYWRvbmx5CQlvbgoK IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMKIyMgc3FsIGRhdGFiYXNlIGRlZmluaXRpb25zCiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIwojCmRhdGFiYXNlIHNxbApzdWZmaXggICAgICAiZGM9c3BuZXQsZGM9bmV0 Igpyb290ZG4gICAgICAiY249YWRtaW4sZGM9c3BuZXQsZGM9bmV0Igpyb290cHcgICAgICBi aW5kLXNlY3JldApkYm5hbWUgICAgICAgICAgSVNQCmRidXNlciAgICAgICAgICBsZGFwCmRi cGFzc3dkICAgICAgICBzcWwtc2VjcmV0CmFsaWFzaW5nX3F1b3RlCSBcIgpzdWJ0cmVlX2Nv bmQgICAgIlVQUEVSKGxkYXBfZW50cmllcy5kbikgTElLRSBDT05DQVQoJyUnLFVQUEVSKD8p KSIKIyBhY3RpdWFseSBpdCBpcyByZWFkIG9ubHkgZGIgLSBpdCBpcyBuZXZlciB1c2VkCmlu c2VudHJ5X3N0bXQgICAiSU5TRVJUIElOVE8gbGRhcF9lbnRyaWVzIChpZCxkbixvY19tYXBf aWQscGFyZW50LGtleXZhbCkgVkFMVUVTIChsZGFwX2VudHJ5X2lkcy5uZXh0dmFsLD8sPyw/ LD8pIgp1cHBlcl9mdW5jICAgICAgVVBQRVIKaGFzX2xkYXBpbmZvX2RuX3J1IG5vCgojIyMj IyMjIyMjCiMgY2hhY2hlCiMjIyMjIyMjIyMKb3ZlcmxheSBwY2FjaGUKIyNwcm94eWNhY2hl ICAgIGJkYiAxMDAwMDAgMyAxMDAwIDEwMApwcm94eWNhY2hlICAgIGJkYiA2NzEwODg2NCAy IDE2Mzg0IDYwCgpwcm94eUF0dHJzZXQgIDAgY24gdWlkIHVpZE51bWJlciBnaWROdW1iZXIg bG9naW5TaGVsbCBob21lRGlyZWN0b3J5IHVzZXJQYXNzd29yZCBkZXNjcmlwdGlvbiBnZWNv cyBtZW1iZXJVaWQgZGMgc3BhbWFzc2Fzc2luIG9iamVjdENsYXNzCnByb3h5QXR0cnNldCAg MSBzcGFtYXNzYXNzaW4gdWlkIGNuIHVzZXJQYXNzd29yZCBkYyBtYWlsTWVzc2FnZVN0b3Jl IG1haWxRdW90YSB1aWROdW1iZXIgZ2lkTnVtYmVyIG1haWxBbGlhc2VkTmFtZSBvYmplY3RD bGFzcwoKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkodWlkTnVtYmVyPSkpICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgm KG9iamVjdENsYXNzPSkoZ2lkTnVtYmVyPSkpICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkodWlkPSkpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0 ZSAgICgmKG9iamVjdENsYXNzPSkobWVtYmVyVWlkPSkpICAgICAgICAgICAgICAgICAgICAg ICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkofCht ZW1iZXJVaWQ9KSh1bmlxdWVNZW1iZXI9KSkpICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0 ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkoZGM9KSkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNz PSkoY249KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAK cHJveHl0ZW1wbGF0ZSAgIChvYmplY3RDbGFzcz0pICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICh1aWQ9KSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAw IDM2MDAKcHJveHl0ZW1wbGF0ZSAgIChjbj0pICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgIChk Yz0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAzNjAwIDM2MDAKCgpwcm94eXRlbXBsYXRlICAgKCYob2JqZWN0Q2xhc3M9KSh1aWROdW1i ZXI9KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAxIDYwMCAzMDAKcHJveHl0ZW1wbGF0 ZSAgICgmKG9iamVjdENsYXNzPSkoZ2lkTnVtYmVyPSkpICAgICAgICAgICAgICAgICAgICAg ICAgICAgMSA2MDAgMzAwCnByb3h5dGVtcGxhdGUgICAoJihvYmplY3RDbGFzcz0pKHVpZD0p KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgNjAwIDMwMApwcm94eXRlbXBs YXRlICAgKCYob2JqZWN0Q2xhc3M9KShkYz0pKSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxIDYwMCAzMDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkoY249 KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSA2MDAgMzAwCnByb3h5dGVt cGxhdGUgICAob2JqZWN0Q2xhc3M9KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEgNjAwIDMwMApwcm94eXRlbXBsYXRlICAgKHVpZD0pICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIDYwMCAzMDAKcHJveHl0 ZW1wbGF0ZSAgIChjbj0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMSA2MDAgMzAwCgojIGRiZCBiYWNrZW5kIGNvbmZpZwoKZGlyZWN0b3J5 IC92YXIvdG1wLwoKaW5kZXggICAgICAgICAgIG9iamVjdENsYXNzIGVxCmluZGV4ICAgICAg ICAgICB1aWQgZXEKaW5kZXggICAgICAgICAgIHVpZE51bWJlciBlcQppbmRleCAgICAgICAg ICAgZ2lkTnVtYmVyIGVxCmluZGV4ICAgICAgICAgICBtZW1iZXJVaWQgZXEKaW5kZXggICAg ICAgICAgIGRjIHByZXMsZXEsc3ViCmluZGV4ICAgICAgICAgICBjbiBwcmVzLGVxLHN1YgoK Y2hlY2twb2ludCAgICAgIDEyOCA2MApjYWNoZXNpemUgICAgICAgMTYzODQwCmlkbGNhY2hl c2l6ZSAgICAxNjM4NDAKZGlydHlyZWFkCgpkYmNvbmZpZyAgICAgICAgc2V0X2NhY2hlc2l6 ZSAwIDE2Nzc3MjE2IDEKZGJjb25maWcgICAgICAgIHNldF9sZ19yZWdpb25tYXggMjYyMTQ0 CmRiY29uZmlnICAgICAgICBzZXRfbGdfYnNpemUgMjA5NzE1Mgo= --------------000408020401050805090402--

1 0

(ITS#6242) PCache cache corruption
by karavelov＠spnet.net 04 Aug '09

04 Aug '09

Full_Name: Luben Karavelov Version: 2.4.11-CVS-HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.34.104.18) Environment: We are trying to deploy openldap in a e-main and web hosting system for centralized management of authentication and configuration. The architecture is one DB server with all the information exposed to slapd server through views and two or three slapd servers for fail-over and load balancing. Each slapd is configured to cache positive and negative responses in bdb backend in order to speed up the LDAP queries (pcache overlay). The Problem: Sometimes there appears a cache corruption : after some correct responses the server starts to reply like there is no such record. The corrupted record does not expire. Tested versions: openldap 2.4.11 (Debian lenny), 2.4.15 (Debian sid), 2.4.17 (compiled from sources), CVS-HEAD bdb-4.2, bdb-4.6. bdb-4.7 unixodbc-2.2.14 Current configuration and details follow in next posts.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

> I am using 2.4.16. The problem is, that caching seems to work for some > entries but not for others. It is not related to the order of the filter > rules. Here is what happens: (lines starting with *** are my comments) > > > > **** slapd is started showing version, query templates and attributes > > bash-2.05# ./slapd -d 4096 > @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ > > jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd > /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn > is always granted unlimited privileges. > /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn > is always granted unlimited privileges. This tells us you have some ACLs in place. Could you show them? Actually, could you post your whole slapd.conf, if you're using any, or the contents of your cn=config database? Of course, after removing any sensitive information, like passwords. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 04 Aug '09

04 Aug '09

masarati(a)aero.polimi.it wrote: >> hyc(a)symas.com wrote: >> > The filter behavior you're describing was noted in ITS#5756, fixed in >> January. >> >> If it was fixed in January, why does openldap-2.4.16 (20090411) still >> exhibit the described behaviour? > > Did you actually try to swap the order of the filters, and did it work? > Since Howard fixed ITS#5756, you might be experiencing something > different. > > Also, can you check whether you're actually using 2.4.16? According to > the changelog, the fix to ITS#5756 was released with 2.4.14. > > p. > I am using 2.4.16. The problem is, that caching seems to work for some entries but not for others. It is not related to the order of the filter rules. Here is what happens: (lines starting with *** are my comments) **** slapd is started showing version, query templates and attributes bash-2.05# ./slapd -d 4096 @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn is always granted unlimited privileges. /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn is always granted unlimited privileges. Total # of attribute sets to be cached = 10. Template: query template: (&(objectClass=)(uid=)) attributes: uid cn Template: query template: (&(uid=)(objectClass=)) attributes: uid cn slapd starting *** Now I enter a search in another window bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=wvk))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=wvk)) # requesting: uid cn # # wvk, People, few.vu.nl dn: uid=wvk,ou=People,dc=few,dc=vu,dc=nl uid: wvk cn: wvk *** requested attributes are returned as expected # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 *** Output of slapd for this search ***** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=wvk)) Lock QC index = 31e698 Not answerable: Unlock QC index=31e698 QUERY NOT ANSWERABLE QUERY CACHEABLE Added query expires at 1249416628 (POSITIVE) Lock AQ index = 31e698 TEMPLATE 31e698 QUERIES++ 1 Unlock AQ index = 31e698 Base of added query = dc=few,dc=vu,dc=nl UUID for query being added = 68ab725c-157a-102e-87a7-cd469e2cf913 ENTRY ADDED/MERGED, CACHED ENTRIES=0 STORED QUERIES = 1 *** same search is repeated bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=wvk))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=wvk)) # requesting: uid cn # *** Note that nothing is returned # search result search: 2 result: 0 Success # numResponses: 1 *** Output of slapd for the second search **** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=wvk)) Lock QC index = 31e698 QUERY ANSWERABLE *** For another uid it works perfectly. /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=jim))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid cn # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim cn: W. van Keulen # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=jim))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid cn # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim cn: W. van Keulen # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 bash-2.05 *** Output of slapd for second case $bash-2.05# ./slapd -d 4096 @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn is always granted unlimited privileges. /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn is always granted unlimited privileges. Total # of attribute sets to be cached = 10. Template: query template: (&(objectClass=)(uid=)) attributes: uid cn Template: query template: (&(uid=)(objectClass=)) attributes: uid cn slapd starting query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31e698 Not answerable: Unlock QC index=31e698 QUERY NOT ANSWERABLE QUERY CACHEABLE Added query expires at 1249417816 (POSITIVE) Lock AQ index = 31e698 TEMPLATE 31e698 QUERIES++ 1 Unlock AQ index = 31e698 Base of added query = dc=few,dc=vu,dc=nl UUID for query being added = 2c8d245c-157d-102e-87c5-e7c795cd8bf5 ENTRY ADDED/MERGED, CACHED ENTRIES=0 STORED QUERIES = 1 query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31e698 QUERY ANSWERABLE There is no difference if I reverse the filter. It works for some uid's, but not for others. Regards, Jim

1 0

Re: state of pcache overlay enhancement - ITS#6152
by hyc＠symas.com 04 Aug '09

04 Aug '09

mathiaz(a)ubuntu.com wrote: > Hi, > > What is the current state of ITS 6152 (pcache enhancements) that were > discussed during the last Ubuntu Developer Summit? An "offline" configure switch has been added to disable the cache expiration. We assume a hook script can be used in NetworkManager to toggle this switch. The other details are not implemented yet but will be soon. -- -- 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

state of pcache overlay enhancement - ITS#6152
by mathiaz＠ubuntu.com 04 Aug '09

04 Aug '09

Hi, What is the current state of ITS 6152 (pcache enhancements) that were discussed during the last Ubuntu Developer Summit? -- Mathias Gug Ubuntu Developer http://www.ubuntu.com

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

> hyc(a)symas.com wrote: > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. > > If it was fixed in January, why does openldap-2.4.16 (20090411) still > exhibit the described behaviour? Did you actually try to swap the order of the filters, and did it work? Since Howard fixed ITS#5756, you might be experiencing something different. Also, can you check whether you're actually using 2.4.16? According to the changelog, the fix to ITS#5756 was released with 2.4.14. p.

1 0

(ITS#6241) certificate list parsing issues
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.250) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200908/msg00003.html> for details. A solution that logs issuer, thisUpdate is being implemented.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

Your message was unreadable, you should use text form for messages sent to the ITS. In any case, according to many sources, the default values for TCP buffers can be pretty small. Usually, they can be configured system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the buffer sizes to values one considers appropriate for the intended use of slapd. Since the optimal size roughly depends on latency and bandwidth, this may probably need to be configured on a per-listener basis, actually. However, in deployments where this problem becomes critical, usually hardware dedicated to slapd is used, so system-wide tuning (and auto-tuning) would be the preferred option anyway. Manual setting should be used only when system-wide or auto-tuning is not available or accessible for some reason. p.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristojosec＠yahoo.es 04 Aug '09

04 Aug '09

Hi,=0A=0AProbably "heavy LDAP" load was a very generic simplified definitio= n.=0AThe traffic model we are testing contains search and modify operations= . The=0Asearch response contains usually a single entry about 3KB in LDIF f= ormat. There=0Ais only a reduce number of LDAP clients (usually one or two)= , that are using=0Aasync LDAP API and sending a lot of operations per secon= d (> 1000 TPS per=0Aclient).=0A=0AUnder these conditions we have tested tha= t increasing the sending buffer of the=0Aserver has improved the performanc= e. That's the reason I am proposing this=0Afeature request.=0A=0ARegards,= =0A=0AEvaristo=0A=0A----- Mensaje original ----=0ADe: Howard Chu <hyc@symas= .com>=0APara: evaristojosec(a)yahoo.es=0ACC: openldap-its(a)openldap.org=0AEnvi= ado: martes, 4 de agosto, 2009 0:43:36=0AAsunto: Re: (ITS#6234) CONFIGURABL= E TCP BUFFERS IN SLAPD FEATURE REQUEST=0A=0Aevaristojosec(a)yahoo.es wrote:= =0A> Full_Name: Evaristo Camarero=0A> Version: 2.4.x=0A> OS: Linux=0A> URL:= ftp://ftp.openldap.org/incoming/=0A> Submission from: (NULL) (194.237.142.= 20)=0A> =0A> =0A> =0A> Hi,=0A> =0A> Working with slapd under heavy load it = could be interesting to have TCP buffers=0A> size configurable at slapd app= lication level instead of getting default OS=0A> values.=0A=0AI don't see t= his having any positive impact on slapd performance. "Heavy LDAP load" gene= rally implies lots of small queries with sets of small result objects; very= rarely do queries return large objects. When a system is under such heavy = load, requesting larger buffers per socket will make the system load worse,= as the kernel will have more memory consumed in these socket buffers and l= ess available for other demands.=0A=0AWhat workload have you tested this wi= th, and what performance impact did you measure as a result?=0A=0A> Some fa= st modifications in daemon.c file to achieve a hardcoded value for the=0A> = sender buffer are:=0A> =0A> int buf_size =3D 1572864; /* 1.5 Mb */= =0A> rc =3Dsetsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size,= =0A> sizeof(buf_size));=0A> if(rc=3D=3D-1) {=0A> Debug(= LDAP_DEBUG_ANY, "slapd(%ld): "=0A> "setsockopt(SO_SNDBUF) = failed errno=3D%d (%s)\n",=0A> (long) l.sl_sd, err, sock_er= rstr(err) );=0A> } else {=0A> Debug( LDAP_DEBUG_ANY, "s= lapd(%ld): setsockopt(SO_SNDBUF) to %d\n",=0A> (long) l.sl_= sd, buf_size, 0);=0A> }=0A=0A-- -- Howard Chu=0A CTO, Symas Corp= . http://www.symas.com=0A Director, Highland Sun http://highla= ndsun.com/hyc/=0A Chief Architect, OpenLDAP http://www.openldap.org/proje= ct/=0A=0A=0A=0A

1 0

Re: (ITS#6240) cn=config replication failing on repeat olcDbConfig
by hyc＠symas.com 03 Aug '09

03 Aug '09

matt.edlefsen(a)gmail.com wrote: > Full_Name: Matt Edlefsen > Version: 2.4.16 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.213.15.129) > > > When trying to setup multi-master replication of a cn=config database I > encountered the following error: > Aug 3 20:21:38 gabbro slapd[81578]: syncrepl_message_to_entry: > rid=001 mods check (olcDbConfig: value #14 provided more than once) Thanks for the report, this is fixed in HEAD. -- -- 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

(ITS#6240) cn=config replication failing on repeat olcDbConfig
by matt.edlefsen＠gmail.com 03 Aug '09

03 Aug '09

Full_Name: Matt Edlefsen Version: 2.4.16 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.213.15.129) When trying to setup multi-master replication of a cn=config database I encountered the following error: Aug 3 20:21:38 gabbro slapd[81578]: syncrepl_message_to_entry: rid=001 mods check (olcDbConfig: value #14 provided more than once) Process: The cn=config used was copied to both servers (using ldapsearch -LLL | slapadd -n 0) from a third server, which in turn was originally converted from a basic slapd.conf using slapd -f -F. To turn on replication I added the following entries/attributes to the cn=config tree of both servers following the steps outlined in the Users Guide (only the relevant attributes are listed): dn: cn=config olcServerID: 1 ldap://rock.earlham.edu/ olcServerID: 2 ldap://gabbro.earlham.edu/ dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=dap://rock.earlham.edu/ binddn="<snip>" bindmethod=simple credentials=<snip> searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://gabbro.earlham.edu/ binddn="<snip>" bindmethod=simple credentials=<snip> searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov When I added the above to the second server it started replicating against the first and when it reached the olcDbConfig attributes of the bdb database config it failed with the error message given above. The olcDbConfig attributes are: olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co…> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig: {8}# <http://www.openldap.org/faq/index.cgi?file=2> olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon rebuilding olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 1 GB cache olcDbConfig: {16}set_cachesize 0 1073741824 1 olcDbConfig: {17} olcDbConfig: {18}# Data Directory olcDbConfig: {19}#set_data_dir db olcDbConfig: {20} olcDbConfig: {21}# Transaction Log settings olcDbConfig: {22}set_lg_regionmax 262144 olcDbConfig: {23}set_lg_bsize 104857600 olcDbConfig: {24}set_lk_max_locks 100000 olcDbConfig: {25}#set_lg_dir logs olcDbConfig: {26} olcDbConfig: {27}# Note: special DB_CONFIG flags are no longer needed for "quick" olcDbConfig: {28}# slapadd(8) or slapindex(8) access (see their -q option). Fix: Removing all the duplicate entries (not counting the {#} prefixes) fixed the problem.

1 0

(ITS#6163)
by karavelov＠spnet.net 03 Aug '09

03 Aug '09

I have tested with 2.4.17 with servers/slapd/back-sql/search.c from CVS HEAD and the issue is resolved. Thanks Luben Karavelov

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by hyc＠symas.com 03 Aug '09

03 Aug '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. I don't see this having any positive impact on slapd performance. "Heavy LDAP load" generally implies lots of small queries with sets of small result objects; very rarely do queries return large objects. When a system is under such heavy load, requesting larger buffers per socket will make the system load worse, as the kernel will have more memory consumed in these socket buffers and less available for other demands. What workload have you tested this with, and what performance impact did you measure as a result? > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } -- -- 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#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

>> But he said that reversing the order of the filters (i.e. no >> objectClass=someclass first) cures the problem. > > Sorry, if he told you that it must have been in a private email. There is > no > such statement recorded in the ITS. He said it would be simple to reverse > the > filters, but that it would not accomplish anything since he wants to cache > searches from Samba. He didn't say that he actually tried reversing the > filters or that it worked. At any rate, the issue in 5756 was confirmed > fixed > so again, I do not believe it's responsible for the current situation. No private message. I probably misunderstood the message in followup 2. My understanding of that message is that he tried swapping the simple filters, but I admit the sentence sound ambiguous to me. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: >> Jim van Keulen wrote: >>> hyc(a)symas.com wrote: >>> > The filter behavior you're describing was noted in ITS#5756, fixed >>> in >>> January. >>> >>> If it was fixed in January, why does openldap-2.4.16 (20090411) still >>> exhibit the described behaviour? >> >> I don't believe what you're seeing now is due to the situation Ando >> described. > > But he said that reversing the order of the filters (i.e. no > objectClass=someclass first) cures the problem. Sorry, if he told you that it must have been in a private email. There is no such statement recorded in the ITS. He said it would be simple to reverse the filters, but that it would not accomplish anything since he wants to cache searches from Samba. He didn't say that he actually tried reversing the filters or that it worked. At any rate, the issue in 5756 was confirmed fixed so again, I do not believe it's responsible for the current situation. -- -- 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#6227) autogroup overlay breaks all searches
by hyc＠symas.com 03 Aug '09

03 Aug '09

mbuschman(a)cashnetusa.com wrote: > Confirmed working. > Also experienced (possibly unrelated?) segfault on slapadd. We can't tell if it's related or not unless you post the stack trace from the segfault. > > hyc(a)symas.com wrote: >> Fixed now in CVS HEAD. >> >> mbuschman(a)cashnetusa.com wrote: >> >>> Full_Name: Marshall Buschman >>> Version: 2.4.17 >>> OS: Debian Etch >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (38.98.177.132) >>> >>> >> >> >>> I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the >>> autogroup overlay, and I get the following error when I do an ldapsearch: >>> >>> $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com >>> # extended LDIF >>> ... >>> # search result >>> search: 2 >>> result: 53 Server is unwilling to perform >>> text: operation not supported within namingContext >>> >>> Relevant config: >>> ---------------------------------------------- >>> moduleload autogroup >>> >>> database bdb >>> suffix "dc=cashnetusa,dc=com" >>> >>> overlay autogroup >>> autogroup-attrset groupOfURLs memberURL member >>> ---------------------------------------------- >>> >>> OpenLDAP does start normally without the overlay. >>> >>> >> >> >> > > > -- -- 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#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> Jim van Keulen wrote: >> hyc(a)symas.com wrote: >> > The filter behavior you're describing was noted in ITS#5756, fixed >> in >> January. >> >> If it was fixed in January, why does openldap-2.4.16 (20090411) still >> exhibit the described behaviour? > > I don't believe what you're seeing now is due to the situation Ando > described. But he said that reversing the order of the filters (i.e. no objectClass=someclass first) cures the problem. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

Jim van Keulen wrote: > hyc(a)symas.com wrote: > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. > > If it was fixed in January, why does openldap-2.4.16 (20090411) still > exhibit the described behaviour? I don't believe what you're seeing now is due to the situation Ando described. -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 03 Aug '09

03 Aug '09

Confirmed working. Also experienced (possibly unrelated?) segfault on slapadd. hyc(a)symas.com wrote: > Fixed now in CVS HEAD. > > mbuschman(a)cashnetusa.com wrote: > >> Full_Name: Marshall Buschman >> Version: 2.4.17 >> OS: Debian Etch >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (38.98.177.132) >> >> > > >> I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the >> autogroup overlay, and I get the following error when I do an ldapsearch: >> >> $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com >> # extended LDIF >> ... >> # search result >> search: 2 >> result: 53 Server is unwilling to perform >> text: operation not supported within namingContext >> >> Relevant config: >> ---------------------------------------------- >> moduleload autogroup >> >> database bdb >> suffix "dc=cashnetusa,dc=com" >> >> overlay autogroup >> autogroup-attrset groupOfURLs memberURL member >> ---------------------------------------------- >> >> OpenLDAP does start normally without the overlay. >> >> > > >

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 03 Aug '09

03 Aug '09

hyc(a)symas.com wrote: > The filter behavior you're describing was noted in ITS#5756, fixed in January. If it was fixed in January, why does openldap-2.4.16 (20090411) still exhibit the described behaviour? regards, Jim van Keulen

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> masarati(a)aero.polimi.it wrote: >> As far as I recall, this is a known issue, although I could not locate >> early postings discussing this issue. What happens is that proxy cache >> makes use of the first item in the filter to discriminate between >> responses. In your filter template, the first item is the objectClass >> equality, which means that any filter with that objectClass value, >> regardless of the uid value, is treated as a duplicate of the first one. >> If you reverse the order of the equality filters you'll get the expected >> behavior. There should be another open ITS for this issue, but I can't >> locate it right now. > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. That's exactly the ITS I was looking for. Apparently I didn't use the right keywords, or just overlooked it. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > As far as I recall, this is a known issue, although I could not locate > early postings discussing this issue. What happens is that proxy cache > makes use of the first item in the filter to discriminate between > responses. In your filter template, the first item is the objectClass > equality, which means that any filter with that objectClass value, > regardless of the uid value, is treated as a duplicate of the first one. > If you reverse the order of the equality filters you'll get the expected > behavior. There should be another open ITS for this issue, but I can't > locate it right now. The filter behavior you're describing was noted in ITS#5756, fixed in January. -- -- 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

(ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

[Resending because I forgot the ITS number in the subject] I have a simple prototype that on add/modrdn populates/maintains an attribute (rdnValue) with the distinguished values of the naming attributes of the RDN. While doing this, it also checks for uniqueness of the rdnValue value within siblings. You can find it here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> Please test and comment. I hope it does what intended. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Please keep replies to the list, so the issue can be tracked. > Thank you for your help. Reversal of the filters is easily done. > However the searches I try to cache are taken from Samba. I have no > control over the way searches are done in Samba. I understand from the > documentation that the search template must be exact the same as the > search filter to be cachable. So this solution does not solve my > problem, I guess. Clear. I understand this issue needs to be fixed somehow. The reason for just using the first simple filter in composite filters is probably related to the fact it did not require extensive data manipulation, as probably would the definition of a criterion that accounts for the whole filter. The ITS remains open as a software bug. p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The ITS remains open, as the man page clearly needs to be improved to avoid any misunderstanding. An example would probably suffice. p. > masarati(a)aero.polimi.it wrote: >> The "strict" and the "ignore" keywords must be part of a single >> argument. >> In fact, the unique_uri statement only takes one argument, consisting of >> the optional "strict" and "ignore" keywords followed by a list of URIs. >> In order to be recognized as a single argument, the whole thing needs to >> be included in double quotes, like >> >> unique_uri "strict >> ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" >> >> p. > ahh I understand - this in mind the manpage makes sense, too. ;-) > > unique_uri <[strict ][ignore ]URI[URI...]...> > > Thanks a lot for the clarification! > > > >

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by daniel＠pluta.biz 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > The "strict" and the "ignore" keywords must be part of a single argument. > In fact, the unique_uri statement only takes one argument, consisting of > the optional "strict" and "ignore" keywords followed by a list of URIs. > In order to be recognized as a single argument, the whole thing needs to > be included in double quotes, like > > unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" > > p. ahh I understand - this in mind the manpage makes sense, too. ;-) unique_uri <[strict ][ignore ]URI[URI...]...> Thanks a lot for the clarification!

1 0

Re: (ITS#6172) Crash with baseObject in back-sql
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> openssl(a)mkarcher.dialup.fu-berlin.de wrote: > >> slapd gets terminated by libc with an "invalid free" error message when >> using >> the baseObject configuration option (whether with or without file) at >> the time >> of the first query. >> >> This is caused by freeing an entry using "free" that has been allocated >> using >> "entry_dup". This does not match (any more?). Essentially what the code >> was >> trying to to is to duplicate the sql_baseObject to bsi_e. The fix I >> suggest adds >> a function "entry_dup_to" to slapd so that backends can do this >> operation >> cleanly without having to create a temporary dynamic object there is no >> obvious >> clean way to get rid of. > > I'd rather have a function that returns the entry struct to the pool > without calling entry_clean(), to avoid as much as possible code > duplication. In any case, good catch. All in all, I favored using your patch as is. It's now in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6163) back-sql DoS when searching for empty attr
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The bug is in the fact that (cn=) is an invalid filter, because cn's syntax is directoryString, which does not allow the empty string. As such, the filter evaluates to undefined, and this is not properly handled by back-sql. A fix is in HEAD, please test (you only need to patch back-sql/search.c and the patch should apply to almost any OpenLDAP 2.4 version). p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The "strict" and the "ignore" keywords must be part of a single argument. In fact, the unique_uri statement only takes one argument, consisting of the optional "strict" and "ignore" keywords followed by a list of URIs. In order to be recognized as a single argument, the whole thing needs to be included in double quotes, like unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

As far as I recall, this is a known issue, although I could not locate early postings discussing this issue. What happens is that proxy cache makes use of the first item in the filter to discriminate between responses. In your filter template, the first item is the objectClass equality, which means that any filter with that objectClass value, regardless of the uid value, is treated as a duplicate of the first one. If you reverse the order of the equality filters you'll get the expected behavior. There should be another open ITS for this issue, but I can't locate it right now. p.

1 0

Re: (ITS#6231) The same problem: sasl realms don't work with digest-md5
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Software usage questions should be directed to the appropriate mailing lists, unless there is clear evidence of a software/documentation bug. This ITS will be closed. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 01 Aug '09

01 Aug '09

masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin-friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many times it > evaluated to answerable > > - "proxycache-" prefixed statements are passed to the private database. > This allows to avoid ambiguities when applying general database directives > in slapd.conf. In fact, it is not clear whether they apply to the proxy > database or to the cache database. > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. Go ahead! -- -- 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#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠symas.com 30 Jul '09

30 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: any > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Our chkhost implementation for OpenSSL does a simple strcasecmp on the name > obtained from the certificate CN; if the CN has an embedded NUL it is possible > for this check to be spoofed. This is now fixed in HEAD. > > Our chkhost implementation for GnuTLS is not vulnerable. > > We didn't write a chkhost implementation for MozNSS, we just use the default one > they provide. Inspecting their code shows that their default checker is also > vulnerable. I will be writing a replacement for libldap shortly. All fixed in HEAD/RE24. Surprisingly, the GnuTLS API got this one right. So did OpenSSL (we just botched our use of their APIs). But the MozNSS APIs all discard the length info of the data instead of returning it, so we had to reimplement some of their basic name-handling code in libldap. Probably should have just done all of this using DER and liblber too, like the other cert parsing code. -- -- 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

(ITS#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠OpenLDAP.org 30 Jul '09

30 Jul '09

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Our chkhost implementation for OpenSSL does a simple strcasecmp on the name obtained from the certificate CN; if the CN has an embedded NUL it is possible for this check to be spoofed. This is now fixed in HEAD. Our chkhost implementation for GnuTLS is not vulnerable. We didn't write a chkhost implementation for MozNSS, we just use the default one they provide. Inspecting their code shows that their default checker is also vulnerable. I will be writing a replacement for libldap shortly.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 30 Jul '09

30 Jul '09

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. Detecting unused accounts can also somewhat achieved by using slapo-accesslog with configuration directive "logops session". Still I see some value for such an simple overlay. > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. Things to consider: Is this attribute supposed to be replicated? How about adding configuration paramters so you can specify 1. the attribute type used and 2. the datetime format. This could be handy in situations where you want to mimique the behaviour of other LDAP servers. Ciao, Michael.

1 0

(ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 30 Jul '09

30 Jul '09

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz Submission from: (NULL) (82.67.204.30) Hi, Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that intercepts successful binds and records the current timestamp in an attribute named "bindTimestamp" in the bound-to entry. It's original use-case is to detect unused accounts. A configuration parameter (olcLastBindPrecision) allows to set a minimum precision for the timestamp (ie, don't update the timestamp unless it's older than <n> seconds). This avoids a performance hit from many unnecessary writes in case there are many binds per minute/hour/day/week/etc. Of course, the behaviour this overlay implements is not described in any RFC, or other. However, it closely resembles some of the functionality from the password policy overlay, and similar functionality already exists in other LDAP servers. I post it here in the hope that it may serve others, and in case the OpenLDAP wishes to include it in one form or another. I would most appreciate any comments or feedback. Regards, Jonathan PS: please note that the OIDs used are not registered, but used temporarily. I do not currently have access to a registered OID to use.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 30 Jul '09

30 Jul '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. > > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } Since you use Linux, you could try the kernel's tcp autotuning capabilities described in tcp(7) (other informative links are <http://fasterdata.es.net/TCP-tuning/linux.html>, <http://www.kernelfaq.com/2007/11/tcp-auto-tuning.html>). Of course, the possibility to manually enforce the size of the buffer may be useful in some cases, so a specific configuration option may deserve consideration. p.

1 0

Re: (ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)
by mkassawara＠gmail.com 29 Jul '09

29 Jul '09

The configure script can't find the BDB headers/libraries in the typical places. Either install them to a typical place seen by the preprocessor/linker (e.g., /usr/include, /usr/lib, /usr/local/ include, /usr/local/lib ...) or set the CPPFLAGS and LDFLAGS environment variables appropriately before running the configure script. If you plan to install OpenLDAP to a custom location, consider using "crle" to add the necessary library path(s) to the runtime linking environment. Also, to prevent another issue down the road, make sure you apply the Oracle patches to BDB 4.7.25 before building it. This is not an ITS... you should use openldap-technical for future correspondence on this issue. On Jul 29, 2009, at 3:09 PM, mark.liu(a)nyu.edu wrote: > Full_Name: Mark Liu > Version: 2.4.16 > OS: Sun Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.122.149.115) > > > I am trying to install openLDAP on Solaris 10. Whenever I tried to > configure > openLDAP, it would give the following message: > > checking db.h usability... no > checking db.h presence... no > checking for db.h... no > configure: error: BDB/HDB: BerkeleyDB not available > > The install would stop there. I thought it might be require a > different version > of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. > OpenLDAP > produced the same result for both instances of BerkeleyDB. > > What do i need to do to get pass this? Thanks! >

1 0

(ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)
by mark.liu＠nyu.edu 29 Jul '09

29 Jul '09

Full_Name: Mark Liu Version: 2.4.16 OS: Sun Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.122.149.115) I am trying to install openLDAP on Solaris 10. Whenever I tried to configure openLDAP, it would give the following message: checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available The install would stop there. I thought it might be require a different version of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. OpenLDAP produced the same result for both instances of BerkeleyDB. What do i need to do to get pass this? Thanks!

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mikbec＠web.de 29 Jul '09

29 Jul '09

hyc(a)symas.com wrote: > mimir(a)samba.org wrote: >> Full_Name: Rafal Szczesniak >> Version: Stable (2.4.16) >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-bugfix.diff >> Submission from: (NULL) (67.51.54.234) >> >> >> This is a bugfix patch for OpenLDAP's gssapi support. >> > One of these patches appears to duplicate ITS#6092. As the original author of > this code, could you also take a look at #6091 and #6093? > Yes, I think this patch tries to resolve the same problem like #6093 but with a different approach. And after some discussion with Hallvard B Furuseth about the guess_service_principal() string problem (#6223) I have sent a all-in-one-patch which results in #6110. best regards mike

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 29 Jul '09

29 Jul '09

Fixing this, and some other problems: - decode.c incorrectly treats length octet 0x80 (indefinite-length) as long length = 0. Fixing to returning an error. - Overly complex and inefficient code, in particular encode.c. Rewriting. Removing struct seqorset and related allocations. - Missing overflow/max-size checks. - ber_scanf() *must* clean up properly on error, as the code notes. Currently it can crash when reading malformed elements. Both encode.c and decode.c mostly access the Ber data "properly" via ber_write()/ber_read() but sometimes accesses the buffer directly. Can clean up and speed up at the same time by collecting that in fewer places. Side effects: - Dropping ber_write(,,,nonzero) support. Any callers likey need to use BerElement.ber_sos_ptr/ber_sos_inner, the struct seqorset replacement. - Dropping ber_log_sos_dump() and ber_sos_dump(), leaving behind stubs. They'd need a new ber parameter to work. Other matters - questions: - decode.c is quite lax about what it accepts. Should we tighten that when feasible, or remain "liberal in what we accept"? E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and wrong CONSTRUCTED/PRIMITIVE encoding bit. - encode.c willingly stores broken identifier octets if passed an invalid tag, e.g. a single octet with low bits 0x1F implying long tag format. I'm inclined to leave that alone, caller's responsibility. -- Hallvard

1 0

Re: (ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by steffen＠hauihau.de 29 Jul '09

29 Jul '09

Dear Howard, please have a look at http://bugs.gentoo.org/show_bug.cgi?id=233633 . The provided patch in the Debian bug tracker does not fix the compiling issue of passwd.c as the defines and typedefs are inserted *after* the first occurrence of "des_key". I've modified this patch, and it's already included in gentoo's ebuild for OpenLDAP 2.4.17. I don't know if I'm authorized to contribute it to the ITS, as I've only modified the original patch. I would do it of course, if 'm allowed to, since there is no employer, who would prevent me to do it, as I'm doing it in my freetime.

1 0

(ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristojosec＠yahoo.es 29 Jul '09

29 Jul '09

Full_Name: Evaristo Camarero Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.20) Hi, Working with slapd under heavy load it could be interesting to have TCP buffers size configurable at slapd application level instead of getting default OS values. Some fast modifications in daemon.c file to achieve a hardcoded value for the sender buffer are: int buf_size = 1572864; /* 1.5 Mb */ rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, sizeof(buf_size)); if(rc==-1) { Debug( LDAP_DEBUG_ANY, "slapd(%ld): " "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", (long) l.sl_sd, err, sock_errstr(err) ); } else { Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", (long) l.sl_sd, buf_size, 0); } Regards, Evaristo

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 29 Jul '09

29 Jul '09

jclarke(a)linagora.com wrote: > On 14.02.2009 01:51, Howard Chu wrote: >> Jonathan Clarke wrote: >>> On 13.02.2009 01:23, Howard Chu wrote: >>>> There are valid reasons to point a syncrepl consumer at the same slapd >>>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>>> subtree of a main database, etc.). Using the exhaustive matching that >>>> serverID uses would preclude those cases from working. >>> I see. I understand you don't want to break existing functionality. >>> However, I still feel this is a bug, or at least that you need to "hack" >>> the setup to get things working as expected. >> >> The docs state that "syncrepl provider" is the LDAP URI of the master >> server. If you're not putting in the same URI as the master is using, >> that's a config error, not a bug. > > Understood. Nothing is broken, and we have worked around this issue > using explicit listeners to slapd -h. > > This behaviour did surprise me, considering the behaviour of serverID > matching. May I suggest that a note of warning is included in the admin > guide? For example: > http://milopita.phillipoux.net/jonathan-clarke-20090216.patch > >>> Would I be right in assuming that in all the "valid reasons to point a >>> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >>> uses a different base DN than the base DN of the database that the >>> syncrepl consumer is configured on? If so, maybe the exhaustive matching >>> that serverID uses could be used, if and only if those two base DNs are >>> different? Actually, the exhaustive matching is only needed if the two base DNs are the same. This is now patched in HEAD, please test. >> That sounds reasonable. Will think about it a bit more. Certainly if the >> two base DNs are the same, it will cause a loop... > > Indeed. For what it's worth, while testing on cn=config, I noticed this > having various consequences including: > 1) cn=config becoming read-only (shadow) and updates returning a referral. > 2) in a MMR setup, some updates not being replicated to all N servers. -- -- 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#6233) print_deref assertion if no deref attributes returned
by hyc＠symas.com 28 Jul '09

28 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.17+ (current HEAD) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.113.59.19) > > > I am testing the LDAP Dereference feature specified here - > http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… > > I am getting an assertion in common.c at line 2077: > 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); > 2075: *ptr++ = '\n'; > 2076: *ptr++ = '\0'; > 2077: assert( ptr<= buf + len ); > > tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); > > In my test, ptr is one greater than buf + len. It appears that len does not > take into consideration the addition of the trailing \0 at line 2076. My test > is looking for a dereference attribute which does not have any values, so that > the attrVals in the control response is empty. If there are values to return in > attrVals, the assertion is not triggered. > Ah the ever-popular off-by-one. Should be OK now in HEAD, thanks for the report. -- -- 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#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by hyc＠symas.com 28 Jul '09

28 Jul '09

steffen.hau(a)rz.uni-mannheim.de wrote: > Full_Name: Steffen Hau > Version: 2.4.17 > OS: gentoo > URL: > Submission from: (NULL) (134.155.35.13) > > > Gentoo prefers gnutls usage over openssl when compiling openldap. But if > with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is > defined and passwd.c failes to compile with: See ITS #4997. There is a patch for this in the debian bug tracker, but until someone with appropriate authorization (i.e., the patch author) contributes it to the ITS with the requisite Rights statements attached, we cannot incorporate it. > passwd.c:813: error: expected declaration specifiers or ... before des_key > passwd.c: In function lmPasswd_to_key: > passwd.c:828: error: key undeclared (first use in this function) > passwd.c:828: error: (Each undeclared identifier is reported only once > passwd.c:828: error: for each function it appears in.) > passwd.c: In function chk_lanman: > passwd.c:839: error: des_key undeclared (first use in this function) > passwd.c:839: error: expected ; before key > passwd.c:840: error: des_context undeclared (first use in this function) > passwd.c:840: error: expected ; before schedule > passwd.c:841: error: des_data_block undeclared (first use in this function) > passwd.c:841: error: expected ; before StdText > passwd.c:842: error: expected ; before PasswordHash1 > passwd.c:859: error: key undeclared (first use in this function) > passwd.c:859: error: too many arguments to function lmPasswd_to_key > passwd.c:860: error: schedule undeclared (first use in this function) > passwd.c:861: error: StdText undeclared (first use in this function) > passwd.c:861: error: PasswordHash1 undeclared (first use in this function) > passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:867: error: too many arguments to function lmPasswd_to_key > passwd.c:869: error: PasswordHash2 undeclared (first use in this function) > passwd.c: In function hash_lanman: > passwd.c:1135: error: des_key undeclared (first use in this function) > passwd.c:1135: error: expected ; before key > passwd.c:1136: error: des_context undeclared (first use in this function) > passwd.c:1136: error: expected ; before schedule > passwd.c:1137: error: des_data_block undeclared (first use in this function) > passwd.c:1137: error: expected ; before StdText > passwd.c:1138: error: expected ; before PasswordHash1 > passwd.c:1155: error: key undeclared (first use in this function) > passwd.c:1155: error: too many arguments to function lmPasswd_to_key > passwd.c:1156: error: schedule undeclared (first use in this function) > passwd.c:1157: error: StdText undeclared (first use in this function) > passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) > passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:1159: error: too many arguments to function lmPasswd_to_key > passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) > make[2]: *** [passwd.o] Error 1 > > I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor > HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in > the configure script, if tls is set when lmpasswd is set. The failure message > for it explains, that there has to be openssl installed in order to use lm > passwords. Perhaps this test has to be changed in a manner that it's checked, > what implementation is used for tls, and only activates lm passwords only, if > tls is either openssl or moznss. > > Please let me know if you need further information. > > Best regards, > Steffen Hau > -- -- 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

(ITS#6233) print_deref assertion if no deref attributes returned
by rmeggins＠redhat.com 28 Jul '09

28 Jul '09

Full_Name: Rich Megginson Version: 2.4.17+ (current HEAD) OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.113.59.19) I am testing the LDAP Dereference feature specified here - http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… I am getting an assertion in common.c at line 2077: 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); 2075: *ptr++ = '\n'; 2076: *ptr++ = '\0'; 2077: assert( ptr <= buf + len ); tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); In my test, ptr is one greater than buf + len. It appears that len does not take into consideration the addition of the trailing \0 at line 2076. My test is looking for a dereference attribute which does not have any values, so that the attrVals in the control response is empty. If there are values to return in attrVals, the assertion is not triggered.

1 0

(ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by steffen.hau＠rz.uni-mannheim.de 28 Jul '09

28 Jul '09

Full_Name: Steffen Hau Version: 2.4.17 OS: gentoo URL: Submission from: (NULL) (134.155.35.13) Gentoo prefers gnutls usage over openssl when compiling openldap. But if with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is defined and passwd.c failes to compile with: passwd.c:813: error: expected declaration specifiers or ... before des_key passwd.c: In function lmPasswd_to_key: passwd.c:828: error: key undeclared (first use in this function) passwd.c:828: error: (Each undeclared identifier is reported only once passwd.c:828: error: for each function it appears in.) passwd.c: In function chk_lanman: passwd.c:839: error: des_key undeclared (first use in this function) passwd.c:839: error: expected ; before key passwd.c:840: error: des_context undeclared (first use in this function) passwd.c:840: error: expected ; before schedule passwd.c:841: error: des_data_block undeclared (first use in this function) passwd.c:841: error: expected ; before StdText passwd.c:842: error: expected ; before PasswordHash1 passwd.c:859: error: key undeclared (first use in this function) passwd.c:859: error: too many arguments to function lmPasswd_to_key passwd.c:860: error: schedule undeclared (first use in this function) passwd.c:861: error: StdText undeclared (first use in this function) passwd.c:861: error: PasswordHash1 undeclared (first use in this function) passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:867: error: too many arguments to function lmPasswd_to_key passwd.c:869: error: PasswordHash2 undeclared (first use in this function) passwd.c: In function hash_lanman: passwd.c:1135: error: des_key undeclared (first use in this function) passwd.c:1135: error: expected ; before key passwd.c:1136: error: des_context undeclared (first use in this function) passwd.c:1136: error: expected ; before schedule passwd.c:1137: error: des_data_block undeclared (first use in this function) passwd.c:1137: error: expected ; before StdText passwd.c:1138: error: expected ; before PasswordHash1 passwd.c:1155: error: key undeclared (first use in this function) passwd.c:1155: error: too many arguments to function lmPasswd_to_key passwd.c:1156: error: schedule undeclared (first use in this function) passwd.c:1157: error: StdText undeclared (first use in this function) passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:1159: error: too many arguments to function lmPasswd_to_key passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) make[2]: *** [passwd.o] Error 1 I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in the configure script, if tls is set when lmpasswd is set. The failure message for it explains, that there has to be openssl installed in order to use lm passwords. Perhaps this test has to be changed in a manner that it's checked, what implementation is used for tls, and only activates lm passwords only, if tls is either openssl or moznss. Please let me know if you need further information. Best regards, Steffen Hau

1 0

(ITS#6231) The same problem: sasl realms don't work with digest-md5
by jackli7312＠yahoo.com.cn 27 Jul '09

27 Jul '09

Full_Name: jackli Version: 2.4.16 OS: fedora9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.41.165.157) I searched this problem from mail list, and there is no response for it. I'm really suffering this for a week. Any help will be greatly appreciated! Please help. Jack hi all, i've got a problem with the sasl authentication using digest-md5 and multiple realms with my openldapServer 2.3.19 (fc5, yum). i want to be able to authenticate against different subtrees of the dit by using different realms and i was reading as many documentation, howtos and so on as i was able to find at the net for at least the last 7 days. i don't get it running...! currently, for testing, i use two different realms: mydomain.net (o=home,dc=mydit,dc=lan) test.mydomain.net (o=test,dc=mydit,dc=lan) in the slapd.conf i added: # sasl-realm mydomain.net authz-regexp uid=(.*),cn=test.mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=test,dc=ditroot authz-regexp uid=(.*),cn=mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot as you can see, the sasl-realm parameter is commented. whether or not i comment or uncomment it, it does not work. (actualy it works, but only either for the default realm or through the last sasl-regexp if i set it, all authentication attemps are of the format: uid=XY,cn=mydomain.net,cn=digest-md5,cn=auth if i do not set it, all authentication is done using: uid=XY,cn=digest-md5,cn=auth i realy tried a lot, e.g.: (things like -h, ... are covered by the ldap.conf) - ldapwhoami -U XY -R test.mydomain.net - ldapwhoami -U XY(a)test.mydomain.net - ldapsearch -U XY -R test.mydomain.net - ldap... of course all of those test where performed with different -R, ... values. i realy do not know what to do anymore, i've got no more ideas... also what i do not understand is whether or not this is a problem with my cyrus-sasl installation, but i cannot imagine that. i guess i'm missing something but i don't know what. can someone help me with this, please? have a nice day... d.a.s.

1 0

Re: (ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: Never mind, fixed in HEAD. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: You could simply post the diff of the two files it was comparing. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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

(ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by michael＠stroeder.com 27 Jul '09

27 Jul '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.81.222) Please let me know whether testrun/ is needed for examining this issue: >>>>> Starting test056-monitor for bdb... running defines.sh Starting slapd on TCP/IP port ... Using ldapsearch to check that slapd is running... Using ldapsearch to read connection monitor entries... Filtering ldapsearch results... Filtering expected data... Comparing filter output... Using ldapsearch to read database monitor entries... Filtering ldapsearch results... Comparing filter output... comparison failed - database monitor output is not correct >>>>> ./scripts/test056-monitor failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--0015175707f6684066046fb12f9b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yeah... those. On Mon, Jul 27, 2009 at 8:48 AM, czybear <czybear(a)qq.com> wrote: > Did you mean patches from the following URL? I didn't apply them yet, I'll > try them tomorry, thank you! > > http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc… > > > ------------------ Original ------------------ > *From: * "Matt Kassawara"<battery(a)writeme.com>; > *Date: * Mon, Jul 27, 2009 10:40 PM > *To: * "czybear"<czybear(a)qq.com>; > *Cc: * "openldap-its"<openldap-its(a)openldap.org>; > *Subject: * Re: (ITS#6229) make test blocked on test001-slapadd > > Did you build against BDB 4.7.25? ?If so, did you apply all the patches? > > On Mon, Jul 27, 2009 at 3:04 AM, <czybear(a)qq.com> wrote: > >> Full_Name: John Chen >> Version: 2.4.16/2.4.17 >> OS: RHEL AS 5.2 (Tikanga) x86)64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (117.88.156.12) >> >> >> [root@as5u2-64]# make test >> cd tests; make test >> make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' >> make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' >> Initiating LDAP tests for BDB... >> Cleaning up test run directory leftover from previous run. >> Running ./scripts/all... >> >>>>> Executing all LDAP tests for bdb >> >>>>> Starting test000-rootdse ... >> running defines.sh >> Starting slapd on TCP/IP port 9011... >> Using ldapsearch to retrieve the root DSE... >> Waiting 5 seconds for slapd to start... >> Using ldapsearch to retrieve the cn=Subschema... >> Using ldapsearch to retrieve the cn=Monitor... >> dn: >> objectClass: top >> objectClass: OpenLDAProotDSE >> structuralObjectClass: OpenLDAProotDSE >> configContext: cn=config >> namingContexts: o=OpenLDAP Project,l=Internet >> monitorContext: cn=Monitor >> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 >> supportedControl: 2.16.840.1.113730.3.4.18 >> supportedControl: 2.16.840.1.113730.3.4.2 >> supportedControl: 1.3.6.1.4.1.4203.1.10.1 >> supportedControl: 1.2.840.113556.1.4.319 >> supportedControl: 1.2.826.0.1.3344810.2.3 >> supportedControl: 1.3.6.1.1.13.2 >> supportedControl: 1.3.6.1.1.13.1 >> supportedControl: 1.3.6.1.1.12 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.3 >> supportedExtension: 1.3.6.1.1.8 >> supportedFeatures: 1.3.6.1.1.14 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 >> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 >> supportedLDAPVersion: 3 >> vendorName: The OpenLDAP Project <http://www.openldap.org/> >> entryDN: >> subschemaSubentry: cn=Subschema >> >> dn: cn=Subschema >> objectClass: top >> objectClass: subentry >> objectClass: subschema >> objectClass: extensibleObject >> cn: Subschema >> >> dn: cn=Monitor >> objectClass: monitorServer >> cn: Monitor >> description: This subtree contains monitoring/managing objects. >> description: This object contains information about this server. >> description: Most of the information is held in operational attributes, >> which >> ?must be explicitly requested. >> monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >> >> >>>>> Test succeeded >> >>>>> ./scripts/test000-rootdse completed OK. >> >> >>>>> Starting test001-slapadd ... >> running defines.sh >> Running slapadd to build slapd database... >> >> ========================================== >> Then blocked, and no moving any more ... >> >> > --0015175707f6684066046fb12f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah... those.<br><br><div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 8:= 48 AM, czybear <span dir=3D"ltr"><<a href=3D"mailto:czybear@qq.com">czyb= ear(a)qq.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>Did you mean patches from the following URL? I didn't apply them y= et, I'll try them tomorry, thank you!</div><div class=3D"im"> <div><a href=3D"http://www.oracle.com/technology/products/berkeley-db/db/up= date/4.7.25/patch.4.7.25.html" target=3D"_blank">http://www.oracle.com/tech= nology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.html</a></div> </div><div> <div>=A0</div> <div>=A0</div> <div style=3D"color:#000"><div class=3D"im"> <div style=3D"padding-right:0px;padding-left:0px;font-size:12px;padding-bot= tom:2px;padding-top:2px;font-family:Arial Narrow">------------------=A0Orig= inal=A0------------------</div> <div style=3D"font-size:12px"> <div><b>From: </b>=A0"Matt Kassawara"<<a href=3D"mailto:batter= y(a)writeme.com" target=3D"_blank">battery(a)writeme.com</a>>;</div> <div><b>Date: </b>=A0Mon, Jul 27, 2009 10:40 PM</div> <div><b>To: </b>=A0"czybear"<<a href=3D"mailto:czybear@qq.com"= target=3D"_blank">czybear(a)qq.com</a>>; </div> <div><b>Cc: </b>=A0"openldap-its"<<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>>; </div= > <div><b>Subject: </b>=A0Re: (ITS#6229) make test blocked on test001-slapadd= </div></div> <div>=A0</div></div><div><div class=3D"h5">Did you build against BDB 4.7.25= ? ?If so, did you apply all the patches?<br><br> <div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 3:04 AM, <span dir=3D"lt= r"><<a href=3D"mailto:czybear@qq.com" target=3D"_blank">czybear(a)qq.com</= a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"padding-left:1ex;margin:0px 0px = 0px 0.8ex;border-left:#ccc 1px solid">Full_Name: John Chen<br>Version: 2.4.= 16/2.4.17<br>OS: RHEL AS 5.2 (Tikanga) x86)64<br>URL: <a href=3D"ftp://ftp.= openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incoming/<= /a><br> Submission from: (NULL) (117.88.156.12)<br><br><br>[root@as5u2-64]# make te= st<br>cd tests; make test<br>make[1]: Entering directory `/home/install/lda= p-2.4/openldap-2.4.16/tests'<br>make[2]: Entering directory `/home/inst= all/ldap-2.4/openldap-2.4.16/tests'<br> Initiating LDAP tests for BDB...<br>Cleaning up test run directory leftover= from previous run.<br>Running ./scripts/all...<br>>>>>> Exe= cuting all LDAP tests for bdb<br>>>>>> Starting test000-root= dse ...<br> running defines.sh<br>Starting slapd on TCP/IP port 9011...<br>Using ldapse= arch to retrieve the root DSE...<br>Waiting 5 seconds for slapd to start...= <br>Using ldapsearch to retrieve the cn=3DSubschema...<br>Using ldapsearch = to retrieve the cn=3DMonitor...<br> dn:<br>objectClass: top<br>objectClass: OpenLDAProotDSE<br>structuralObject= Class: OpenLDAProotDSE<br>configContext: cn=3Dconfig<br>namingContexts: o= =3DOpenLDAP Project,l=3DInternet<br>monitorContext: cn=3DMonitor<br>support= edControl: 1.3.6.1.4.1.4203.1.9.1.1<br> supportedControl: 2.16.840.1.113730.3.4.18<br>supportedControl: 2.16.840.1.= 113730.3.4.2<br>supportedControl: 1.3.6.1.4.1.4203.1.10.1<br>supportedContr= ol: 1.2.840.113556.1.4.319<br>supportedControl: 1.2.826.0.1.3344810.2.3<br> supportedControl: 1.3.6.1.1.13.2<br>supportedControl: 1.3.6.1.1.13.1<br>sup= portedControl: 1.3.6.1.1.12<br>supportedExtension: 1.3.6.1.4.1.4203.1.11.1<= br>supportedExtension: 1.3.6.1.4.1.4203.1.11.3<br>supportedExtension: 1.3.6= .1.1.8<br> supportedFeatures: 1.3.6.1.1.14<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.= 1<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.2<br>supportedFeatures: 1.3.6.= 1.4.1.4203.1.5.3<br>supportedFeatures: 1.3.6.1.4.1.4203.1.5.4<br>supportedF= eatures: 1.3.6.1.4.1.4203.1.5.5<br> supportedLDAPVersion: 3<br>vendorName: The OpenLDAP Project <<a href=3D"= http://www.openldap.org/" target=3D"_blank">http://www.openldap.org/</a>&gt= ;<br>entryDN:<br>subschemaSubentry: cn=3DSubschema<br><br>dn: cn=3DSubschem= a<br> objectClass: top<br>objectClass: subentry<br>objectClass: subschema<br>obje= ctClass: extensibleObject<br>cn: Subschema<br><br>dn: cn=3DMonitor<br>objec= tClass: monitorServer<br>cn: Monitor<br>description: This subtree contains = monitoring/managing objects.<br> description: This object contains information about this server.<br>descrip= tion: Most of the information is held in operational attributes, which<br>?= must be explicitly requested.<br>monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul= 23 2009 13:44:24)<br> <br>>>>>> Test succeeded<br>>>>>> ./scripts/t= est000-rootdse completed OK.<br><br>>>>>> Starting test001-s= lapadd ...<br>running defines.sh<br>Running slapadd to build slapd database= ...<br> <br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Then blocked, = and no moving any more ...<br><br></blockquote></div><br></div></div></div>= </div></blockquote></div><br> --0015175707f6684066046fb12f9b--

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--000e0cd51bbc607056046fb112fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc… Include the list in your reply next time... On Mon, Jul 27, 2009 at 8:44 AM, czybear <czybear(a)qq.com> wrote: > yes, I build aginst BDB 4.7.25 and downloaded from > http://www.oracle.com/technology/software/products/berkeley-db/htdocs/popup… > I didn't see any patches about BDB 4.7.25 from Oracle yet. > > > ------------------ Original ------------------ > *From: * "Matt Kassawara"<battery(a)writeme.com>; > *Date: * Mon, Jul 27, 2009 10:40 PM > *To: * "czybear"<czybear(a)qq.com>; > *Cc: * "openldap-its"<openldap-its(a)openldap.org>; > *Subject: * Re: (ITS#6229) make test blocked on test001-slapadd > > Did you build against BDB 4.7.25? ?If so, did you apply all the patches? On > Mon, Jul 27, 2009 at 3:04 AM, wrote: Full_Name: John Chen Version: > 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: > ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (117.88.156.12) > [root@as5u2-64]# make test cd tests; make test make[1]: Entering directory > `/home/install/ldap-2.4/openldap-2.4.16/tests' make[2]: Entering directory > `/home/install/ldap-2.4/openldap-2.4.16/tests' Initiating LDAP tests for > BDB... Cleaning up test run directory leftover from previous run. Running > ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting > test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to > start... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch > to retrieve the cn=Monitor... dn: objectClass: top objectClass: > OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: > cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: > cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: > 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: > 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 > supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 > supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 > supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: > 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 > vendorName: The OpenLDAP Project entryDN: subschemaSubentry: cn=Subschema > dn: cn=Subschema objectClass: top objectClass: subentry objectClass: > subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor > objectClass: monitorServer cn: Monitor description: This subtree contains > monitoring/managing objects. description: This object contains information > about this server. description: Most of the information is held in > operational attributes, which ?must be explicitly requested. monitoredInfo: > OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>>>> > ./scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... > running defines.sh Running slapadd to build slapd database... > ========================================== Then blocked, and no moving any > more ... > --000e0cd51bbc607056046fb112fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><a href=3D"http://www.oracle.com/technology/products/berkeley-db/db/up= date/4.7.25/patch.4.7.25.html">http://www.oracle.com/technology/products/be= rkeley-db/db/update/4.7.25/patch.4.7.25.html</a><br></div><div></div><div> Include the list in your reply next time...</div><br><div class=3D"gmail_qu= ote">On Mon, Jul 27, 2009 at 8:44 AM, czybear <span dir=3D"ltr"><<a href= =3D"mailto:czybear@qq.com">czybear(a)qq.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div>yes, I build aginst BDB 4.7.25 and downloaded from <a href=3D"http://w= ww.oracle.com/technology/software/products/berkeley-db/htdocs/popup/db/4.7.= 25/db-targz.html" target=3D"_blank">http://www.oracle.com/technology/softwa= re/products/berkeley-db/htdocs/popup/db/4.7.25/db-targz.html</a></div> <div>I didn't see any patches about BDB 4.7.25 from Oracle yet.</div> <div> <div>=A0</div> <div>=A0</div> <div style=3D"color:#000"> <div style=3D"padding-right:0px;padding-left:0px;font-size:12px;padding-bot= tom:2px;padding-top:2px;font-family:Arial Narrow">------------------=A0Orig= inal=A0------------------</div> <div style=3D"font-size:12px"> <div><b>From: </b>=A0"Matt Kassawara"<<a href=3D"mailto:batter= y(a)writeme.com" target=3D"_blank">battery(a)writeme.com</a>>;</div> <div><b>Date: </b>=A0Mon, Jul 27, 2009 10:40 PM</div> <div><b>To: </b>=A0"czybear"<<a href=3D"mailto:czybear@qq.com"= target=3D"_blank">czybear(a)qq.com</a>>; </div> <div><b>Cc: </b>=A0"openldap-its"<<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>>; </div= > <div><b>Subject: </b>=A0Re: (ITS#6229) make test blocked on test001-slapadd= </div></div> <div>=A0</div>Did you build against BDB 4.7.25? ?If so, did you apply all t= he patches? On Mon, Jul 27, 2009 at 3:04 AM, wrote: Full_Name: John Chen Ve= rsion: 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: <a href=3D"ftp:/= /ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incom= ing/</a> Submission from: (NULL) (117.88.156.12) [root@as5u2-64]# make test= cd tests; make test make[1]: Entering directory `/home/install/ldap-2.4/op= enldap-2.4.16/tests' make[2]: Entering directory `/home/install/ldap-2.= 4/openldap-2.4.16/tests' Initiating LDAP tests for BDB... Cleaning up t= est run directory leftover from previous run. Running ./scripts/all... >= >>>> Executing all LDAP tests for bdb >>>>> Star= ting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9= 011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for s= lapd to start... Using ldapsearch to retrieve the cn=3DSubschema... Using l= dapsearch to retrieve the cn=3DMonitor... dn: objectClass: top objectClass:= OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn= =3Dconfig namingContexts: o=3DOpenLDAP Project,l=3DInternet monitorContext:= cn=3DMonitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: = 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supporte= dControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 = supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 = supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedEx= tension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.= 3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supported= Features: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 = supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.42= 03.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 = vendorName: The OpenLDAP Project entryDN: subschemaSubentry: cn=3DSubschema= dn: cn=3DSubschema objectClass: top objectClass: subentry objectClass: sub= schema objectClass: extensibleObject cn: Subschema dn: cn=3DMonitor objectC= lass: monitorServer cn: Monitor description: This subtree contains monitori= ng/managing objects. description: This object contains information about th= is server. description: Most of the information is held in operational attr= ibutes, which ?must be explicitly requested. monitoredInfo: OpenLDAP: slapd= 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>= >>> ./scripts/test000-rootdse completed OK. >>>>> S= tarting test001-slapadd ... running defines.sh Running slapadd to build sla= pd database... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then blo= cked, and no moving any more ... </div> </div></blockquote></div><br> --000e0cd51bbc607056046fb112fc--

1 0

Re: (ITS#6229) make test blocked on test001-slapadd
by battery＠writeme.com 27 Jul '09

27 Jul '09

--000e0cd2e7328a11aa046fb0ee75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Did you build against BDB 4.7.25? If so, did you apply all the patches? On Mon, Jul 27, 2009 at 3:04 AM, <czybear(a)qq.com> wrote: > Full_Name: John Chen > Version: 2.4.16/2.4.17 > OS: RHEL AS 5.2 (Tikanga) x86)64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (117.88.156.12) > > > [root@as5u2-64]# make test > cd tests; make test > make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' > make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all... > >>>>> Executing all LDAP tests for bdb > >>>>> Starting test000-rootdse ... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Using ldapsearch to retrieve the cn=Subschema... > Using ldapsearch to retrieve the cn=Monitor... > dn: > objectClass: top > objectClass: OpenLDAProotDSE > structuralObjectClass: OpenLDAProotDSE > configContext: cn=config > namingContexts: o=OpenLDAP Project,l=Internet > monitorContext: cn=Monitor > supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 > supportedControl: 2.16.840.1.113730.3.4.18 > supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 1.3.6.1.4.1.4203.1.10.1 > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.826.0.1.3344810.2.3 > supportedControl: 1.3.6.1.1.13.2 > supportedControl: 1.3.6.1.1.13.1 > supportedControl: 1.3.6.1.1.12 > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 1.3.6.1.4.1.4203.1.11.3 > supportedExtension: 1.3.6.1.1.8 > supportedFeatures: 1.3.6.1.1.14 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 > supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 > supportedLDAPVersion: 3 > vendorName: The OpenLDAP Project <http://www.openldap.org/> > entryDN: > subschemaSubentry: cn=Subschema > > dn: cn=Subschema > objectClass: top > objectClass: subentry > objectClass: subschema > objectClass: extensibleObject > cn: Subschema > > dn: cn=Monitor > objectClass: monitorServer > cn: Monitor > description: This subtree contains monitoring/managing objects. > description: This object contains information about this server. > description: Most of the information is held in operational attributes, > which > must be explicitly requested. > monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) > > >>>>> Test succeeded > >>>>> ./scripts/test000-rootdse completed OK. > > >>>>> Starting test001-slapadd ... > running defines.sh > Running slapadd to build slapd database... > > ========================================== > Then blocked, and no moving any more ... > > --000e0cd2e7328a11aa046fb0ee75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you build against BDB 4.7.25? =A0If so, did you apply all the patches?<= br><br><div class=3D"gmail_quote">On Mon, Jul 27, 2009 at 3:04 AM, <span d= ir=3D"ltr"><<a href=3D"mailto:czybear@qq.com">czybear(a)qq.com</a>></sp= an> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Full_Name: John Chen<br> Version: 2.4.16/2.4.17<br> OS: RHEL AS 5.2 (Tikanga) x86)64<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (117.88.156.12)<br> <br> <br> [root@as5u2-64]# make test<br> cd tests; make test<br> make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests&#= 39;<br> make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests&#= 39;<br> Initiating LDAP tests for BDB...<br> Cleaning up test run directory leftover from previous run.<br> Running ./scripts/all...<br> >>>>> Executing all LDAP tests for bdb<br> >>>>> Starting test000-rootdse ...<br> running defines.sh<br> Starting slapd on TCP/IP port 9011...<br> Using ldapsearch to retrieve the root DSE...<br> Waiting 5 seconds for slapd to start...<br> Using ldapsearch to retrieve the cn=3DSubschema...<br> Using ldapsearch to retrieve the cn=3DMonitor...<br> dn:<br> objectClass: top<br> objectClass: OpenLDAProotDSE<br> structuralObjectClass: OpenLDAProotDSE<br> configContext: cn=3Dconfig<br> namingContexts: o=3DOpenLDAP Project,l=3DInternet<br> monitorContext: cn=3DMonitor<br> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1<br> supportedControl: 2.16.840.1.113730.3.4.18<br> supportedControl: 2.16.840.1.113730.3.4.2<br> supportedControl: 1.3.6.1.4.1.4203.1.10.1<br> supportedControl: 1.2.840.113556.1.4.319<br> supportedControl: 1.2.826.0.1.3344810.2.3<br> supportedControl: 1.3.6.1.1.13.2<br> supportedControl: 1.3.6.1.1.13.1<br> supportedControl: 1.3.6.1.1.12<br> supportedExtension: 1.3.6.1.4.1.4203.1.11.1<br> supportedExtension: 1.3.6.1.4.1.4203.1.11.3<br> supportedExtension: 1.3.6.1.1.8<br> supportedFeatures: 1.3.6.1.1.14<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4<br> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5<br> supportedLDAPVersion: 3<br> vendorName: The OpenLDAP Project <<a href=3D"http://www.openldap.org/" t= arget=3D"_blank">http://www.openldap.org/</a>><br> entryDN:<br> subschemaSubentry: cn=3DSubschema<br> <br> dn: cn=3DSubschema<br> objectClass: top<br> objectClass: subentry<br> objectClass: subschema<br> objectClass: extensibleObject<br> cn: Subschema<br> <br> dn: cn=3DMonitor<br> objectClass: monitorServer<br> cn: Monitor<br> description: This subtree contains monitoring/managing objects.<br> description: This object contains information about this server.<br> description: Most of the information is held in operational attributes, whi= ch<br> =A0must be explicitly requested.<br> monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24)<br> <br> >>>>> Test succeeded<br> >>>>> ./scripts/test000-rootdse completed OK.<br> <br> >>>>> Starting test001-slapadd ...<br> running defines.sh<br> Running slapadd to build slapd database...<br> <br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> Then blocked, and no moving any more ...<br> <br> </blockquote></div><br> --000e0cd2e7328a11aa046fb0ee75--

1 0

(ITS#6229) make test blocked on test001-slapadd
by czybear＠qq.com 27 Jul '09

27 Jul '09

Full_Name: John Chen Version: 2.4.16/2.4.17 OS: RHEL AS 5.2 (Tikanga) x86)64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (117.88.156.12) [root@as5u2-64]# make test cd tests; make test make[1]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' make[2]: Entering directory `/home/install/ldap-2.4/openldap-2.4.16/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch to retrieve the cn=Monitor... dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 vendorName: The OpenLDAP Project <http://www.openldap.org/> entryDN: subschemaSubentry: cn=Subschema dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor objectClass: monitorServer cn: Monitor description: This subtree contains monitoring/managing objects. description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. monitoredInfo: OpenLDAP: slapd 2.4.16 (Jul 23 2009 13:44:24) >>>>> Test succeeded >>>>> ./scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... ========================================== Then blocked, and no moving any more ...

1 0

Re: (ITS#6228) test000-rootdse: slapd fails to start
by hyc＠symas.com 25 Jul '09

25 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.115.191) > > > HEAD synced right now fails right in test000. Thanks, fixed. > > ----------- console output ----------- > > michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test > cd tests; make test > make[1]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all for bdb... >>>>>> Executing all LDAP tests for bdb >>>>>> Starting test000-rootdse for bdb... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (2749) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed for bdb (exit 255) > make[2]: *** [bdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > ----------- last lines of tests/testrun/slapd.1.log ----------- > > backend_startup_one: starting "cn=config" > config_back_db_open > config_build_entry: "cn=config" > config_build_entry: "cn=module{0}" > config_build_entry: "cn=module{1}" > config_build_entry: "cn=schema" > config_build_entry: "cn={0}core" > config_build_entry: "cn={1}cosine" > config_build_entry: "cn={2}corba" > config_build_entry: "cn={3}java" > config_build_entry: "cn={4}inetorgperson" > config_build_entry: "cn={5}misc" > config_build_entry: "cn={6}nis" > config_build_entry: "cn={7}openldap" > config_build_entry: "cn={8}duaconf" > config_build_entry: "cn={9}dyngroup" > config_build_entry: "cn={10}ppolicy" > config_build_entry: "olcDatabase={-1}frontend" > config_build_entry: "olcDatabase={0}config" > config_build_entry: "olcDatabase={1}bdb" > config_build_attrs: error 21 on olcDbCacheSize value #0 > config_build_entry: build "1000d" failed: "" > backend_startup_one: bi_db_open failed! (-1) > lt-slapd shutdown: initiated > ====> bdb_cache_release_all > lt-slapd destroy: freeing system resources. > slapd stopped. > > -- -- 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

(ITS#6228) test000-rootdse: slapd fails to start
by michael＠stroeder.com 25 Jul '09

25 Jul '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.115.191) HEAD synced right now fails right in test000. ----------- console output ----------- michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test cd tests; make test make[1]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[2]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all for bdb... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (2749) - No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2 ----------- last lines of tests/testrun/slapd.1.log ----------- backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=module{1}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}duaconf" config_build_entry: "cn={9}dyngroup" config_build_entry: "cn={10}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_attrs: error 21 on olcDbCacheSize value #0 config_build_entry: build "1000d" failed: "" backend_startup_one: bi_db_open failed! (-1) lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources. slapd stopped.

1 0

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 25 Jul '09

25 Jul '09

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB83678E9A284CB48B3D6C2FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > jerry(a)plainjoe.org wrote: >> Correction to the URL. Should be: >> ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principa= l.diff >> >=20 > That file is zero bytes long. Did we run out of space on > ftp.openldap.org again? Howard, I've got update patches (more bug fixes related to the gssapi bind). I'll try uploading a new patch on Monday. cheers, jerry --------------enigB83678E9A284CB48B3D6C2FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKawDfIR7qMdg1EfYRAt3iAKChKPg7VCwWuqevthDTvlcELJdTPgCg8pNq AIp/ts+OeQ2gfB4AlwehEAY= =RhWQ -----END PGP SIGNATURE----- --------------enigB83678E9A284CB48B3D6C2FB--

1 0

Re: ITS#6226
by test.007＠seznam.cz 25 Jul '09

25 Jul '09

Probably dup, sorry, I should have checked.

1 0

Re: (ITS#6222) Add "unlimited" option for cachesize settings
by hyc＠symas.com 24 Jul '09

24 Jul '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Now that we have multiple cache sizes, it would be extremely useful, > particularly with dncachesize, to be able to specify an "unlimited" setting, so > that the 2.3 behavior can be easily replicated. Also so that people who have > systems with plenty of RAM can just set it once. Yeah, I guess it was kind of a bad idea to make the default 2.4 behavior differ from 2.3 here. Fixed in HEAD. > In particular, I've noticed in 2.3->2.4 upgrades, if dncachesize is particularly > small in relation to the size of the database, slapd is essentially unusable. > I'd rather see dncachesize default to unlimited if it isn't set (2.3 behavior), > and people can tune it down from there if they need to do so. This allows slapd > to remain usable without severely impacting the ability of slapd to function. > It is so bad, that it becomes impossible to modify cn=config via ldap commands, > and you have to stop slapd and manually hack the cn=config text files to return > slapd to a usable state. > -- -- 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#6225) GSSAPI support for client library (fixes)
by hyc＠symas.com 24 Jul '09

24 Jul '09

mimir(a)samba.org wrote: > Full_Name: Rafal Szczesniak > Version: Stable (2.4.16) > OS: GNU/Linux > URL: http://www.samba.org/~mimir/gssapi-bugfix.diff > Submission from: (NULL) (67.51.54.234) > > > This is a bugfix patch for OpenLDAP's gssapi support. > One of these patches appears to duplicate ITS#6092. As the original author of this code, could you also take a look at #6091 and #6093? -- -- 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#6223) [patch] snprint() fix in guess_service_principal()
by hyc＠symas.com 24 Jul '09

24 Jul '09

jerry(a)plainjoe.org wrote: > Correction to the URL. Should be: > ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff That file is zero bytes long. Did we run out of space on ftp.openldap.org again? -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 24 Jul '09

24 Jul '09

Thanks for the encouragement Michael :) For those who find this in searches to come, I compiled OpenSSL (0.9.8k) myself and the problem is resolved. Not sure if this is a bug fixed between 0.9.8h and 0.9.8k or something weird that IBM did when building the package, but all is well now. Steve=20 On Fri, 2009-07-24 at 13:24 +0200, Michael Str=C3=B6der wrote: > steve(a)falchion.com wrote: > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, >=20 > Being in your situation I'd try that. >=20 > > which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). >=20 > You could build all the necessary libs (Berkeley DB, OpenSSL, > cyrus-sasl, heimdal etc.) and install them in a separate prefix without > conflicting with any pre-installed libs. I'd go that route and did that > on e.g. old Solaris platforms. And I think it would be feasible for me > even though I'm not an C programmer. >=20 > > Do I sound frustrated yet? Cause I am... >=20 > Sometimes things are hard. But just don't give up! >=20 > Ciao, Michael.

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by hyc＠symas.com 24 Jul '09

24 Jul '09

Fixed now in CVS HEAD. mbuschman(a)cashnetusa.com wrote: > Full_Name: Marshall Buschman > Version: 2.4.17 > OS: Debian Etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.98.177.132) > > I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the > autogroup overlay, and I get the following error when I do an ldapsearch: > > $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com > # extended LDIF > ... > # search result > search: 2 > result: 53 Server is unwilling to perform > text: operation not supported within namingContext > > Relevant config: > ---------------------------------------------- > moduleload autogroup > > database bdb > suffix "dc=cashnetusa,dc=com" > > overlay autogroup > autogroup-attrset groupOfURLs memberURL member > ---------------------------------------------- > > OpenLDAP does start normally without the overlay. > -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

OS is Debian Lenny, not Debian Etch. Apologies. openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6227. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6227) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6227) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6227 > > Please remember to retain your issue tracking number (ITS#6227) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > >

1 0

(ITS#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

Full_Name: Marshall Buschman Version: 2.4.17 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.98.177.132) I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the autogroup overlay, and I get the following error when I do an ldapsearch: $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset groupOfURLs memberURL member ---------------------------------------------- OpenLDAP does start normally without the overlay.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by michael＠stroeder.com 24 Jul '09

24 Jul '09

steve(a)falchion.com wrote: > Now you might tell me (as you've already implied) to compile my own SSL > libraries, Being in your situation I'd try that. > which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). You could build all the necessary libs (Berkeley DB, OpenSSL, cyrus-sasl, heimdal etc.) and install them in a separate prefix without conflicting with any pre-installed libs. I'd go that route and did that on e.g. old Solaris platforms. And I think it would be feasible for me even though I'm not an C programmer. > Do I sound frustrated yet? Cause I am... Sometimes things are hard. But just don't give up! Ciao, Michael.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

Thank-you, that is much more helpful. I apologize for my rant. I'll join that mailing list and post my issue there. Thanks, Steve On Thu, 2009-07-23 at 15:23 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > Thanks, that was sooo helpful. > > > > What I'm trying to do is port your software package to a platform where > > it obviously fails to work properly using the vendor's supplied SSL > > libraries, and you're giving me a PFO. > > The ITS is for tracking problems in the actual OpenLDAP code base. Since > you're not reporting an actual issue in OpenLDAP code, this is the wrong forum > for this discussion. > > You can get help on interoperability issues elsewhere, e.g. the > openldap-technical mailing list. > > > So now I get to go to IBM and say "your library is broken but I can't > > tell you how/why" (gee... I wonder how that call will go) or abandon > > open source and install their LDAP server package (which is what they'll > > tell me to do anyhow). > > > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). > > > Do I sound frustrated yet? Cause I am... > > > > Sorry to anyone else who reads this rant. > > You obviously have to ask the right questions to the right people who can > actually help you. We can't fix your OpenSSL build for you. > > > > Steve > > > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: > >> Steve Paras-Charlton wrote: > >>> > >>> I tried re-compiling with CC="gcc -g" and got the following backtrace > >>> from gdb: > >>> > >>> Program received signal SIGSEGV, Segmentation fault. > >>> [Switching to Thread 1] > >>> 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> (gdb) bt > >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > >>> is_server=1) at tls_o.c:320 > >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > >>> tls2.c:245 > >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > >>> arg=0x2ff22ae8) at tls2.c:800 > >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > >>> > >>> This one seems much more useful from a debugging perspective. > >>> > >>> I noticed that the configure program has some options along the lines of > >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > >>> to help debug the issue perhaps? How would I use it (not sure what > >>> options it takes). > >> > >> This trace is the kind that we would normally look for, yes. But the crash is > >> in an OpenSSL function, and you haven't got debug symbols for that since you > >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, > >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS > >> will be closed. > >> > > > > > >

1 0

2.4.17 - autogroup overlay breaks searches
by Marshall Buschman 23 Jul '09

23 Jul '09

Hello All: I'm running OpenLDAP 2.4.17+bdb 4.7 on Debian Lenny. I've enabled the autogroup overlay, and I get the following when I do an ldapsearch. Disabling the overlay does fix the issue, but I do need the functionality the overlay provides. $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset posixGroup memberURL member ---------------------------------------------- Help? -Marshall Buschman

2 1

Re: (ITS#6200)
by hyc＠symas.com 23 Jul '09

23 Jul '09

imf(a)u.washington.edu wrote: > The changes made to 2.4.17 seem to have fixed the crashes in the caching > module. Thanks for that. > > We still are able to crash 2.4.17, however. It only happens after a heavy > load is placed on the producer for>24 hours continuous. Unfortunately, > we've not been able to get good tracebacks. They all look like this, > > (gdb) where > #0 0x00869410 in __kernel_vsyscall () > #1 0x00390d80 in raise () from /lib/libc.so.6 > #2 0x00392691 in abort () from /lib/libc.so.6 > #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 > #4 0x0808d532 in malloc () > #5 0x0822c93f in ?? () > #6 0x0822c933 in ?? () > #7 0x00000039 in ?? () > #8 0x0822c908 in ?? () > #9 0x00000000 in ?? () > > The producer slowly grows its memory footprint. I can't tell if it's from > just normal operations or memory leaks. I suspect it's a little of both. > The end result, as you can see from the core above, is that there's likely > some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down > further. There's not enough information here. An assert is always accompanied by an error message on stderr; we need to see the actual error message. There are no symbols in the stack trace pertaining to slapd itself. You seem to be running a stripped binary. Please provide a trace using a non-stripped binary that was compiled with -g (debug symbols enabled). > > The load profile that we placed on the server is documented in my prior > report. See above. -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 23 Jul '09

23 Jul '09

Steve Paras-Charlton wrote: > Thanks, that was sooo helpful. > > What I'm trying to do is port your software package to a platform where > it obviously fails to work properly using the vendor's supplied SSL > libraries, and you're giving me a PFO. The ITS is for tracking problems in the actual OpenLDAP code base. Since you're not reporting an actual issue in OpenLDAP code, this is the wrong forum for this discussion. You can get help on interoperability issues elsewhere, e.g. the openldap-technical mailing list. > So now I get to go to IBM and say "your library is broken but I can't > tell you how/why" (gee... I wonder how that call will go) or abandon > open source and install their LDAP server package (which is what they'll > tell me to do anyhow). > > Now you might tell me (as you've already implied) to compile my own SSL > libraries, which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). > Do I sound frustrated yet? Cause I am... > > Sorry to anyone else who reads this rant. You obviously have to ask the right questions to the right people who can actually help you. We can't fix your OpenSSL build for you. > > Steve > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: >> Steve Paras-Charlton wrote: >>> >>> I tried re-compiling with CC="gcc -g" and got the following backtrace >>> from gdb: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 1] >>> 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> (gdb) bt >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, >>> is_server=1) at tls_o.c:320 >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at >>> tls2.c:245 >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, >>> arg=0x2ff22ae8) at tls2.c:800 >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 >>> >>> This one seems much more useful from a debugging perspective. >>> >>> I noticed that the configure program has some options along the lines of >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this >>> to help debug the issue perhaps? How would I use it (not sure what >>> options it takes). >> >> This trace is the kind that we would normally look for, yes. But the crash is >> in an OpenSSL function, and you haven't got debug symbols for that since you >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS >> will be closed. >> > > -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

Thanks, that was sooo helpful. What I'm trying to do is port your software package to a platform where it obviously fails to work properly using the vendor's supplied SSL libraries, and you're giving me a PFO. So now I get to go to IBM and say "your library is broken but I can't tell you how/why" (gee... I wonder how that call will go) or abandon open source and install their LDAP server package (which is what they'll tell me to do anyhow). Now you might tell me (as you've already implied) to compile my own SSL libraries, which I may try, but doing so opens me up to a world of interop issues as IBM tends to compile their tools with links to specific versions of shared libraries (I've been there and done that in AIX this year once already). Do I sound frustrated yet? Cause I am... Sorry to anyone else who reads this rant. Steve On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > > > I tried re-compiling with CC="gcc -g" and got the following backtrace > > from gdb: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1] > > 0xd26d07d0 in SSL_CTX_set_info_callback () > > > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > > (gdb) bt > > #0 0xd26d07d0 in SSL_CTX_set_info_callback () > > > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > > #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > > is_server=1) at tls_o.c:320 > > #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > > tls2.c:245 > > #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > > arg=0x2ff22ae8) at tls2.c:800 > > #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > > > > This one seems much more useful from a debugging perspective. > > > > I noticed that the configure program has some options along the lines of > > "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > > to help debug the issue perhaps? How would I use it (not sure what > > options it takes). > > This trace is the kind that we would normally look for, yes. But the crash is > in an OpenSSL function, and you haven't got debug symbols for that since you > haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, > your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS > will be closed. >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 23 Jul '09

23 Jul '09

Steve Paras-Charlton wrote: > > I tried re-compiling with CC="gcc -g" and got the following backtrace > from gdb: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1] > 0xd26d07d0 in SSL_CTX_set_info_callback () > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > (gdb) bt > #0 0xd26d07d0 in SSL_CTX_set_info_callback () > > from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > is_server=1) at tls_o.c:320 > #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > tls2.c:245 > #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > arg=0x2ff22ae8) at tls2.c:800 > #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > > This one seems much more useful from a debugging perspective. > > I noticed that the configure program has some options along the lines of > "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > to help debug the issue perhaps? How would I use it (not sure what > options it takes). This trace is the kind that we would normally look for, yes. But the crash is in an OpenSSL function, and you haven't got debug symbols for that since you haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS will be closed. -- -- 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

ITS#6226
by masarati＠aero.polimi.it 23 Jul '09

23 Jul '09

Duplicate of ITS#5941? p.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

I tried re-compiling with CC="gcc -g" and got the following backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0xd26d07d0 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) (gdb) bt #0 0xd26d07d0 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, is_server=1) at tls_o.c:320 #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at tls2.c:245 #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, arg=0x2ff22ae8) at tls2.c:800 #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 This one seems much more useful from a debugging perspective. I noticed that the configure program has some options along the lines of "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this to help debug the issue perhaps? How would I use it (not sure what options it takes). Thanks, Steve

1 0

(ITS#6200)
by imf＠u.washington.edu 23 Jul '09

23 Jul '09

The changes made to 2.4.17 seem to have fixed the crashes in the caching module. Thanks for that. We still are able to crash 2.4.17, however. It only happens after a heavy load is placed on the producer for >24 hours continuous. Unfortunately, we've not been able to get good tracebacks. They all look like this, (gdb) where #0 0x00869410 in __kernel_vsyscall () #1 0x00390d80 in raise () from /lib/libc.so.6 #2 0x00392691 in abort () from /lib/libc.so.6 #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in malloc () #5 0x0822c93f in ?? () #6 0x0822c933 in ?? () #7 0x00000039 in ?? () #8 0x0822c908 in ?? () #9 0x00000000 in ?? () The producer slowly grows its memory footprint. I can't tell if it's from just normal operations or memory leaks. I suspect it's a little of both. The end result, as you can see from the core above, is that there's likely some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down further. The load profile that we placed on the server is documented in my prior report. See above. --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344

1 0

(ITS#6226) Double free() with translucent+rwm
by test.007＠seznam.cz 23 Jul '09

23 Jul '09

Full_Name: Test Seven Version: 2.4.17 OS: Linux/Windows URL: Submission from: (NULL) (195.113.184.10) Have sample setup with bdb database, add the following to the bottom of slapd.conf: overlay translucent overlay rwm uri "ldap://127.6.6.6/" # (the server 127.6.6.6 must not exist) Run any search query against the server (with correct credentials). Slapd tries to contact the remote server, then it properly returns an error (32, or 52...) to the client, but then it aborts. Variations: a) Change .conf: uri "ldap://something.that.resolves.but.doesnt.respond" b) Add to the bottom of .conf: idassert-bind binddn="cn=doesnt,ou=matter" credentials=secret The variations return different errors to the client, and may crash elsewhere. Problem in the code (for Variation a): ldap_back_dobind_int() calls send_ldap_result(op,rs), which eventually free-s ((*op).o_request).oq_search.rs_filterstr.bv_val; the same string is later free-d after return to translucent_search() after being retrieved from local variable "fbv".

1 0

(ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 22 Jul '09

22 Jul '09

Full_Name: Rafal Szczesniak Version: Stable (2.4.16) OS: GNU/Linux URL: http://www.samba.org/~mimir/gssapi-bugfix.diff Submission from: (NULL) (67.51.54.234) This is a bugfix patch for OpenLDAP's gssapi support.

1 0

(ITS#6224) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Full_Name: Gerald Carter Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.4.6-guess_service_principal.diff Submission from: (NULL) (71.12.192.77) There's an off by one error in guess_service_principal() when copying and checking the return value from snprintf(). Trivial patch is included.

1 0

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Correction to the URL. Should be: ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff

1 0

(ITS#6223) [patch] snprint() fix in guess_service_principal()
by jerry＠plainjoe.org 22 Jul '09

22 Jul '09

Full_Name: Gerald Carter Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.4.6-guess_service_principal.diff Submission from: (NULL) (71.12.192.77) There's an off by one error in guess_service_principal() when copying and checking the return value from snprintf(). Trivial patch is included.

1 0

(ITS#6222) Add "unlimited" option for cachesize settings
by quanah＠zimbra.com 22 Jul '09

22 Jul '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Now that we have multiple cache sizes, it would be extremely useful, particularly with dncachesize, to be able to specify an "unlimited" setting, so that the 2.3 behavior can be easily replicated. Also so that people who have systems with plenty of RAM can just set it once. In particular, I've noticed in 2.3->2.4 upgrades, if dncachesize is particularly small in relation to the size of the database, slapd is essentially unusable. I'd rather see dncachesize default to unlimited if it isn't set (2.3 behavior), and people can tune it down from there if they need to do so. This allows slapd to remain usable without severely impacting the ability of slapd to function. It is so bad, that it becomes impossible to modify cn=config via ldap commands, and you have to stop slapd and manually hack the cn=config text files to return slapd to a usable state.

1 0

Re: (ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 22 Jul '09

22 Jul '09

Howard Chu wrote: > moenoel(a)informatik.uni-bremen.de wrote: >> Full_Name: Christian Manal >> Version: 2.4.17 >> OS: SunOS 5.10 Generic_139556-08 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) >> >> >> Clients that take a long time to process search results are geting a >> writetimeout, even though the keyword is unset or 0 in slapd.conf. >> Setting the >> value to a big enough number solves the problem, but that behavior >> doesn't >> conform to the docs. >> >> Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of >> entries from the directory, but failed sporadically on slow systems since >> updating to OpenLDAP 2.4.17. >> >> Backend is hdb using BDB 4.4 from opencsw repository. Server setup is >> one master >> and four slaves on Solaris 10. > > Thanks for the report, this is now fixed in CVS HEAD. > I just tested it and can confirm that it works now. Thank you. Regards, Christian Manal

1 0

Re: (ITS#6145) Resource leaks shown when running cppcheck against openldap
by hyc＠symas.com 21 Jul '09

21 Jul '09

Paul Albert wrote: > Even if these are one shot commands, it could still mask a potential > problem that comes up in a later release that does have a real leak (think why any programmer doesn't want any warnings in his code when building). Would you consider making the changes if I were to get you a patch to fix all of these problems? If I were to do this, would you like one patch to cover the entire fix or a patch per file? Thanks for the offer. The use of scanf() in getpass.c was in code that was never actually compiled before. Due to ITS#4643 I've removed the obsolete scanf() calls. The assignment error detected in slapi_utils.c is wrong, there is no error in this code. Your tool needs to be fixed. dsaschema is a contrib module; you're welcome to submit a patch for that. The code in thr_debug.c is not compiled by default; any developer who uses it is expected to know what they're doing. Since the only way to free the table being allocated is by use of something like an atexit() handler, and those things tend to be non-portable, it's best left alone. The code in tests/progs is never installed, it's only for internal testing (and again, it's all one-shot commands) so none of that is of any concern. ldapdelete.c and ldapmodrdn.c are now fixed in HEAD. >> sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . >> [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn >> [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp >> [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: >> saveline >> [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t >> [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an >> auto-variable to an effective parameter of a function >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry >> [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter -- -- 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

ITS#4643 getpass()
by hyc＠symas.com 21 Jul '09

21 Jul '09

Since getpass() has been dropped from POSIX and is now considered unsafe, I've decided to remove all detection of it. I've reworked the implementation of lutil_getpass() which is used instead, when getpassphrase() is not present. In addition to streamlining the code, I've removed the Merit-specific use of telnet control codes, since that was specifically for a long obsolete deployment at UMich (most likely the old ud client which was deleted from the OpenLDAP tree years ago). -- -- 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#6202) adding command line option to disable line breaking in ldif output
by hyc＠symas.com 21 Jul '09

21 Jul '09

dieter(a)bloms.de wrote: > Hi, > > On Thu, Jul 09, Michael Str=F6der wrote: > >>> I want to do an enhancement request for ldapsearch, because it insert a= > line >>> break after 78 characters. >>> Many people like me use the ldapsearch command in shell script and have= > to >>> workaround this issue. >>> Maybe it make sense to add a command line option to deactivate this lin= > e breaks. >> =20 >> I'd rather recommend to use a decent scripting language with LDAP and/or >> LDIF modules than using ldapsearch in shell scripts. This gives better >> control over data and error handling. > > there are several ldapsearch binaries from other distributor, which > includes an option -T for this concern. > > http://www.koders.com/c/fidD1B671B4DA7CB116CA077E4694EEBAE167D3F85E.aspx > http://docs.sun.com/source/816-6400-10/lsearch.html > =2E.. > > so why doesn't ldapsearch from openldap inlcude this option. > It doesn't break any rfc and historcal implementation and as far as I > can see (with google), there are many admins who have to workaround this > with a little perl script. > > I think it must be a little diff, with a few lines > > I can write it, but is someone willing to inlcude it in the upstream > versions ? It has already been written, see ITS#6149. Closing this ITS as a dup. Since the LDIF spec says that lines MAY be folded, any script that processes LDIF MUST be able to handle folded lines correctly. As such, there is nothing to gain from changing things at this late date, IMO. Other folks may have different opinions, but I don't think the ITS is the place to discuss this. -- -- 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#6214) slapacl causes bdb_db_close error
by hyc＠symas.com 21 Jul '09

21 Jul '09

dkastens(a)uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.17 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.173.16.92) > > > I'm using BerkeleyDB.4.6.21 > This issue existed in openldap 2.4.16, so I updated to 2.4.17, but the error > still exists. It seems no one else encountered the problem or reported it against 2.4.16 before... Anyway, thanks for the report, it's now fixed in CVS HEAD. > When I call "slapacl", for example > slapacl -b uid=xmuster,ou=people,dc=myorg -D uid=xmuster,ou=people,dc=myorg > the output ends with the lines: > > bdb(dc=myorg): Error: closing the transaction region with active transactions > bdb_db_close: database "dc=myorg": close failed: Invalid argument (22) > > and the database is corrupted. slapd wasn't running during execution. After > running slapacl slapd starts with the message: > > bdb_db_open: database "dc=myorg": unclean shutdown detected; attempting > recovery. > > This seems to be an old but re-occuring bug. > -- -- 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#6220) Problem with writetimeout
by hyc＠symas.com 21 Jul '09

21 Jul '09

moenoel(a)informatik.uni-bremen.de wrote: > Full_Name: Christian Manal > Version: 2.4.17 > OS: SunOS 5.10 Generic_139556-08 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) > > > Clients that take a long time to process search results are geting a > writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the > value to a big enough number solves the problem, but that behavior doesn't > conform to the docs. > > Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of > entries from the directory, but failed sporadically on slow systems since > updating to OpenLDAP 2.4.17. > > Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master > and four slaves on Solaris 10. Thanks for the report, this is now fixed in CVS HEAD. -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

On Tue, 2009-07-21 at 11:17 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > >> steve(a)falchion.com wrote: > >>> 2.4.17 fails in an identical manner. > >>> > >>> For those interested, 2.4.17 failed to compile because the installed > >>> 2.4.16 libs were being picked up instead of the freshly compiled ones > >>> during the link phase. > >> > >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > > > Any ideas what that problem might be or what leads you to believe this? > > The backtrace shows that these SSL functions are contained inside your > libldap_r shared library object file. Usually they should be present in > OpenSSL's own shared libraries. If OpenSSL was only provided as a static > library, it's not clear that their code will behave correctly when used inside > a shared library (i.e., PIC vs non-PIC dependencies). Thanks for that info. I apologize for my ignorance but I got out of code development 15-20 years ago. Would it help if I compiled slapd statically? Is there an option for that in configure? > > > Unfortunately this OpenSSL is the one distributed by IBM as part of the > > AIX operating system, so it's not really my build... If I'm going to go > > to them with this, I could use a little more ammo :) > > It would also help if you compile without optimization, with debug symbols, > and run the non-stripped binaries. Your backtraces are lacking a lot of info > at the moment. I re-configured with --enable-debug and re-compiled, then ran slapd from the servers/slapd directory and got the following backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) (gdb) bt #0 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #1 0xd2512118 in tlso_ctx_init () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #2 0xd250e70c in ldap_int_tls_init_ctx () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #3 0xd2510400 in ldap_pvt_tls_set_option () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #4 0x10001fb0 in main () To my relatively untrained eye this doesn't look much different from the original. Can you give me an example of how I could compile and run to produce a better stack trace? I couldn't find documentation of that sort on the OpenLDAP web page... Thanks again, Steve > > > > > Steve > > > >>> > >>> Steve > >>> > >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >>>> > >>>> Steve > >>>> > >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>>>> <steve(a)falchion.com> wrote: > >>>>> > >>>>>> Haven't tried it. is it stable now (or soon to be?) > >>>>> > >>>>> I'd assume that depends on what bugs people report against it. Knowing > >>>>> whether or not this affects 2.4.17 would certainly be useful in that > >>>>> determination. ;) > >>>>> > >>>>> --Quanah > >> > > > > > >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 21 Jul '09

21 Jul '09

Steve Paras-Charlton wrote: > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: >> steve(a)falchion.com wrote: >>> 2.4.17 fails in an identical manner. >>> >>> For those interested, 2.4.17 failed to compile because the installed >>> 2.4.16 libs were being picked up instead of the freshly compiled ones >>> during the link phase. >> >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > Any ideas what that problem might be or what leads you to believe this? The backtrace shows that these SSL functions are contained inside your libldap_r shared library object file. Usually they should be present in OpenSSL's own shared libraries. If OpenSSL was only provided as a static library, it's not clear that their code will behave correctly when used inside a shared library (i.e., PIC vs non-PIC dependencies). > Unfortunately this OpenSSL is the one distributed by IBM as part of the > AIX operating system, so it's not really my build... If I'm going to go > to them with this, I could use a little more ammo :) It would also help if you compile without optimization, with debug symbols, and run the non-stripped binaries. Your backtraces are lacking a lot of info at the moment. > > Steve > >>> >>> Steve >>> >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? >>>> >>>> Steve >>>> >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton >>>>> <steve(a)falchion.com> wrote: >>>>> >>>>>> Haven't tried it. is it stable now (or soon to be?) >>>>> >>>>> I'd assume that depends on what bugs people report against it. Knowing >>>>> whether or not this affects 2.4.17 would certainly be useful in that >>>>> determination. ;) >>>>> >>>>> --Quanah >> > > -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > steve(a)falchion.com wrote: > > 2.4.17 fails in an identical manner. > > > > For those interested, 2.4.17 failed to compile because the installed > > 2.4.16 libs were being picked up instead of the freshly compiled ones > > during the link phase. > > Looks like a problem in your OpenSSL build, not in OpenLDAP. Any ideas what that problem might be or what leads you to believe this? Unfortunately this OpenSSL is the one distributed by IBM as part of the AIX operating system, so it's not really my build... If I'm going to go to them with this, I could use a little more ammo :) Steve > > > > Steve > > > > On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >> > >> Steve > >> > >> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>> <steve(a)falchion.com> wrote: > >>> > >>>> Haven't tried it. is it stable now (or soon to be?) > >>> > >>> I'd assume that depends on what bugs people report against it. Knowing > >>> whether or not this affects 2.4.17 would certainly be useful in that > >>> determination. ;) > >>> > >>> --Quanah >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs