openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: ldap_int_sasl_bind() and canonical Kerberos names
by Quanah Gibson-Mount 24 Oct '07

24 Oct '07

--On October 24, 2007 10:42:43 PM +0100 Simon Wilkinson <simon(a)sxw.org.uk> wrote: > >> >> The patch unconditionally disables hostname canonicalisation for >> the sasl client. > > I think this will break GSSAPI connections to LDAP servers that are > behind DNS round robin style load balancers. > > Assume that you have 'ldap' that is a CNAME for ldap-1 and ldap2. The > LDAP library initiates a connection to 'ldap', and DNS points it to > 'ldap-1'. Providing you ask SASL to set up a connection to 'ldap-1', > you're fine (this is what the code does at the moment). However, if you > ask the SASL library for a connection to 'ldap' (this is what your change > does, as far as I can tell), and the library does a canonicalisation step > (as most Kerberos implementations currently do), it will get 'ldap-2' > back from the DNS. So, you end up trying to negotiate a SASL connection > with 'ldap-2', when you're actually connected to 'ldap-1'. This tends not > to work. Simon, Thanks! That'd completely destroy Stanford's setup. Ouch. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

servers/slapd/overlays/slapover.txt
by Gavin Henry 24 Oct '07

24 Oct '07

Anymore notes anywhere? CVS says: 1.1 Sat Mar 20 19:30:57 2004 UTC; 3 years, 7 months ago by hyc Overlay API notes. work in progress, please comment. It references docs that don't exist. Thanks. -- 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/

2 2

ldap_int_sasl_bind() and canonical Kerberos names
by Geert Jansen 24 Oct '07

24 Oct '07

Hi, at the moment, ldap_int_sasl_bind() uses ldap_host_connected_to() to get a fully qualified host name that will be used as the server fqdn with the sasl client. This fqdn is acquired by ldap_host_connected_to() using a reverse DNS lookup. The code explains why this is done: /* * do a reverse lookup on the addr to get the official hostname. * this is necessary for kerberos to work right, since the official * hostname is used as the kerberos instance. */ Using reverse DNS names has however always been problematic. The following comment is from the MIT code: (lib/krb5/os/sn2princ.c): /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ To address this issue, a draft RFC has been written (draft-ietf-krb-wg-kerberos-referrals-09) that adds server-side name canonicalisation to Kerberos and therefore removes the need to use reverse DNS for this. This draft has been implemented in MIT Kerberos 1.6. The feature is enabled by default and if you want to use it you probably want to set "rdns = false" in [libdefaults] to disable canonicalisation based on reverse DNS. Disabling these reverse DNS lookups however is not possible at the moment with the OpenLDAP client as explained above. I did a quick patch to have ldap_int_sasl_bind() use a value based on the LDAP option LDAP_OPT_HOST_NAME and that worked as expected. Would you guys be interested in a patch that allows the disabling hostname canonicalisation based on reverse DNS? The patch would need to make this behaviour optional and non-default as some real workloads may break and also it would somehow need to handle LDAP URIs with multiple hosts. Regards, Geert Jansen

2 3

syncrepl fails on RE_2_4
by Dieter Kluenter 24 Oct '07

24 Oct '07

3 3

Re: commit: openldap-guide/admin appendix-ldap-result-codes.sdf aspell.en.pws dbtools.sdf install.sdf overlays.sdf replication.sdf
by Gavin Henry 24 Oct '07

24 Oct '07

> Log Message: > Pull down latest guide updates from HEAD Sorry, should have done that. Gavin.

1 0

Any more upgrading issues we can thing of (2.3.x -> 2.4.x)?
by Gavin Henry 24 Oct '07

24 Oct '07

Need anything more in appendix-upgrading.sdf? I guess we'll see when we're out of Beta. 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

last call for testing 2.3, 2.4
by Quanah Gibson-Mount 24 Oct '07

24 Oct '07

Please test current tip for 2.3 and 2.4. All known issues are believed fixed at this time. If there are no problem reports by tomorrow noon my time, I plan on tagging for release 2.3.39 and 2.4.6. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 8

Re: thread pools, performance
by Howard Chu 23 Oct '07

23 Oct '07

Rick Jones wrote: > There are definitely interrupt coalescing settings available with tg3-driven > cards, as well as bnx2 driven ones: > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Really nice work there, thanks. > Also, if the platform and the I/O card support it, and it isn't the default, MSI > or MSI-X interrupts are often lower overhead than legacy INTA irq's. They can > also allow - on NICs which have the support - the interrupts to be spread > intelligently (well, semi-intelligently at least :) across multiple cores. For reference, the machine is a Celestica A8440. http://www.amd.com.cn/CHCN/assets/content_type/DownloadableAssets/A8440_Dat… The ethernet controllers are on a hub attached by HyperTransport to a single processor, I don't think you can usefully distribute the interrupts to anything beyond that socket. > Although, if there is still 10% idle, that probably needs to go next :) Heh heh. The 80/20 rule hits this with a vengeance. That's "10%" of "800%" total, which means really only about 1.2% of a CPU, which is almost totally indistinguishable from measurement error in the oprofile results. This is all intuition (guesswork) now, no more obvious hot spots left to attack. Maybe if I'm really bored over the holidays I'll spend some time on it. (Not likely.) >> Reminds me of the old leapfrogging games with Excelan ethernet cards and >> their onboard TCP engines (15+ years ago), allowing machines of that >> time to hit a whopping 250KB/sec on 10Mbit ethernet. A couple years >> later the main CPUs got fast enough to do 500KB/sec without using the >> cards' "accelerators." It's been many years since I saw another NIC with >> onboard TCP engine after that, but they're on the market now... > > Don't forget the "NFS accelerators" from ca 1990 and where they are today :) I think I have a few in the parts bin... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Please test RE24
by Howard Chu 23 Oct '07

23 Oct '07

I don't remember if we posted this already or not. We're prepping 2.4.6 for release; please test RE24 and submit any problems you encounter to the ITS. Likewise, RE23 looks about ready. If you're interested in 2.3.39 please test and report results for RE23 as well. Currently all tests in RE24 pass for me on OpenSUSE 10.2 x86_64 and FedoraCore6 x86_64. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 6

ITS#4943 tpool.c, thread pools
by Howard Chu 20 Oct '07

20 Oct '07

I presume we can close this ITS now. I've been running some tests on a quad-processor AMD system, and seeing a lot of mutex contention in the frontend. It looks like the current threadpool and connection manager architecture are a bad fit for a NUMA system like this. I'm planning to add support for multiple thread pools (one per CPU would be the idea) and multiple listener threads to slapd. As a first step, after 2.4.6 is released, I'm going to unifdef the SLAPD_LIGHTWEIGHT_DISPATCHER symbol and delete the old dispatcher code. Based on some experimental changes I've already made, I see a difference between 25K auths/sec with the current code, vs 39K auths/sec using separate thread pools. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel