openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 06 Jun '11

06 Jun '11

Thanks Howard, it working perfectly again. This also resolves my other ITS, #6891. On 06/05/2011 04:36 PM, Howard Chu wrote: > tgates81(a)gmail.com wrote: >> Full_Name: Tyler Gates >> Version: 2.4.25 >> OS: Ubuntu 10.04 LTS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (65.184.61.44) >> >> >> I've been fighting with a strange issue related to a backend database >> using a >> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming >> there was >> just something wrong with my cn=config I decided to start back fresh >> using >> slapd.conf instead. >> Once I got the config working just fine I used slaptest to convert >> the config to >> a new cn=config. Unfortunately when I tried using -F cn=config >> instead of my -f >> slapd.conf, slapd failed with the same old message: > > Looks like this was broken by the patch for ITS#6837. Working on a new > fix. >> >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, >> database 0 (hdb) has no suffix >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: >> starting >> "(unknown)" >> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one >> (type=hdb, >> suffix="(null)"): bi_db_open failed! (-1) >> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated >> >> >> The backend database has never required me specify a suffix since it >> is already >> specified in the ldap overlay and when I try to add it in I get slapd >> trying to >> open the database twice which results in the second instance having >> access >> issues thus rendering all of the database inaccessible to queries. >> >> I'm assuming there has been a configuration change in cn=config for this >> particular layout but slaptest has not been updated. Below is a copy >> of the flat >> file I used that worked fine but failed once converted to cn=config >> using >> slaptest -f slapd.conf -F /etc/ldap/slapd.d/ >> >> root@directory-proxy:~# grep "^[^#]" >> /etc/ldap/slapd.conf.back_ldap_ppcache >> 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/openldap.schema >> include /etc/ldap/schema/sudo.schema >> include /etc/ldap/schema/autofs.schema >> include /etc/ldap/schema/ppolicy.schema >> include /etc/ldap/schema/qmail.schema >> include /etc/ldap/schema/puppet.schema >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >> modulepath /usr/lib/ldap >> moduleload back_ldap >> moduleload back_hdb >> moduleload pcache >> moduleload ppolicy >> TLSCertificateFile /etc/ldap/ssl/slapd.crt >> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key >> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt >> loglevel -1 >> allow bind_anon_dn >> database config >> rootdn cn=admin,cn=config >> rootpw secret >> access to * by >> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> manage by * break >> database ldap >> suffix "dc=domain,dc=com" >> rootdn "cn=Manager,dc=domain,dc=com" >> rootpw secret >> uri "ldaps://directory1.domain.com >> ldaps://directory2.domain.com" >> overlay pcache >> proxycache hdb 100000 3 1000 100 >> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory >> loginShell gecos description memberUid uniqueMember objectClass >> proxyAttrset 1 cn automountInformation >> proxyAttrset 2 cn mail >> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 >> proxyTemplate (&(objectClass=)(uid=)) 0 1800 >> proxyTemplate (&(objectClass=)(cn=)) 0 1800 >> proxyTemplate (&(objectClass=)) 0 1800 >> proxyTemplate (objectClass=) 0 1800 >> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 >> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 >> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 >> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 >> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 >> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 >> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 >> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 >> directory /var/lib/ldap >> cachesize 1000 >> idletimeout 600 >> idlcachesize 3000 >> index objectClass eq >> index cn,mail,surname,givenname eq,subinitial >> index uidNumber,gidNumber,memberuid,member,uniqueMember eq >> index uid eq,subinitial >> index nisMapName,automountInformation eq >> index userPassword,homeDirectory,loginShell,gecos,description eq >> index pcacheQueryID eq >> >> > >

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 06 Jun '11

06 Jun '11

This is now fixed with ITS 6948 patch. On 04/12/2011 03:42 PM, Quanah Gibson-Mount wrote: > --On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates > <tgates81(a)gmail.com> wrote: > >> I can't get a back trace because it doesn't crash under gdb, slapd >> only responds to queries with error: >> >> client: >> result: 80 Other (e.g., implementation specific) error >> text: internal error >> server: >> bdb(dc=example,dc=com): PANIC: fatal region error detected; run >> recovery >> >> Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one >> (type=hdb, suffix="(null)"): bi_db_open failed! (-1) > > These all indicate permissions issues. It sounds like the slapd > instance does not have permissions to access the database. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by hyc＠symas.com 05 Jun '11

05 Jun '11

