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 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.
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...
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...
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] ^^^^^
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 == NO_ACCESS_TO_LDAP or ldapret == NO_TLS_LDAP:
ldapaccess = False
4) (Regression) Client will now report success in discovery even when the
server is down:
Unable to verify that vm-037.idm.lab.bos.redhat.com (realm
IDM.LAB.BOS.REDHAT.COM) is an IPA server
Discovery was successful!
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-037.idm.lab.bos.redhat.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
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.
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.
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.
Freeipa-devel mailing list