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

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

fixed and pushed to master and ipa-3-1

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to