Thank you! I’ll give the re-initialization of all my replicas a try! Kendal
On 4/27/17, 5:58 AM, "thierry bordaz" <[email protected]> wrote: 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. regards > >> 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>, > cn=masters,cn=ipa,cn=etc,$SUFFIX > >> 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? > Right. > >> 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)? > Nope. > >> 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. > > rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
