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

Wed Feb 6 16:32:29 UTC 2013

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