- openldap-bugs - openldap.org

(ITS#4795) dsiallow bind_simple_unprotected
by hugo.monteiro＠fct.unl.pt 29 Dec '06

29 Dec '06

Full_Name: Hugo Monteiro Version: 2.3.27 OS: GNU/Linux Debian Sarge URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.139.79.96) Though it's been deprecated for a long time now, the documentation still referes to dsiallow bind_simple_unprotected, leading people into mistake, and some headaches. Keep up the good work. Cheers, Hugo Monteiro.

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2.3.31 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.49.19.14) > > > an ldapsearch like this works > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn > > dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org > cn: Robert Brooks > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > however this does not: > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn > > # search result > search: 2 > result: 65 Object class violation > > # numResponses: > This is working just fine in HEAD/re23 (using the built-in test data): bash-3.00$ ../clients/tools/ldapsearch -x -H ldap://:9011 -b dc=example,dc=com -LLL cn=*mit* cn dn # refldap://localhost:9012/dc=example,dc=com??sub dn: cn=Mitya Kovalev,dc=example,dc=com cn: Mitya Kovalev That's why I suspect it's related to some issue (or inconsistency) within your data/metadata. Could you post more? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > objectclass searches fail (with back-sql/mysql) if there is no data in the > ldap_entry_objclasses table. Just a simple dummy entry like this is enough to > fix the problem. > I see. A solution I see would be to use UNION to merge the results of a query with and one without the outer join to ldap_entry_objclasses. This, however, requires some extensive code manipulation, and likely would be much less efficient, so I believe the workaround of having one row in ldap_entry_objclasses is better. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Frank Cusack wrote: >> >> Oh, in that case I am definitely missing a lot. Since my understanding >> of the timeout value passed to ldap_sasl_bind() is that it is a *bind* >> timeout, which I assumed would be because some artibrary SASL mechanism >> might take some arbitrarily long amount of time. If there is no bind >> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout >> passed to ldap_sasl_bind() should just be the connect() timeout then. > ldap_sasl_bind() cannot be passed any timeout. What timeout are you > referring to? grrr ... I would have sworn there was a timeout arg! I must have confused it with ldap_search(). The Netscape API does not have a timeout arg either. I'd implemented my thread wrapper (w/ timeout) before I learned of the LDAP_OPT_NETWORK_TIMEOUT option (LDAP_X_OPT_CONNECT_TIMEOUT for Netscape API). I guess when I found that option, I falsely remembered that ldap_sasl_bind_s() had a timeout arg. > I must disagree with the above. As far as I understand. > LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time > out as required. ldap_sasl_bind() should return as soon as the packet > with the request has been sent, and the rest of the timeout policy for > the bind only part should be dealt with by the client using the > ldap_result() timeout arg as appropriate. I've recently tested that > behavior for customers who wanted some certain timelimit on all > operations, not just searches, and that required some extensive > modifications to the proxy backends, but the client library (libldap) was > not touched at all. In that case, the code basically uses > ldap_sasl_bind() to wrap simple binds (that's what the proxy backends > mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected. > I can't speak for truly SASL bind as I didn't experiment timeouts with > that. Sounds right. In the case of a truly SASL bind where there might be a long delay, async ldap_sasl_bind() should be enough. Thanks for your patience. -frank

1 0

(ITS#4794) Value return filters leak
by ando＠sys-net.it 28 Dec '06

28 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Members of the vrf list are malloc'ed on the heap but freed as if in the thread's slab.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

Frank Cusack wrote: > > Oh, in that case I am definitely missing a lot. Since my understanding > of the timeout value passed to ldap_sasl_bind() is that it is a *bind* > timeout, which I assumed would be because some artibrary SASL mechanism > might take some arbitrarily long amount of time. If there is no bind > timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout > passed to ldap_sasl_bind() should just be the connect() timeout then. ldap_sasl_bind() cannot be passed any timeout. What timeout are you referring to? >> ldap_initialize() doesn't actually establish any connection, >> it just sets up the handler, and the connection is established by the >> first operation that requires it. the asynchronous bind, muck like any >> other asynchronous operation, simply returns after sending the packet(s) >> containing the request. > > That much I do understand. (Although I thought the async bind() > functions > weren't actually implemented async.) They are. > >> But, of course, the first of them requires the >> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT >> comes into play. Doing a really asynchronous connect() implies >> returning >> some sort of LDAP_X_INPROGRESS, keeping track of the status of the >> connection and polling it for response for each subsequent call until >> the >> connection is established before actually sending any request. In this >> sense the change should be intrusive: in this design, client code should >> be able to handle the LDAP_X_INPROGRESS return code and resubmit the >> request until the connection is ready. A "smarter" design would cache >> the request, poll for connect() response during calls to ldap_result(), >> and submit the actual request when the connection is established. > > Sure, I understand that also (now). > > What I'm saying is that most folks probably don't really need an async > connect(), they just need a non-blocking one that returns in some known > amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it > only controls the connect() part, and not the subsequent bind (important > since you can only get to connect() via the ldap_bind() or other > calls, ie > there is no ldap_connect() and ldap_open() is deprecated). But a new > LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. I must disagree with the above. As far as I understand. LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time out as required. ldap_sasl_bind() should return as soon as the packet with the request has been sent, and the rest of the timeout policy for the bind only part should be dealt with by the client using the ldap_result() timeout arg as appropriate. I've recently tested that behavior for customers who wanted some certain timelimit on all operations, not just searches, and that required some extensive modifications to the proxy backends, but the client library (libldap) was not touched at all. In that case, the code basically uses ldap_sasl_bind() to wrap simple binds (that's what the proxy backends mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected. I can't speak for truly SASL bind as I didn't experiment timeouts with that. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is >> close to the desired functionality. AFAICT it implements a *separate* >> timeout for the connect() (and maybe unbind/close()?) part of an ldap >> connection. Why someone would want to distinguish between connect() >> and bind I don't know, especially when they don't get feedback about >> how long connect() took. >> >> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT >> which would be the total time for connect() and bind, given that >> non-blocking connect() is already implemented. That would probably >> solve a lot of folk's need for a working async bind. >> >> > I think you're missing a point: there's no bind timeout because there's > no need for it. The delay (or the hang) you likely see when dong > ldap_sasl_bind() is actually spent doing a connect() to establish a > connection. Oh, in that case I am definitely missing a lot. Since my understanding of the timeout value passed to ldap_sasl_bind() is that it is a *bind* timeout, which I assumed would be because some artibrary SASL mechanism might take some arbitrarily long amount of time. If there is no bind timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout passed to ldap_sasl_bind() should just be the connect() timeout then. > ldap_initialize() doesn't actually establish any connection, > it just sets up the handler, and the connection is established by the > first operation that requires it. the asynchronous bind, muck like any > other asynchronous operation, simply returns after sending the packet(s) > containing the request. That much I do understand. (Although I thought the async bind() functions weren't actually implemented async.) > But, of course, the first of them requires the > connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT > comes into play. Doing a really asynchronous connect() implies returning > some sort of LDAP_X_INPROGRESS, keeping track of the status of the > connection and polling it for response for each subsequent call until the > connection is established before actually sending any request. In this > sense the change should be intrusive: in this design, client code should > be able to handle the LDAP_X_INPROGRESS return code and resubmit the > request until the connection is ready. A "smarter" design would cache > the request, poll for connect() response during calls to ldap_result(), > and submit the actual request when the connection is established. Sure, I understand that also (now). What I'm saying is that most folks probably don't really need an async connect(), they just need a non-blocking one that returns in some known amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it only controls the connect() part, and not the subsequent bind (important since you can only get to connect() via the ldap_bind() or other calls, ie there is no ldap_connect() and ldap_open() is deprecated). But a new LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. -frank

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

fcusack(a)fcusack.com wrote: > Unfortunately I won't be able to contribute a patch as I've worked > around it in my application (I created a separate thread to handle > the ldap connect) so I can't afford to invest the time. Plus I needed > a solution that would work with the Netscape API as well as OpenLDAP. > > I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is > close to the desired functionality. AFAICT it implements a *separate* > timeout for the connect() (and maybe unbind/close()?) part of an ldap > connection. Why someone would want to distinguish between connect() > and bind I don't know, especially when they don't get feedback about > how long connect() took. > > It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT > which would be the total time for connect() and bind, given that > non-blocking connect() is already implemented. That would probably > solve a lot of folk's need for a working async bind. > > I think you're missing a point: there's no bind timeout because there's no need for it. The delay (or the hang) you likely see when dong ldap_sasl_bind() is actually spent doing a connect() to establish a connection. ldap_initialize() doesn't actually establish any connection, it just sets up the handler, and the connection is established by the first operation that requires it. the asynchronous bind, muck like any other asynchronous operation, simply returns after sending the packet(s) containing the request. But, of course, the first of them requires the connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT comes into play. Doing a really asynchronous connect() implies returning some sort of LDAP_X_INPROGRESS, keeping track of the status of the connection and polling it for response for each subsequent call until the connection is established before actually sending any request. In this sense the change should be intrusive: in this design, client code should be able to handle the LDAP_X_INPROGRESS return code and resubmit the request until the connection is ready. A "smarter" design would cache the request, poll for connect() response during calls to ldap_result(), and submit the actual request when the connection is established. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 27 Dec '06

27 Dec '06

On December 22, 2006 10:56:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely have > the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Unfortunately I won't be able to contribute a patch as I've worked around it in my application (I created a separate thread to handle the ldap connect) so I can't afford to invest the time. Plus I needed a solution that would work with the Netscape API as well as OpenLDAP. I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is close to the desired functionality. AFAICT it implements a *separate* timeout for the connect() (and maybe unbind/close()?) part of an ldap connection. Why someone would want to distinguish between connect() and bind I don't know, especially when they don't get feedback about how long connect() took. It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT which would be the total time for connect() and bind, given that non-blocking connect() is already implemented. That would probably solve a lot of folk's need for a working async bind. -frank

1 0

(ITS#4793) connection_get race condition on Windows
by hyc＠OpenLDAP.org 26 Dec '06

26 Dec '06

Full_Name: Howard Chu Version: HEAD OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc test039 was consistently failing in an assert() in slapd_set_read() called from connection_read(). The problem was that connection_get() was returning a connection structure that got closed and immediately reused. The problem may also be in RE23 since they're using the same connection manager now, but I haven't built RE23 on Windows recently to verify.

1 0

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > >> The patch is coming. > > Something's missing... My fault, sorry. Had an old back-ldap.h. Builds fine now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

ando(a)sys-net.it wrote: > The patch is coming. Something's missing... gcc -g -O2 -I../../../include -I../../../../head/include -I.. -I../../../../head/servers/slapd/back-ldap/.. -I/usr/local/include -I/usr/local/BerkeleyDB.4.2/include -c ../../../../head/servers/slapd/back-ldap/config.c -o config.o ../../../../head/servers/slapd/back-ldap/config.c: In function `slap_idassert_authzfrom_parse': ../../../../head/servers/slapd/back-ldap/config.c:567: error: `LDAP_BACK_AUTH_AUTHZ_ALL' undeclared (first use in this function) ../../../../head/servers/slapd/back-ldap/config.c:567: error: (Each undeclared identifier is reported only once ../../../../head/servers/slapd/back-ldap/config.c:567: error: for each function it appears in.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I've had a patch for the Filter handling sitting here half-finished for >> quite a while. The intent is to preserve all of the original filter data >> so that it can be reused directly. > > This is now in HEAD. I haven't yet caught all the cases in get_ssa or > get_mra that drop the info when validation fails, but otherwise it's > usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for > filter components with unknown attributes, it now ORs the > SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way > the original filter structure can be preserved. back-ldap's filter munging strategy still needs to be adapted to the new code. Probably it shouldn't use the filterstr at all. Any filter component with an unknown attribute is now logged with a '?' prefix, e.g. "(foo=a*b)" becomes "(?foo=a*b)". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > I've had a patch for the Filter handling sitting here half-finished for > quite a while. The intent is to preserve all of the original filter data > so that it can be reused directly. This is now in HEAD. I haven't yet caught all the cases in get_ssa or get_mra that drop the info when validation fails, but otherwise it's usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for filter components with unknown attributes, it now ORs the SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way the original filter structure can be preserved. > On a related note, RFC4511 changes the behavior of presence matching on > unknown attributes to be Undefined now instead of FALSE. So presumably > we should update our code accordingly. This is now in HEAD as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by azia＠techxact.com 25 Dec '06

25 Dec '06

Full_Name: Ahmad Zia Version: openldap-2.3.31 OS: Redhat ES 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.227.142.2) I have successfully compiled, make openldad but when I get to the point where I have to run "make test" it says cannot connect to the openldap server after timing out. When I use this command , I get the following: [root@TXDXB openldap]# rpm -qa | grep openldap openldap-devel-2.2.13-6.4E openldap-2.2.13-6.4E openldap-clients-2.2.13-6.4E its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I only have ldap.conf and I do not have slapd.conf, so what I gather so far is that I am not able to install the server module. I have used the parameter --enable-slapd with ./configure command but its still the same thing. Can you please tell me what am I doing wrong

1 0

Re: (ITS#4790) re23 hangs during shutdown after test033
by hyc＠symas.com 24 Dec '06

24 Dec '06

---- <ando(a)sys-net.it> wrote: > > Full_Name: Pierangelo Masarati > Version: re23 (2.3.31) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.28.220.33) > > > Apparently, one thread is unable to terminate correctly, so the test succeeds, > but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't > investigate this in depth right now, but I could easily reproduce it on two > different systems (different kernels and so), so I'm positive I can easily > reproduce it. This is a bad patch to connections_shutdown in RE23, there is a "continue" after checking for a client session that shouldn't be there. This line is not present in HEAD and the bug doesn't exist in HEAD. Strange that it got there since we just recently sync'd RE23 with HEAD's connection.c. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

(ITS#4791) privileged connections handling in proxy backends
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando Privileged connections, under special circumstances, are cached and shared among client-side connections. This may result in very heavy traffic between the proxy and the remote server(s) on a single connection. As a consequence, multiple issues may arise: - heavy contention on the handler's resources - requests limitation at the remote server side on a single connection (this occurs if the remote server is OpenLDAP, but other implementations may follow similar design) - bottelneck whenever the shared connection needs be regenerated, i.e. because it expires (conn-ttl) As a workaround, a pool of privileged connections is proposed. A fixed maximum side pool is deisgned, so that whenever a privileged connection is requested, the related list of connections is walked looking for an idle one (refcnt == 0). If found, it's moved to the tail, to provide a simple round-robin mech to avoid reusing the same connections. If none is found, a new connection is generated, if use-temporary-conn is set to yes or the size limit is not reached, or the thread idles waiting for one to become available. If a new connection is created and there's room for it in the list, it's appended. Tests show a clear benefit on Linux when binding through back-ldap, since this nicely works around the bottleneck created by sharing the bind connection when operations are always proxied authz, to save network resources. Another benefit is represented by a clear smoothing of the response rates. Previously, frequent transients would occur, giving uneven response rates over time, while right now steady rates under steady conditions are observed. The patch is coming. p.

1 0

(ITS#4790) re23 hangs during shutdown after test033
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: re23 (2.3.31) OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Apparently, one thread is unable to terminate correctly, so the test succeeds, but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't investigate this in depth right now, but I could easily reproduce it on two different systems (different kernels and so), so I'm positive I can easily reproduce it. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 24 Dec '06

24 Dec '06

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: > > >> I presume there's some kind of callback for registering new suffixes but I >> haven't looked very hard. >> > > This highlights some other issues lurking in here - back-monitor > basically doesn't deal with dynamic configuration well at all. It > assumes that all databases and overlays have been fully configured by > the time it starts - an assumption that was valid for old-style > slapd.conf use, but not with back-config. > > The monitor_subsys_database_init_one() function probably needs to be > split into separate pieces so that database and overlay info can be set > up and removed incrementally. > The point is that back-monitor has no clean means to detect what database is serving what naming context, since it was designed way ahead of back-config. So when time came to introduce monitor customization, the best mechanism I could find was the extended filter on the naming context. This is really creating trouble. The best solution would be to re-design back-monitor so that the database section mimics back-config using X-ORDERED 'SIBLING' style (and is updated accordingly, especially when entry renaming will be supported by back-config). The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get rid of those "cn=Database X", "cn=Overlay Y" stuff and so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#3707 filters
by hyc＠symas.com 23 Dec '06

23 Dec '06

I've had a patch for the Filter handling sitting here half-finished for quite a while. The intent is to preserve all of the original filter data so that it can be reused directly. On a related note, RFC4511 changes the behavior of presence matching on unknown attributes to be Undefined now instead of FALSE. So presumably we should update our code accordingly. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 23 Dec '06

23 Dec '06

hyc(a)OpenLDAP.org wrote: > I presume there's some kind of callback for registering new suffixes but I > haven't looked very hard. This highlights some other issues lurking in here - back-monitor basically doesn't deal with dynamic configuration well at all. It assumes that all databases and overlays have been fully configured by the time it starts - an assumption that was valid for old-style slapd.conf use, but not with back-config. The monitor_subsys_database_init_one() function probably needs to be split into separate pieces so that database and overlay info can be set up and removed incrementally. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4789) can't add BDB database when monitoring
by hyc＠OpenLDAP.org 23 Dec '06

23 Dec '06

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When back-monitor is active, attempting to add a bdb database thru cn=config fails in bdb_monitor_db_open. The call to mbe->register_entry_attrs() fails because the new database's suffixes aren't known to back-monitor: monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=foo,dc=example,dc=com)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=example,dc=com)! send_ldap_result: conn=0 op=12 p=3 send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup" I presume there's some kind of callback for registering new suffixes but I haven't looked very hard.

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 22 Dec '06

22 Dec '06

On Wednesday 20 December 2006 01:43, dhawes(a)vt.edu wrote: > On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > > David Hawes wrote: > > > Here's the valgrind output with the set clause in place: > > > > > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > > > > > Here's the valgrind output without the set clause (for reference): > > > > > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > > > > > The following patch causes memory use to stabilize with my SLAMD test: > > > > Try the patch in HEAD sets.c 1.29 -> 1.30. > > I haven't tested the patch with valgrind yet, but I no longer see the > memory leak with my SLAMD test. Just to follow up, I no longer see the memory leaks with valgrind. dave

1 0

Re: (ITS#4788) test043-delta-syncrepl failed (exit 49)
by hyc＠symas.com 22 Dec '06

22 Dec '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: SuSE Linux 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.24.222) > > >>>>>> Starting test043-delta-syncrepl ... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entries in the master... > Starting slave slapd on TCP/IP port 9012... > Using ldapsearch to check that slave slapd is running... > Using ldapadd to populate the master directory... > Waiting 15 seconds for syncrepl to receive changes... > Stopping the provider, sleeping 10 seconds and restarting it... > Using ldapsearch to check that master slapd is running... > Using ldapmodify to modify master directory... > Waiting 15 seconds for syncrepl to receive changes... > Stopping consumer to test recovery... > Modifying more entries on the master... > Restarting consumer... > Waiting 25 seconds for syncrepl to receive changes... > Try updating the slave slapd... > ldapmodify failed (49)! >>>>>> ./scripts/test043-delta-syncrepl failed (exit 49) > make[2]: *** [bdb-mod] Error 49 > make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' > make: *** [test] Error 2 You didn't look back far enough in slapd.2.log; the real error is here: syncrepl_message_to_entry: rid 001 mods check (auditContext: attribute type undefined) ldap_msgfree this is from Ando's recent patch to accesslog.c. I think that an appropriate fix would be to exclude dsaOperational attributes from replication since they only have meaning on the hosting DSA. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4788) test043-delta-syncrepl failed (exit 49)
by michael＠stroeder.com 22 Dec '06

22 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.24.222) >>>>> Starting test043-delta-syncrepl ... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entries in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the master... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the slave slapd... ldapmodify failed (49)! >>>>> ./scripts/test043-delta-syncrepl failed (exit 49) make[2]: *** [bdb-mod] Error 49 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2 ---------------------------------------------------------------------------- test.out: ldap_initialize( ldap://localhost:9012 ) ldap_bind: Invalid credentials (49) ---------------------------------------------------------------------------- last lines of slapd.2.log slap_listener_activate(7): >>> slap_listener(ldap://localhost:9012/)ldap_pvt_gethostbyname_a: host=nb2, r=0 conn=0 fd=11 ACCEPT from IP=127.0.0.1:6312 (IP=127.0.0.1:9012) connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=Manager,dc=example,dc=com bdb_dn2entry("cn=manager,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 11 conn=0 op=0 RESULT tag=97 err=49 text= connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 ber_get_next ber_get_next on fd 11 failed errno=0 (Success) connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 conn=0 fd=11 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 22 Dec '06

22 Dec '06

fcusack(a)fcusack.com wrote: > But still you can do the bind async, and just close the fd on the client > side on timeout. I don't see why connect() timeout can't be handled > the same way. (ignoring the problem that there is no API call AFAICT > to just drop the connection) > I'll note that there's been some interest in that area --- I loosely have the same need (see <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but unfortunately it's not in my priority list, considering that it might have relevant impact on the client library. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4784) a small patch for back-sql
by ando＠sys-net.it 21 Dec '06

21 Dec '06

> back-sql fails to compile with BACKSQL_TRACE defined, I think this is the > correct fix. (blind) fixed in HEAD/re23. Thanks for reporting. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4787) Download links with version vs. date
by michael＠stroeder.com 21 Dec '06

21 Dec '06

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.77) HI! It's hard for beginners to understand the download links here: http://www.openldap.org/software/download/ The file names of latest release contains the release number but the file names of releases tagged as "stable" contains the release date. Current example: 2.3.31 ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.3.31.tgz 2.3.27 (20060823) ftp://ftp.openldap.org/pub/OpenLDAP/openldap-stable/openldap-stable-2006082… I see several problems with this current practice: 1. Common practice in other open source projects is to create file names with dates only for CVS/SVN snapshots. So it might be hard for beginners to recognize that these files are really stable releases even though the string "stable" is also in the file name. Note that these .tar.gz files could be obtained from another source, not directly from the official download page. 2. On the mailing lists always the version number is referred/proposed. But this does not appear in the file name. And frankly no-one remembers the release dates. Especially since also CHANGES does not contain the release dates. So the only mapping is the download page. 3. Common practice is that the root directory name within the .tar.gz matches the exact version in the .tar.gz file name. => I'd recommend to always create the same form of file names containing solely the release version. I see no benefit in using the date at all. Ciao, Michael.

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 21 Dec '06

21 Dec '06

Pierangelo Masarati wrote: > I'll note that unless you defined it yourself, "dn" is not a valid > attribute name. I suspect your back-sql meta-data generates an entry > that doesn't pass schema checking, otherwise I don't see a chance for > that error to be reported. Pierangelo, the objects are inetOrgPerson objects, the full object looks like this # robb(a)example.org, sql.example.org dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org objectClass: inetOrgPerson cn: Robert Brooks uid: robb(a)example.org mail: robb(a)example.org I believe the only required attribute for such an object is cn. A similar search against a non back-sql part for the tree (see below) does not show an error ldapsearch -x -b "ou=people,dc=example,dc=org" "cn=Robert Brooks" dn cn objectclass # robb, people, example.org dn: uid=robb,ou=people,dc=example,dc=org cn: Robert Brooks objectClass: account objectClass: posixAccount objectClass: shadowAccount Unfortunately seems some software doesn't understand it doesn't need to request dn explicitly hence I noticed this. > In any case, since the behavior you report is very data and meta-data > dependent, you don't provide enough info for debugging, and at a very > first glance this is not indicative of a software bug. Let me know what you'd like, I thought this one may well reproduce on any back-sql, so didn't spray the ITS with extraneous information. Regards, Rob -- Robert Brooks, Network Manager, Cable & Wireless UK <robb(a)wtg.cw.com> http://wtg.cw.com/ Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601 - "What was your username again?" - BOFH -

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 20 Dec '06

20 Dec '06

robb(a)wtg.cw.com wrote: > an ldapsearch like this works > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn > > dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org > cn: Robert Brooks > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > however this does not: > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn > > # search result > search: 2 > result: 65 Object class violation > > # numResponses: I'll note that unless you defined it yourself, "dn" is not a valid attribute name. I suspect your back-sql meta-data generates an entry that doesn't pass schema checking, otherwise I don't see a chance for that error to be reported. In any case, since the behavior you report is very data and meta-data dependent, you don't provide enough info for debugging, and at a very first glance this is not indicative of a software bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org 20 Dec '06

20 Dec '06

At 01:51 PM 12/20/2006, fcusack(a)fcusack.com wrote: >But still you can do the bind async, and just close the fd on the client >side on timeout. If you are waiting on a timeout, you're not truely async. Truely async implies never blocking, including not blocking for a time. > I don't see why connect() timeout can't be handled >the same way. (ignoring the problem that there is no API call AFAICT >to just drop the connection) My comments were for truely async. -- Kurt

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 20 Dec '06

20 Dec '06

On December 20, 2006 9:18:18 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" >> <Kurt(a)OpenLDAP.org> wrote: >> >>> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >>> >>>> Full_Name: Frank Cusack >>>> Version: 2.3.27 >>>> OS: any >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (209.76.127.62) >>>> >>>> connect() is always done synchronously. Any idea when this will be >>>> fixed? >>>> >>> It's actually not considered a bug. ldap_sasl_bind(3) is async >>> in doesn't wait for the LDAP response. There is no LDAP restart >>> API, as would be needed if the API didn't block on various >>> system calls. >>> >> >> Why is that required here? >> >> ldap_sasl_bind() >> ldap_result() >> if (timeout) { >> ldap_abandon() >> if (just_return_on_error) { >> return error >> } else { >> do_something_else >> } >> } >> >> To restart a bind, just abandon and bind again. >> > There was a discussion recently on the subject (look in hte ITS). A bind > cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and > recreate a fresh connection. OK, I see that abandon isn't really the right thing here. But still you can do the bind async, and just close the fd on the client side on timeout. I don't see why connect() timeout can't be handled the same way. (ignoring the problem that there is no API call AFAICT to just drop the connection) -frank

1 0

(ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) an ldapsearch like this works ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org cn: Robert Brooks # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 however this does not: ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn # search result search: 2 result: 65 Object class violation # numResponses:

1 0

(ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) objectclass searches fail (with back-sql/mysql) if there is no data in the ldap_entry_objclasses table. Just a simple dummy entry like this is enough to fix the problem. +----------+----------+ | entry_id | oc_name | +----------+----------+ | 0 | dcObject | +----------+----------+

1 0

(ITS#4784) a small patch for back-sql
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.3.30-tracesql.patch Submission from: (NULL) (62.49.19.14) back-sql fails to compile with BACKSQL_TRACE defined, I think this is the correct fix.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 20 Dec '06

20 Dec '06

fcusack(a)fcusack.com wrote: > On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" > <Kurt(a)OpenLDAP.org> wrote: > >> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> >>> Full_Name: Frank Cusack >>> Version: 2.3.27 >>> OS: any >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (209.76.127.62) >>> >>> connect() is always done synchronously. Any idea when this will be >>> fixed? >>> >> It's actually not considered a bug. ldap_sasl_bind(3) is async >> in doesn't wait for the LDAP response. There is no LDAP restart >> API, as would be needed if the API didn't block on various >> system calls. >> > > Why is that required here? > > ldap_sasl_bind() > ldap_result() > if (timeout) { > ldap_abandon() > if (just_return_on_error) { > return error > } else { > do_something_else > } > } > > To restart a bind, just abandon and bind again. > There was a discussion recently on the subject (look in hte ITS). A bind cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and recreate a fresh connection. > I am not all that familiar with the LDAP API, so forgive me if I'm > way off base here. > p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > David Hawes wrote: > > Here's the valgrind output with the set clause in place: > > > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > > > Here's the valgrind output without the set clause (for reference): > > > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > > > The following patch causes memory use to stabilize with my SLAMD test: > > Try the patch in HEAD sets.c 1.29 -> 1.30. I haven't tested the patch with valgrind yet, but I no longer see the memory leak with my SLAMD test. Thanks for your help with this. dave

1 0

ITS#3971 slapo-glue and slapo-rwm
by hyc＠symas.com 19 Dec '06

19 Dec '06

This issue has been fixed in HEAD with the patches for ITS#4638. This ITS will be closed in favor of #4638. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4780) ACL set memory leak
by hyc＠symas.com 19 Dec '06

19 Dec '06

David Hawes wrote: > Here's the valgrind output with the set clause in place: > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > Here's the valgrind output without the set clause (for reference): > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > The following patch causes memory use to stabilize with my SLAMD test: Try the patch in HEAD sets.c 1.29 -> 1.30. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 19 Dec '06

19 Dec '06

On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" <Kurt(a)OpenLDAP.org> wrote: > At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> Full_Name: Frank Cusack >> Version: 2.3.27 >> OS: any >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.76.127.62) >> >> connect() is always done synchronously. Any idea when this will be >> fixed? > > It's actually not considered a bug. ldap_sasl_bind(3) is async > in doesn't wait for the LDAP response. There is no LDAP restart > API, as would be needed if the API didn't block on various > system calls. Why is that required here? ldap_sasl_bind() ldap_result() if (timeout) { ldap_abandon() if (just_return_on_error) { return error } else { do_something_else } } To restart a bind, just abandon and bind again. I am not all that familiar with the LDAP API, so forgive me if I'm way off base here. -frank

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Tuesday 19 December 2006 19:39, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: > > On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: > >> dhawes(a)vt.edu wrote: > >>> I notice the same behavior on 2.3.27, but did not notice it with older > >>> versions such as 2.2.26. > >> > >> I can't confirm this issue neither with HEAD nor with re23; I used > >> valgrind and the set string you posted verbatim, although I didn't use > >> slamd. However, right now I don't see how it may be a matter of > >> concurrency. > > > > I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 > > does not exhibit this behavior while 2.3.4 (and later) does. > > I've also been unable to reproduce this. Can you run using valgrind or > some other malloc tracer and get some diagnostics? Absolutely. Here's the valgrind output with the set clause in place: http://filebox.vt.edu/users/dhawes/valgrind-with-set.log Here's the valgrind output without the set clause (for reference): http://filebox.vt.edu/users/dhawes/valgrind-without-set.log The following patch causes memory use to stabilize with my SLAMD test: --- openldap-2.3.31-orig/servers/slapd/sets.c 2006-01-03 17:16:15.000000000 -0500 +++ openldap-2.3.31/servers/slapd/sets.c 2006-12-19 21:37:40.000000000 -0500 @@ -440,6 +440,7 @@ AC_MEMCPY( set->bv_val, &filter[ - len - 1 ], len ); set->bv_len = len; SF_PUSH( set ); + cp->set_op->o_tmpfree( set->bv_val, cp->set_op->o_tmpmemctx ); set = NULL; break; Of course, this patch makes sets useless, so it's hardly a fix. I'm still looking at the code to determine what's going on here--I'm sure you guys will be able to pinpoint it in an instant. dave

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org 19 Dec '06

19 Dec '06

At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >Full_Name: Frank Cusack >Version: 2.3.27 >OS: any >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (209.76.127.62) > >connect() is always done synchronously. Any idea when this will be fixed? It's actually not considered a bug. ldap_sasl_bind(3) is async in doesn't wait for the LDAP response. There is no LDAP restart API, as would be needed if the API didn't block on various system calls. So the first step in "fixing" this would be to design an LDAP restart API... yet another reason to redesign the whole API... Kurt

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by hyc＠symas.com 19 Dec '06

19 Dec '06

fcusack(a)fcusack.com wrote: > Full_Name: Frank Cusack > Version: 2.3.27 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.76.127.62) > > > connect() is always done synchronously. Any idea when this will be fixed? You're welcome to submit a patch. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 19 Dec '06

19 Dec '06

Full_Name: Frank Cusack Version: 2.3.27 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.76.127.62) connect() is always done synchronously. Any idea when this will be fixed?

1 0

Re: (ITS#4780) ACL set memory leak
by hyc＠symas.com 19 Dec '06

19 Dec '06

dhawes(a)vt.edu wrote: > On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: >> dhawes(a)vt.edu wrote: >>> I notice the same behavior on 2.3.27, but did not notice it with older >>> versions such as 2.2.26. >> I can't confirm this issue neither with HEAD nor with re23; I used >> valgrind and the set string you posted verbatim, although I didn't use >> slamd. However, right now I don't see how it may be a matter of >> concurrency. > > I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 does > not exhibit this behavior while 2.3.4 (and later) does. I've also been unable to reproduce this. Can you run using valgrind or some other malloc tracer and get some diagnostics? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: > dhawes(a)vt.edu wrote: > > When using ACL sets, OpenLDAP 2.3.30 steadily uses up all the system > > memory before crashing (slapd: ch_malloc.c:57: ch_malloc: Assertion `0' > > failed). > > > > The system is loaded using SLAMD with 4 clients doing anonymous searches > > on a filter file of approximately 300,000 filters (taken from a typical > > day on a production server). SLAMD reports that 2885650 entries are > > returned in the 30 minutes it takes to use up all available memory (4G). > > > > The instance contains approximately 1 million entries in a bdb backend, > > and uses the following simple set of ACLs for this test: > > > > ... > > access to dn.base="" > > by * read > > > > access to dn.base="cn=Subschema" > > by * read > > > > access to dn.base="dc=example,dc=com" > > by * read > > > > access to dn.base="ou=People,dc=example,dc=com" > > by * read > > > > access to * > > by set="[string1] & [string2]" read > > by peername.ip=<slamd client ip 1> read > > by peername.ip=<slamd client ip 2> read > > by peername.ip=<slamd client ip 3> read > > by peername.ip=<slamd client ip 4> read > > by * none > > ... > > > > Removing the "by set=" clause and running the SLAMD job causes OpenLDAP > > memory usage to stabilize. > > > > I notice the same behavior on 2.3.27, but did not notice it with older > > versions such as 2.2.26. > > I can't confirm this issue neither with HEAD nor with re23; I used > valgrind and the set string you posted verbatim, although I didn't use > slamd. However, right now I don't see how it may be a matter of > concurrency. I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 does not exhibit this behavior while 2.3.4 (and later) does. dave

1 0

Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)OpenLDAP.org wrote: > 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently > skip usage of back-monitor, the way back-bdb does. > should be fixed now (not quite clean, though) > 2) multiple calls are made to ldap_back_is_proxy_authz with > sendok=LDAP_BACK_SENDERR without checking the return status or aborting the > operation. As such, when proxy authorization is not in effect for an operation, > the client receives multiple Error Result messages for its request (even though > it continues to completion). This should be fixed now, thanks for pointing out. > Likewise for ldap_back_proxy_authz_bind. Here the fix is slightly different: whenever ldap_back_proxy_authz_bind() succeeds, it should set rc to 1; this is the actual error. > Either > these functions should never send a result back to the client, or their return > status should be checked and processing should stop when they fail. I've cleaned > up several instances of this type of error in previous revisions but can't track > them all down now. Errors of this type may also exist in RE23; I haven't > looked. > There shouldn't be too many, as that stuff was only recently reworked. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)symas.com wrote: > In my case, all backends are dynamic modules, and back-monitor was not > loaded. > OK. In my intentions, back-monitor shouldn't be a module; it should be statically built-in, much like back-ldif and back-config, although the requirement might be less strict. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4782) back-ldap bugs
by hyc＠symas.com 19 Dec '06