tgates81(a)gmail.com wrote: > Full_Name: Tyler Gates > Version: 2.4.25 > OS: Ubuntu 10.04 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.184.61.44) > > > I've been fighting with a strange issue related to a backend database using a > pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming there was > just something wrong with my cn=config I decided to start back fresh using > slapd.conf instead. > Once I got the config working just fine I used slaptest to convert the config to > a new cn=config. Unfortunately when I tried using -F cn=config instead of my -f > slapd.conf, slapd failed with the same old message: Looks like this was broken by the patch for ITS#6837. Working on a new fix. > > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, > database 0 (hdb) has no suffix > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: starting > "(unknown)" > May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one (type=hdb, > suffix="(null)"): bi_db_open failed! (-1) > May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated > > > The backend database has never required me specify a suffix since it is already > specified in the ldap overlay and when I try to add it in I get slapd trying to > open the database twice which results in the second instance having access > issues thus rendering all of the database inaccessible to queries. > > I'm assuming there has been a configuration change in cn=config for this > particular layout but slaptest has not been updated. Below is a copy of the flat > file I used that worked fine but failed once converted to cn=config using > slaptest -f slapd.conf -F /etc/ldap/slapd.d/ > > root@directory-proxy:~# grep "^[^#]" /etc/ldap/slapd.conf.back_ldap_ppcache > 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/openldap.schema > include /etc/ldap/schema/sudo.schema > include /etc/ldap/schema/autofs.schema > include /etc/ldap/schema/ppolicy.schema > include /etc/ldap/schema/qmail.schema > include /etc/ldap/schema/puppet.schema > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > modulepath /usr/lib/ldap > moduleload back_ldap > moduleload back_hdb > moduleload pcache > moduleload ppolicy > TLSCertificateFile /etc/ldap/ssl/slapd.crt > TLSCertificateKeyFile /etc/ldap/ssl/slapd.key > TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt > loglevel -1 > allow bind_anon_dn > database config > rootdn cn=admin,cn=config > rootpw secret > access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > manage by * break > database ldap > suffix "dc=domain,dc=com" > rootdn "cn=Manager,dc=domain,dc=com" > rootpw secret > uri "ldaps://directory1.domain.com ldaps://directory2.domain.com" > overlay pcache > proxycache hdb 100000 3 1000 100 > proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory > loginShell gecos description memberUid uniqueMember objectClass > proxyAttrset 1 cn automountInformation > proxyAttrset 2 cn mail > proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 > proxyTemplate (&(objectClass=)(uid=)) 0 1800 > proxyTemplate (&(objectClass=)(cn=)) 0 1800 > proxyTemplate (&(objectClass=)) 0 1800 > proxyTemplate (objectClass=) 0 1800 > proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 > proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 > proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 > proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 > proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 > proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 > proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 > proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 > directory /var/lib/ldap > cachesize 1000 > idletimeout 600 > idlcachesize 3000 > index objectClass eq > index cn,mail,surname,givenname eq,subinitial > index uidNumber,gidNumber,memberuid,member,uniqueMember eq > index uid eq,subinitial > index nisMapName,automountInformation eq > index userPassword,homeDirectory,loginShell,gecos,description eq > index pcacheQueryID eq > > -- -- 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#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 05 Jun '11

05 Jun '11

Sad enough I had to turn off using the assertion control in upcoming web2ldap release as yet another vendor-specific workaround - this time for OpenLDAP... It works with OpenDS and OpenDJ and web2ldap uses it with these servers.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 05 Jun '11

05 Jun '11

hyc(a)symas.com wrote: > Fixed now. 60+ test iterations without error. Ciao, Michael.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 05 Jun '11

05 Jun '11

hyc(a)symas.com wrote: > Howard Chu wrote: > Ah this is a simple timing issue in the test startup; the incoming entry was > ignored because its entryCSN was older than the local one. > >> (back-config explicitly prevents any attempts to delete both of these entries. >> When syncrepl fails to delete an entry, it does a modify to change the >> objectclass to glue, which explains how they got to their final state when the >> test aborted.) > > I guess we can try to patch the startup sequencing of the script; this problem > can only occur in cn=config, because of the special nature of the cn=schema > and olcDatabase={0}config entries. > Fixed now. -- -- 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#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> BTW: This is git master (formerly known as HEAD). >> >> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz > > I see, and I was also able to reproduce it here. The difference is that on > server2, 2 of the entries have objectClass: glue instead of their correct > objectclasses. From the diffs, this affected cn=schema,cn=config and > olcDatabase={0}config,cn=config. Looking at the logs, this happened because > during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't > match the UUIDs sent from some other master, so syncrepl attempted to delete them. > > Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config > are always created automatically by each slapd, so naturally their UUIDs > differ on each server. But, also generally, after the first refresh each > consumer would modify their local entries and overwrite the UUIDs with the > ones received from their provider. Not sure why this didn't happen this time > around. Ah this is a simple timing issue in the test startup; the incoming entry was ignored because its entryCSN was older than the local one. > (back-config explicitly prevents any attempts to delete both of these entries. > When syncrepl fails to delete an entry, it does a modify to change the > objectclass to glue, which explains how they got to their final state when the > test aborted.) I guess we can try to patch the startup sequencing of the script; this problem can only occur in cn=config, because of the special nature of the cn=schema and olcDatabase={0}config entries. -- -- 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#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I see, and I was also able to reproduce it here. The difference is that on server2, 2 of the entries have objectClass: glue instead of their correct objectclasses. From the diffs, this affected cn=schema,cn=config and olcDatabase={0}config,cn=config. Looking at the logs, this happened because during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't match the UUIDs sent from some other master, so syncrepl attempted to delete them. Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config are always created automatically by each slapd, so naturally their UUIDs differ on each server. But, also generally, after the first refresh each consumer would modify their local entries and overwrite the UUIDs with the ones received from their provider. Not sure why this didn't happen this time around. (back-config explicitly prevents any attempts to delete both of these entries. When syncrepl fails to delete an entry, it does a modify to change the objectclass to glue, which explains how they got to their final state when the test aborted.) -- -- 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#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> BTW: This is git master (formerly known as HEAD). >> >> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz > > I have the test running now, will see how it goes. It's probably a good idea > to include the git commit ID now instead of just referencing master/HEAD . I always do git pull before posting an ITS applying HEAD to make sure nothing came in after the error. Ciao, Michael.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I have the test running now, will see how it goes. It's probably a good idea to include the git commit ID now instead of just referencing master/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

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