openldap-devel January 2009

openldap-devel@openldap.org

18 participants
21 discussions

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

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

23 Jan '09

---- Original message ---- >Date: Fri, 23 Jan 2009 09:43:18 -0800 >From: Quanah Gibson-Mount <quanah(a)zimbra.com> >Subject: RE24 connection code reworking >To: openldap-devel(a)openldap.org > >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. > Not used to testing from OpenLDAP active tree, but I can do some work for testing on AIX. Do you have a quick link for pulling a copy of the active tree (rsync, cvs, git?) Cheers, Bill >Thanks, >Quanah > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration >

2 1

Re: commit: openldap-guide/admin replication.sdf
by Howard Chu 22 Jan '09

22 Jan '09

ghenry(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > replication.sdf 1.71 -> 1.72 > > Log Message: > (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances. See #5874. MMR is required to work in this circumstance, and the bug needs to be fixed. -- -- 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

back-ldif in HEAD with test011
by Quanah Gibson-Mount 20 Jan '09

20 Jan '09

I got failure because the entries were in a different order: [quanah@freelancer testrun]$ diff -u ldapsearch.flt ldif.flt --- ldapsearch.flt 2009-01-20 13:50:56.000000000 -0800 +++ ldif.flt 2009-01-20 13:50:56.000000000 -0800 @@ -14,15 +14,6 @@ telephoneNumber: +1 313 555 1817 associatedDomain: example.com -dn: cn=Manager,dc=example,dc=com -objectClass: person -cn: Manager -cn: Directory Manager -cn: Dir Man -sn: Manager -description: Manager of the directory -userPassword:: c2VjcmV0 - dn: ou=People,dc=example,dc=com objectClass: organizationalUnit objectClass: extensibleObject @@ -105,6 +96,15 @@ facsimileTelephoneNumber: +1 313 555 2756 telephoneNumber: +1 313 555 8232 +dn: cn=Manager,dc=example,dc=com +objectClass: person +cn: Manager +cn: Directory Manager +cn: Dir Man +sn: Manager +description: Manager of the directory +userPassword:: c2VjcmV0 + dn: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Mark Elliot We may need to change the expectations for this test if ldif is the database. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 1

Re: commit: ldap/servers/slapd connection.c
by Howard Chu 12 Jan '09

12 Jan '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > connection.c 1.421 -> 1.422 > > Log Message: > ITS#5835 tentative fix - remove bogus call to connection_close(). > Note that with this change, all calls to connection_closing() and > connection_close() always occur in pairs - probably the two > functions should be collapsed into one. Ugh, no, that's not true. connection_closing() is also called by itself in result.c if a write fails, and connection_resched() probably was supposed to catch that too. Need to study this a bit more. -- -- 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

slapd.conf vs slapd.d in the docs
by Gavin Henry 12 Jan '09

12 Jan '09

Hi all, I'm just wondering how we move forward with the docs and the config backend. Should we document examples with both, or only slapd.d or move example config to the appendix and have an appendix for each format so it doesn't clutter the guide. My feeling is the last option is best. Thoughts? Gavin. -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2009