openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(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 24 Dec '06

24 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 24 Dec '06

24 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 24 Dec '06

24 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs