openldap-devel

openldap-devel@openldap.org

1418 discussions

RE24 connection code round 2
by Quanah Gibson-Mount 28 Jan '09

28 Jan '09

The connection code has been reworked a bit more since the last call for testing. Please test heavily with current RE24 CVS. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 6

RE24 connection code reworking
by Quanah Gibson-Mount 28 Jan '09

28 Jan '09

RE24 has had some code reworking in the connections area, due to some race conditions that were being triggered. It would be useful if people could test current RE24 to see if they encounter issues. There are still a number of outstanding issues that need to be resolved before 2.4.14 will be released, but I'd appreciate a head start on making sure that at least make test is passing for folks with this new code in place. So far, it does for both Howard and I, but Michael Ströder has reported failures in his OpenSuSE builds that we can't reproduce. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

10 37

autoconf
by Howard Chu 27 Jan '09

27 Jan '09

Prior to ITS#5888 we have been using autoconf 2.59 to generate our configure script. During the commits of #5888 autoconf 2.61 was used. Is there any particular reason to stick to 2.59, or to change to 2.61, at this point in time? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 4

Re: RE24 connection code reworking
by Howard Chu 26 Jan '09

26 Jan '09

Pierangelo Masarati wrote: > Howard Chu wrote: > >> What kind of system are you running on? Linux / multiprocessor? > > No, right now that's just my poor man's laptop (Intel(R) Pentium(R) M > processor 2.26GHz, UP) running Linux (2.6.18, CentOS 5.2). Tomorrow I > can check on better hardware, including SMP (quad Opteron), but I don't > think that's a problem. Of course it's using epoll(). Can you try a newer Linux kernel? The last useful log entries are: do_syncrep2: rid=001 (-1) Can't contact LDAP server do_syncrepl: rid=001 retrying (4 retries left) connection_read(10): no connection! The do_syncrep2 message is printed at syncrepl.c:1208. At that point both err and rc are -1. It'll fall into line 1217 and tear down the connection, which would remove it from epoll's control. So I don't understand why epoll is waking up repeatedly after that point, unless perhaps there's a kernel bug in epoll... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: RE24 connection code reworking
by William Jojo 26 Jan '09

26 Jan '09

---- Original message ---- >Date: Sat, 24 Jan 2009 16:15:06 -0800 >From: Howard Chu <hyc(a)symas.com> >Subject: Re: RE24 connection code reworking >To: Pierangelo Masarati <ando(a)sys-net.it> >Cc: Quanah Gibson-Mount <quanah(a)zimbra.com>,openldap-devel(a)openldap.org > >Pierangelo Masarati wrote: >> Pierangelo Masarati wrote: >> >>> I ran 30 times test045 with HEAD and got no failures. Then re24 failed >>> after 44 runs with the backtrace below (identical to the previous ones). > >I got thru 80 runs of test045 on HEAD (prior to my syncrepl patch) and then >slapd hung on shutdown, with a deadlock between connections_shutdown(), >connection_closing(), and send_ldap_ber(). So, still tinkering with this. > Ok, make test runs flawlessly on AIX 5.3 with GCC 4.2.3, BDB 4.6.21.3, Cyrus SASL 2.1.22. How can I do successive runs of a specific test such as you've described here? Wait a second, I pulled down OPENLDAP_REL_ENG_2_4 should I be grabbing HEAD for these tests? Please try to overlook my ignorance, just want to help :-) Cheers, Bill

4 8

Re: TLS cleanup
by Howard Chu 25 Jan '09

25 Jan '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> Pierangelo Masarati wrote: >>> Howard Chu wrote: >>>> So, back to the question of libldap's TLS support... The alternate code >>>> in HEAD allows multiple TLS implementations to be used at once. The idea >>>> here was that a single libldap binary would be able to coexist with >>>> multiple apps even if they explicitly used different TLS libraries >>>> themselves. In practice I'm not sure that's so important, since probably >>>> few apps are aware enough to even make that choice. The other downside >>>> of this approach is that the meaning of SSL and SSL_CTX handles in >>>> libldap changed (they had to be wrapped so we could insert a tag >>>> identifying which implementation went with which handle). >>>> >>>> One possibility here is to preserve the old TLS options for OpenSSL >>>> only, and make them fail on the other implementations, and introduce new >>>> TLS options just for manipulating the generic handles. >>>> >>>> Another choice here is to keep the modular layout but still only support >>>> one implementation at a time, chosen at compile time. Then we don't need >>>> the identifying tag in each session and context handle. >>> I favor the second option. >> One implementation chosen at compile time? > > Yes. As you said, it is very unlikely that one needs to use more than > one. I do not object to having more than one compiled in, or even more > than one usable, but is it really worth the effort? I suppose since the code was already written, there wasn't much more effort to consider. But without dynamic loading it's probably moot, since the people who care about using non-OpenSSL would never link more than one into their build anyway. So I've stripped all that out and gone with the single approach... I still see a few warts with the visible implementation; the few functions we added that need an SSL handle (get_strength, get_DN, etc) should not use an SSL handle. We should have never have exposed the underlying SSL/SSL_CTX handles in our own APIs. get_strength and get_dn could just as easily have passed the Sockbuf pointer around instead, and let the library internals find the SSL handles themselves. Of course, these are all ldap_pvt_*, so we may still decide to change them in this respect. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

