openldap-bugs

openldap-bugs@openldap.org

1 participants
21146 discussions

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron RIchton > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.30.206) > > > BDB 4.2.52. I've had a couple (different) machines SEGV on slapd > shutdown. Both > had identical stack traces: Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35? Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now. <http://www.stanford.edu/services/directory/openldap/configuration/bdb-build…> 5 are direct from sleepycat: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/patc…> with the last one there possibly impacting you if you don't have it? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu 26 Apr '07

26 Apr '07

Full_Name: Aaron RIchton Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.30.206) BDB 4.2.52. I've had a couple (different) machines SEGV on slapd shutdown. Both had identical stack traces: current thread: t@1 =>[1] __dbreg_revoke_id(dbp = 0xa498818, have_lock = 0, force_id = -1), line 427 in "dbreg.c" [2] __dbreg_close_files(dbenv = 0x405320), line 206 in "dbreg_util.c" [3] __log_dbenv_refresh(dbenv = 0x405320), line 744 in "log.c" [4] __dbenv_refresh(dbenv = 0x405320, orig_flags = 0, rep_check = 0), line 648 in "env_open.c" [5] __dbenv_close(dbenv = 0x405320, rep_check = 0), line 579 in "env_open.c" [6] __dbenv_close_pp(dbenv = 0x405320, flags = 0), line 534 in "env_open.c" [7] hdb_db_close(be = 0x367340), line 517 in "init.c" [8] backend_shutdown(be = 0x367340), line 351 in "backend.c" [9] slap_shutdown(be = (nil)), line 279 in "init.c" [10] main(argc = 4, argv = 0xffbffd6c), line 870 in "main.c" No idea if this is Sleepycat or slapd, but it dirties the database in a way that automatic nor command-line db_recover appreciate: Ignoring log file: log.0000000007: magic number 0, not 40988 Invalid log file: log.0000000007: Invalid argument PANIC: Invalid argument PANIC: DB_RUNRECOVERY: Fatal error, run database recovery hdb_db_open: Database cannot be recovered, err -30978. Restore from backup! DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: txn_checkpoint failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (-30978)

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by hyc＠symas.com 25 Apr '07

25 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > overlay chain breaks with databases ldbm and ldif: > > ./run -b {ldbm or ldif} test032-chain outputs: > ... > Starting second slapd on TCP/IP port 9012... > ... > Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" > on port 9012... > ldapcompare failed (10)! > > ldapcompare output in testrun/test.out: > Compare Result: Referral (10) > Matched DN: ou=People,dc=example,dc=com > Referral: ldap://localhost:9011/ou=People,dc=example,dc=com > UNDEFINED > > testrun/slapd.1.log says the Compare was sent to the chained server, but > with baseDN=<Matched DN above>: > ... > do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) > conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" > ... > conn=5 op=2 RESULT tag=111 err=16 text= > ... > > Slapcat says the Matched DN entry is correct (same as in a BDB run): > dn: ou=People,dc=example,dc=com > objectClass: referral > objectClass: extensibleObject > ou: People > ref: ldap://localhost:9011/ou=People,dc=example,dc=com > structuralObjectClass: referral > > > Also the Statslog output is wrong for all three databases: > > With LDBM and LDIF, the CMP operation is not logged, only its result: > grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above > conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=14 closed > > With BDB, the CMP operation is not logged, but both the returned > result and the suppressed referral result is logged: > conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=6 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=12 closed > > > I haven't tried other databases, but since two different databases > had the same bug and same wrong Statlog, I'm guessing others do too. This seems to be a known limitation, see the FIXME in slapd/compare.c, near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem for back-ldif, which does not provide its own compare entry point. As for back-ldbm, there is a missing referral_rewrite call in back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, but you're welcome to fix it if you wish. Just have a look at back-bdb/referral.c for the correct code. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 25 Apr '07

25 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard overlay chain breaks with databases ldbm and ldif: ./run -b {ldbm or ldif} test032-chain outputs: ... Starting second slapd on TCP/IP port 9012... ... Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" on port 9012... ldapcompare failed (10)! ldapcompare output in testrun/test.out: Compare Result: Referral (10) Matched DN: ou=People,dc=example,dc=com Referral: ldap://localhost:9011/ou=People,dc=example,dc=com UNDEFINED testrun/slapd.1.log says the Compare was sent to the chained server, but with baseDN=<Matched DN above>: ... do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" ... conn=5 op=2 RESULT tag=111 err=16 text= ... Slapcat says the Matched DN entry is correct (same as in a BDB run): dn: ou=People,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: People ref: ldap://localhost:9011/ou=People,dc=example,dc=com structuralObjectClass: referral Also the Statslog output is wrong for all three databases: With LDBM and LDIF, the CMP operation is not logged, only its result: grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=14 closed With BDB, the CMP operation is not logged, but both the returned result and the suppressed referral result is logged: conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=6 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=12 closed I haven't tried other databases, but since two different databases had the same bug and same wrong Statlog, I'm guessing others do too.

1 0

Re: (ITS#4936) default modulepath
by ahasenack＠terra.com.br 23 Apr '07

23 Apr '07

On Mon, Apr 23, 2007 at 09:17:26PM +0000, abartlet(a)samba.org wrote: > It would be very useful if OpenLDAP would provide a default value for > modulepath. > > This would ensure that on systems with multiple openldap installs (such as test > rigs) that we do not need to specify the *correct* modulepath, when starting the > config with different slapd binaries. > > Similarly, it would avoid the need to guess which modulepath is correct for a > given system, such as when we find slapd in the path (as Samba4's test mode > does), but needs to automatically enable modules. Another scenario is with some tool providing a config file for slapd. It wouldn't have to guess the host arch whether it's i386 or x86_64 and set the correct module_path (/usr/lib/openldap vs /usr/lib64/openldap).

1 0

(ITS#4936) default modulepath
by abartlet＠samba.org 23 Apr '07

23 Apr '07

Full_Name: Andrew Bartlett Version: devel OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.70.73.150) It would be very useful if OpenLDAP would provide a default value for modulepath. This would ensure that on systems with multiple openldap installs (such as test rigs) that we do not need to specify the *correct* modulepath, when starting the config with different slapd binaries. Similarly, it would avoid the need to guess which modulepath is correct for a given system, such as when we find slapd in the path (as Samba4's test mode does), but needs to automatically enable modules. (Discussed with Howard Chu)

1 0

Re: (ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

--=__PartDCFBBB68.0__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Confirmed fix works. — Luke --=__PartDCFBBB68.0__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"> <META content=3D"MSHTML 6.00.5346.5" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>Confirmed fix works.</DIV> <DIV> </DIV> <DIV>=E2=80=94 Luke<BR></DIV></BODY></HTML> --=__PartDCFBBB68.0__=--

1 0

(ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

Full_Name: Luke Howard Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.16.129.17) SASL_MAX_BUFF_SIZE is too small for SASL mechanisms, such as GSS-SPNEGO, that use a buffer size unconstrained by the 64K limit defined for some mechanisms in RFC 2222. A more reasonable default would 0xFFFFFF (2^24), used as the maximum buffer size by many of the mechanisms shipped with Cyrus itself.

1 0

(ITS#4934) Port change
by babu.suresh＠pacificlife.com 20 Apr '07

20 Apr '07

Full_Name: Babu Version: 2.3 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.8.254) My openldap was running on default port 389 and imported all schema & data. Now I would like to change the port to different..would be 4000/5000. OpenLDAP process started successfully with non default port but I am getting "error 32 no such object" when try to browse the data using soferra. is it possible to change the port anytime? thank you

1 0

(ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by donn＠u.washington.edu 20 Apr '07

20 Apr '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Appears to me that unless timelimit value passed to ldap_search_ext() is positive, the ld_timelimit from .ldaprc overrides, so there's no way for syncrepl ldap_sync_search() to literally specify "unlimited". To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> "TIMELIMIT 23"; start replica slapd with a sufficiently large replication backlog; observe timeout at 23 seconds. To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; and pass &timeout unconditionally.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs