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] == 
>>                   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
>> 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 ad...@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.


Freeipa-devel mailing list

Reply via email to