19 Dec '06

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD >> OS: URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.168.84.21) >> Submitted by: hyc >> >> >> 1) back-ldap fails to startup if back-monitor isn't enabled. It should >> silently >> skip usage of back-monitor, the way back-bdb does. >> > That's what's supposed to do. Do you mean back-monitor "compiled" or > "instantiated"? "Compiled" should be moot, as back-monitor should now > be always compiled. In my case, all backends are dynamic modules, and back-monitor was not loaded. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently > skip usage of back-monitor, the way back-bdb does. > That's what's supposed to do. Do you mean back-monitor "compiled" or "instantiated"? "Compiled" should be moot, as back-monitor should now be always compiled. > 2) multiple calls are made to ldap_back_is_proxy_authz with > sendok=LDAP_BACK_SENDERR without checking the return status or aborting the > operation. As such, when proxy authorization is not in effect for an operation, > the client receives multiple Error Result messages for its request (even though > it continues to completion). Likewise for ldap_back_proxy_authz_bind. Either > these functions should never send a result back to the client, or their return > status should be checked and processing should stop when they fail. I've cleaned > up several instances of this type of error in previous revisions but can't track > them all down now. Errors of this type may also exist in RE23; I haven't > looked. > I've been cleaning up some of those in back-ldap (and in back-meta as well); some might have slipped thru. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4782) back-ldap bugs
by hyc＠OpenLDAP.org 19 Dec '06

19 Dec '06

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently skip usage of back-monitor, the way back-bdb does. 2) multiple calls are made to ldap_back_is_proxy_authz with sendok=LDAP_BACK_SENDERR without checking the return status or aborting the operation. As such, when proxy authorization is not in effect for an operation, the client receives multiple Error Result messages for its request (even though it continues to completion). Likewise for ldap_back_proxy_authz_bind. Either these functions should never send a result back to the client, or their return status should be checked and processing should stop when they fail. I've cleaned up several instances of this type of error in previous revisions but can't track them all down now. Errors of this type may also exist in RE23; I haven't looked.

1 0

Re: (ITS#4774) Add network timeout option to ldapsearch
by lukeh＠padl.com 17 Dec '06

17 Dec '06

Kurt, >Given this, -e nettimeout=X might be better choice here. >Or -o nettimeout=X. Agreed. I have prepared a patch for the following which I will commit to HEAD: -o <opt>[=<optparam] general options nettimeout=<timeout> (in seconds, or "none" or "max") -- Luke -- www.padl.com | www.lukehoward.com

1 0

Re: (ITS#4585) slapd-search generates TIME_WAIT connections increasingly
by ando＠sys-net.it 17 Dec '06

17 Dec '06

Roland, Howard pointed out that part of your problem could be related to the fact that AD makes an intensive use of referrals, and automatic referral chasing with OpenLDAP's client library was buggy (ITS#4545). A fix to this issue will appear in OpenLDAP 2.3.31; you can get the corresponding code from the CVS under the tag OPENLDAP_REL_ENG_2_3, or wait a few days for the official release. Could you please check if your problem persists with this release? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4781) optimize bind behavior in back-ldap when idassert is in use
by ando＠sys-net.it 17 Dec '06

17 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When idassert is used with "override" (i.e. it occurs also when the instance of back-ldap is the authorizing backend) and it is going to accept to authorize any identity, there is no need to create/destroy a connection for each bind, since subsequent operations will ever occur on the privileged, cached connection with identity assertion. So a separate cached connection is used only for binds, which of course need to be serialized (i.e. wait for response before submitting another one). Here there's room for further optimization: in case the connection is busy waiting for response, back-ldap can either wait or use a temporary (the original behavior). Further optimization will allow a pool of dedicated connections to alleviate concurrency issues. A patch is coming. p.

1 0

Re: (ITS#4780) ACL set memory leak
by ando＠sys-net.it 16 Dec '06

16 Dec '06

dhawes(a)vt.edu wrote: > When using ACL sets, OpenLDAP 2.3.30 steadily uses up all the system memory > before crashing (slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed). > > The system is loaded using SLAMD with 4 clients doing anonymous searches on a > filter file of approximately 300,000 filters (taken from a typical day on a > production server). SLAMD reports that 2885650 entries are returned in the 30 > minutes it takes to use up all available memory (4G). > > The instance contains approximately 1 million entries in a bdb backend, and uses > the following simple set of ACLs for this test: > > ... > access to dn.base="" > by * read > > access to dn.base="cn=Subschema" > by * read > > access to dn.base="dc=example,dc=com" > by * read > > access to dn.base="ou=People,dc=example,dc=com" > by * read > > access to * > by set="[string1] & [string2]" read > by peername.ip=<slamd client ip 1> read > by peername.ip=<slamd client ip 2> read > by peername.ip=<slamd client ip 3> read > by peername.ip=<slamd client ip 4> read > by * none > ... > > Removing the "by set=" clause and running the SLAMD job causes OpenLDAP memory > usage to stabilize. > > I notice the same behavior on 2.3.27, but did not notice it with older versions > such as 2.2.26. > I can't confirm this issue neither with HEAD nor with re23; I used valgrind and the set string you posted verbatim, although I didn't use slamd. However, right now I don't see how it may be a matter of concurrency. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4780) ACL set memory leak
by dhawes＠vt.edu 15 Dec '06

15 Dec '06

Full_Name: David Hawes Version: 2.3.30 OS: Debian GNU/Linux 3.1 URL: Submission from: (NULL) (128.173.13.109) When using ACL sets, OpenLDAP 2.3.30 steadily uses up all the system memory before crashing (slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed). The system is loaded using SLAMD with 4 clients doing anonymous searches on a filter file of approximately 300,000 filters (taken from a typical day on a production server). SLAMD reports that 2885650 entries are returned in the 30 minutes it takes to use up all available memory (4G). The instance contains approximately 1 million entries in a bdb backend, and uses the following simple set of ACLs for this test: ... access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.base="dc=example,dc=com" by * read access to dn.base="ou=People,dc=example,dc=com" by * read access to * by set="[string1] & [string2]" read by peername.ip=<slamd client ip 1> read by peername.ip=<slamd client ip 2> read by peername.ip=<slamd client ip 3> read by peername.ip=<slamd client ip 4> read by * none ... Removing the "by set=" clause and running the SLAMD job causes OpenLDAP memory usage to stabilize. I notice the same behavior on 2.3.27, but did not notice it with older versions such as 2.2.26.

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 15 Dec '06

15 Dec '06

<quote who="ando(a)sys-net.it"> > Gavin Henry wrote: >> <quote who="Pierangelo Masarati"> >>> Gavin, >>> >>> from the preamble, one may infer that monitoring is optional in the >>> sense it can be optionally built. That's how it used to be; >> >> In 2.3. I see. Thanks. >> >>> however, in >>> 2.4, it is always enabled, but it still must be explicitly exposed in >>> slapd.conf/slapd.d by using "database monitor". >> >> Ah, understood. >> >>> I would replace >>> "enabled" with "exposed", and possibly explicitly indicate that in 2.4 >>> it is no longer an option to build the monitor interface. >> >> Yes, that sounds fine. >> >>> No global directive should occur after "database monitor", as it >>> represents a database instantiation like any other. Although most >>> global directives wouldn't complain if appearing __after__ a database >>> instantiation, such use should be considered at least "bad practice". Understood. >> >> OK. But I was right with the fact you can put rootpw directly beneath >> it, >> or is that what you are saying about bad practices? > > "rootdn" and "rootpw" are per-database directives. They __have__ to go > there. What I call "bad practice" is, say, putting a "threads" > directive inside a database. It will be handled as expected, i.e. it > impacts the whole instance of slapd, but it appears like it were for > that database only! Ah yes! ;-) Agreed and now understood. > >>> About access control, it may be worth stressing that some attributes >>> can >>> actually be written; this requires to protect them and, at the same >>> time, to grant the desired identities write privileges on them. >> >> Only with the rootpw defined? > > back-monitor honors access control much like any other database (at > least it should; if it doesn't, then it's a bug). > > So any ACL applies (should apply) and as such there's much freedom in > defining who has access to what under which circumstances. So I don't > see any need to write any specific information about access control, as > soon as the administrator is warned that access control needs to be > taken into account for that database as well. OK. > >> If so; >> >> What attributes can be written to? > > AFAIR: managedInfo and derived attrs are writable; practically, they can > only be written whenever a modify hook is defined for that subsystem, > and constraints may be present. > > managedInfo can be written in "cn=Log,cn=Monitor" but it can only take > the values that are allowed as loglevels (see loglevel in slapd.conf(5), > but note that in HEAD, and possibly in 2.3 as well, I don't remember, > modules can add further log levels). OK. This should be all documented! ;-) > > readOnly can be written in each database entry (those residing below > "cn=Databases,cn=Monitor") > > I'm not sure there' any more in stock back-monitor; but beware that > back-monitor can be extended by modules through an API, so there might > be more. In general, look for any modify hook in the definition of each > subsystem. Modules, as in overlays? That was what my last question was really asking. For example, how accesslog is used by Delta-Syncrepl. I was merely trying to understand if, when some other feature gets enabled, it relies on back-monitor to work properly. > >> What are their purpose/effects? > > perform non-persistent state changes (i.e. changes that are not > reflected in back-config and don't et to the persistent storage on disk > when the system is arrested. OK. > >> What ACL example can we show to protect them? > > I don't think anything relevant is needed; in case, something like > > # only let the manager rite managed info (add further modifiable attrs) > access to attrs=managedInfo > by dn.exact="cn=Manager" write > by * read > > # only let the manager read connections data (may be sensible) > access to dn.children="cn=Connections,cn=Monitor" > by dn.exact="cn=Manager" read > by * none > > # allow read access to anything else > access to * > by * read > > unless there's anything else worth protecting. Looks standard enough. > >> Are they used by any overlays/backends? > > Not sure I got the point. See my above comment regarding accesslog. Thanks for your time. Gavin. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > 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#4770) monitoringslapd.sdf patch
by ando＠sys-net.it 15 Dec '06

15 Dec '06

Gavin Henry wrote: > <quote who="Pierangelo Masarati"> >> Gavin, >> >> from the preamble, one may infer that monitoring is optional in the >> sense it can be optionally built. That's how it used to be; > > In 2.3. I see. Thanks. > >> however, in >> 2.4, it is always enabled, but it still must be explicitly exposed in >> slapd.conf/slapd.d by using "database monitor". > > Ah, understood. > >> I would replace >> "enabled" with "exposed", and possibly explicitly indicate that in 2.4 >> it is no longer an option to build the monitor interface. > > Yes, that sounds fine. > >> No global directive should occur after "database monitor", as it >> represents a database instantiation like any other. Although most >> global directives wouldn't complain if appearing __after__ a database >> instantiation, such use should be considered at least "bad practice". > > OK. But I was right with the fact you can put rootpw directly beneath it, > or is that what you are saying about bad practices? "rootdn" and "rootpw" are per-database directives. They __have__ to go there. What I call "bad practice" is, say, putting a "threads" directive inside a database. It will be handled as expected, i.e. it impacts the whole instance of slapd, but it appears like it were for that database only! >> About access control, it may be worth stressing that some attributes can >> actually be written; this requires to protect them and, at the same >> time, to grant the desired identities write privileges on them. > > Only with the rootpw defined? back-monitor honors access control much like any other database (at least it should; if it doesn't, then it's a bug). So any ACL applies (should apply) and as such there's much freedom in defining who has access to what under which circumstances. So I don't see any need to write any specific information about access control, as soon as the administrator is warned that access control needs to be taken into account for that database as well. > If so; > > What attributes can be written to? AFAIR: managedInfo and derived attrs are writable; practically, they can only be written whenever a modify hook is defined for that subsystem, and constraints may be present. managedInfo can be written in "cn=Log,cn=Monitor" but it can only take the values that are allowed as loglevels (see loglevel in slapd.conf(5), but note that in HEAD, and possibly in 2.3 as well, I don't remember, modules can add further log levels). readOnly can be written in each database entry (those residing below "cn=Databases,cn=Monitor") I'm not sure there' any more in stock back-monitor; but beware that back-monitor can be extended by modules through an API, so there might be more. In general, look for any modify hook in the definition of each subsystem. > What are their purpose/effects? perform non-persistent state changes (i.e. changes that are not reflected in back-config and don't et to the persistent storage on disk when the system is arrested. > What ACL example can we show to protect them? I don't think anything relevant is needed; in case, something like # only let the manager rite managed info (add further modifiable attrs) access to attrs=managedInfo by dn.exact="cn=Manager" write by * read # only let the manager read connections data (may be sensible) access to dn.children="cn=Connections,cn=Monitor" by dn.exact="cn=Manager" read by * none # allow read access to anything else access to * by * read unless there's anything else worth protecting. > Are they used by any overlays/backends? Not sure I got the point. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 15 Dec '06

15 Dec '06

<quote who="Pierangelo Masarati"> > Gavin, > > from the preamble, one may infer that monitoring is optional in the > sense it can be optionally built. That's how it used to be; In 2.3. I see. Thanks. > however, in > 2.4, it is always enabled, but it still must be explicitly exposed in > slapd.conf/slapd.d by using "database monitor". Ah, understood. > I would replace > "enabled" with "exposed", and possibly explicitly indicate that in 2.4 > it is no longer an option to build the monitor interface. Yes, that sounds fine. > > No global directive should occur after "database monitor", as it > represents a database instantiation like any other. Although most > global directives wouldn't complain if appearing __after__ a database > instantiation, such use should be considered at least "bad practice". OK. But I was right with the fact you can put rootpw directly beneath it, or is that what you are saying about bad practices? > > About access control, it may be worth stressing that some attributes can > actually be written; this requires to protect them and, at the same > time, to grant the desired identities write privileges on them. Only with the rootpw defined? If so; What attributes can be written to? What are their purpose/effects? What ACL example can we show to protect them? Are they used by any overlays/backends? > > Sorry I haven't time to go into too much detail. Anyway, it seems > you're doing a great job. > > Thanks, p. > Your thanks is much appreciated. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ando＠sys-net.it 15 Dec '06

15 Dec '06

Gavin, from the preamble, one may infer that monitoring is optional in the sense it can be optionally built. That's how it used to be; however, in 2.4, it is always enabled, but it still must be explicitly exposed in slapd.conf/slapd.d by using "database monitor". I would replace "enabled" with "exposed", and possibly explicitly indicate that in 2.4 it is no longer an option to build the monitor interface. No global directive should occur after "database monitor", as it represents a database instantiation like any other. Although most global directives wouldn't complain if appearing __after__ a database instantiation, such use should be considered at least "bad practice". About access control, it may be worth stressing that some attributes can actually be written; this requires to protect them and, at the same time, to grant the desired identities write privileges on them. Sorry I haven't time to go into too much detail. Anyway, it seems you're doing a great job. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it 14 Dec '06

14 Dec '06

Damon.Groenveld(a)ca.com wrote: > Given that the code (in aclparse.c) calls inet_addr() with the > peername.ip parameter, I can't see how it could will work with IPv6. > > The only possible workaround is using a regex instead of ip type which > by passes the inet_addr() call. > > I raised it as a bug since the latest version (as far as I can tell) is > meant to support IPv6 and there is no way that peername.ip does and > there isn't an alternative. > This is now fixed in HEAD; please test it. Porting this feature to re23 is unlikely, though. Thanks for reporting. p.

1 0

Re: [JunkMail] Re: ITS#4510 syncrepl starttls in Admin Guide
by quanah＠stanford.edu 14 Dec '06

14 Dec '06

--On Friday, December 15, 2006 12:15 AM +0000 hyc(a)symas.com wrote: > Quanah Gibson-Mount wrote: >> >> >> --On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: >> >>> Feel free to submit a patch. This may need to be two separate patches >>> since there are several new TLS config keywords in RE24 vs RE23. >> > You might as well incorporate the ITS#4540 patch while you're at it. Done, in both slapd.conf(5) and the admin guide. >> I've made the following change to the 2.3 admin guide: > > I'd probably put starttls a little lower on the list, but no big deal. I'm going to leave it as is, as it matches slapd.conf(5). > The last two sentences are a little ambiguous to me. I would say > > If the the StartTLS request fails and the {{EX:critical}} argument was > used, the session will be aborted. Otherwise the syncrepl session > continues without TLS. Fixed in the admin guide, and slapd.conf(5), which is where I had grabbed the text from. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: [JunkMail] Re: ITS#4510 syncrepl starttls in Admin Guide
by hyc＠symas.com 14 Dec '06

14 Dec '06

Quanah Gibson-Mount wrote: > > > --On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: > >> Feel free to submit a patch. This may need to be two separate patches >> since there are several new TLS config keywords in RE24 vs RE23. > You might as well incorporate the ITS#4540 patch while you're at it. > I've made the following change to the 2.3 admin guide: I'd probably put starttls a little lower on the list, but no big deal. > (OL) helpus2:/tmp/quanah/ldap-rel-eng-2-3/doc/guide/admin> cvs diff -u > slapdconf2.sdf > Index: slapdconf2.sdf > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/slapdconf2.sdf,v > retrieving revision 1.1.2.10 > diff -u -r1.1.2.10 slapdconf2.sdf > --- slapdconf2.sdf 3 Jan 2006 22:16:03 -0000 1.1.2.10 > +++ slapdconf2.sdf 15 Dec 2006 00:05:16 -0000 > @@ -609,6 +609,7 @@ > > > olcSyncrepl: rid=<replica ID> > > provider=ldap[s]://<hostname>[:port] > +> [starttls=yes|critical] > > [type=refreshOnly|refreshAndPersist] > > [interval=dd:hh:mm:ss] > > [retry=[<retry interval> <# of retries>]+] > @@ -658,6 +659,11 @@ > {{EX:replica}} directives define two independent replication > mechanisms. They do not represent the replication peers of each other. > > +The {{EX:starttls}} parameter specifies use of the StartTLS extended > +operation to establish a TLS session before Binding to the provider. If > the > +critical argument is supplied, the session will be aborted if the StartTLS > +request fails. Otherwise the syncrepl session continues without TLS. > + The last two sentences are a little ambiguous to me. I would say If the the StartTLS request fails and the {{EX:critical}} argument was used, the session will be aborted. Otherwise the syncrepl session continues without TLS. > The content of the syncrepl replica is defined using a search > specification as its result set. The consumer slapd will > send search requests to the provider slapd according to the search > > > If this is acceptable, I will commit it. > > --Quanah -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#4510 syncrepl starttls in Admin Guide
by quanah＠stanford.edu 14 Dec '06

14 Dec '06

--On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: > Feel free to submit a patch. This may need to be two separate patches > since there are several new TLS config keywords in RE24 vs RE23. I've made the following change to the 2.3 admin guide: (OL) helpus2:/tmp/quanah/ldap-rel-eng-2-3/doc/guide/admin> cvs diff -u slapdconf2.sdf Index: slapdconf2.sdf =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/slapdconf2.sdf,v retrieving revision 1.1.2.10 diff -u -r1.1.2.10 slapdconf2.sdf --- slapdconf2.sdf 3 Jan 2006 22:16:03 -0000 1.1.2.10 +++ slapdconf2.sdf 15 Dec 2006 00:05:16 -0000 @@ -609,6 +609,7 @@ > olcSyncrepl: rid=<replica ID> > provider=ldap[s]://<hostname>[:port] +> [starttls=yes|critical] > [type=refreshOnly|refreshAndPersist] > [interval=dd:hh:mm:ss] > [retry=[<retry interval> <# of retries>]+] @@ -658,6 +659,11 @@ {{EX:replica}} directives define two independent replication mechanisms. They do not represent the replication peers of each other. +The {{EX:starttls}} parameter specifies use of the StartTLS extended +operation to establish a TLS session before Binding to the provider. If the +critical argument is supplied, the session will be aborted if the StartTLS +request fails. Otherwise the syncrepl session continues without TLS. + The content of the syncrepl replica is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search If this is acceptable, I will commit it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4779) Problem using BDB replication in OpenLDAP
by Kurt＠OpenLDAP.org 14 Dec '06

14 Dec '06

This issue will be closed, see ITS#4778. At 09:57 PM 12/13/2006, seuler.shi(a)gmail.com wrote: >Full_Name: Seuler >Version: OpenLDAP:2.3.30 >OS: Fedora 5 Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (194.138.202.50) > > >Problem using BDB replication in OpenLDAP >> >> Software version: >> Berkeley DB: 4.5.20 >> OpenLDAP:2.3.30 >> >> We want to configure the replication management in OpenLDAP's backend >> database. All write requests in OpenLDAP master site will spread to >> OpenLDAP client site for we have configured the backend database >> replication. >> >> We mend the source code the OpenLDAP according to the rep_mgr example >> provide by >> >> Berkeley DB. >> >> A test case is executed as follow: >> >> step 1: start openldap server site and client site; >> step 2: send write requests to the master site; >> step 3: search the master site and ensure the records are inserted in >> backend; database successfully; >> >> step 4: search the client site, but not ldap entry is displayed; >> step 5: kill the client site process and reboot it; >> step 5: search the client site right now after it reboot; >> >> Result: After step 5(reboot the client site), the search results from >> client site >> is same as the master site. >> >> At step 4: If we intend to insert an entry into the openLDAP server with >> BDB client configuration via ldapadd command, it will return "the entry >> already exists". After the failed insert operation, if search operation >> is executed, one entry will be displayed.Once a insert operation is >> tried, the number of entries in the subsequent search will increase by 1. >> >> >> >> My question: >> >> Why we can not search any info during the client is normally running? But >> once I rebooted the client site, it worked well and could accept search >> requests? How to solve this problem:)

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 14 Dec '06

14 Dec '06

On Wed, 13 Dec 2006, Howard Chu wrote: > I don't have time to backport the changes from HEAD to RE23 myself, but > if someone submits the patch I can commit it. Seeing as I asked for it in the first place (and need it, due to our baroque setup), I guess I can. Probably won't happen before the weekend, though, but it looks straight-forward enough. -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

(ITS#4779) Problem using BDB replication in OpenLDAP
by seuler.shi＠gmail.com 13 Dec '06

13 Dec '06

Full_Name: Seuler Version: OpenLDAP:2.3.30 OS: Fedora 5 Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) Problem using BDB replication in OpenLDAP > > Software version: > Berkeley DB: 4.5.20 > OpenLDAP:2.3.30 > > We want to configure the replication management in OpenLDAP's backend > database. All write requests in OpenLDAP master site will spread to > OpenLDAP client site for we have configured the backend database > replication. > > We mend the source code the OpenLDAP according to the rep_mgr example > provide by > > Berkeley DB. > > A test case is executed as follow: > > step 1: start openldap server site and client site; > step 2: send write requests to the master site; > step 3: search the master site and ensure the records are inserted in > backend; database successfully; > > step 4: search the client site, but not ldap entry is displayed; > step 5: kill the client site process and reboot it; > step 5: search the client site right now after it reboot; > > Result: After step 5(reboot the client site), the search results from > client site > is same as the master site. > > At step 4: If we intend to insert an entry into the openLDAP server with > BDB client configuration via ldapadd command, it will return "the entry > already exists". After the failed insert operation, if search operation > is executed, one entry will be displayed.Once a insert operation is > tried, the number of entries in the subsequent search will increase by 1. > > > > My question: > > Why we can not search any info during the client is normally running? But > once I rebooted the client site, it worked well and could accept search > requests? How to solve this problem:)

1 0

Re: ITS#4545 bug in libldap
by hyc＠symas.com 13 Dec '06

13 Dec '06

hyc(a)symas.com wrote: > I tried again with chase-referrals TRUE in the slapd.3.conf, and that > seems to have been the difference. Without the patch, slapd.3.log is > 3.4GB. With the patch it's only 400MB and there are no leaked requests. > Probably I had forgotten that I'd enabled chase-referrals when I > submitted the original ITS, since they're originally disabled in this test. > Bah. The last patch was still wrong, it skips the normal cleanup for a completed request. New patch coming up. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Kurt＠OpenLDAP.org 13 Dec '06

13 Dec '06

Discussion of the development of OpenLDAP Software enhancements are more appropriately directed to a list about OpenLDAP Software development, e.g., openldap-devel(a)openldap.org. This issue report will be closed. Kurt At 05:52 PM 12/13/2006, seuler.shi(a)gmail.com wrote: >Full_Name: Seuler Shi >Version: 2.3.30 >OS: Fedora 5 Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (194.138.202.50) > > >Problem using BDB as backend of OpenLDAP > >Software version: >Berkeley DB: 4.5.20 >OpenLDAP:2.3.30 > >We want to configure the replication management in OpenLDAP's backend database. >All write requests in OpenLDAP master site will spread to OpenLDAP client site >for we have configured the backend database replication. > >We mend the source code the OpenLDAP according to the rep_mgr example provide by > >Berkeley DB. > >A test case is executed as follow: > >step 1: start openldap server site and client site; >step 2: send write requests to the master site; >step 3: search the master site and ensure the records are inserted in backend; >database successfully; > >step 4: search the client site, but not ldap entry is displayed; >step 5: kill the client site process and reboot it; >step 5: search the client site right now after it reboot; > >Result: After step 5(reboot the client site), the search results from client >site >is same as the master site. > >At step 4: If we intend to insert an entry into the openLDAP server with BDB >client configuration via ldapadd command, it will return "the entry already >exists". After the failed insert operation, if search operation is executed, one >entry will be displayed.Once a insert operation is tried, the number of entries >in the subsequent search will increase by 1. > > > >My question: > >Why we can not search any info during the client is normally running? But once >I rebooted the client site, it worked well and could accept search requests? >How to solve this problem:)

1 0

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by quanah＠stanford.edu 13 Dec '06

13 Dec '06

--On Thursday, December 14, 2006 1:52 AM +0000 seuler.shi(a)gmail.com wrote: > Full_Name: Seuler Shi > Version: 2.3.30 > OS: Fedora 5 Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.138.202.50) > > > Problem using BDB as backend of OpenLDAP > > Software version: > Berkeley DB: 4.5.20 > OpenLDAP:2.3.30 > > We want to configure the replication management in OpenLDAP's backend > database. All write requests in OpenLDAP master site will spread to > OpenLDAP client site for we have configured the backend database > replication. > > We mend the source code the OpenLDAP according to the rep_mgr example > provide by > > Berkeley DB. > > A test case is executed as follow: > > step 1: start openldap server site and client site; > step 2: send write requests to the master site; > step 3: search the master site and ensure the records are inserted in > backend; database successfully; > > step 4: search the client site, but not ldap entry is displayed; > step 5: kill the client site process and reboot it; > step 5: search the client site right now after it reboot; > > Result: After step 5(reboot the client site), the search results from > client site > is same as the master site. > > At step 4: If we intend to insert an entry into the openLDAP server with > BDB client configuration via ldapadd command, it will return "the entry > already exists". After the failed insert operation, if search operation > is executed, one entry will be displayed.Once a insert operation is > tried, the number of entries in the subsequent search will increase by 1. > > > > My question: > > Why we can not search any info during the client is normally running? But > once I rebooted the client site, it worked well and could accept search > requests? How to solve this problem:) Why are you using BDB Replication? That isn't supported. Use slurpd, syncrepl, or delta-syncrepl. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: ITS#4545 bug in libldap
by hyc＠symas.com 13 Dec '06

13 Dec '06

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> By the way, the main problem appears to have already been fixed; >> slapd.3.log is now only (!) 360MB. This last patch (result.c 1.141) >> just cleans up two leaked requests. > CVS log for tests/scripts/test036-meta-concurrency > I told it to stop searching referrals (treat it as an error ... :) Commenting out that change had no effect, which makes sense. That change only affected the clients, not slapd. I tried again with chase-referrals TRUE in the slapd.3.conf, and that seems to have been the difference. Without the patch, slapd.3.log is 3.4GB. With the patch it's only 400MB and there are no leaked requests. Probably I had forgotten that I'd enabled chase-referrals when I submitted the original ITS, since they're originally disabled in this test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by seuler.shi＠gmail.com 13 Dec '06

13 Dec '06

Full_Name: Seuler Shi Version: 2.3.30 OS: Fedora 5 Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) Problem using BDB as backend of OpenLDAP Software version: Berkeley DB: 4.5.20 OpenLDAP:2.3.30 We want to configure the replication management in OpenLDAP's backend database. All write requests in OpenLDAP master site will spread to OpenLDAP client site for we have configured the backend database replication. We mend the source code the OpenLDAP according to the rep_mgr example provide by Berkeley DB. A test case is executed as follow: step 1: start openldap server site and client site; step 2: send write requests to the master site; step 3: search the master site and ensure the records are inserted in backend; database successfully; step 4: search the client site, but not ldap entry is displayed; step 5: kill the client site process and reboot it; step 5: search the client site right now after it reboot; Result: After step 5(reboot the client site), the search results from client site is same as the master site. At step 4: If we intend to insert an entry into the openLDAP server with BDB client configuration via ldapadd command, it will return "the entry already exists". After the failed insert operation, if search operation is executed, one entry will be displayed.Once a insert operation is tried, the number of entries in the subsequent search will increase by 1. My question: Why we can not search any info during the client is normally running? But once I rebooted the client site, it worked well and could accept search requests? How to solve this problem:)

1 0

connection_close() called with c_struct_state == SLAP_C_INACTIVE
by Pierangelo Masarati 13 Dec '06

13 Dec '06

Recently, with 2.3.30, I got an assertion during shutdown because connection_close() was called with c_struct_state == SLAP_C_INACTIVE. Unfortunately I couldn't save neither the core nor a backtrace. I guess the fix in connection.c 1.375 -> 1.376 should be backported to re23, but the code changed since then, and I fear I could break something. Is this correct? p.

2 4

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 13 Dec '06

13 Dec '06

daveh(a)ci.com.au wrote: > On Thu, 16 Nov 2006, Howard Chu wrote: > >> Since the rid is supposed to be unique, would you settle for that? >> Particularly since there may be multiple sessions to the same host... > > Yes, that will do nicely. In the meantime I was getting it to print > si->si_bindconf.sb_uri.bv_val, as I sort of need it right now... > I don't have time to backport the changes from HEAD to RE23 myself, but if someone submits the patch I can commit it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#4545 bug in libldap
by ando＠sys-net.it 12 Dec '06

12 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > >> I haven't quite figured out everything that's going on, but this patch >> definitely shows when it occurs in test036: >> > > OK, fixed in HEAD. > > By the way, the main problem appears to have already been fixed; > slapd.3.log is now only (!) 360MB. This last patch (result.c 1.141) just > cleans up two leaked requests. > CVS log for tests/scripts/test036-meta-concurrency *1.19* <http://www.openldap.org/devel/cvsweb.cgi/%7Echeckout%7E/tests/scripts/test0…> /Sun Dec 3 20:37:40 2006 UTC/; 9 days, 11 hours ago by /ando/ CVS Tags: *HEAD* Changed since *1.18*: +3 -2 lines Diffs to 1.18 <http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/test036-meta-concurr…> (colored diff) <http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/test036-meta-concurr…> I told it to stop searching referrals (treat it as an error ... :) p.

1 0

ITS#4510 syncrepl starttls in Admin Guide
by hyc＠symas.com 12 Dec '06

12 Dec '06

Feel free to submit a patch. This may need to be two separate patches since there are several new TLS config keywords in RE24 vs RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

ITS#3947 ldap(3) man page points to non existing man pages
by hyc＠symas.com 12 Dec '06

12 Dec '06

The two manpages listed specifically in this ITS have been added to HEAD. For anything else, it's really a dupe of ITS#2240. I'm closing this in favor of #2240. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4615) Possible bug in access log overlay with distributed databases
by hyc＠symas.com 12 Dec '06

12 Dec '06

This is now fixed in HEAD. ckacoroski(a)nsd.org wrote: > Full_Name: Ski Kacoroski > Version: 2.3.24 > OS: Debian Linux Sarge 3.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (152.157.64.243) > > > I have the following setup: > > dc=nsd, dc=org # superior database with accesslog nsdlog > | > -- ou=people # ou in superior database > | > -- ou=hosts # subordinate database with accesslog hostslog > > When I make a change, search, add, delete to an object in > "ou=people,dc=nsd,dc=org", I get logs in nsdlog only. This is makes sense > > When I do a search with base "dc=nsd,dc=org" and scope of base I get an entry in > nsdlog only. This makes sense. If I change the scope to one or sub I get an > entry in nsdlog and hostslog. This also makes sense to me. > > When I do the following search: > ldapsearch -x -b "ou=hosts,dc=nsd,dc=org" -h localhost "(uid=test)" with any -s > option I get entries in both nsdlog and hostslog even though the search should > just be in the "ou=hosts,dc=nsd,dc=org" database. > > Question is why I am still getting search entries in the nsdlog? Is this > expected behaviour? > Also, if I make a add to an object in "ou=hosts,,dc=nsd,dc=org" I get 3 > duplicate entries in both logs where I only expected to get entries in the > hostslog. If I change the rootdn of "ou=hosts,dc=nsd,dc=org" to be > "cn=root,ou=hosts,dc=nsd,dc=org" instead of "cn=root,dc=nsd,dc=org", I only get > 1 duplicate entry in the nsdlog (e.g. I only get the add entry, not the bind or > unbind entries as I am not binding to the rootdn in "dc=nsd,dc=org". > > Question is why I am still getting the add entry in nsdlog? Is this expected > behaviour? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#4545 bug in libldap
by hyc＠symas.com 12 Dec '06

12 Dec '06

hyc(a)symas.com wrote: > I haven't quite figured out everything that's going on, but this patch > definitely shows when it occurs in test036: OK, fixed in HEAD. By the way, the main problem appears to have already been fixed; slapd.3.log is now only (!) 360MB. This last patch (result.c 1.141) just cleans up two leaked requests. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

ITS#4545 bug in libldap
by hyc＠symas.com 12 Dec '06

12 Dec '06

I haven't quite figured out everything that's going on, but this patch definitely shows when it occurs in test036: Index: result.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/result.c,v retrieving revision 1.140 diff -u -r1.140 result.c --- result.c 3 Dec 2006 23:11:12 -0000 1.140 +++ result.c 12 Dec 2006 22:53:25 -0000 @@ -914,6 +914,10 @@ } if ( lr != NULL ) { + if ( tag == LDAP_RES_SEARCH_RESULT ) { + Debug( LDAP_DEBUG_TRACE, "request done: ld %p msgid %ld but mis-handled!\n", + (void *)ld, (long) id, 0 ); + } ldap_return_request( ld, lr, 0 ); lr = NULL; } The response is actually returned to the caller properly, but we never decide to "mark request completed." Setting a breakpoint here will let you poke around at it. v3ref is set to V3REF_TOAPP at this point. This should mean that the result included a referral and it will be returned to the caller, which means that we can dispose of the request, but we never do. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4777) translucent overlay breaks if first mod in modlist is a delete
by hyc＠symas.com 12 Dec '06

12 Dec '06

kuenne(a)rentec.com wrote: > Full_Name: Karsten Kuenne > Version: 2.3.30 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.223.241.248) > > > The following loop in translucent.c at around line 297 fails if the first mod in > the modlist is a delete and eventually crashes slapd: This is now fixed in HEAD, thanks for the report. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4777) translucent overlay breaks if first mod in modlist is a delete
by kuenne＠rentec.com 12 Dec '06

12 Dec '06

Full_Name: Karsten Kuenne Version: 2.3.30 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.223.241.248) The following loop in translucent.c at around line 297 fails if the first mod in the modlist is a delete and eventually crashes slapd: .... Debug(LDAP_DEBUG_TRACE, "=> translucent_modify: silently dropping delete: %s\n", m->sml_desc->ad_cname.bv_val, 0, 0); ==> for(mm = op->orm_modlist; mm->sml_next != m; mm = mm->sml_next); mm->sml_next = m->sml_next; m->sml_next = NULL; slap_mods_free(m, 1); .... I tried to come up with a fix but so far I always got a "Invalid modification" because I apparently got something wrong so I worked around it on the client side for now.

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 12 Dec '06

12 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="hyc(a)symas.com"> >>> ghenry(a)suretecsystems.com wrote: >>>> Full_Name: Gavin Henry >>>> Version: 2.3.30 >>>> OS: FC6 >>>> URL: >>>> http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>>> Submission from: (NULL) (212.159.59.85) >>>> >>>> >>>> Hi all, >>>> >>>> Monitoring section updated. Please review and provide feedback. >>> You use the term "subentries" in several places where I'm pretty sure >>> you mean "child entries"; "subentry" has a special meaning in >>> X.500/LDAP >>> that isn't relevant here. >> >> Sure, that's what I meant really ;-) >> >> I'll update it and send another patch. Or is there an easier way? > > Your original patch is already in CVS now. Just send a diff against the > CVS version. New version with TOC set to 3: http://www.suretecsystems.com/our_docs/admin_guide.patch Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4774) Add network timeout option to ldapsearch
by Kurt＠OpenLDAP.org 12 Dec '06

