- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs