Bug 490476 - RFE: autofs should DNS for SRV records in order to locate LDAP server
RFE: autofs should DNS for SRV records in order to locate LDAP server
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.3
All Linux
low Severity low
: ---
: ---
Assigned To: Ian Kent
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-16 12:25 EDT by Ondrej Valousek
Modified: 2009-09-02 07:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, autofs could use the LDAP server on a network only if the location of the LDAP server were specified manually. Now, if no LDAP server is specified, autofs can look up domain SRV server records to make LDAP connections. This functionality simplifies the use of autofs on networks where an LDAP server is available.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:59:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Dependency for SRV server lookup patch (7.58 KB, patch)
2009-03-31 23:26 EDT, Ian Kent
no flags Details | Diff
Patch to allow "ldap[s]:///<domain dn>" as a valid LDAP_URI and lookup domain SRV server records for LDAP connections (21.73 KB, patch)
2009-04-01 12:56 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Ondrej Valousek 2009-03-16 12:25:35 EDT
Description of problem:
In case of using LDAP repository for automounter maps, it would be nice if the automounter was able to make use of SRV records in
DNS for locating LDAP servers on the network. It should follow RFC2782 regarding this.
Note: it has already been implemented in both openldap utilities (check the -H parameter for ldapsearch at http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html) and nss_ldap library by PADL so I guess automounter developers could take the existing code from these to implement this feature.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:
automounter does not work if no ldap server is specified for maps stored in ldap repository.

Expected results:
In case of no ldap server is specified, autofs uses the specified DN to build a DNS query to find the expropriate ldap server on the network. 

Additional info:
http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html
http://www.ietf.org/rfc/rfc2782.txt
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173
Comment 1 Ondrej Valousek 2009-03-17 07:56:26 EDT
Update:
autofs could use libldap and functions
ldap_dn2domain
ldap_domain2hostlist
defined there to achieve this functionality...
Comment 2 Ian Kent 2009-03-17 09:11:19 EDT
(In reply to comment #1)
> Update:
> autofs could use libldap and functions
> ldap_dn2domain
> ldap_domain2hostlist
> defined there to achieve this functionality...  

I have had a bit of a look around regarding this.

The code in nss_ldap is not GPL and so will not be used.
At this point I think this should be done internally to the
ldap library, not in autofs.

If it is done in autofs then it may be possible to use the
ldap library routines but (as is common) these functions
aren't included in man pages of the package documentation
I have so I'm not clear on the status of these functions,
let alone how to use them.

Also, the semantic requirements of the RFE have not been
described so they can be discussed and possibly agreed.
Comment 3 Ondrej Valousek 2009-03-18 06:56:45 EDT
Document about Open Solaris name services discovery:
http://opensolaris.org/os/project/duckwater/Documentation/ns-discovery/
Perhaps we should be consistent with this, too.
Comment 4 Ian Kent 2009-03-19 21:12:13 EDT
For the record:

Ondrej Valousek wrote:
> 
>> Strange ... I seem to remember accepting this same argument a few 
>> times in the past and ending up getting myself a rather large headache 
>> when complains came in. I'm quite wary of this now.
> Ok, frankly speaking you are right. The best method would be to:
> - remember that we got the host list from dns and not a config file
> - if yes, monitor serial number of the zone in the SOA record
> - reload the configuration if the serial number changed

I don't think that monitoring the serial number would be effective as I think the zone covers a lot more than just the SRV records. In any case monitoring DNS would generate a bunch of network traffic that shouldn't be needed.

Re-loading the configuration needs to be done outside the lookup module but the SRV lookup needs to be done within the lookup module, another problem.

I think the better idea is to specify the domain dn in the configuration (since that won't change often, if at all) using something like LDAP_URI="ldap:///dn=themaw,dc=net" and use the ":///" to trigger the SRV lookup. The problem then is that I connect to the LDAP server on every lookup which would lead to a DNS query every time. So that will need to change to using a persistent LDAP connection, since once we are connected to a server we shouldn't have to worry about updates to the list, at least until we need to connect again.

Anyway, I've done some initial work on it but there is a bit more to do to make it happen. The persistent LDAP connection is a bit tricky, for some not so obvious reasons, but is something I need to do anyway along with sorting out a problem with reconnecting, so I'm not sure yet when I'll have something.

Ian
Comment 5 Ian Kent 2009-03-30 22:41:42 EDT
(In reply to comment #4)
> For the record:
> 
> Ondrej Valousek wrote:
> > 
> >> Strange ... I seem to remember accepting this same argument a few 
> >> times in the past and ending up getting myself a rather large headache 
> >> when complains came in. I'm quite wary of this now.
> > Ok, frankly speaking you are right. The best method would be to:
> > - remember that we got the host list from dns and not a config file
> > - if yes, monitor serial number of the zone in the SOA record
> > - reload the configuration if the serial number changed
> 
> I don't think that monitoring the serial number would be effective as I think
> the zone covers a lot more than just the SRV records. In any case monitoring
> DNS would generate a bunch of network traffic that shouldn't be needed.
> 
> Re-loading the configuration needs to be done outside the lookup module but the
> SRV lookup needs to be done within the lookup module, another problem.
> 
> I think the better idea is to specify the domain dn in the configuration (since
> that won't change often, if at all) using something like
> LDAP_URI="ldap:///dn=themaw,dc=net" and use the ":///" to trigger the SRV
> lookup. The problem then is that I connect to the LDAP server on every lookup
> which would lead to a DNS query every time. So that will need to change to
> using a persistent LDAP connection, since once we are connected to a server we
> shouldn't have to worry about updates to the list, at least until we need to
> connect again.
> 
> Anyway, I've done some initial work on it but there is a bit more to do to make
> it happen. The persistent LDAP connection is a bit tricky, for some not so
> obvious reasons, but is something I need to do anyway along with sorting out a
> problem with reconnecting, so I'm not sure yet when I'll have something.

As Jeff Moyer points out upstream, we didn't use persistent
connections originally because having many autofs clients keeping
connections open could cause a problem for servers.

The better way to handle this is to use the TTL (maximum time the
entry should be cached) in the SRV RR record. If that value isn't
set then we should use a fairly long default time (say 1 hour) as
these entries shouldn't change very often.

Ian
Comment 7 Ian Kent 2009-03-31 23:26:31 EDT
Created attachment 337432 [details]
Dependency for SRV server lookup patch
Comment 8 Ian Kent 2009-04-01 12:56:01 EDT
Created attachment 337582 [details]
Patch to allow "ldap[s]:///<domain dn>" as a valid LDAP_URI and lookup domain SRV server records for LDAP connections
Comment 9 Ian Kent 2009-04-02 05:05:58 EDT
A test build including the patches above has been done
for this request.

It can be found at:
http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.102.bz490476.1/

I'm not sure even if this will function properly.
Could you try it out please.

Ian
Comment 10 Ondrej Valousek 2009-04-03 05:28:30 EDT
I tried and it works correctly for me on both RH5 and F10.
Couple of points (sorted by importance) though:
1. When LDAP_URI="ldap:///" or no LDAP_URI is provided, we should possibly try to autoconfigure and perform SRV query on domain as returned by dnsdomainname.
2. When invalid search_base is provided we should probably print something else than "lookup(ldap): couldn't initialize LDAP connection to ldap:///<some_dn>"
3. The check with ldap_dn2domain() and the back ldap_domain2dn() with the warning "Domain dn does not match supplied dn" seems to me redundant and misleading. Instead, I would more welcome some simple info like "Performing SRV lookup on domain <domain>"
4. the function names ads_dns_lookup_srv() and ads_dns_parse_rr_srv() which appear in logs look too Samba-ish. But this is really very minor cosmetic thing :-)
Comment 11 Ondrej Valousek 2009-04-03 05:45:07 EDT
Update:
Problem #2 has been resolved as per autofs-5.0.3-42.src.rpm
Comment 12 Ian Kent 2009-04-03 09:39:15 EDT
(In reply to comment #10)
> I tried and it works correctly for me on both RH5 and F10.
> Couple of points (sorted by importance) though:
> 1. When LDAP_URI="ldap:///" or no LDAP_URI is provided, we should possibly try
> to autoconfigure and perform SRV query on domain as returned by dnsdomainname.

Maybe, I'll have a look at this.

> 2. When invalid search_base is provided we should probably print something else
> than "lookup(ldap): couldn't initialize LDAP connection to ldap:///<some_dn>"
> 3. The check with ldap_dn2domain() and the back ldap_domain2dn() with the
> warning "Domain dn does not match supplied dn" seems to me redundant and
> misleading. Instead, I would more welcome some simple info like "Performing SRV
> lookup on domain <domain>"

Yes, this was I think a misunderstanding on my part, due to a
misunderstanding on your part !! I'll replace that with a debug
log message.

> 4. the function names ads_dns_lookup_srv() and ads_dns_parse_rr_srv() which
> appear in logs look too Samba-ish. But this is really very minor cosmetic thing
> :-)  

That's because it is Samba code. I could get rid of the "ads_"
prefix I suppose.

Ian
Comment 13 Ian Kent 2009-04-03 10:24:58 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > I tried and it works correctly for me on both RH5 and F10.
> > Couple of points (sorted by importance) though:
> > 1. When LDAP_URI="ldap:///" or no LDAP_URI is provided, we should possibly try
> > to autoconfigure and perform SRV query on domain as returned by dnsdomainname.
> 
> Maybe, I'll have a look at this.

If LDAP_URI is not set then absolutely not.
That is an indication that the user wants to use the settings
of the LDAP library configuration. Changing that will change
expected behaviour.
Comment 14 Ondrej Valousek 2009-04-03 10:55:03 EDT
> If LDAP_URI is not set then absolutely not.
> That is an indication that the user wants to use the settings
> of the LDAP library configuration. Changing that will change
> expected behaviour.
Ok, to be more precise, I meant when no LDAP_URI && no URI in the LDAP library configuration found...
Comment 15 Ian Kent 2009-04-03 12:13:52 EDT
(In reply to comment #14)
> > If LDAP_URI is not set then absolutely not.
> > That is an indication that the user wants to use the settings
> > of the LDAP library configuration. Changing that will change
> > expected behaviour.
> Ok, to be more precise, I meant when no LDAP_URI && no URI in the LDAP library
> configuration found...  

No, that belongs to the LDAP library not autofs.

We don't look in files that belong to other packages.
If the LDAP library changed one day or if a distribution
started using a different implementation that would just add
extra hassle. Not only that, there's no way to know where
that file may be located on a given distribution.
Comment 16 Ondrej Valousek 2009-04-16 12:32:25 EDT
Ok, to make myself more clear:
Autofs looks for setting in the
/etc/openldap/ldap.conf if no settings is found there, it looks in /etc/sysconfig/autofs, right?

So if we find no LDAP_URI setting in /etc/sysconfig/autofs, we look for
URI setting in /etc/openldap/ldap.conf.
Would it make a sense to perform SRV lookup against the default DNS domain as returned by 'dnsdomainname' if we find no URI
here either?
Comment 17 Ian Kent 2009-04-17 00:30:00 EDT
(In reply to comment #16)
> Ok, to make myself more clear:
> Autofs looks for setting in the
> /etc/openldap/ldap.conf if no settings is found there, it looks in
> /etc/sysconfig/autofs, right?

No that's not right and I never said the it was this way, as I've
already told you in private email.

If the LDAP_URI is not set then the calls that autofs makes to
the LDAP client library will cause the LDAP library to consult
its configuration in /etc/openldap/ldap.conf.

> 
> So if we find no LDAP_URI setting in /etc/sysconfig/autofs, we look for
> URI setting in /etc/openldap/ldap.conf.
> Would it make a sense to perform SRV lookup against the default DNS domain as
> returned by 'dnsdomainname' if we find no URI
> here either?  

No, we can't do that, it would change the current expected behaviour
and we have no way of knowing whether URI is set or not.
Comment 18 Ondrej Valousek 2009-04-17 03:10:59 EDT
Aha - now I understand - thanks for the clarification.
Would it make any sense to implement the LDAP_URI of form "ldap:///" as we discussed earlier at least?
Thanks
Comment 19 Ian Kent 2009-05-20 23:10:33 EDT
This issue has been fixed in the latest autofs package
autofs-5.0.1-0.rc2.125.

The autofs RHTS test bugzillas/bz490476 can be used to
verify this correction.
Comment 23 Ruediger Landmann 2009-08-31 07:30:30 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Previously, autofs could use the LDAP server on a network only if the location of the LDAP server were specified manually. Now, if no LDAP server is specified, autofs can look up domain SRV server records to make LDAP connections. This functionality simplifies the use of autofs on networks where an LDAP server is available.
Comment 24 errata-xmlrpc 2009-09-02 07:59:50 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1397.html

Note You need to log in before you can comment on or make changes to this bug.