Martin Kosek wrote:
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
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
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

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:

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
                   return [NO_ACCESS_TO_LDAP]               ^^^^^

Heh, ok.

3) (Regression) You neither set ds.server nor add server to
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 (realm
Discovery was successful!
DNS Domain:
IPA Server:
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
Kerberos authentication failed
kinit: Generic error (see e-text) while getting initial credentials

Please make sure the following ports are opened in the firewall
        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
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
traffic on network - we should connect to the first server

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" %
+        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 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




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
Unable to confirm that 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/
index 8338329..7fc6aae 100644
--- a/ipa-client/ipaclient/
+++ b/ipa-client/ipaclient/
@@ -201,7 +201,8 @@ class IPADiscovery(object):
                      return NO_LDAP_SERVER
                  root_logger.debug("Search for LDAP SRV record in %s",
-                servers = self.ipadns_search_srv(domain, '_ldap._tcp',
+                servers = self.ipadns_search_srv(domain, '_ldap._tcp',
+                                                 break_on_first=False)
                  if servers:
                      autodiscovered = True
                      self.domain = domain

ACK if you squash this patch.


fixed and pushed to master and ipa-3-1


Freeipa-devel mailing list

Reply via email to