TLS cleanup
by Howard Chu 25 Jan '09

25 Jan '09

So, back to the question of libldap's TLS support... The alternate code in HEAD allows multiple TLS implementations to be used at once. The idea here was that a single libldap binary would be able to coexist with multiple apps even if they explicitly used different TLS libraries themselves. In practice I'm not sure that's so important, since probably few apps are aware enough to even make that choice. The other downside of this approach is that the meaning of SSL and SSL_CTX handles in libldap changed (they had to be wrapped so we could insert a tag identifying which implementation went with which handle). One possibility here is to preserve the old TLS options for OpenSSL only, and make them fail on the other implementations, and introduce new TLS options just for manipulating the generic handles. Another choice here is to keep the modular layout but still only support one implementation at a time, chosen at compile time. Then we don't need the identifying tag in each session and context handle. Comments? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

back-slapd retry issue with ldaps
by Quanah Gibson-Mount 25 Jan '09

25 Jan '09

This was reported in Debian's bug tracker: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512693> I didn't see a documented fix in the CHANGES file that would resolve this, but didn't want to file an ITS until Pierangelo could confirm this was a real issue or not. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 3

Re: RE24 connection code reworking
by Brett ＠Google 24 Jan '09

24 Jan '09

"make test" works fine on SuSE 10.3 x86_64 .. using default os's bdb 4.5 and also specifically against bdb 4.7 + patches on SuSE 11.0 i686 using bdb 4.7 + patches.. "make test" fails at test047: >>>>> Starting test047-ldap ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test047-ldap: line 138: kill: (19224) - No such process >>>>> ./scripts/test047-ldap failed (exit 255) make[2]: *** [hdb-yes] Error 255 make[2]: Leaving directory `/home/maxfieb/keep-ldap/openldap-src-RE24/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/maxfieb/keep-ldap/openldap-src-RE24/tests' make: *** [test] Error 2 Cheers Brett http://www.agaveblue.org/projects/x10/download.html On Sat, Jan 24, 2009 at 3:43 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > RE24 has had some code reworking in the connections area, due to some race > conditions that were being triggered. It would be useful if people could > test current RE24 to see if they encounter issues. There are still a number > of outstanding issues that need to be resolved before 2.4.14 will be > released, but I'd appreciate a head start on making sure that at least make > test is passing for folks with this new code in place. So far, it does for > both Howard and I, but Michael Ströder has reported failures in his OpenSuSE > builds that we can't reproduce. > > Thanks, > Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

3 4

[Fwd: Re: (ITS#5881) referral problem with refreshAndPersist mode]
by Howard Chu 24 Jan '09

24 Jan '09

Unfortunately, I think the spec is broken here. There's no way for the consumer to record the references it receives, because they're not accompanied by the DN of the entry that triggered the reference. It would have made more sense for the provider to send the references uninterpreted, as regular LDAP entries. Any suggestions? -------- Original Message -------- Subject: Re: (ITS#5881) referral problem with refreshAndPersist mode Date: Sat, 24 Jan 2009 05:12:08 GMT From: hyc(a)symas.com To: openldap-its(a)openldap.org joao.alfredo(a)gmail.com wrote: > Full_Name: João Alfredo > Version: 2.4.13 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.189.117.10) > > > I am using a refreshAndPersist replication mode on OpenLdap 2.4.13. > > When I add referral OU on Master, this entrie is not replicate to Consumer. > > My test.ldif: > dn: ou=MUNICIPIOS,dc=pr > ou: MUNICIPIOS > ref: ldap://<IP>/ou=MUNICIPIOS,dc=pr > objectClass: referral > objectClass: extensibleObject > dc: MUNICIPIOS > Logs on consumer side: > Jan 8 17:50:15 ecelepar10173 slapd[2722]: do_syncrep2: rid=000 reference > received error Interesting, you've found a bug that has been present since syncrepl's code was first written in 2003. The syncrepl code assumes that it will only receive LDAP entries from the provider. But according to RFC4533, references are supposed to be sent as-is and stored by the consumer. The syncprov overlay obeys the spec and sends references correctly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel