- openldap-bugs - openldap.org

Re: (ITS#5591) olcSpReloadHint attribute missing from olcSyncProvConfig objectClass
by ando＠sys-net.it 02 Jul '08

02 Jul '08

mark.horstman(a)att.com wrote: > servers/slapd/overlays/syncprov.c defines the olcSpReloadHint attribute but does > not include it in the olcSyncProvConfig definition. This seems to be why one > cannot add that attribute to a syncprov overlay configured in slapd.d/cn=config. Thanks, fixed in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5591) olcSpReloadHint attribute missing from olcSyncProvConfig objectClass
by mark.horstman＠att.com 02 Jul '08

02 Jul '08

Full_Name: Mark Horstman Version: 2.4.10 OS: Linux 2.6.9-67.0.4.ELsmp 2.6.9-67.0.15.ELsmp i686 i686 i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.160.98.31) servers/slapd/overlays/syncprov.c defines the olcSpReloadHint attribute but does not include it in the olcSyncProvConfig definition. This seems to be why one cannot add that attribute to a syncprov overlay configured in slapd.d/cn=config.

1 0

Re: (ITS#5587) some changes in cn=config are not written to slapd.d
by jstrunk＠math.utexas.edu 02 Jul '08

02 Jul '08

On Wednesday 02 July 2008 10:05:02 am Howard Chu wrote: > Jeff Strunk wrote: > > One example is adding the olcSyncrepl attribute to > > olcDatabase={1}hdb,cn=config . Ldapmodify reported success. Ldapsearch > > shows the new attribute. syncrepl works. > > However, /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif > > does not have an olcSyncrepl attribute. When slapd is restarted, the > > olcSyncrepl attribute is missing. > > > > The same thing happened when adding the entry for the syncrepl overlay. > > Have you successfully run "make test"? Those exact operations are part of > test050... Have you got any slapd debug messages from these modification > attempts? This was an Ubuntu issue. They created an apparmor profile for /usr/sbin/slapd, but they didn't let it write to /etc/ldap/slapd.d . It the debug log, you'll find a permission denied error when trying to write a tempfile with this bug. It works with the following line in /etc/apparmor.d/usr.sbin.slapd : /etc/ldap/slapd.d/** rw, My strange symptom of only being able to write to cn=config.ldif was because I used the following line instead: /etc/ldap/slapd.d/* rw, Thanks, Jeff

1 0

Re: (ITS#5589) Segfault in syncrepl on provider
by michael＠fladi.at 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, I can confirm that the segfault is now gone in CVS. Syncrepl works as expected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhrmfoACgkQeJ3z1zFMUGbzjgCeLn+en9DepG5UvwVDyBTPcNav A1EAniRDgkQI8/MZF4o8yXSr552+NQZz =gvp/ -----END PGP SIGNATURE-----

1 0

Re: (ITS#5587) some changes in cn=config are not written to slapd.d
by hyc＠symas.com 02 Jul '08

02 Jul '08

Jeff Strunk wrote: > One example is adding the olcSyncrepl attribute to > olcDatabase={1}hdb,cn=config . Ldapmodify reported success. Ldapsearch shows > the new attribute. syncrepl works. > However, /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif does > not have an olcSyncrepl attribute. When slapd is restarted, the olcSyncrepl > attribute is missing. > > The same thing happened when adding the entry for the syncrepl overlay. Have you successfully run "make test"? Those exact operations are part of test050... Have you got any slapd debug messages from these modification attempts? -- -- 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#5587) some changes in cn=config are not written to slapd.d
by jstrunk＠math.utexas.edu 02 Jul '08

02 Jul '08

On Wednesday 02 July 2008 09:49:14 am Howard Chu wrote: > jstrunk(a)math.utexas.edu wrote: > > Full_Name: Jeff Strunk > > Version: 2.4.9-0ubuntu0.8.04 > > OS: Ubuntu 8.04 > > URL: > > Submission from: (NULL) (146.6.139.147) > > > > > > I am setting up a new LDAP server and trying to utilize the cn=config > > configuration style. While testing it out, I noticed that changes I make > > to cn=config are getting written to /etc/ldap/slapd.d/cn=config/ldif, but > > changes made to olcDatabase={1}hdb,cn=config are not getting written to > > /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif or anything > > else. > > > > What could be happening? > > Impossible to guess with the info you've provided. What are the changes you > tried to make that aren't being saved? One example is adding the olcSyncrepl attribute to olcDatabase={1}hdb,cn=config . Ldapmodify reported success. Ldapsearch shows the new attribute. syncrepl works. However, /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif does not have an olcSyncrepl attribute. When slapd is restarted, the olcSyncrepl attribute is missing. The same thing happened when adding the entry for the syncrepl overlay. Thank you, Jeff

1 0

Re: (ITS#5590) Method for storing last successful bind by a user
by hyc＠symas.com 02 Jul '08

02 Jul '08

prieheck(a)iwu.edu wrote: > Full_Name: Pat Riehecky > Version: 2.4.10 > OS: Ubuntu Linux 8.04, kernel 2.6.24 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.178.132.251) > > > Our internal auditing system is poor. Periodically I am asked about how often > certain classes of users use our system. As a University our account database > just grows and grows. It would be nice to have a metric for how often alumni > use their accounts. I envision something similar to the modifyTimestamp that > OpenLDAP already records. This will assist with various types of tracking in > environments where ppolicy cannot be implemented due to either politics or > limitations. I suggest you use slapo-accesslog(5) and log Bind requests there; that's what the overlay was designed for... -- -- 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#5587) some changes in cn=config are not written to slapd.d
by hyc＠symas.com 02 Jul '08

02 Jul '08

jstrunk(a)math.utexas.edu wrote: > Full_Name: Jeff Strunk > Version: 2.4.9-0ubuntu0.8.04 > OS: Ubuntu 8.04 > URL: > Submission from: (NULL) (146.6.139.147) > > > I am setting up a new LDAP server and trying to utilize the cn=config > configuration style. While testing it out, I noticed that changes I make to > cn=config are getting written to /etc/ldap/slapd.d/cn=config/ldif, but changes > made to olcDatabase={1}hdb,cn=config are not getting written to > /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif or anything else. > > What could be happening? Impossible to guess with the info you've provided. What are the changes you tried to make that aren't being saved? -- -- 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#5589) Segfault in syncrepl on provider
by hyc＠symas.com 02 Jul '08

02 Jul '08

michael(a)fladi.at wrote: > Full_Name: Michael Fladischer > Version: 2.4.10 > OS: Debian GNU/Linux Unstable > URL: http://storage.fladi.at/~fladischer.michael/slapd/ > Submission from: (NULL) (193.170.104.18) > > > I'm running two instances of slapd (2.4.10 from Debian/Unstable) on separate > machines. > One is the master/provider and the other the slave, pulling changes via syncrepl > from the provider. > Since 2.4.9 the provider slapd instance crashes with a segfault when the slave > attempts to search for the latest changes. If there are no changes the operation > completes successful. > If I change an attribute of an object on the master (add/delete/modify) the > slapd instance crashes with a segfault immediately the moment when the slave > starts his search. > I can reproduce this every time but only with a slave slapd doing the search. > The segfault does not occur when searching with ldapsearch. > > A backtrace can be found at the provided URL. Thanks for the report, a fix is now in CVS HEAD. Please test. -- -- 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#5590) Method for storing last successful bind by a user
by prieheck＠iwu.edu 02 Jul '08

02 Jul '08

Full_Name: Pat Riehecky Version: 2.4.10 OS: Ubuntu Linux 8.04, kernel 2.6.24 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.178.132.251) Our internal auditing system is poor. Periodically I am asked about how often certain classes of users use our system. As a University our account database just grows and grows. It would be nice to have a metric for how often alumni use their accounts. I envision something similar to the modifyTimestamp that OpenLDAP already records. This will assist with various types of tracking in environments where ppolicy cannot be implemented due to either politics or limitations.

1 0

(ITS#5589) Segfault in syncrepl on provider
by michael＠fladi.at 02 Jul '08

02 Jul '08

Full_Name: Michael Fladischer Version: 2.4.10 OS: Debian GNU/Linux Unstable URL: http://storage.fladi.at/~fladischer.michael/slapd/ Submission from: (NULL) (193.170.104.18) I'm running two instances of slapd (2.4.10 from Debian/Unstable) on separate machines. One is the master/provider and the other the slave, pulling changes via syncrepl from the provider. Since 2.4.9 the provider slapd instance crashes with a segfault when the slave attempts to search for the latest changes. If there are no changes the operation completes successful. If I change an attribute of an object on the master (add/delete/modify) the slapd instance crashes with a segfault immediately the moment when the slave starts his search. I can reproduce this every time but only with a slave slapd doing the search. The segfault does not occur when searching with ldapsearch. A backtrace can be found at the provided URL.

1 0

(ITS#5588) Parsing of serialNumber looks broken
by ando＠sys-net.it 01 Jul '08

01 Jul '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Parsing of the "0xXXXX" and "'XX'H" form of hexadecimal serialNumber seems to be broken in serialNumberAndIssuerCheck(); also, escaping of double double dquotes in issuer is missing. A patch is coming. p.

1 0

Re: (ITS#5583) slapadd core dumps
by dieter＠dkluenter.de 01 Jul '08

01 Jul '08

Pierangelo Masarati <ando(a)sys-net.it> writes: > Dieter Kluenter wrote: >> Pierangelo Masarati <ando(a)sys-net.it> writes: >> >>> dieter(a)dkluenter.de wrote: >>> >>>> Sorry, forgot it, >>> Should be fixed in HEAD, please test. I infer you're using multiple >>> instances of slapo-dynlist(5) in your slapd.conf, aren't you? >> No, just one instance. > > Sounds odd, because the error was related to executing slapo-dynlist's > db_open() function while the static vars holding the dgIdentity (and > the dgAuthz) attrs being already initialized. Can you test the fix to > overlays/dynlist.c 1.51->1.52? It is for HEAD, but should apply > straightforwardly to 2.4. patch applied, compiled, succesfully installed. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#5587) some changes in cn=config are not written to slapd.d
by jstrunk＠math.utexas.edu 01 Jul '08

01 Jul '08

Full_Name: Jeff Strunk Version: 2.4.9-0ubuntu0.8.04 OS: Ubuntu 8.04 URL: Submission from: (NULL) (146.6.139.147) I am setting up a new LDAP server and trying to utilize the cn=config configuration style. While testing it out, I noticed that changes I make to cn=config are getting written to /etc/ldap/slapd.d/cn=config/ldif, but changes made to olcDatabase={1}hdb,cn=config are not getting written to /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb,cn=config.ldif or anything else. What could be happening? slapd is started with: slapd -g openldap -u openldap -F /etc/ldap/slapd.d I think my permissions are correct: /etc/ldap/slapd.d total 8 drwxr-xr-x 4 openldap openldap 4096 2008-07-01 10:43 cn=config -rw------- 1 openldap openldap 1325 2008-07-01 10:51 cn=config.ldif /etc/ldap/slapd.d/cn=config total 60 -rw------- 1 openldap openldap 395 2008-07-01 09:06 cn=module{0}.ldif drwxr-xr-x 2 openldap openldap 4096 2008-06-27 13:59 cn=schema -rw------- 1 openldap openldap 30183 2008-06-27 13:59 cn=schema.ldif -rw------- 1 openldap openldap 659 2008-07-01 10:43 olcDatabase={0}config.ldif -rw------- 1 openldap openldap 500 2008-06-27 13:59 olcDatabase={-1}frontend.ldif drwxr-xr-x 2 openldap openldap 4096 2008-07-01 10:43 olcDatabase={1}hdb -rw------- 1 openldap openldap 7805 2008-07-01 10:05 olcDatabase={1}hdb.ldif /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb total 4 -rw------- 1 openldap openldap 464 2008-07-01 10:43 olcOverlay={0}syncprov.ldif /etc/ldap/slapd.d/cn=config/cn=schema total 76 -rw------- 1 openldap openldap 15428 2008-06-27 13:59 cn={0}core.ldif -rw------- 1 openldap openldap 11290 2008-06-27 13:59 cn={1}cosine.ldif -rw------- 1 openldap openldap 2784 2008-06-27 13:59 cn={2}inetorgperson.ldif -rw------- 1 openldap openldap 6420 2008-06-27 13:59 cn={3}nis.ldif -rw------- 1 openldap openldap 842 2008-06-27 13:59 cn={4}autofs.ldif -rw------- 1 openldap openldap 11791 2008-06-27 13:59 cn={5}samba.ldif -rw------- 1 openldap openldap 1829 2008-06-27 13:59 cn={6}sudo.ldif -rw------- 1 openldap openldap 10677 2008-06-27 13:59 cn={7}pykota.ldif -rw------- 1 openldap openldap 1494 2008-06-27 13:59 cn={8}local.ldif

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by amg1127＠cefetrs.tche.br 01 Jul '08

01 Jul '08

Strange... Apparently, your message did not reach my mail server... Anyway... When I did your proposed change, the server did the right thing: $ ./crash-server.sh adding new entry "cn=bugtestgroup_3301,ou=groups,dc=cefetrs,dc=tche,dc=br" ldap_add: Constraint violation (19) additional info: some attributes not unique -------------------------- Humm... Now, I know why... Your mail server does not have a 'PTR record'... Jul 1 08:59:20 cmi postfix/smtpd[26501]: NOQUEUE: reject: RCPT from unknown[194.244.21.122]: 450 4.7.1 Client host rejected: cannot find your hostname, [194.244.21.122]; from=<ando(a)sys-net.it> to=<amg1127(a)cefetrs.tche.br> proto=ESMTP helo=<mail2.sys-net.it> Jul 1 10:09:19 cmi postfix/smtpd[30576]: NOQUEUE: reject: RCPT from unknown[194.244.21.122]: 450 4.7.1 Client host rejected: cannot find your hostname, [194.244.21.122]; from=<ando(a)sys-net.it> to=<amg1127(a)cefetrs.tche.br> proto=ESMTP helo=<mail2.sys-net.it> Jul 1 11:19:22 cmi postfix/smtpd[3467]: NOQUEUE: reject: RCPT from unknown[194.244.21.122]: 450 4.7.1 Client host rejected: cannot find your hostname, [194.244.21.122]; from=<ando(a)sys-net.it> to=<amg1127(a)cefetrs.tche.br> proto=ESMTP helo=<mail2.sys-net.it> Jul 1 12:29:20 cmi postfix/smtpd[10287]: NOQUEUE: reject: RCPT from unknown[194.244.21.122]: 450 4.7.1 Client host rejected: cannot find your hostname, [194.244.21.122]; from=<ando(a)sys-net.it> to=<amg1127(a)cefetrs.tche.br> proto=ESMTP helo=<mail2.sys-net.it> # host 194.244.21.122 Host 122.21.244.194.in-addr.arpa not found: 3(NXDOMAIN) -- Anderson Medeiros Gomes amg1127(a)cefetrs.tche.br Coordenadoria de Manutenção e Redes Centro Federal de Educação Tecnológica de Pelotas http://www.cefetrs.tche.br/ > Your logs show something relatively odd: apparently, slapo-unique(5) > is trying to perform an internal search with a really malformed > filter: > > ==> unique_search , > str2filter "(&objectClass=posixGroup(|(gidNumber=1000)))" > put_filter: "(&objectClass=posixGroup(|(gidNumber=1000)))" > put_filter: AND > put_filter_list "objectClass=posixGroup(|(gidNumber=1000))" > > Can you please try using "(objectClass=posixGroup)" instead of > "objectClass=posixGroup" as the unique_uri filter in your test > slapd.conf? > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: ando(a)sys-net.it > -----------------------------------

1 0

(ITS#5586) SLAPD crashing with SIGABRT in connction.c on Solaris
by dbb＠st-andrews.ac.uk 01 Jul '08

01 Jul '08

Full_Name: Duncan Brannen Version: 2.4.10 OS: Solaris 10 URL: http://www.st-andrews.ac.uk/openldapconf.tar Submission from: (NULL) (138.251.61.69) Slapd is crashing on a daily basis, robin 91 logs % /usr/local/SUNWspro/bin/dbx /usr/local/libexec/slapd ./slapd.core.01-07-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.0.6 Reading liblber-2.4.so.2.0.6 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@10 a l@10 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@13 a l@13 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@14 a l@14 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1390, 0x1a13c4, 0x367, 0x0, 0xa810c, 0x1d7708), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1214890154), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *c dbx: reference through nil pointer ------------------------------- >From another core t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x2580f8 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1390, 0x1a13c4, 0x367, 0x0, 0xa810c, 0x1d7708), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1214582536), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *c dbx: reference through nil pointer ----------------------------- I've not been able to reproduce reliably, but it's only affecting the servers queried by our mailhosts doing this kind of search. Jul 1 11:13:10 robin slapd[13561]: [ID 469902 local4.debug] conn=21586 op=8 SRCH base="dc=st-andrews,dc=ac,dc=uk" scope=2 deref=0 filter="(&(uid=(a)st-andrews.ac.uk)(objectClass=posixAccount))" I'll copy the config files to the url http://www.st-andrews.ac.uk/openldapconf.tar for information.

1 0

Re: (ITS#5584)
by hyc＠symas.com 01 Jul '08

01 Jul '08

abartlet(a)samba.org wrote: > --=-GddVbqVLc61XV3X/kWQ/ > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > I've uploaded the patch to http://abartlet.net/memberof.patch I committed a different patch to HEAD. Please test. -- -- 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#5573) Attribute types 'entryCSN' and 'contextCSN' not available in subschema
by hyc＠symas.com 30 Jun '08

30 Jun '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.82.89) > > > Please add attribute types 'entryCSN' and 'contextCSN' to subschema. There's still no published spec for CSNs, just a couple expired drafts. -- -- 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#5585) GnuTLS SSF strength conversion issue
by quanah＠OpenLDAP.org 30 Jun '08

30 Jun '08

Full_Name: Quanah Gibson-Mount Version: 2.4.10/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When using GnuTLS rather than OpenSSL for OpenLDAP, the SSF reported when using startTLS is incorrect. This is because GnuTLS reports the strength in bytes, while the OpenLDAP code expects the strength in bits. Code needs to be updated to adjust the SSF value when linked against GnuTLS to our expected result.

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by vorlon＠debian.org 30 Jun '08

30 Jun '08

On Mon, Jun 30, 2008 at 10:09:59AM +0200, Pierangelo Masarati wrote: > vorlon(a)debian.org wrote: >> So meta_back_db_config() seems to be getting called before >> meta_back_db_open() ? > This is now fixed in HEAD; however, despite solving the sigsegv issue, > the test still fails because ldap_first_message(3) is not available. > This sounds odd, can anyone explain why it is not getting loaded? Thanks, applied this latest patch and I confirm that it fixes the segfault. I also don't see any problems resolving the ldap_first_message symbol. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5583) slapadd core dumps
by rhafer＠suse.de 30 Jun '08

30 Jun '08

On Sonntag, 29. Juni 2008, you wrote: > Pierangelo Masarati <ando(a)sys-net.it> writes: > > Dieter Kluenter wrote: > >> Pierangelo Masarati <ando(a)sys-net.it> writes: > >>> dieter(a)dkluenter.de wrote: > >>>> Sorry, forgot it, > >>> > >>> Should be fixed in HEAD, please test. I infer you're using > >>> multiple instances of slapo-dynlist(5) in your slapd.conf, aren't > >>> you? > >> > >> No, just one instance. > > > > Sounds odd, because the error was related to executing > > slapo-dynlist's db_open() function while the static vars holding > > the dgIdentity (and the dgAuthz) attrs being already initialized. > > Can you test the fix to overlays/dynlist.c 1.51->1.52? It is for > > HEAD, but should apply straightforwardly to 2.4. > > I just compiled HEAD and slapadd added the ldif file as expected. But > a second error occured, test failed with test001 Is this on openSUSE 11.0? Then you might have hit http://sourceware.org/bugzilla/show_bug.cgi?id=4980 (or ITS#5251). We have patched around that glibc bug in our openldap packages. A possible workaround that doesn't require patching is to remove the "localhost" entry from the "::1" line in /etc/hosts. > , but I will check > this tomorrow, same as the dynlist patch. -- Ralf

1 0

Re: (ITS#5574) Attribute type 'auditContext' not available in subschema
by ando＠sys-net.it 30 Jun '08

30 Jun '08

michael(a)stroeder.com wrote: > I can't see it with RE24 (at the moment 2.4.10). > Which version are you looking at? > > On my system slapo-accesslog is built and actively used. > BTW: Other schema elements of slapo-accesslog are not available either: > object class auditModify, attribute type reqAuthzID etc. HEAD. I checked the code to see if the HIDE flag was being set, and I didn't notice it was (it's being added right before registering the schema item, rather than when defining it, that's why I overlooked it). Of course you can't see it with 2.4. I think its publication as non-experimental is pending Howard's completion of the related I.D. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5574) Attribute type 'auditContext' not available in subschema
by michael＠stroeder.com 30 Jun '08

30 Jun '08

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: OpenSUSE Linux 10.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.82.89) >> >> >> Please add attribute type 'auditContext' to subschema. > > It is registered by slapo-accesslog(5). I can see it when > slapo-accesslog(5) is built. I can't see it with RE24 (at the moment 2.4.10). Which version are you looking at? On my system slapo-accesslog is built and actively used. BTW: Other schema elements of slapo-accesslog are not available either: object class auditModify, attribute type reqAuthzID etc. Ciao, Michael.

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by ando＠sys-net.it 30 Jun '08

30 Jun '08

vorlon(a)debian.org wrote: > So meta_back_db_config() seems to be getting called before > meta_back_db_open() ? This is now fixed in HEAD; however, despite solving the sigsegv issue, the test still fails because ldap_first_message(3) is not available. This sounds odd, can anyone explain why it is not getting loaded? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by ando＠sys-net.it 29 Jun '08

29 Jun '08

vorlon(a)debian.org wrote: > So meta_back_db_config() seems to be getting called before > meta_back_db_open() ? ... which is correct. A fix is coming. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs