Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.66.157.14) A user of the Debian OpenLDAP package requested support in the command-line utilities for using SRV entries to locate the local LDAP server. My understanding of the suggestion is that if one didn't specify -h or -H, a SRV record lookup would be tried before falling back to localhost. (You may not want to change the default behavior, though, and add another switch.) For the full suggestion, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 It looks like much of the necessary code is already there in libldap, and looking at the libldap code, you could also intuit the correct server based on any search base provided.
On Jun 2, 2007, at 5:31 AM, rra@stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > A user of the Debian OpenLDAP package requested support in the > command-line > utilities for using SRV entries to locate the local LDAP server. My > understanding of the suggestion is that if one didn't specify -h or > -H, a SRV > record lookup would be tried before falling back to localhost. > (You may not > want to change the default behavior, though, and add another switch.) One could use DNS SRV on the domain provided by -H, or by ldap.conf (5), and use it present, with (likely best) or without an option to enable the behavior. One could also use DNS SRV on the domain associated with the baseObject/target DN with an option to enable this behavior. That is, ldapsearch -b "dc=example,dc=org" would cause a DNS SRV lookup on example.org. This is what the DNSSRV backend does. Not sure adding to the command line tools would be especially useful. That is, I don't think DNS SRV fits well in the common use pattern of command line tools. But someone implements this behind an option, it shouldn't do any harm. Lastly I note that the domain to use DNS SRV should come from the user (or application entity), not the local host. Using the local resolver configuration is a really bad idea. -- Kurt > > For the full suggestion, see: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 > > It looks like much of the necessary code is already there in > libldap, and > looking at the libldap code, you could also intuit the correct > server based on > any search base provided. > >
moved from Incoming to Software Enhancements
changed notes changed state Open to Test
Committed to HEAD. Command-line clients now use DNS SRV to look up the host names related to a DN and build a list of URIs for subsequent use. To trigger, use -H "<proto>:///DN". The <host> portion must be empty, and a DN must be present. The DN must be in the "dc=<component>" form; it's turned into a domain and the host list is looked up using DNS SRV. After that, a list of URIs is built using the returned host/ports, and using <proto> as the LDAP scheme. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
ando <ando@sys-net.it> writes: > Committed to HEAD. Command-line clients now use DNS SRV to look up the > host names related to a DN and build a list of URIs for subsequent use. > To trigger, use -H "<proto>:///DN". The <host> portion must be empty, > and a DN must be present. The DN must be in the "dc=<component>" form; > it's turned into a domain and the host list is looked up using DNS SRV. > After that, a list of URIs is built using the returned host/ports, and > using <proto> as the LDAP scheme. Thank you! I've forwarded this information to the original Debian bug reporter who was interested in the feature in the hopes that he'll be able to test and provide feedback on the implementation. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
moved from Software Enhancements to Development
changed notes changed state Test to Release
changed state Release to Closed
moved from Development to Archive.Development
committed to HEAD/RE24