openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

06 Aug '09

> Here are slapd.conf and proxycache.conf as attachments. I just wanted to feed back before I leave for a few days. I don't see anything critical in your files. You explicitly give the rootdn write permissions, which is useless, but apart from this everything looks fine. I've tested a simple setup and it works as expected. I used HEAD and re24 code; the latter is nearly identical to 2.4.17. I also tested with TLS. At this point, I'm a bit clueless. There must be something we're overlooking. p.

1 0

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

06 Aug '09

This is a multi-part message in MIME format. --------------050103000202040305030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: > > 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. > Here are slapd.conf and proxycache.conf as attachments. regards, Jim vK --------------050103000202040305030502 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" # oOpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.5 2002/11/26 18:26:01 kurt Exp $tdn # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/opt/openldap/schema/DUAConfig.schema include /etc/opt/openldap/schema/misc.schema include /etc/opt/openldap/schema/core.schema include /etc/opt/openldap/schema/cosine.schema include /etc/opt/openldap/schema/inetorgperson.schema include /etc/opt/openldap/schema/solaris-nis.schema include /etc/opt/openldap/schema/solaris.schema include /etc/opt/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://feathercraft.few.vu.nl logfile /var/log/openldap threads 8 pidfile /var/opt/openldap/slapd.pid argsfile /var/opt/openldap/slapd.args # Load dynamic backend modules: modulepath /opt/openldap/openldap-2.4.16/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la #moduleload back_ldbm.la # # Sample security restrictions # # Disallow clear text exchange of passwords #disallow bind_simple_unprotected # # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! gentlehup on #TLSCipherSuite ALL:!EXP:!LOW:!ADH:@STRENGTH #TLSCACertificateFile /usr/local/ssl/certs/few-ca-cert.pem #TLSCACertificatePath /usr/local/ssl/certs #TLSCertificateFile /usr/local/ssl/certs/flits.few.vu.nl-cert.pem #TLSCertificateKeyFile /etc/opt/openldap/private/flits.few.vu.nl-key.rsa #TLSVerifyClient never ####################################################################### # ldbm database definitions ####################################################################### database config rootdn "uid=Admin,cn=config" rootpw * access to dn.subtree="cn=config" by dn.exact="uid=Admin,cn=config" write by * read database monitor rootdn "uid=Admin,cn=Monitor" rootpw * access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,cn=Monitor" write by * read include /etc/opt/openldap/proxycache.conf --------------050103000202040305030502 Content-Type: text/plain; name="proxycache.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxycache.conf" database ldap suffix "dc=few,dc=vu,dc=nl" rootdn cn=Manager,dc=few,dc=vu,dc=nl rootpw * tls start uri ldap://klondike.few.vu.nl acl-bind bindmethod=simple binddn="cn=sambaLdapManager,ou=Special Users,dc=few,dc=vu,dc=nl" credentials=* sizelimit unlimited #loglevel 4095 overlay pcache proxycache bdb 100000 10 1000 100 proxyAttrset 0 uid cn proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(uid=)(objectClass=)) 0 1800 cachesize 10000 directory /var/opt/openldap/openldap-data/proxy access to * by * read ## required to support pdb_getsampwnam ## required to support pdb_getsambapwrid() ## uncomment these if you are storing posixAccount and ## posixGroup entries in the directory as well ### required by OpenLDAP index objectclass eq index cn pres,sub,eq index sn pres,sub,eq ### required to support pdb_getsampwnam index uid pres,sub,eq ### required to support pdb_getsambapwrid() index displayName pres,sub,eq ### uncomment these if you are storing posixAccount and ### posixGroup entries in the directory as well index uidNumber eq index gidNumber eq index memberUid eq index sambaSid eq index sambaPrimaryGroupSID eq index sambaDomainName eq index queryId eq index default sub --------------050103000202040305030502--

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

> This may be specific to glued databases (databases rooted at ""). The problem could be partially addressed by telling back-bdb (who's maintaining this data in the monitor backend) to check subordinates as soon as it discovers it's a glue instance. However, this poses two different problems: - is the aggregate information resulting from adding all glued databases cache usage still useful? - what happens if heterogeneous databases are glued? Significantly, what if the superior database is not bdb/hdb? Probably, the monitor database should also present subordinate databases as separate entries. p.

1 0

(ITS#6244) "now" dynacl module
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

Full_Name: Pierangelo Masarati Version: re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c Submission from: (NULL) (93.149.38.247) Submitted by: ando This simple module implements a dynacl that allows to compare a given generalizedTime-valued attribute with "now", according to generalizedTimeOrderingMatch (greater-or-equal, less-or-equal). p.

1 0

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

05 Aug '09

--On August 5, 2009 5:35:57 PM +0000 quanah(a)zimbra.com wrote: > 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 This may be specific to glued databases (databases rooted at ""). I see that it's reporting the caches as under the Frontend database, instead of the actual BDB database, which is database 3, and shows no cache information: # Database 3, Databases, Monitor dn: cn=Database 3,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: readOnly: FALSE monitorOverlay: accesslog monitorOverlay: syncprov entryDN: cn=Database 3,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE I see the same behavior on the replica, where it is Database 2 instead of database 3, as it has no accesslog DB. On the master, the accesslog DB caches are correct: # Database 2, Databases, Monitor dn: cn=Database 2,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: syncprov olmBDBEntryCache: 297 olmBDBDNCache: 517 olmBDBIDLCache: 9 olmDbDirectory: /opt/zimbra/data/ldap/accesslog/db/ entryDN: cn=Database 2,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(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

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