12 Dec '06

At 12:59 AM 12/12/2006, lukeh(a)padl.com wrote: >Full_Name: Luke Howard >Version: HEAD >OS: >URL: http://www.padl.com/~lukeh/openldap-HEAD-nto.diff >Submission from: (NULL) (203.13.32.80) > > >A customer had requested we add an option to ldapsearch to allow a network >timeout to be specified on the command line. > >A patch against HEAD is attached. > >I am aware that you can specify NETWORK_TIMEOUT in ldap.conf, and that free >command line options are precious. Given this, -e nettimeout=X might be better choice here. Or -o nettimeout=X.

1 0

(ITS#4776) slapo-chain(5) does not use the DN in the referral
by ando＠sys-net.it 12 Dec '06

12 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) When chasing a referral, if the DN in the referral differs from the one in the original request slapo-chain(5) disregards it and uses the original request DN. This behavior disagrees with that of the client library. p.

1 0

(ITS#4774) Add network timeout option to ldapsearch
by lukeh＠padl.com 11 Dec '06

11 Dec '06

Full_Name: Luke Howard Version: HEAD OS: URL: http://www.padl.com/~lukeh/openldap-HEAD-nto.diff Submission from: (NULL) (203.13.32.80) A customer had requested we add an option to ldapsearch to allow a network timeout to be specified on the command line. A patch against HEAD is attached. I am aware that you can specify NETWORK_TIMEOUT in ldap.conf, and that free command line options are precious.

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 11 Dec '06

11 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="hyc(a)symas.com"> >>> ghenry(a)suretecsystems.com wrote: >>>> Full_Name: Gavin Henry >>>> Version: 2.3.30 >>>> OS: FC6 >>>> URL: >>>> http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>>> Submission from: (NULL) (212.159.59.85) >>>> >>>> >>>> Hi all, >>>> >>>> Monitoring section updated. Please review and provide feedback. >>> You use the term "subentries" in several places where I'm pretty sure >>> you mean "child entries"; "subentry" has a special meaning in >>> X.500/LDAP >>> that isn't relevant here. >> >> Sure, that's what I meant really ;-) >> >> I'll update it and send another patch. Or is there an easier way? > > Your original patch is already in CVS now. Just send a diff against the > CVS version. Thanks. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ >

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by hyc＠symas.com 11 Dec '06

11 Dec '06

ghenry(a)suretecsystems.com wrote: > <quote who="hyc(a)symas.com"> >> ghenry(a)suretecsystems.com wrote: >>> Full_Name: Gavin Henry >>> Version: 2.3.30 >>> OS: FC6 >>> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >>> Submission from: (NULL) (212.159.59.85) >>> >>> >>> Hi all, >>> >>> Monitoring section updated. Please review and provide feedback. >> You use the term "subentries" in several places where I'm pretty sure >> you mean "child entries"; "subentry" has a special meaning in X.500/LDAP >> that isn't relevant here. > > Sure, that's what I meant really ;-) > > I'll update it and send another patch. Or is there an easier way? Your original patch is already in CVS now. Just send a diff against the CVS version. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 11 Dec '06

11 Dec '06

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. > > You use the term "subentries" in several places where I'm pretty sure > you mean "child entries"; "subentry" has a special meaning in X.500/LDAP > that isn't relevant here. Sure, that's what I meant really ;-) I'll update it and send another patch. Or is there an easier way? Thanks. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > > >

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by hyc＠symas.com 11 Dec '06

11 Dec '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.30 > OS: FC6 > URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch > Submission from: (NULL) (212.159.59.85) > > > Hi all, > > Monitoring section updated. Please review and provide feedback. You use the term "subentries" in several places where I'm pretty sure you mean "child entries"; "subentry" has a special meaning in X.500/LDAP that isn't relevant here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4773) syncrepl segfault with incorrect config
by ando＠sys-net.it 10 Dec '06

10 Dec '06

Adrian Bridgett wrote: > On Sat, Dec 9, 2006 at 22:29:50 +0100 (+0100), Pierangelo Masarati wrote: > >> It is already fixed in HEAD; fixing it in re23 might be too >> difficult to consider, so, since the correct behavior is clearly >> documented, it might be not worth the effort. >> > > Fair enough, I'm sure I searched through the bugs for syncrepl items > and didn't see anything, but I guess it was fixed outside of a bug > report which would explain it. > Well, AFAIR it was not fixed as a consequence of a bug report; rather, HEAD code provides support to tag overlays as specific for the global or per-database level, if their use is not appropriate at all levels. slapo-syncprov in HEAD checks if it's being instantiated at the right level, otherwise it bails out. What actually happens if it's instantiated at the wrong level, namely what causes the core dump you reported, is not ficed at all, as it makes no longer sense. That's what I meant when I said that fixing this issue in re23 might not be worth: support for tagging overlays and to check if they're appropriately instantiated is interspersed in many code changes which may not be trivial to isolate. p.

1 0

Re: (ITS#4773) syncrepl segfault with incorrect config
by adrian＠smop.co.uk 10 Dec '06

10 Dec '06

On Sat, Dec 9, 2006 at 22:29:50 +0100 (+0100), Pierangelo Masarati wrote: > It is already fixed in HEAD; fixing it in re23 might be too > difficult to consider, so, since the correct behavior is clearly > documented, it might be not worth the effort. Fair enough, I'm sure I searched through the bugs for syncrepl items and didn't see anything, but I guess it was fixed outside of a bug report which would explain it. Many thanks, Adrian -- Adrian Bridgett - adrian(a)smop.co.uk GPG key available on public key servers

1 0

Re: (ITS#4773) syncrepl segfault with incorrect config
by ando＠sys-net.it 09 Dec '06

09 Dec '06

adrian(a)smop.co.uk wrote: > Trying to add or delete entries with syncrepl overlay I was getting segfaults. > > I couldn't check against my test box (remote location, no power), but eventually > came across: > http://www.mail-archive.com/openldap-software@openldap.org/msg06772.html > > This was in fact the problem I had too - I had specified syncrepl early on > rather than after the database definition. Moving syncrepl into the correct > place fixed it. > > Two hours wasted trying to figure out what was wrong, it would be good to have > some error message in this case :-) > It is already fixed in HEAD; fixing it in re23 might be too difficult to consider, so, since the correct behavior is clearly documented, it might be not worth the effort. p.

1 0

(ITS#4773) syncrepl segfault with incorrect config
by adrian＠smop.co.uk 08 Dec '06

08 Dec '06

Full_Name: Adrian Bridgett Version: 2.3.29 OS: Linux (Debian) URL: Submission from: (NULL) (81.5.177.202) Trying to add or delete entries with syncrepl overlay I was getting segfaults. I couldn't check against my test box (remote location, no power), but eventually came across: http://www.mail-archive.com/openldap-software@openldap.org/msg06772.html This was in fact the problem I had too - I had specified syncrepl early on rather than after the database definition. Moving syncrepl into the correct place fixed it. Two hours wasted trying to figure out what was wrong, it would be good to have some error message in this case :-) The stack traces I got out weren't terribly helpful to me (from a debug build of 2.3.27 running on Debian sarge all up to date): #0 0xa7f3501f in lutil_debug (debug=255, level=4, fmt=0x4 <Address 0x4 out of bounds>) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/liblber/debug.c:63 #1 0x0807f71b in fe_op_modify () #2 0x0807f0f5 in fe_op_modify () (repeat of #2) #939 0x0807f0f5 in fe_op_modify () #940 0x0807f0f5 in fe_op_modify () #941 0x0807f0f5 in fe_op_modify () #942 0x080bf2fa in overlay_op_walk () #943 0x080bf3fd in overlay_op_walk () #944 0x080bf531 in overlay_op_walk () #945 0x0807e900 in do_modify () #946 0x0806960f in connection_done () #947 0xa7f46c28 in ldap_int_thread_pool_wrapper (xpool=0x24) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/libldap_r/tpool.c:478 #948 0xa7d51b63 in start_thread () from /lib/tls/libpthread.so.0 #949 0xa7ce018a in clone () from /lib/tls/libc.so.6 #0 0x0806fca8 in fe_op_add () #1 0x0806ff58 in fe_op_add () (repeat of #1) #11378 0x0806ff58 in fe_op_add () #11379 0x080bf2fa in overlay_op_walk () #11380 0x080bf3fd in overlay_op_walk () #11381 0x080bf591 in overlay_op_walk () #11382 0x0806f7af in do_add () #11383 0x0806960f in connection_done () #11384 0xa7f23c28 in ldap_int_thread_pool_wrapper (xpool=0x26) at /home/autobuild/builds/openldap2.3/openldap-2.3.27/libraries/libldap_r/tpool.c:478 #11385 0xa7d2eb63 in start_thread () from /lib/tls/libpthread.so.0 #11386 0xa7cbd18a in clone () from /lib/tls/libc.so.6 Please shout if you want any more info. Thanks for a great product, Adrian

1 0

(ITS#4772) SEGV during DEL/syncprov_qtask
by richton＠nbcs.rutgers.edu 07 Dec '06

07 Dec '06

Full_Name: Aaron Richton Version: 2.3.30 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061208-segv.txt Submission from: (NULL) (68.196.250.61) I realize I've already got #4723 open as "no idea why this is SEGV," but this trace looked notably different, so I'm filing separate. I'm going to continue debugging along the lines of #4723, which was leaning towards OpenSSL. But if anything jumps out at somebody from this trace, feel free to speak up. As it turns out, this was near a batch of a large number of DELs. Might be good to take a glance through slog or similar and see if a memory debugger comes up clean, especially with deletes...

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. >> >> Thanks, >> >> Gavin. >> >> (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) >> > At the moment the only comment I have is regarding back-monitor itself, > not the doc: I question the decision to define the monitor info > attributes as operational instead of user attributes. Requiring the use > of "+" to return all of the monitored info seems pretty unfriendly, > particularly since it causes the return of actual operational attributes > that are completely irrelevant to the purpose of monitoring. I.e., the > monitor info should be considered to be dynamically generated user > attributes, not operational attributes. OK. So what would be the next step, re-work it? Just let me know the changes so I can document them. There's nothing like documenting a moving target! ;-) Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by hyc＠symas.com 07 Dec '06

07 Dec '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.30 > OS: FC6 > URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch > Submission from: (NULL) (212.159.59.85) > > > Hi all, > > Monitoring section updated. Please review and provide feedback. > > Thanks, > > Gavin. > > (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) > At the moment the only comment I have is regarding back-monitor itself, not the doc: I question the decision to define the monitor info attributes as operational instead of user attributes. Requiring the use of "+" to return all of the monitored info seems pretty unfriendly, particularly since it causes the return of actual operational attributes that are completely irrelevant to the purpose of monitoring. I.e., the monitor info should be considered to be dynamically generated user attributes, not operational attributes. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4771) Memory Leak in connection.c
by marco.dettorre＠sys-net.it 07 Dec '06

07 Dec '06

Full_Name: Marco D'Ettorre Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There is a memory leak in connection_op_queue (servers/slapd/connection.c +1821). A fix for this: --- servers/slapd/connection.c.orig 2006-12-07 18:30:14.000000000 +0100 +++ servers/slapd/connection.c 2006-12-07 19:07:09.000000000 +0100 @@ -1751,6 +1751,9 @@ { op->o_conn->c_sasl_bindop = NULL; + ch_free( op->o_callback ); + op->o_callback = NULL; + return SLAP_CB_CONTINUE; } Regards Marco

1 0

(ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

Full_Name: Gavin Henry Version: 2.3.30 OS: FC6 URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch Submission from: (NULL) (212.159.59.85) Hi all, Monitoring section updated. Please review and provide feedback. Thanks, Gavin. (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

freeing mem from ldap_parse_result
by Dale Moore 06 Dec '06

06 Dec '06

I'm trying to write exceptionally correct code with no memory leaks. I'm calling ldap_parse_result(3). And of course one of the parameters is char ***referalsp; The documentation says to free the memory allocated to this data structure by calling the routine ldap_value_free(). But the routine ldap_value_free() is deprecated. My options are - Compile with -DLDAP_DEPRECATED = I hate to create software using deprecated API - Call ber_memvfree((void **)) instead of ldap_value_free() - Use a different mechanism to parse the message The bug I'm reporting here is - a problem with the documentation or - in the premature deprecation of ldap_value_free or - the lack of deprecation of ldap_parse_ressult() I'm not sure which. Looking for advice. Dale Moore

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs