- openldap-bugs - openldap.org

(ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠OpenLDAP.org 20 Jul '07

20 Jul '07

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Dear All, It's not clear or explained what AVA means in slapd-meta(5) and slapo-rwm(5) A user was asking in #ldap I presume it means "Attribute Value"? If so, I will add an explaination in each man page. Gavin.

1 0

(ITS#5053) openldap 2.3.36 crashing
by igbed＠wmin.ac.uk 20 Jul '07

20 Jul '07

Full_Name: Damian Igbe Version: 2.3.6 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.74.11.24) I have a delta-syncrepl replication working with password policy in place. Authentication to the master works fine but when a client tries to authenticate to the replica server, the following bug is encountered and the system crashes. bdb_modify: modify failed (20) send_ldap_result: conn=1 op=3 p=3 send_ldap_response: msgid=4 tag=97 err=49 ber_flush: 82 bytes to sd 17 slapd: ppolicy.c:847: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. Aborted Please help. Thanks Damian It also happens in other instances with errors such as: => key_change(DELETE,13) <= key_change 0 => key_change(ADD,13) <= key_change 0 => entry_encode(0x00000013): uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk bdb_modify: updated id=00000013 dn="uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk" send_ldap_result: conn=2 op=3 p=3 bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk") bdb_entry_get: rc=0 bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk") bdb_entry_get: rc=0 bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk") bdb_entry_get: rc=0 bdb_dn2entry("uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk") bdb_modify_internal: 0x00000013: uid=delaitt,ou=staff,ou=users,dc=cscs,dc=wmin,dc=ac,dc=uk bdb_modify: modify failed (20) send_ldap_result: conn=2 op=3 p=3 send_ldap_response: msgid=4 tag=97 err=49 ber_flush: 82 bytes to sd 17 slapd: ppolicy.c:847: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. Aborted

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 20 Jul '07

20 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23 > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. > findcsn_cb() says > /* We just want to know that at least one exists, so it's OK if > * we exceed the unchecked limit or size limit. > */ > > This looks like it can return a false positive if two or more other > entries which the filter would eliminate have the same hash as the > value syncprov searches for. I don't believe this can cause any problem though. CSN indexing doesn't use a hash the way other indices do; the CSN timestamp is converted to binary form and saved as a 40 bit integer. Index collisions will only occur for multiple changes that occurred within the same 1-second interval. The purpose of this search is to detect if a consumer's context CSN is stale, i.e., the provider no longer has any entries as old as the consumer's CSN. The fact that there is any index collision essentially proves that the CSN is not stale. > Also syncprov_findcsn() passes fc_limits uninitialized outside of the > .lms_s_unchecked field to slapd. Valgrind complains in test018 about > .lms_s_pr_hide in back-bdb/search.c:bdb_search(). Tested in HEAD. Fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5052) slapadd -q can create invalid index
by hyc＠OpenLDAP.org 20 Jul '07

20 Jul '07

Full_Name: Howard Chu Version: 2.3.x OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.95.127.34) Submitted by: hyc On a database with a zero-length suffix, slapadd and slapindex in quick mode can erroneously generate index records for the context entry, which has an entry ID of zero. The entry ID zero is normally invalid in an index, and is always filtered out of index operations, but the quick mode indexer didn't exclude it as it should.

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com 20 Jul '07

20 Jul '07

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: 19/07/07 HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Dear All, >> >> Is slapd not started and giving below expected? >> >> >> ================ >> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" >> scope=subordinate >> filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": >> unable to find entry >> backend_startup_one: bi_db_open failed! (1) >> slapd shutdown: initiated >> ================ >> >> Using a config like: >> >> ================ >> include /usr/local/etc/openldap/schema/core.schema >> >> pidfile /usr/local/var/run/slapd.pid >> argsfile /usr/local/var/run/slapd.args >> >> # Load dynamic backend modules: >> modulepath /usr/local/libexec/openldap >> moduleload back_bdb.la >> moduleload back_ldap.la >> moduleload back_monitor.la >> moduleload translucent.la >> >> database bdb >> directory /usr/local/var/openldap-data >> cachesize 10000 >> suffix "dc=suretecsystems,dc=com" >> >> rootdn "cn=admin,dc=suretecsystems,dc=com" >> rootpw {SSHA}blah >> >> index default eq >> index objectClass,uid,dc,o,ou >> >> overlay translucent >> uri ldap://x.x.x.x:389 >> idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com" >> credentials=blah >> >> database config >> rootdn "cn=config" >> rootpw {SSHA}blah >> >> database monitor >> ================ >> >> >> If I remove "database monitor", all is obviously well. >> >> However, if I put "database monitor" before "database bdb", slapd starts >> fine, >> but complains with: >> >> ================ >> monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" >> scope=subordinate >> filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": >> unable to find entry >> slapd starting >> ================ > > Pretty sure your monitor database needs a rootdn now for this to work. > Ok. What can the rootdn do on the monitor database then? Write to anything? I can update the "Monitoring" section with this info then ;-) Gavin.

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by hyc＠symas.com 19 Jul '07

19 Jul '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: 19/07/07 HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Dear All, > > Is slapd not started and giving below expected? > > > ================ > monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" > scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": > unable to find entry > backend_startup_one: bi_db_open failed! (1) > slapd shutdown: initiated > ================ > > Using a config like: > > ================ > include /usr/local/etc/openldap/schema/core.schema > > pidfile /usr/local/var/run/slapd.pid > argsfile /usr/local/var/run/slapd.args > > # Load dynamic backend modules: > modulepath /usr/local/libexec/openldap > moduleload back_bdb.la > moduleload back_ldap.la > moduleload back_monitor.la > moduleload translucent.la > > database bdb > directory /usr/local/var/openldap-data > cachesize 10000 > suffix "dc=suretecsystems,dc=com" > > rootdn "cn=admin,dc=suretecsystems,dc=com" > rootpw {SSHA}blah > > index default eq > index objectClass,uid,dc,o,ou > > overlay translucent > uri ldap://x.x.x.x:389 > idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials=blah > > database config > rootdn "cn=config" > rootpw {SSHA}blah > > database monitor > ================ > > > If I remove "database monitor", all is obviously well. > > However, if I put "database monitor" before "database bdb", slapd starts fine, > but complains with: > > ================ > monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" > scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": > unable to find entry > slapd starting > ================ Pretty sure your monitor database needs a rootdn now for this to work. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠suretecsystems.com 19 Jul '07

19 Jul '07

<quote who="dhawes(a)vt.edu"> > On Thursday 19 July 2007 05:35, Gavin Henry wrote: >> > An updated version of addpartial is available at: >> > >> > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz >> > >> > This version includes changes to work with OpenLDAP 2.3 as well as >> > ensuring syncrepl works properly. >> > >> > david hawes >> >> If this hasn't been added to 2.4/HEAD yet, would you consider updating >> it >> for inclusion in 2.4 contrib? > > Absolutely, I've been meaning to test with 2.4. I'll bump it to the top > of > the list. Can you make sure that is dynamically configurable via cn=config like everything else in 2.4. Thanks. > > dave > > >

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by dhawes＠vt.edu 19 Jul '07

19 Jul '07

On Thursday 19 July 2007 05:35, Gavin Henry wrote: > > An updated version of addpartial is available at: > > > > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz > > > > This version includes changes to work with OpenLDAP 2.3 as well as > > ensuring syncrepl works properly. > > > > david hawes > > If this hasn't been added to 2.4/HEAD yet, would you consider updating it > for inclusion in 2.4 contrib? Absolutely, I've been meaning to test with 2.4. I'll bump it to the top of the list. dave

1 0

(ITS#5051) Translucent overlay and back-monitor
by ghenry＠OpenLDAP.org 19 Jul '07

19 Jul '07

Full_Name: Gavin Henry Version: 19/07/07 HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear All, Is slapd not started and giving below expected? ================ monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": unable to find entry backend_startup_one: bi_db_open failed! (1) slapd shutdown: initiated ================ Using a config like: ================ include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload translucent.la database bdb directory /usr/local/var/openldap-data cachesize 10000 suffix "dc=suretecsystems,dc=com" rootdn "cn=admin,dc=suretecsystems,dc=com" rootpw {SSHA}blah index default eq index objectClass,uid,dc,o,ou overlay translucent uri ldap://x.x.x.x:389 idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials=blah database config rootdn "cn=config" rootpw {SSHA}blah database monitor ================ If I remove "database monitor", all is obviously well. However, if I put "database monitor" before "database bdb", slapd starts fine, but complains with: ================ monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": unable to find entry slapd starting ================ Gavin.

1 0

(ITS#5050) array bounds violation in test045-syncreplication-proxied
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard syncprov + back-ldap, and presumably + back-meta if that were used, give an array bounds violation in test045-syncreplication-proxied: syncprov_db_open() uses connection_fake_init(), which sets op->o_tag=0. It passes op to back-ldap. ldap_back_op_result() assumes op is a known LDAP request: It calls slap_req2op() and gets SLAP_OP_LAST (for unknown tag). That is used as an index into ldapinfo_t.li_timeout[], which has size SLAP_OP_LAST. back-meta/bind.c does the same in meta_back_bind_op_result() and meta_back_op_result(). HEAD backtrace, from an assert(0) I put in slap_req2op(): #3 0x003d8d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0809ac0e in slap_req2op (tag=0) at operation.c:203 #5 0x0816dba8 in ldap_back_op_result (lc=0x83a12f8, op=0xbfffe948, rs=0xbfffe70c, msgid=1, timeout=-1, sendok=20) at bind.c:1582 #6 0x0816d727 in ldap_back_dobind_int (lcp=0xbfffe760, op=0xbfffe948, rs=0xbfffe70c, sendok=LDAP_BACK_GETCONN, retries=0, dolock=1) at bind.c:1411 #7 0x0816d814 in ldap_back_dobind (lcp=0xbfffe760, op=0xbfffe948, rs=0xbfffe70c, sendok=LDAP_BACK_DONTSEND) at bind.c:1440 #8 0x0812921a in ldap_back_entry_get (op=0xbfffe948, ndn=0x833b2a8, oc=0x0, at=0x82ec610, rw=0, ent=0xbfffe944) at search.c:790 #9 0x080f7a55 in overlay_entry_get_ov (op=0xbfffe948, dn=0x833b2a8, oc=0x0, ad=0x82ec610, rw=0, e=0xbfffe944, on=0x0) at backover.c:365 #10 0x081bd9da in syncprov_db_open (be=0x833a8a0) at syncprov.c:2550 #11 0x080f70b2 in over_db_func (be=0x833a8a0, which=db_open) at backover.c:61 #12 0x080f74c9 in over_db_open (be=0x833a8a0) at backover.c:174 #13 0x08092515 in backend_startup_one (be=0x833a8a0) at backend.c:212 #14 0x080929a2 in backend_startup (be=0x833a8a0) at backend.c:303 #15 0x080b9a94 in slap_startup (be=0x0) at init.c:243 #16 0x0806719d in main (argc=8, argv=0xbfffef14) at main.c:919

1 0

(ITS#5049) uninitialized Connection in syncprov
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard syncprov_db_close() does not initialize 'conn' before passing it to connection_fake_init(). (That function is a bit misnamed - the passed connection must be initialized, but not the passed operation.) Fixing in HEAD. Is RE23 frozen now?

1 0

(ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. findcsn_cb() says /* We just want to know that at least one exists, so it's OK if * we exceed the unchecked limit or size limit. */ This looks like it can return a false positive if two or more other entries which the filter would eliminate have the same hash as the value syncprov searches for. Also syncprov_findcsn() passes fc_limits uninitialized outside of the .lms_s_unchecked field to slapd. Valgrind complains in test018 about .lms_s_pr_hide in back-bdb/search.c:bdb_search(). Tested in HEAD.

1 0

(ITS#5046) ITS auto-reply and copyright date
by ghenry＠OpenLDAP.org 14 Jul '07

14 Jul '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry ITS auto-reply needs updating: "Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved."

1 0

(ITS#5045) collect.c and Dynamic Config
by ghenry＠OpenLDAP.org 14 Jul '07

14 Jul '07

Full_Name: Gavin Henry Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, I think if collect.c is still to be used as demonstration of overlay code in 2.4, then it needs some of the usual ConfigDriver/ConfigTable/ConfigOCs stuff. Would be useful for new contributors etc. Saying that, there is no harm in others reviewing existing overlays. Just some thoughts. Gavin.

1 0

Re: (ITS#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by h.b.furuseth＠usit.uio.no 13 Jul '07

13 Jul '07

Do you use "database ldbm" in slapd.conf? The LDAP Compare operation can make it crash that way. (Since OpenLDAP 2.3.16; back-ldbm/compare.c rev 1.53.) I've committed a fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/Attic/comp… BDB more reliable. LDBM has been removed in OpenLDAP 2.4. -- Regards, Hallvard

1 0

Re: (ITS#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by hyc＠symas.com 13 Jul '07

13 Jul '07

alexander.kasper(a)ruhr-uni-bochum.de wrote: > Full_Name: Alexander Kasper > Version: @(#) $OpenLDAP: slapd 2.3.36 (Jul 6 2007 14:15:37) $ > OS: Linux version 2.6.18-xendomU (root@localhost) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (134.147.48.236) > > > I cannot clearly reproduce the error/assert > > slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= > 0' failed > > since the slapd dies randomly. I'm runnig it on a virtual xen userDomain in > 64Bit mode. > > plz tell me, which debug-level would be fine, since -d 65535 produce 10MB output > for one search, and as i said slapd dies randomly. There are reports that Xen does not properly support mutexes. As such, it cannot be used to run slapd. http://www.openldap.org/lists/openldap-software/200603/msg00207.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by alexander.kasper＠ruhr-uni-bochum.de 13 Jul '07

13 Jul '07

Full_Name: Alexander Kasper Version: @(#) $OpenLDAP: slapd 2.3.36 (Jul 6 2007 14:15:37) $ OS: Linux version 2.6.18-xendomU (root@localhost) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.147.48.236) I cannot clearly reproduce the error/assert slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed since the slapd dies randomly. I'm runnig it on a virtual xen userDomain in 64Bit mode. plz tell me, which debug-level would be fine, since -d 65535 produce 10MB output for one search, and as i said slapd dies randomly. greets Alex

1 0

Re: (ITS#5028) incomplete slapcat docs
by ghenry＠suretecsystems.com 13 Jul '07

13 Jul '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="h.b.furuseth(a)usit.uio.no"> >> hyc(a)symas.com writes: >>> steve(a)stevenwills.com wrote: >>>> The slapcat man page says in the Limitations section: >>>> >>>> In general, your slapd(8) should not be running (at least, not >>>> in >>>> read-write mode) when you do this to ensure consistency of the >>>> database. >>>> (...) >>> Given that back-ldbm has been deleted for 2.4, I guess we can just >>> delete this sentence. >> >> It could produce garbage data with back-ldif, and with some foreign >> database module. I think it should say it's safe with bdb (and null). >> Could copy it to the slapd-bdb(5) too. (I don't suggest to make >> slapcat(8) refer the user to that, since there is only one example >> anyway.) > > Obviously hdb too. Would it produce garbage on 2.4? Do we want to do anything with this for .37? > >> >> -- >> Regards, >> Hallvard >> >> >> > > >

1 0

Re: (ITS#5043) double free in slapo-rwm when rewriting search filters
by ando＠sys-net.it 12 Jul '07

12 Jul '07

Fixed in HEAD/re23 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5043) double free in slapo-rwm when rewriting search filters
by ando＠sys-net.it 12 Jul '07

12 Jul '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See subject; a fix is coming.

1 0

(ITS#5042) Contribution: Active Directory Password Cache
by s.hetze＠linux-ag.de 12 Jul '07

12 Jul '07

Full_Name: Sebastian Hetze Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/Sebastian-Hetze-pgk-070712.tgz Submission from: (NULL) (212.21.78.130) Hi *, in your FTP incoming you find a piece of software that we would like to contribute to the slapd-modules collection. We hope you find it useful and we would very much like to receive feedback about useability, ideas for improvements and (in the very unlikely case of occurance ;-) bugreports and fixes. Best regards Sebastian Hetze ------------------------------------------------------------------------------------ Active Directory Password Cache =============================== Active Directory does not provide any means to read user credentials on any public API. It is possible, to install additional libraries as password sniffer to catch and forward cleartext passwords on changes. In case you cannot or simply dont want to install such libraries, the Active Directory Password Cache overlay is your option. The Active Directory Password Cache overlay allows to mirror user account credentials without any modification on the AD server. It only takes one occasional simple bind authentication against the OpenLDAP server. If the credential has not been mirrored yet, the overlay uses the krbPrincipalName and the password provided by the user to perform a Kerberos init against the Active Directory. A successful Kerberos init guarantees a correct password for this principal, and therefor the bind finally succeeds. Within this overlay operation, the password gets encrypted with the default OpenLDAP hash alorithm and stored as userPassword attribute. There is an option to update the sambaNTPassword also (using code borrowed from Howard Chu's smbk5pwd overlay). All following simple bind authentications will first try these cached credentials, making the OpenLDAP server independent from AD. In case the user changes its password on the Active Directory server, the old password stays valid in OpenLDAP until the user first presents the new password for an simple bind. Within this bind operation, the overlay performs another Kerberos init and updates the cached credentials in OpenLDAP.

1 0

Can't delete user using DN (Error 32) or add user using DN (Error 68)
by Chase Putans 12 Jul '07

12 Jul '07

I am not sure this is actually a bug, but I figure I will submit this anyways. We had a power outage some time ago, and the bdb files got corrupted. I ran a slapindex after shutting down and it seems one entry is now missing. I have tried re-adding it, but when I do that, I get an error that this entry already exists. When I try and delete with that particular DN, it says that it does not exist. This is openldap 2.2.29-1 installed via Yum on FC4. [root@PDC]# ldapadd -D "<ROOT DN>" -x -W -f entrymods Enter LDAP Password: adding new entry "uid=<username>,ou=People,dc=3sixtygroup,dc=com" ldap_add: Already exists (68) [root@PDC]# ldapdelete -D "<ROOT DN>" -x -W -f entrymods2 Enter LDAP Password: Delete Result: No such object (32) Matched DN: ou=People,dc=3sixtygroup,dc=com Contents of entrymods is as follows: dn: uid=<username>,ou=People,dc=3sixtygroup,dc=com uid: <username> objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: sambaSamAccount cn: <username> sn: <username> givenName: <username> uidNumber: <uidnumber> gidNumber: <gidnumber> homeDirectory: /home/<username> loginShell: /bin/bash gecos: System User sambaLogonTime: 0 sambaLogoffTime: 2147483647 displayName: <username> sambaSID: <> sambaPrimaryGroupSID: <> sambaLogonScript: scripts\logon.bat sambaHomePath: \\PDC\<username> sambaHomeDrive: H: sambaAcctFlags: [U] Contents of entrymods2: uid=<username>,ou=People,dc=3sixtygroup,dc=com changetype: delete Any help would be much appreciated. Thanks. -- Chase Putans Systems Administrator / Programmer / Web Developer / Support The 3Sixty Group http://3sixtygroup.com Ph: 800-440-3967 Fax: 800-453-9683

2 4

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by hyc＠symas.com 12 Jul '07

12 Jul '07

hyc(a)symas.com wrote: > Thinking back, I think the idea here is that you might have a set of nested > databases connected by referral entries. E.g., > > database ldbm > suffix dc=sub,dc=example,dc=com > > database ldbm > suffix dc=example,dc=com > > If you had an referral entry in the superior DB that pointed to the sub > database, you would need the manageDSAit control to be able to operate on the > referral entry. > > None of this really makes sense post 2.1 since subordinate/glue makes it > superfluous. > I'm going to rip all of that out. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by rra＠stanford.edu 12 Jul '07

12 Jul '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > I believe the circumstances that caused this ITS to be opened have > changed, is that correct? Yes, the underlying toolchain bug is now fixed and the ITS can be closed. Thanks for the check! -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by quanah＠zimbra.com 12 Jul '07

12 Jul '07

Russ, I believe the circumstances that caused this ITS to be opened have changed, is that correct? --Quanah --On May 24, 2007 2:37:49 AM +0000 kurt(a)OpenLDAP.org wrote: > > On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote: >> libtool does not pass -pthread through > > Our libtool does. But gcc might not do the right thing with it. > In that case, it's a gcc bug which should be reported to the gcc > folks. > > I believe using -lpthread over -pthread will cause more problems > than its worth. That is, the problems caused by the missing link > on some platforms is not nearly as bad as the caused by using > -lc instead of -lc_r on other platforms. > > -- Kurt > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Solaris Client
by daniel perez del campo 10 Jul '07

10 Jul '07

Hi, I have configurated openLdap in Debian, and it works well with Linux clients. But I want to authenticate a Solaris client against the Ldap server. I don't know how to do this. Could someone tell me what have I have to do?? Or some guide? I have looked for information in Google and I don't find anything clear. Thanks a lot, and sorry for my english. Dani _________________________________________________________________ Grandes éxitos, superhéroes, imitaciones, cine y TV... http://es.msn.kiwee.com/ Lo mejor para tu móvil.

3 2

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 07 Jul '07

07 Jul '07

Gavin Henry <ghenry(a)suretecsystems.com> wrote: > It would be best to move this dicussion to openldap-devel(a)openldap.org now. Let's go... Summarry: I've added a new feature to slapo-constraint for constraining a value attribute the the existing values of another attribute. The idea is that you can have a catalog of allowed values (eg: for titles: Mr, Mrs, Miss) and constraint an attribute to these values Before working further on this patch (style, dod), I'd like some feeback on: 1) the way it's implemented: is there rought bugs, or is the logic fine? 2) configuration syntax: do we keep this one or do we swtich to something else? Could someone comment on the patch? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by ghenry＠suretecsystems.com 07 Jul '07

07 Jul '07

<quote who="manu(a)netbsd.org"> >> Did you see http://www.openldap.org/devel/contributing.html > > Right, but before moving foward with appropriate style, documentation, > and so on, I'd like to have some input about the config syntax and the > way it's implemented. I had no feedback at all yet on that. It would be best to move this dicussion to openldap-devel(a)openldap.org now. Try raising a question again there. Gavin. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > manu(a)netbsd.org > > >

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 07 Jul '07

07 Jul '07

> Did you see http://www.openldap.org/devel/contributing.html Right, but before moving foward with appropriate style, documentation, and so on, I'd like to have some input about the config syntax and the way it's implemented. I had no feedback at all yet on that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

start_tls while chasing referrals
by Bin Lu 06 Jul '07

06 Jul '07

Hi, I noticed the following bug fix in referral chasing http://bugzilla.padl.com/show_bug.cgi?id=210 This seems only to take care of the usage with pam ldap lib. What if the ldap connection is not from the pam lib? In that case, when an ldap operation reaches a referral point, would the new connection be consistent if the original connection is using TLS(and the referral url is not using ldaps)? Our test shows it is not. Please advice, if that is also a security hole? Regards, Wenwu

2 1

Re: (ITS#5041) ldapwhoami takes unused "user" arg
by ando＠sys-net.it 06 Jul '07

06 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > ldapwhoami and "ldapexop whoami" take an unused command line > argument "user". The code has been there since rev 1.1. could be a leftover or something like that? In any case, just trimmed. 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5041) ldapwhoami takes unused "user" arg
by h.b.furuseth＠usit.uio.no 05 Jul '07

05 Jul '07

Full_Name: Hallvard B Furuseth Version: 1.1->current OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldapwhoami and "ldapexop whoami" take an unused command line argument "user". The code has been there since rev 1.1.

1 0

(ITS#5040) modifyTimestamp being updated on login (bind) failure
by dan.cushing＠netideasinc.com 05 Jul '07

05 Jul '07

Full_Name: Dan Cushing Version: 2.3.36 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.76.187.82) When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user entry is updated if the user attempts to login (bind) with an incorrect password. This is happening because the password lockout feature is enabled and the operational attribute 'pwdFailureTime' is being updated. It seems like this results in a misleading modifyTimestamp. Is it intended that the modifyTimestamp attribute be updated when operational attributes are updated? To reproduce the issue, compile with the ppolicy overlay and enable password lockout. Below I've included the entries for a minimal policy.ldif file that I tested with. Then perform the following actions. 1) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "modifyTimestamp: 20070705142825Z" 2) As testuser execute the following search: ldapsearch -x -D "uid=testuser,o=testorg.com" -w correctPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "modifyTimestamp: 20070705142825Z" 3) As testuser execute the following search (note the INCORRECT password): ldapsearch -x -D "uid=testuser,o=testorg.com" -w WRONGPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "ldap_bind: Invalid credentials (49)" 4) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "pwdFailureTime: 20070705144735Z modifyTimestamp: 20070705144735Z". Note that the 'pwdFailureTime attribute has been created and the 'modifyTimestamp' attribute has been updated to the time that the bind attempt failed. Contents of my Standard policy file are ... dn: cn=Standard, ou=Policies, o=testorg.com pwdLockout: TRUE pwdMaxFailure: 3 objectClass: top objectClass: device objectClass: pwdPolicy pwdFailureCountInterval: 120 pwdLockoutDuration: 3600 cn: Standard pwdAttribute: userPassword

1 0

Re: (ITS#5035) Warning patrol
by ando＠sys-net.it 05 Jul '07

05 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > #1. slapd/frontend.c:frontend_init() has the statement > if ( slap_known_controls ) > which is always true since slap_known_controls is an array. > Maybe it should be if ( slap_known_controls[0] )? > > Except... controls.c says slap_known_controls[0] == NULL, which is > not true - at least not at the time of the if-test above. What's > that about? Probably a leftover of a time when slap_known_controls was a pointer > #2. The return value from op->o_callback->sc_cleanup() is never > used. Should it be? I noticed because the pcache_op_cleanup() > function does not return anything. What should it return? two possibilities: a) ignore it: cleanup could occur too late, when response has already been returned to client; in this case a return code is there only because of the standard API b) handle it: cleanup return code could be usefully returned to caller if (a), then the return code can be safely ignored > #3. RE23 struct sync_cookie.rid and struct syncinfo_s.si_rid are > 'long', but are printed as 'int'. Could change the formats, but - > any reason not to instead change their types to 'int' as in HEAD? > I haven't looked at the HEAD syncrepl changes, so I don't know > what other issues might be involved. There should be no impact, since they're both limited to 0,999 > #4. bconfig.c: Integer overflow in (1 << (sizeof(int)*8 - 1)) in > slap_loglevel_get(). If anything else have been trusting signed > integer overflow to resemble unsigned integers, it's time to cease > that. The behaviour is undefined, and compilers make use of this > fact to optimize. > > The loglevel functions are confused about types anyway. They > collect masks in slap_mask_t, but the API uses an int for the > masks. Agree > Either the API should use slap_mask_t Agree > or masks should be > stored in (unsigned) ints. Not for 2.3, I think. Agree 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5036) test034-translucent fails on HEAD
by ghenry＠suretecsystems.com 05 Jul '07

05 Jul '07

<quote who="hyc(a)symas.com"> > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Full_Name: Hallvard B Furuseth >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 >>> Submission from: (NULL) (129.240.202.105) >>> Submitted by: hallvard >>> >>> >>> test034-translucent fails. Output: >> >>> Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd >>> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers >>> --disable-backends --enable-bdb --enable-ldap --enable-relay >>> --enable-null >>> --enable-meta --enable-overlays CC=gcc-4.2.0 >>> 'CPPFLAGS=-DLDAP_DEPRECATED >>> -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' >> >> Strange. I got the same result with those options. But with this >> configuration, >> the test works fine: >> >> --enable-modules --enable-backends=mod --enable-overlays=mod >> --enable-slapi >> --disable-sql >> >> The test also fails with your options, but without any of the CPPFLAGS >> set. >> > Duh... In your test back-monitor is missing. Usually the monitor would be > olcDatabase={1} in the config, so the bdb instance would be > olcDatabase={2}, > and that's the name that's coded into the script. > I'm trying to get push based Syncrepl going for the docs and this test is also failing for me with HEAD updated 2 hrs ago. My options: env CC=gcc CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include" \ LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" \ LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.2/lib" ./configure \ --prefix=/opt/suretec/ldap --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ --disable-sql --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers Gavin.

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 04 Jul '07

04 Jul '07

Buchan Milne writes: >> libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. >> "cc -ldb-4.3" uses /lib64/libdb-4.3.so. > > Only if the 32bit package is installed (which unfortunately happens by > default e.g. with 'yum install db4-devel' you get both i386 and > x86_64). OK. A libtool bug triggered by a RedHat irritant (but still non-bug). > On RHEL5: > # rpm -e db4-devel-4.3.29-9.fc6.i386 > works around this. Thanks. The system folks here say we need some of the 32-bit stuff, though:-( I wrote: > Is OpenLDAP using a patched libtool? One of the differences is that > ltmain.sh contains VERSION=1.5.22-OpenLDAP, while I get VERSION=1.5.22. Er, yes, it seems so. I was even one of the sinners, though those patches are gone now. It doesn't mention that it is a generated file. -- Regards, Hallvard

1 0

(ITS#5039) Support config for start_tls in ldap.conf
by ahasenack＠terra.com.br 04 Jul '07

04 Jul '07

Full_Name: Andreas Hasenack Version: 2.3.36 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.98) This is an enhancement request. It would be helpfull if there were some configuration option for /etc/openldap/ldap.conf to mimic the -ZZ command line, that is, behave as if the user added -ZZ to it. Perhaps something along the lines of the sasl secprops, or the server's "security" keyword. My scenario is that it doesn't matter if I block clear text communication with the ldap server via ACL or security: if the client initiates a simple bind operation in clear text, the password is exposed even if the server rejects the operation. The point here is to avoid accidents, like leaving out the -ZZ option when doing command line operations. It would be like an initial default. It also saves typing, of course ;) I can easily workaround this with shell aliases, or wrapper scripts, of course. That's why this is an enhancement request.

1 0

Re: (ITS#5037) slapd-bdb filterindex.c: out of order if statement in filter
by quanah＠zimbra.com 04 Jul '07

04 Jul '07

--On Wednesday, July 04, 2007 1:30 AM +0000 openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** nm, the function call sets db. But still the if needs to be re-ordered. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5037) slapd-bdb filterindex.c: out of order if statement in filter
by quanah＠zimbra.com 04 Jul '07

04 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.36/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) back-bdb's filterindex.c has code like the following throughout: if( rc != LDAP_SUCCESS ) { Debug( LDAP_DEBUG_TRACE, "<= bdb_presence_candidates: (%s) index_param " "returned=%d\n", desc->ad_cname.bv_val, rc, 0 ); return 0; } if( db == NULL ) { /* not indexed */ Debug( LDAP_DEBUG_TRACE, "<= bdb_presence_candidates: (%s) not indexed\n", desc->ad_cname.bv_val, 0, 0 ); return 0; } and if( rc != LDAP_SUCCESS ) { Debug( LDAP_DEBUG_ANY, "<= bdb_equality_candidates: (%s) " "index_param failed (%d)\n", ava->aa_desc->ad_cname.bv_val, rc, 0 ); return 0; } if ( db == NULL ) { Debug( LDAP_DEBUG_ANY, "<= bdb_equality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; } However, if "db" is NULL, bdb_index_param will return LDAP_INAPPROPRIATE_MATCH, which does not equal LDAP_SUCCESS, meaning that the "db == NULL" if statement is never reached. It appears the db==NULL check should be done first. Possibly, the db==NULL check should be moved before the bdb_index_param call, I can't imagine there's much point in calling the function if it isn't indexed, and the only result is to log an error and return? --Quanah

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 03 Jul '07

03 Jul '07

Philip Guenther wrote: > On Mon, 30 Apr 2007, Howard Chu wrote: >> guenther+ldapdev(a)sendmail.com wrote: > ... >>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>> section 3.1.3) and will terminate the connection if they don't match >>> - 'try' is the same as 'demand' and 'hard' >> Not quite. With both "allow" and "try" it's OK if the server provides no >> certificate. > > That's true of 'demand' and 'hard' as well. The only difference between > 'try' and 'demand' in the code is that the latter passes > SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that > flag has NO EFFECT on SSL clients. This is documented on the > SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source > for it. > > If you don't believe me, I suggest you try configuring your server to > accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) > and give ldapsearch a whirl with > LDAPTLS_REQCERT=hard > LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA > > in your environment. That's what I did. When this text was written, there was no support for anonymous cipher suites. So the meaning of the text is: assuming a cipher suite that actually uses certificates, the client would proceed even if the server didn't provide a cert. It's entirely possible that this circumstance has been overcome by other developments. Most likely this hasn't been a valid use case for quite a long time. But it has nothing to do with Diffie-Hellman key exchanges... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 >> Submission from: (NULL) (129.240.202.105) >> Submitted by: hallvard >> >> >> test034-translucent fails. Output: > >> Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd >> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers >> --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null >> --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED >> -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' > > Strange. I got the same result with those options. But with this configuration, > the test works fine: > > --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi > --disable-sql > > The test also fails with your options, but without any of the CPPFLAGS set. > Duh... In your test back-monitor is missing. Usually the monitor would be olcDatabase={1} in the config, so the bdb instance would be olcDatabase={2}, and that's the name that's coded into the script. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test034-translucent fails. Output: > Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd > --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers > --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null > --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED > -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' Strange. I got the same result with those options. But with this configuration, the test works fine: --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi --disable-sql The test also fails with your options, but without any of the CPPFLAGS set. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5036) test034-translucent fails on HEAD
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test034-translucent fails. Output: $ ./run test034 Cleaning up test run directory leftover from previous run. Running ./scripts/test034-translucent... running defines.sh == thr_debug: Leaked 1 mutexes. == == thr_debug: Leaked 1 mutexes. == Running slapadd to build remote slapd database... == thr_debug: Leaked 6 mutexes. == Starting remote slapd on TCP/IP port 9011... Starting local slapd on TCP/IP port 9012... Testing slapd Translucent Proxy operations... Testing search: no remote data defined... Populating remote database... Testing search: remote database via local slapd... Testing add: prohibited local record... Testing add: valid local record, no_glue... Testing modrdn: valid local record, no_glue... Dynamically configuring local slapd without translucent_no_glue... modifying entry "olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config" ldap_modify: No such object (32) matched DN: cn=config ldapmodify of dynamic config failed (32) Enclosing logs from testrun directory. Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG'

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

Cut&paste errors... h.b.furuseth(a)usit.uio.no writes: > I forgot keys must be pointers. s/keys/thread-specific data/ > So ldap_pvt_thread_unique_id() would > malloc it if not already set, and fill in with the incremented pointers. s/incremented pointers/incremented counter/.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 03 Jul '07

03 Jul '07

h.b.furuseth(a)usit.uio.no writes: > Oh, and make max_pending 0 or greater, since > negative numbers confuse pool_query(). I'll do that one, since it fixes a bug and removes no functionality. (And I forgot a few others, e.g. swapkey() function I mentioned earlier, but guess I'd prefer to stick to single-file changes for now.) >> OK, suppose we use a pthread thread-specific key here. What are you >> proposing for the unique value? > > An unsigned long counter, maintained by libldap_r. If the thread-local > variable is zero (thus uninitialized), increment the counter and grab > its value. I forgot keys must be pointers. So ldap_pvt_thread_unique_id() would malloc it if not already set, and fill in with the incremented pointers. For pool threads that'd not be necessary: The thread-local could hold the pointer to the thread context, and the thread could have unique ID (thread_context - thread_keys + 1). The "+1" in case others think thread ID 0 means no thread, like tpool thought recently. The comp.programming.threads question took off in an unexpected direction, so I'm not holding my breath about answers to DCE threads and the like. OS/390 threads - a quick google does seem to indicate that OS/400 threads (and thus presumably OS/390) resemble DCE threads. At least they have a pthread_getunique_np() function, and possibly "field1-3". -- Regards, Hallvard

1 0

Re: (ITS#5027) loglevel if none specified
by ando＠sys-net.it 03 Jul '07

03 Jul '07

steve(a)stevenwills.com wrote: > a great deal of logging is done. This seems inconsistent. Either the docs or the > code are incorrect. Which is right? The man page is incorrect. By default, loglevel is stats. Fixed in HEAD/re23. Thanks, 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by bgmilne＠staff.telkomsa.net 02 Jul '07

02 Jul '07

--nextPart2297483.Rso0kROPCI Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday, 30 June 2007, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, HEAD > OS: RedHat Linux/x86_64 > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. > "cc -ldb-4.3" uses /lib64/libdb-4.3.so. Only if the 32bit package is installed (which unfortunately happens by defa= ult=20 e.g. with 'yum install db4-devel' you get both i386 and x86_64). On RHEL5: # rpm -e db4-devel-4.3.29-9.fc6.i386 works around this. Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) http://en.wikipedia.org/wiki/List_of_Internet_slang_phrases --nextPart2297483.Rso0kROPCI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGiQdQrJK6UGDSBKcRAp3mAKDCZ+E3X5R85vVnxKGKwGmzU8elawCfRSfV dpfd0S1AdPcYJoQOt5UZbxc= =4+i/ -----END PGP SIGNATURE----- --nextPart2297483.Rso0kROPCI--

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 02 Jul '07

02 Jul '07

I just forgot to autoconf:-( It works if I use libtool-1.5.24 and run libtoolize --copy --force aclocal autoconf However I'm doing something wrong. With libtool 1.5.22, which OpenLDAP uses now, the build/ltmain.sh and build/config.* I generate don't match the existing ones. Nor aclocal.m4 when I run aclocal, but then I don't know which automake version to use. Is OpenLDAP using a patched libtool? One of the differences is that ltmain.sh contains VERSION=1.5.22-OpenLDAP, while I get VERSION=1.5.22. build/README is outdated, it says we use libtool 1.4.3. -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 02 Jul '07

02 Jul '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> I wonder if we've been waiting for each other... Anyway, I've committed >> some pending fixes now that HEAD passes all tests for me. I've some >> more cleanup, but if we are close to a freeze I don't know if that means >> I should rush it in or wait until afterwards. > > Cleanup as in tidying the code, or as in fixing functionality? One cleanup (move thread start before queuing task in pool_submit(), one mini functionality: Make thread counts int instead of long, since pool_query() wants that. Oh, and make max_pending 0 or greater, since negative numbers confuse pool_query(). >> Another time when tls.c code loses information is if pointers are wider >> than long, which does happen. (Don't know how it is nowadays, but I >> remember plenty of postings about it some years ago.) > > Probably the OpenSSL API should have used a void * here. Too bad. Yup. I've seen mention it is coming in future version. > OK, suppose we use a pthread thread-specific key here. What are you > proposing for the unique value? An unsigned long counter, maintained by libldap_r. If the thread-local variable is zero (thus uninitialized), increment the counter and grab its value. >>>>> It's really >>>>> not hard. If we were to disallow increasing the number of threads at >>>>> runtime, we could simply allocate a block of thread stacks all at once, >>>>> which would then allow our thread IDs to be simple integers from 0-N. >> >> IIRC disallowing that would fix some other tpool problem too, but I >> don't remember what. > > I'm not really keen on that since I like having the ability to both increase > and decrease the setting dynamically. Me too, the only pro is it makes implementation simpler. >> Which led me to notice that the setstacksize call now _decreases_ the >> stack size on some hosts. I don't suppose that was intentional, so I >> guess it should be >> size_t cursize; >> if( pthread_attr_getstacksize( &attr, &cursize ) >> || cursize < LDAP_PVT_THREAD_STACK_SIZE ) >> pthread_attr_setstacksize( &attr, LDAP_PVT_THREAD_STACK_SIZE ); >> in thr_posix and I don't know what in other thr_* files. A RE24 change >> I guess, since reduces the max number of threads before slapd gets into >> trouble. > > I don't consider this a bug. If someone wants a larger thread stack > they can recompile to get it. Or perhaps we should make it a tunable > variable and add a config keyword for it. OK -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 01 Jul '07

01 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > I wonder if we've been waiting for each other... Anyway, I've committed > some pending fixes now that HEAD passes all tests for me. I've some > more cleanup, but if we are close to a freeze I don't know if that means > I should rush it in or wait until afterwards. Cleanup as in tidying the code, or as in fixing functionality? > >>> We did have code which compared thread IDs with '==' for >>> quite some time. Do you remember if anyone complained, or if the >>> switch to using ldap_pvt_thread_equal() was a "just in case" fix? >> Yes, I needed to use pthread_equal() on OS/390 since their thread type >> was a structure. > > I'm not sure, but I gather that's derived from the DCE threads reference > implementation where pthread_t has three members 'field1', 'field2' and > 'field3'. tls.c can't stuff all of them in a long, so the old one may > not get a unique ID. OTOH DCE has a pthread_getunique_np() call which > uses just the 2nd field as a unique integer thread ID, I expect we could > use that. Except I don't have a host to test such a change on. Dunno > why pthread_equal checks all three fields. I've asked on > comp.programming.threads. I don't remember which version of the spec OS/390 implemented, it was certainly old but it wasn't DCE. Might have been Draft 6 IIRC. > Also I note that the DCE struct will get four padding bytes on a 64-bit > host which aligns the struct at 8*n addresses, and the compiler is not > obliged to preserve these during struct copy. > > On the other hand DCE threads are based on an extremely outdated Posix > draft, so I don't know how relevant it is now. Yes, Draft 4, and I don't know of any systems that still use that exclusively. > Another time when tls.c code loses information is if pointers are wider > than long, which does happen. (Don't know how it is nowadays, but I > remember plenty of postings about it some years ago.) Probably the OpenSSL API should have used a void * here. Too bad. > [Using address of the thread's stack] >>>> That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. > > As modified by PTHREAD_STACK_MIN and pthread_attr_getguardsize(). And > slight other variations, apparently. I tried on a few hosts and Solaris > would a few times use some extra space near the stack of a thread or two. > > OTOH we could allocate stack memory ourselves and then use > pthread_attr_setstack() to put the stack just where we want it. > > However this doesn't help tls.c with threads that have been created by > _other_ packages. And the SSL id_callback function apparently has no > way to return failure:-( > > All in all I still like a thread-specific key better - they are the > standard way of doing things like this. We only need it for pthreads > since the other thread types as far as I can tell have integer IDs. OK, suppose we use a pthread thread-specific key here. What are you proposing for the unique value? >>>> It's really >>>> not hard. If we were to disallow increasing the number of threads at >>>> runtime, we could simply allocate a block of thread stacks all at once, >>>> which would then allow our thread IDs to be simple integers from 0-N. > > IIRC disallowing that would fix some other tpool problem too, but I > don't remember what. I'm not really keen on that since I like having the ability to both increase and decrease the setting dynamically. > Which led me to notice that the setstacksize call now _decreases_ the > stack size on some hosts. I don't suppose that was intentional, so I > guess it should be > size_t cursize; > if( pthread_attr_getstacksize( &attr, &cursize ) > || cursize < LDAP_PVT_THREAD_STACK_SIZE ) > pthread_attr_setstacksize( &attr, LDAP_PVT_THREAD_STACK_SIZE ); > in thr_posix and I don't know what in other thr_* files. A RE24 change > I guess, since reduces the max number of threads before slapd gets into > trouble. I don't consider this a bug. If someone wants a larger thread stack they can recompile to get it. Or perhaps we should make it a tunable variable and add a config keyword for it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs