[Freeipa-devel] [PATCH] 362 Add LDAP server fallback to client installer

Thu Feb 7 21:56:06 UTC 2013

Martin Kosek wrote:
> On 02/07/2013 04:03 PM, Rob Crittenden wrote:
>> Martin Kosek wrote:
>>> On 02/06/2013 04:12 PM, Rob Crittenden wrote:
>>>> Martin Kosek wrote:
>>>>> On 02/05/2013 05:57 PM, Rob Crittenden wrote:
>>>>>> Martin Kosek wrote:
>>>>>>> On 02/04/2013 05:59 PM, Rob Crittenden wrote:
>>>>>>>> Martin Kosek wrote:
>>>>>>>>> When ipa-client-install is run without --server option, it
>>>>>>>>> tries to
>>>>>>>>> search SRV records for IPA/LDAP server hostname, but it returns
>>>>>>>>> only
>>>>>>>>> the first record found and when the LDAP server on that
>>>>>>>>> hostname is
>>>>>>>>> not available, the whole client installation fails.
>>>>>>>>>
>>>>>>>>> Get all LDAP SRV records instead and fallback to next hostname
>>>>>>>>> when
>>>>>>>>> the current one is not available.
>>>>>>>>>
>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3388
>>>>>>>>
>>>>>>>> I worked on the same ticket, unfortunately, but I didn't mark it as
>>>>>>>> assigned
>>>>>>>> which caused some duplicate effort. Sorry about that.
>>>>>>>>
>>>>>>>> I came up with a very similar solution but took it a bit
>>>>>>>> further. This
>>>>>>>> expands
>>>>>>>> the treatment of the discovered servers as a list of servers
>>>>>>>> rather than a
>>>>>>>> single value.
>>>>>>>>
>>>>>>>> I do a bit more aggressive testing of all servers returned and
>>>>>>>> remove any
>>>>>>>> from
>>>>>>>> the list that are not IPA servers. A server not responding is
>>>>>>>> left in the
>>>>>>>> configured list.
>>>>>>>>
>>>>>>>> rob
>>>>>>>
>>>>>>> 1) (minor) If I connected IPA host to other IPA server before next
>>>>>>> enrollment,
>>>>>>> there will be outdated /etc/ipa/ca.crt. This will cause all tries to
>>>>>>> connect to
>>>>>>> IPA server to fail with TLS error, but without giving any clue to
>>>>>>> user...
>>>>>>
>>>>>> Yeah, this can be a problem but I'm going to leave things as-is
>>>>>> for now. I
>>>>>> believe we have a separate ticket to clean this up. I don't want to
>>>>>> combine too
>>>>>> many things into this patch, it is disruptive enough.
>>>>>>
>>>>>>>
>>>>>>> # ipa-client-install
>>>>>>> Provide your IPA server name (ex: ipa.example.com):
>>>>>>>
>>>>>>> He would need to reach out to the log to find this line:
>>>>>>> LDAP Error: Connect error: TLS error -8054:You are attempting to
>>>>>>> import a
>>>>>>> cert
>>>>>>> with the same issuer/serial as an existing cert, but that is not
>>>>>>> the same
>>>>>>> cert.
>>>>>>>
>>>>>>> I am thinking if we should not expose some LDAP errors after all?
>>>>>>> To give
>>>>>>> some
>>>>>>> clue to user...
>>>>>>
>>>>>> Yeah, I switched the LDAP error unhandled exception back from
>>>>>> debug to error.
>>>>>>
>>>>>>>
>>>>>>> 2) (minor) While we are touching these errors I would also fix a
>>>>>>> typo there
>>>>>>> :-)
>>>>>>> ...
>>>>>>>                if isinstance(err, ldap.INAPPROPRIATE_AUTH):
>>>>>>>                    root_logger.debug("LDAP Error: Anonymous acces
>>>>>>> not
>>>>>>> allowed")
>>>>>>>                    return [NO_ACCESS_TO_LDAP]               ^^^^^
>>>>>>> ...
>>>>>>
>>>>>> Heh, ok.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 3) (Regression) You neither set ds.server nor add server to
>>>>>>> valid_servers
>>>>>>> when
>>>>>>> anonymous access is not enabled. The installer then does not try to
>>>>>>> connect to
>>>>>>> this server even though the installation would succeed:
>>>>>>>
>>>>>>> ...
>>>>>>>                 elif ldapret[0] == NO_ACCESS_TO_LDAP or
>>>>>>> ldapret[0] ==
>>>>>>> NO_TLS_LDAP:
>>>>>>>                     ldapaccess = False
>>>>>>> ...
>>>>>>
>>>>>> Good point. The handling for this is done a bit later so I need to
>>>>>> defer a
>>>>>> little processing but it should work now.
>>>>>>
>>>>>>>
>>>>>>> 4) (Regression) Client will now report success in discovery even
>>>>>>> when the
>>>>>>> server is down:
>>>>>>>
>>>>>>> # ipa-client-install
>>>>>>> Unable to verify that vm-037.idm.lab.bos.redhat.com (realm
>>>>>>> IDM.LAB.BOS.REDHAT.COM) is an IPA server
>>>>>>> Discovery was successful!
>>>>>>> Hostname: vm-148.idm.lab.bos.redhat.com
>>>>>>> Realm: IDM.LAB.BOS.REDHAT.COM
>>>>>>> DNS Domain: idm.lab.bos.redhat.com
>>>>>>> IPA Server: vm-037.idm.lab.bos.redhat.com
>>>>>>> BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>>>>>>>
>>>>>>> Continue to configure the system with these values? [no]: y
>>>>>>> User authorized to enroll computers: admin
>>>>>>> Synchronizing time with KDC...
>>>>>>> Password for admin at IDM.LAB.BOS.REDHAT.COM:
>>>>>>> Kerberos authentication failed
>>>>>>> kinit: Generic error (see e-text) while getting initial credentials
>>>>>>>
>>>>>>> Please make sure the following ports are opened in the firewall
>>>>>>> settings:
>>>>>>>         TCP: 80, 88, 389
>>>>>>>         UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
>>>>>>> Also note that following ports are necessary for ipa-client
>>>>>>> working properly
>>>>>>> after enrollment:
>>>>>>>         TCP: 464
>>>>>>>         UDP: 464, 123 (if NTP enabled)
>>>>>>> Installation failed. Rolling back changes.
>>>>>>> IPA client is not configured on this system.
>>>>>>>
>>>>>>>
>>>>>>> LDAP on vm-037 in this case is down. I think this would cause a
>>>>>>> regression
>>>>>>> too,
>>>>>>> because previously we simply reported that no discovered server
>>>>>>> is available
>>>>>>> and let user enter the server manually.
>>>>>>
>>>>>> Fixed.
>>>>>>
>>>>>>>
>>>>>>> IMO we are trying to be too smart when processing the
>>>>>>> (discovered) servers.
>>>>>>> Why
>>>>>>> do we need to process and verify _all_ discovered servers even
>>>>>>> when the
>>>>>>> list is
>>>>>>> not written anywhere in case of SRV lookup? I think it causes
>>>>>>> unnecessary
>>>>>>> traffic on network - we should connect to the first server
>>>>>>> available.
>>>>>>
>>>>>> That's a good point. Now we except on the first discovered server.
>>>>>>
>>>>>> I think for user-provided servers we still want to verify them all
>>>>>> since they
>>>>>> will be hardcoded in a config file.
>>>>>>
>>>>>>> 5) In ipa-client-automount:
>>>>>>>
>>>>>>> +    # Now confirm that our server is an IPA server. Stop
>>>>>>> checking on the
>>>>>>> first
>>>>>>> +    # success so we know we have at least one good one.
>>>>>>> +    for server in servers:
>>>>>>> +        root_logger.debug("Verifying that %s is an IPA server" %
>>>>>>> server)
>>>>>>> +        ldapret = ds.ipacheckldap(server, api.env.realm)
>>>>>>>
>>>>>>>
>>>>>>> In case of successful autodiscovery, this looks redundant as we
>>>>>>> try to
>>>>>>> verify
>>>>>>> the servers second time even though we already did it with
>>>>>>> ds.search and
>>>>>>> ds.server should already contain a functional server.
>>>>>>
>>>>>> That's true, I ripped all this out.
>>>>>>
>>>>>> rob
>>>>>>
>>>>>
>>>>> 1) One whitespace error:
>>>>>
>>>>> git apply /home/mkosek/freeipa-rcrit-1084-2-client-failover.patch
>>>>> /home/mkosek/freeipa-rcrit-1084-2-client-failover.patch:96: trailing
>>>>> whitespace.
>>>>>
>>>>> warning: 1 line adds whitespace errors.
>>>>>
>>>>> 2) When ipa-client-automount --server option is passed, the
>>>>> --server value is
>>>>> then never user. This leads to installation failure when --no-sssd and
>>>>> --server
>>>>> options are used:
>>>>>
>>>>> ...
>>>>> Raised exception local variable 'server' referenced before assignment
>>>>> ...
>>>>>
>>>>>
>>>>> ipa-client-install looks OK so far, I did not find any issue in my
>>>>> tests.
>>>>>
>>>>> Martin
>>>>>
>>>>
>>>> Fixed
>>>>
>>>> rob
>>>
>>> Looks good. Just one more remark:
>>>
>>> 1) When --server has anonymous search disabled (i.e.
>>> ret==ipadiscovery.NO_ACCESS_TO_LDAP), ipa-client-automount just exits:
>>>
>>> # ipa-client-automount --server vm-024.idm.lab.bos.redhat.com
>>> Unable to confirm that vm-024.idm.lab.bos.redhat.com is an IPA server
>>>
>>> When I do autodiscovery, the exact same server is used and installation
>>> succeeds:
>>>
>>> # ipa-client-automount
>>> Searching for IPA server...
>>> IPA server: DNS discovery
>>> Location: default
>>> Continue to configure the system with these values? [no]: y
>>> Configured /etc/nsswitch.conf
>>> Configured /etc/sysconfig/nfs
>>> Configured /etc/idmapd.conf
>>> Started rpcidmapd
>>> Started rpcgssd
>>> Restarting sssd, waiting for it to become available.
>>> Started autofs
>>>
>>> Martin
>>>
>>
>> Fixed. I think this has existed for a while.
>>
>> rob
>
> Ok, sorry if I bugged you for existing bugs then :-)
>
> I think the patch is OK, I have found just one case when we did not
> fallback because we always used just one SRV record. This is a diff that
> fixed the issue for me:
>
> diff --git a/ipa-client/ipaclient/ipadiscovery.py
> b/ipa-client/ipaclient/ipadiscovery.py
> index 8338329..7fc6aae 100644
> --- a/ipa-client/ipaclient/ipadiscovery.py
> +++ b/ipa-client/ipaclient/ipadiscovery.py
> @@ -201,7 +201,8 @@ class IPADiscovery(object):
>                       return NO_LDAP_SERVER
>               else:
>                   root_logger.debug("Search for LDAP SRV record in %s",
> domain)
> -                servers = self.ipadns_search_srv(domain, '_ldap._tcp',
> 389)
> +                servers = self.ipadns_search_srv(domain, '_ldap._tcp',
> 389,
> +                                                 break_on_first=False)
>                   if servers:
>                       autodiscovered = True
>                       self.domain = domain
>
>
> ACK if you squash this patch.
>
> Martin

fixed and pushed to master and ipa-3-1

rob