[Freeipa-devel] [PATCH] 362 Add LDAP server fallback to client installer
Martin Kosek
mkosek at redhat.com
Thu Feb 7 18:13:00 UTC 2013
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
More information about the Freeipa-devel
mailing list