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

Wed Feb 6 09:48:30 UTC 2013

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