- openldap-bugs - openldap.org

ldapsearch and buffered stdout
by Dale.Moore＠cs.cmu.edu 03 Jul '08

03 Jul '08

The client tool can read from stdin and produce output on stdout. For example ldapsearch -L -x -f - 'cn=%s' uid This will read cn values from stdin and produce search results on stdout. But doing this interactively does not produce the immediate feedback because stdout is often buffered. The search results are presented only after a sufficient amount have been buffered, or an EOF is encountered. It would be very nice if ldapsearch application would flush stdout after each search. Below is a diff of the ldapsearch client tool with my proposed change. *************** *** 1,5 **** /* ldapsearch -- a tool for searching LDAP directories */ ! /* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.234.2.9 2008/02/12 19:59:52 quanah Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2008 The OpenLDAP Foundation. --- 1,5 ---- /* ldapsearch -- a tool for searching LDAP directories */ ! /* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.234.2.9 2008/02/12 19:59:52 quanah Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2008 The OpenLDAP Foundation. *************** *** 998,1003 **** --- 998,1004 ---- if ( !contoper ) break; } + fflush(stdout); } if ( fp != stdin ) { fclose( fp );

3 2

(ITS#5593) Back-meta search references
by andrew.graham＠agustawestland.com 03 Jul '08

03 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) Please provide an option to stop search references being proxied from target to client in back-meta.

1 0

(ITS#5592) Quarantine in back-meta
by andrew.graham＠agustawestland.com 03 Jul '08

03 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) The quarantine function in back-meta will permanently disable a target if a query is received while the quarantine has been imposed. To reproduce, use the config file below. Send a query and the quarantine will be set. Send another query within 20 seconds and the quarantine will not lift without restarting slapd. ---- slapd.conf ---- include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database meta suffix dc=example,dc=com uri ldap://afakeaddress/dc=target,dc=example,dc=com quarantine 20,+

1 0

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 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() ? ... 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

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

30 Jun '08

On Sun, Jun 29, 2008 at 11:29:58PM -0700, Steve Langasek wrote: > Are you seeing this as well, or is this somehow specific to Debian? (It > doesn't seem like it should be related to libltdl in any way, and we don't > have any other patches that touch the meta backend; and I saw this segfault > both with the version of the patch I sent, and the one extracted from CVS.) > Unfortunately, running these tests under gdb seems to be pretty awkward. :/ Well, here's the backtrace: 0x00007f9d6a45ef60 in meta_back_db_config (be=0xa7bbb0, fname=0x9f1040 "/home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/tests/testrun/slapd.3.conf", lineno=65, argc=6, argv=0xa3d230) at /home/devel/openldap/build-area/openldap2.3-2.4.10/servers/slapd/back-meta/config.c:1162 1162 return mi->mi_ldap_extra->idassert_parse_cf( fname, lineno, argc, argv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert ); #0 0x00007f9d6a45ef60 in meta_back_db_config (be=0xa7bbb0, fname=0x9f1040 "/home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/tests/testrun/slapd.3.conf", lineno=65, argc=6, argv=0xa3d230) at /home/devel/openldap/build-area/openldap2.3-2.4.10/servers/slapd/back-meta/config.c:1162 #1 0x000000000042ab13 in read_config_file (fname=<value optimized out>, depth=<value optimized out>, cf=0x0, cft=0x71e0e0) at /home/devel/openldap/build-area/openldap2.3-2.4.10/servers/slapd/config.c:786 #2 0x000000000042692d in read_config ( fname=0x9f1040 "/home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/tests/testrun/slapd.3.conf", dir=0x0) at /home/devel/openldap/build-area/openldap2.3-2.4.10/servers/slapd/bconfig.c:3461 #3 0x0000000000419f3b in main (argc=8, argv=0x7fff77dc3e88) at /home/devel/openldap/build-area/openldap2.3-2.4.10/servers/slapd/main.c:754 $1 = (ldap_extra_t *) 0x0 So meta_back_db_config() seems to be getting called before meta_back_db_open() ? -- 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#5355) back-meta calls back-ldap directly
by ando＠sys-net.it 30 Jun '08

30 Jun '08

vorlon(a)debian.org wrote: > On Sun, Jun 29, 2008 at 05:23:57PM -0700, Howard Chu wrote: >> Steve Langasek wrote: >>> Is the correct fix to add >>> this function to the ldap_extra_t struct, as in the attached patch? > >> Pretty much. There are a few other functions that need to be added as >> well. All of them are provided in current CVS HEAD, just grab the >> relevant changes from there. > > Ok. With the patch from CVS HEAD applied, I'm seeing a segfault in make > test (specifically, the meta backend test): > > >>>>> Starting test035-meta ... > running defines.sh > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Starting slapd on TCP/IP port 9012... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Starting slapd on TCP/IP port 9013... > /home/devel/openldap/build-area/openldap2.3-2.4.10/tests/scripts/test035-meta: line 118: 22990 Segmentation fault $SLAPD -f $CONF3 -h $URI3 -d $LVL /$TIMING > $LOG3 2>&1 I'm not seeing anything like that, but I don't build back-meta as a module. It would be helpful if you provide at least a stack backtrace for that sigsegv, to help understand where and why it occurred. > Are you seeing this as well, or is this somehow specific to Debian? (It > doesn't seem like it should be related to libltdl in any way, and we don't > have any other patches that touch the meta backend; and I saw this segfault > both with the version of the patch I sent, and the one extracted from CVS.) > Unfortunately, running these tests under gdb seems to be pretty awkward. :/ One thing that is still missing from that test is that if you build back-ldap as a module, you need to load it before opening a back-meta database, in order load the requested symbols. I'm fixing this right now. 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 vorlon＠debian.org 30 Jun '08

30 Jun '08

On Sun, Jun 29, 2008 at 05:23:57PM -0700, Howard Chu wrote: > Steve Langasek wrote: >> Is the correct fix to add >> this function to the ldap_extra_t struct, as in the attached patch? > Pretty much. There are a few other functions that need to be added as > well. All of them are provided in current CVS HEAD, just grab the > relevant changes from there. Ok. With the patch from CVS HEAD applied, I'm seeing a segfault in make test (specifically, the meta backend test): >>>>> Starting test035-meta ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... /home/devel/openldap/build-area/openldap2.3-2.4.10/tests/scripts/test035-meta: line 118: 22990 Segmentation fault $SLAPD -f $CONF3 -h $URI3 -d $LVL /$TIMING > $LOG3 2>&1 Are you seeing this as well, or is this somehow specific to Debian? (It doesn't seem like it should be related to libltdl in any way, and we don't have any other patches that touch the meta backend; and I saw this segfault both with the version of the patch I sent, and the one extracted from CVS.) Unfortunately, running these tests under gdb seems to be pretty awkward. :/ -- 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

(ITS#5584)
by abartlet＠samba.org 30 Jun '08

30 Jun '08

--=-GddVbqVLc61XV3X/kWQ/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've uploaded the patch to http://abartlet.net/memberof.patch --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-GddVbqVLc61XV3X/kWQ/ 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) iD8DBQBIaD8sz4A8Wyi0NrsRAjTZAJ4mQaT1xP5zbZG4Db0UM1BbzfmDYACePtXf MCnHmzCUac6KL/WbRX7aSxE= =2c9m -----END PGP SIGNATURE----- --=-GddVbqVLc61XV3X/kWQ/--

1 0

[PATCH] (ITS#5584)
by abartlet＠samba.org 30 Jun '08

30 Jun '08

--=-AN4G/3lLejTAf6KGBTk7 Content-Type: multipart/mixed; boundary="=-NvwPd4A703Oz/HjyG5IJ" --=-NvwPd4A703Oz/HjyG5IJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think I've figured out the right way to fix this, handling modify with 0 replacement elements just like a delete. See attached.=20 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-NvwPd4A703Oz/HjyG5IJ Content-Disposition: attachment; filename=memberof.patch Content-Type: text/x-patch; name=memberof.patch; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvbWVtYmVyb2YuYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC9yZXBvL09wZW5MREFQL3BrZy9sZGFwL3NlcnZlcnMvc2xhcGQvb3ZlcmxheXMvbWVt YmVyb2YuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTkNCmRpZmYgLXUgLXIxLjE5IG1lbWJl cm9mLmMNCi0tLSBzZXJ2ZXJzL3NsYXBkL292ZXJsYXlzL21lbWJlcm9mLmMJMTEgSmFuIDIwMDgg MDU6MDc6NDMgLTAwMDAJMS4xOQ0KKysrIHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvbWVtYmVyb2Yu YwkzMCBKdW4gMjAwOCAwMToyODoxMiAtMDAwMA0KQEAgLTg0MywxMSArODQzLDE3IEBADQogCQkJ CQlicmVhazsNCiAJCQ0KIAkJCQljYXNlIExEQVBfTU9EX1JFUExBQ0U6DQorCQkJCQkvKiBIYW5k bGUgdGhpcyBqdXN0IGxpa2UgYSBkZWxldGUgKHNlZSBhYm92ZSkgKi8NCisJCQkJCWlmICggbWwt PnNtbF9udmFsdWVzID09IE5VTEwgKSB7DQorCQkJCQkJbWxwID0gJm1sLT5zbWxfbmV4dDsNCisJ CQkJCQlicmVhazsNCisJCQkJCX0NCisNCiAJCQkJY2FzZSBMREFQX01PRF9BREQ6DQogCQkJCQkv KiBOT1RFOiByaWdodCBub3csIHRoZSBhdHRyaWJ1dGVUeXBlIHdlIHVzZQ0KIAkJCQkJICogZm9y IG1lbWJlciBtdXN0IGhhdmUgYSBub3JtYWxpemVkIHZhbHVlICovDQogCQkJCQlhc3NlcnQoIG1s LT5zbWxfbnZhbHVlcyAhPSBOVUxMICk7DQotCQkNCisNCiAJCQkJCWZvciAoIGkgPSAwOyAhQkVS X0JWSVNOVUxMKCAmbWwtPnNtbF9udmFsdWVzWyBpIF0gKTsgaSsrICkgew0KIAkJCQkJCWludAkJ cmM7DQogCQkJCQkJRW50cnkJCSplOw0KQEAgLTEzNjIsNyArMTM2OCw3IEBADQogCQkJCQliZXJf YnZhcnJheV9mcmVlX3goIHZhbHMsIG9wLT5vX3RtcG1lbWN0eCApOw0KIAkJCQl9DQogCQ0KLQkJ CQlpZiAoIG1sLT5zbWxfb3AgPT0gTERBUF9NT0RfREVMRVRFICkgew0KKwkJCQlpZiAoIG1sLT5z bWxfb3AgPT0gTERBUF9NT0RfREVMRVRFIHx8IG1sLT5zbWxfbnZhbHVlcyA9PSBOVUxMKSB7DQog CQkJCQlicmVhazsNCiAJCQkJfQ0KIAkJCQkvKiBmYWxsIHRocnUgKi8NCg== --=-NvwPd4A703Oz/HjyG5IJ-- --=-AN4G/3lLejTAf6KGBTk7 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) iD8DBQBIaDb3z4A8Wyi0NrsRAqd2AJ9pvfUj4jqL8HyFCfMh3zE47IfNwwCfTXOo /lvXcMQzo0XgFPVqe8W/h1c= =ssFN -----END PGP SIGNATURE----- --=-AN4G/3lLejTAf6KGBTk7--

1 0

(ITS#5584) memberof and modify: replace with 0 new entries
by abartlet＠samba.org 30 Jun '08

30 Jun '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) The memberOf plugin asserts if I attempt a modify like: (snippet from our python test script, using ldb, but I hope you get the idea) ldb.modify_ldif(""" dn: cn=ldaptestgroup2,cn=users,""" + self.base_dn + """ changetype: modify replace: member """) slapd: memberof.c:849: memberof_op_modify: Assertion `ml->sml_mod.sm_nvalues != ((void *)0)' failed. I think this just needs to be handled like the delete case, which our tests already show pass correctly.

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by hyc＠symas.com 30 Jun '08

30 Jun '08

Steve Langasek wrote: > Is the correct fix to add > this function to the ldap_extra_t struct, as in the attached patch? Pretty much. There are a few other functions that need to be added as well. All of them are provided in current CVS HEAD, just grab the relevant changes from there. -- -- 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#5395) Patch for test system
by abartlet＠samba.org 30 Jun '08

30 Jun '08

--=-9ss+Mrcd1KUNsVlI3qDP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-02-28 at 10:15 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-02-28 at 10:02 +0100, Pierangelo Masarati wrote: > >> abartlet(a)samba.org wrote: > >>> Full_Name: Andrew Bartlett > >>> Version: CVS HEAD > >>> OS: Fedora 8 > >>> URL: http://abartlet.net/patches/memberof-refint.patch > >>> Submission from: (NULL) (59.167.251.137) > >>> > >>> > >>> I've added a patch to show that refint and memberof work together. > >> Your patch seems to be missing some (trivial) modification to > >> tests/scripts/define.sh (the MEMBEROFREFINTOUT env var). >=20 > Thanks. In the meanwhile I figured it out (easy enough ;), and it seems > to work fine. I'm going to commit it, unless there's any IPR issue > (which I'd delegate to Howard or Kurt). Is there anything more that needs to be done here? If you need an IPR note, then please consider the modifications in this contribution licensed: Copyright 2008 Red Hat Inc. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-9ss+Mrcd1KUNsVlI3qDP 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) iD8DBQBIaCZTz4A8Wyi0NrsRApQeAJ9iWFzB1Fp+5nsSZqDZg6HsB6WPWgCeLAkl dObIvmosUhr/R2Ju2KqIEuM= =RGa/ -----END PGP SIGNATURE----- --=-9ss+Mrcd1KUNsVlI3qDP--

1 0

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

30 Jun '08

--BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 29, 2008 at 11:49:37AM -0700, Howard Chu wrote: > vorlon(a)debian.org wrote: >> This bug is marked as fixed in 2.4.8, but I still see the same problem in >> the test suite in 2.4.10. Trying to start slapd with back-meta gives: >> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf >> Is this a regression since 2.4.8? > Looks more like an incomplete fix. The functions in question haven't > changed since 2006. Since we're not using a hacked libltdl the problem > you're seeing doesn't show up here. I guess you should have tested this > sooner... Well, given that back_meta has been broken for an indeterminate period of time on systems whose libltdl doesn't use the insane RTLD_GLOBAL option :), the Debian userbase for that backend is roughly nonexistent which means verifying the fix was not a high priority (except that I would like to be able to turn on 'make test' during our builds). Is the correct fix to add this function to the ldap_extra_t struct, as in the attached patch? Cheers, -- 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 --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=no_backend_inter-linking Index: trunk/servers/slapd/back-ldap/back-ldap.h =================================================================== --- trunk.orig/servers/slapd/back-ldap/back-ldap.h +++ trunk/servers/slapd/back-ldap/back-ldap.h @@ -428,6 +428,8 @@ int (*proxy_authz_ctrl)( Operation *op, SlapReply *rs, struct berval *bound_ndn, int version, slap_idassert_t *si, LDAPControl *ctrl ); int (*controls_free)( Operation *op, SlapReply *rs, LDAPControl ***pctrls ); + int (*idassert_parse_cf)( const char *fname, int lineno, int argc, + char *argv[], slap_idassert_t *si ); } ldap_extra_t; LDAP_END_DECL Index: trunk/servers/slapd/back-meta/config.c =================================================================== --- trunk.orig/servers/slapd/back-meta/config.c +++ trunk/servers/slapd/back-meta/config.c @@ -1089,7 +1089,7 @@ } cargv[ 2 ] = binddn; - rc = slap_idassert_parse_cf( fname, lineno, cargc, cargv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert ); + rc = mi->mi_ldap_extra->idassert_parse_cf( fname, lineno, cargc, cargv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert ); if ( rc == 0 ) { struct berval bv; @@ -1159,7 +1159,7 @@ return 1; } - return slap_idassert_parse_cf( fname, lineno, argc, argv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert ); + return mi->mi_ldap_extra->idassert_parse_cf( fname, lineno, argc, argv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert ); /* idassert-authzFrom */ } else if ( strcasecmp( argv[ 0 ], "idassert-authzFrom" ) == 0 ) { Index: trunk/servers/slapd/back-ldap/init.c =================================================================== --- trunk.orig/servers/slapd/back-ldap/init.c +++ trunk/servers/slapd/back-ldap/init.c @@ -34,7 +34,8 @@ static const ldap_extra_t ldap_extra = { ldap_back_proxy_authz_ctrl, - ldap_back_controls_free + ldap_back_controls_free, + slap_idassert_parse_cf }; int --BI5RvnYi6R4T2M87--

1 0

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

29 Jun '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. I just compiled HEAD and slapadd added the ldif file as expected. But a second error occured, test failed with test001, but I will check this tomorrow, same as the dynlist patch. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

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

29 Jun '08

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. 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#5583) slapadd core dumps
by ando＠sys-net.it 29 Jun '08

29 Jun '08

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. 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#5583) slapadd core dumps
by dieter＠dkluenter.de 29 Jun '08

29 Jun '08

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. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by ando＠sys-net.it 29 Jun '08

29 Jun '08

amg1127(a)cefetrs.tche.br wrote: > I submitted a bug report in Ubuntu's Launchpad. The address is: > > https://bugs.launchpad.net/ubuntu/+source/openldap2.3/+bug/243337 > > The bug refers to 2.4.9, but it is reproducible in OpenLDAP 2.4.10 (I could > reproduce it, at least). 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

Re: (ITS#5583) slapadd core dumps
by ando＠sys-net.it 29 Jun '08

29 Jun '08

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? 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#5583) slapadd core dumps
by dieter＠dkluenter.de 29 Jun '08

29 Jun '08

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: 2.4.10 >> OS: openSUSE >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.217.87) [...] > > Where is the backtrace? Sorry, forgot it, #0 0x00007f07d3c6a5c5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f07d3c6a5c5 in raise () from /lib64/libc.so.6 #1 0x00007f07d3c6bbb3 in abort () from /lib64/libc.so.6 #2 0x00007f07d3c631e9 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004894a1 in slap_bv2ad (bv=0x7fffddbd3c30, ad=0x7f07d2bbc4f0, text=0x7fffddbd3c70) at ad.c:164 #4 0x00000000004893a3 in slap_str2ad (str=0x7f07d29bad62 "dgIdentity", ad=0x7f07d2bbc4f0, text=0x7fffddbd3c70) at ad.c:123 #5 0x00007f07d29ba0bc in dynlist_db_open (be=0x7fffddbd3ce0, cr=0x7fffddbd3f20) at dynlist.c:1560 #6 0x00000000004bae67 in over_db_open (be=0x8b9a90, cr=0x7fffddbd3f20) at backover.c:153 #7 0x0000000000449819 in backend_startup_one (be=0x8b9a90, cr=0x7fffddbd3f20) at backend.c:224 #8 0x0000000000449ad2 in backend_startup (be=0x8b9a90) at backend.c:267 #9 0x000000000047366f in slap_startup (be=0x8b9a90) at init.c:225 #10 0x00000000004c1853 in slap_tool_init (progname=0x55a728 "slapadd", tool=1, argc=10, argv=0x7fffddbe4a08) at slapcommon.c:725 #11 0x00000000004beff0 in slapadd (argc=10, argv=0x7fffddbe4a08) at slapadd.c:73 #12 0x00000000004190ef in main (argc=10, argv=0x7fffddbe4a08) at main.c:636 (gdb) -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by hyc＠symas.com 29 Jun '08

29 Jun '08

hyc(a)symas.com wrote: > vorlon(a)debian.org wrote: >> This bug is marked as fixed in 2.4.8, but I still see the same problem in >> the test suite in 2.4.10. Trying to start slapd with back-meta gives: >> >> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf >> >> Is this a regression since 2.4.8? > > Looks more like an incomplete fix. The functions in question haven't changed > since 2006. Since we're not using a hacked libltdl the problem you're seeing > doesn't show up here. I guess you should have tested this sooner... Additional patches for back-ldap/back-meta are now in 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#5355) back-meta calls back-ldap directly
by hyc＠symas.com 29 Jun '08

29 Jun '08

vorlon(a)debian.org wrote: > This bug is marked as fixed in 2.4.8, but I still see the same problem in > the test suite in 2.4.10. Trying to start slapd with back-meta gives: > > /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf > > Is this a regression since 2.4.8? Looks more like an incomplete fix. The functions in question haven't changed since 2006. Since we're not using a hacked libltdl the problem you're seeing doesn't show up here. I guess you should have tested this sooner... -- -- 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#5579) Interaction of ppolicy attributes
by hyc＠symas.com 29 Jun '08

29 Jun '08

Andrew Findlay wrote: > Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear > on the subject of that attribute: > > 5.3.3 pwdAccountLockedTime > The current implementation does allow > admins to set the value, which appears to be the only way to > lock/unlock an account without changing the password. The current implementation allows pretty much anybody to set the attribute. It's intended that it can only be set when using the Relax Constraints control. -- -- 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#5583) slapadd core dumps
by hyc＠symas.com 29 Jun '08

29 Jun '08

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.10 > OS: openSUSE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.217.87) > running slapadd with following options > > ./slapd -T add -d-1 -qwv -f /opt/openldap/etc/openldap/slapd.conf -F > /opt/openldap/etc/openldap/slapd.d -l /tmp/hdk-init.ldif > > slapadd startup: initiated. > backend_startup_one: starting "o=avci,c=de" > hdb_db_open: "o=avci,c=de" > hdb_db_open: database "o=avci,c=de": dbenv_open(/tmp/ldap). > slapd: ad.c:164: slap_bv2ad: Assertion `*ad == ((void *)0)' failed. > Abgebrochen (core dumped) > > output of gdb Where is the backtrace? -- -- 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#5583) slapadd core dumps
by dieter＠dkluenter.de 29 Jun '08

29 Jun '08

Full_Name: Dieter Kluenter Version: 2.4.10 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.217.87) Hello, processor: amd64 my configure flags: export CFLAGS="-g -march=athlon64" PREFIX="/opt/openldap" DATABASE="bdb" make distclean ; ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests ; running slapadd with following options ./slapd -T add -d-1 -qwv -f /opt/openldap/etc/openldap/slapd.conf -F /opt/openldap/etc/openldap/slapd.d -l /tmp/hdk-init.ldif slapadd startup: initiated. backend_startup_one: starting "o=avci,c=de" hdb_db_open: "o=avci,c=de" hdb_db_open: database "o=avci,c=de": dbenv_open(/tmp/ldap). slapd: ad.c:164: slap_bv2ad: Assertion `*ad == ((void *)0)' failed. Abgebrochen (core dumped) output of gdb (gdb) file /work/openldap/2.4.10/servers/slapd/.libs/slapd Reading symbols from /work/openldap/2.4.10/servers/slapd/.libs/slapd..done (gdb) core-file core warning: Can't read pathname for load map: Input/output error. Reading symbols from /opt/openldap/lib/libldap_r-2.4.so.2...done. Loaded symbols for /opt/openldap/lib/libldap_r-2.4.so.2 Reading symbols from /opt/openldap/lib/liblber-2.4.so.2...done. Loaded symbols for /opt/openldap/lib/liblber-2.4.so.2 Reading symbols from /usr/lib64/libltdl.so.3...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /usr/lib64/libdb-4.5.so...done. Loaded symbols for /usr/lib64/libdb-4.5.so Reading symbols from /usr/lib64/libodbc.so.1...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /usr/lib64/libssl.so.0.9.8...done. Loaded symbols for /usr/lib64/libssl.so.0.9.8 Reading symbols from /usr/lib64/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib64/libcrypto.so.0.9.8 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libz.so.1...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /usr/lib64/sasl2/liblogin.so...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libcrammd5.so...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /usr/lib64/sasl2/libplain.so...done. Loaded symbols for /usr/lib64/sasl2/libplain.so Reading symbols from /opt/openldap/libexec/openldap/dynlist-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/dynlist-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/accesslog-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/accesslog-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/ppolicy-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/ppolicy-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/syncprov-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/syncprov-2.4.so.2 Core was generated by `./slapd -Tadd -d-1 -qwv -f /opt/openldap/etc/openldap/slapd.conf -F /opt/openld' Program terminated with signal 6, Aborted. [New process 16951] #0 0x00007f39e0ea95c5 in raise () from /lib64/libc.so.6 (gdb) quit -Dieter

1 0

Re: (ITS#5579) Interaction of ppolicy attributes
by andrew.findlay＠skills-1st.co.uk 29 Jun '08

29 Jun '08

On Sat, Jun 28, 2008 at 07:21:44PM -0700, Howard Chu wrote: > >pwdFailureTime cannot be modified directly, so I think there is a case for > >clearing it when pwdAccountLockedTime is cleared explicitly. > > Technically, you're not supposed to be able to modify pwdAccountLockedTime > directly either. The current behavior is a temporary hack. The only > legitimate way to remove those attributes is by setting a new password. I'm > rejecting this ITS. Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear on the subject of that attribute: 5.3.3 pwdAccountLockedTime This attribute holds the time that the user's account was locked. A locked account means that the password may no longer be used to authenticate. A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account. One reading of that clause is that *setting* pwdAccountLockedTime to 000001010000Z is the way to lock an account by administrative action. There does not appear to be anything in the I-D that would cause the server to set that value itself. The current implementation does allow admins to set the value, which appears to be the only way to lock/unlock an account without changing the password. I would certainly prefer to have separate attributes for 'admin lock' and 'auto lock'. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs