openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs