Bug 490476
Summary: | RFE: autofs should DNS for SRV records in order to locate LDAP server | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Ondrej Valousek <ondrejv> | ||||||
Component: | autofs | Assignee: | Ian Kent <ikent> | ||||||
Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.3 | CC: | ikent, jmoyer, rlerch | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
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 11:59:50 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Ondrej Valousek
2009-03-16 16:25:35 UTC
Update: autofs could use libldap and functions ldap_dn2domain ldap_domain2hostlist defined there to achieve this functionality... (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. Document about Open Solaris name services discovery: http://opensolaris.org/os/project/duckwater/Documentation/ns-discovery/ Perhaps we should be consistent with this, too. 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
(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 Created attachment 337432 [details]
Dependency for SRV server lookup patch
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
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 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 :-) Update: Problem #2 has been resolved as per autofs-5.0.3-42.src.rpm (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 (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. > 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...
(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. 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? (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. 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 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. 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. 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 |