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.


I worked on the same ticket, unfortunately, but I didn't mark it as
which caused some duplicate effort. Sorry about that.

I came up with a very similar solution but took it a bit further. This
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
the list that are not IPA servers. A server not responding is left in the
configured list.


1) (minor) If I connected IPA host to other IPA server before next
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
with the same issuer/serial as an existing cert, but that is not the same

I am thinking if we should not expose some LDAP errors after all? To give
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
                   return [NO_ACCESS_TO_LDAP]               ^^^^^

Heh, ok.

3) (Regression) You neither set ds.server nor add server to valid_servers
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
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
because previously we simply reported that no discovered server is available
and let user enter the server manually.


IMO we are trying to be too smart when processing the (discovered) servers.
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
+    # 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
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.


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

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
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.




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

# 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


Fixed. I think this has existed for a while.


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
                 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.


Freeipa-devel mailing list

Reply via email to