(ITS#4793) connection_get race condition on Windows
by hyc＠OpenLDAP.org
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.
16 years, 9 months
Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com
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/
16 years, 9 months
Re: ITS#3707 filters
by hyc＠symas.com
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/
16 years, 9 months
Re: ITS#3707 filters
by hyc＠symas.com
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/
16 years, 9 months
(ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by azia＠techxact.com
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
16 years, 9 months
Re: (ITS#4790) re23 hangs during shutdown after test033
by hyc＠symas.com
---- <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
16 years, 9 months
(ITS#4791) privileged connections handling in proxy backends
by ando＠sys-net.it
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.
16 years, 9 months
(ITS#4790) re23 hangs during shutdown after test033
by ando＠sys-net.it
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.
16 years, 9 months
Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it
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
------------------------------------------
16 years, 9 months
