On 04/26/2017 11:58 PM, Rob Crittenden wrote:
Kendal Montgomery wrote:
Hi all,

I’ve been struggling the last few days with rebuilding part of my
FreeIPA infrastructure, which has lead me to some questions about how
some of the IPA infrastructure works.  To give a bit of background, I
have two IPA servers (my initially installed IPA server, and a replica)
both of which have DNS, NTP, and CA roles.  I’m running CentOS 7.3,
FreeIPA 4.4 currently (upgraded from original CentOS 7 installations
which I believe was FreeIPA 4.1? initiall).  I have several remote sites
that each have two IPA server replicas that have replication topology
segments for domain and ca suffixes back to the two on-prem IPA
servers.  This has been working quite well for over a year now, through
the upgrades, etc.  Occasionally I get an issue with getting some
conflicting records in LDAP, which I’ve cleared up by following some of
the documentation out there.  It seems when this happens however, I end
up getting into a situation where replication stops working, and I end
up needing to “refresh” the installations. I have done this once so far,
and am in the process again currently, by deleting each remote IPA
server (ipa server-del), then re-installing each server to get a clean
copy of the databases for everything.  Last time I had no issues doing
this.  This time around, I’m running into some issues with the CA
setup.  I seem to be able to run ipa-replica-install just fine without
the --setup-ca option.  I may be running into some issues identified in
an earlier post this week, so I’ll ask about this issue separately if I
continue to have problems.  In working through these issues, I realized
I don’t really know enough about how the interaction between the IPA
clients and IPA server is working, with regard to the PKI
infrastructure.  I have some questions on what server roles I need at
each site and how the PKI infrastructure works within the IPA
environment, and how the clients communicate to it:

You don't need to uninstall a master in order to fix replication issues.
You can re-initialize it from a working master. I'm pretty sure that if
you re-init one you need to re-init them all though, to be safe. I cc'd
a couple of 389-ds devs to clarify.
Hi Kendal,

Regarding re-initialization it is a safety practice to re-init all of them when you need to re-init one. It is sometime not necessary to re-init all servers but checking if it is necessary or not take usually more time that a full reinit. A concern of full reinit is if you have large database (so reinit take longer) or difficulty to find a calm period to do this this task.

Reading your description I understand that you had to cleanup some conflicting entries (ldapsearch -D 'cn=directory manager' -W -b "<suffix>" "(objectclass=nsds5ReplConflict)" dn). The management of those entries will greatly improve but it is a complex task, with many corner cases. The better is to avoid creation of those entries. A recommendation to avoid those entries is, avoid parallel upgrade of IPA servers and do not disconnect IPA servers when doing those upgrade.


1)       How do the IPA clients discover servers with the CA role and
use them?
They don't, they talk to one of the IPA masters and lets that figure it out.

An IPA master does this by looking at cn=<host>,

2)       Is all this interaction done through APIs on the IPA server –
in other words, are these requests fielded by the IPA server and proxied
somehow to known servers with the CA role?

3)       Do the clients need “direct” access to a server with the CA
role to request and obtain certificates and renewals? (i.e. do I need
each IPA server to have the CA role)?

4)       Is it sufficient to just have one server with CA role at each
site?  Or even just one at the main on-prem site?
One per site may be sufficient, you want to ensure that you have > 1 CAs
and since you have separate sites, having one at each would give you
lots of leeway in case of catastrophe.


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to