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

Thu Feb 7 15:03:54 UTC 2013

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-1084-4-client-failover.patch
Type: text/x-diff
Size: 17724 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130207/2b819668/attachment.bin>