On 08/02/2017 04:17 PM, Fraser Tweedale wrote:

- /var/log/ipareplica-install.log from replica
- /etc/pki/pki-tomcat/ca/debug from both master and replica

Those logs should do for a start.

I'd also like to see your /etc/pki/pki-tomcat/ca/CS.cfg from both
master and replica.  Depending on where investigation goes I might
ask for some LDAP entries too, but I'm not up to that point yet.

Feel free to send logs directly to me and/or redact them as you see

Oh, and which version of IPA are you creating the replica from?


Actually that won't be necessary, it took two of us looking at it, but we figured out the problem.  Based on what I can gather, when IPA0 was built, kinit admin wasn't run prior to updating the GoDaddy certs.  (The documentation isn't real clear on that, if said documentation was perused while setting it up.  As I said, I didn't build the server.)  Once the GD cert files were pulled from nssdb on IPA0 and reinstalled and updated with kinit admin ipa-certupdate, it seems to have cleared up the wonky configuration on that side. 

Then, we went the nuclear option and removed the ipa-server packages from IPA1, re-installed them, ran ipa-client-install (which I didn't run and wasn't clear that it needed to be run), then run the ipa-replica-install --setup-ca and now everything is kosher. 

I was fairly certain as I got into debugging it that it wasn't a bug, as the documentation tells you different things depending on what documentation you look at (ie, RH vs FreeIPA docs), so wasn't sure where the issue lie.   Most of the time, I had focused on something not right with IPA1, not really considering IPA0 could be jacked up in its own special way.  It was my colleague who reminded me there were two parts to the equation.  Tunnel vision still gets me even after 20 years of doing this! 

Now though, we're up and running fine and ready to being a real rollout to our production servers. 

I appreciate all the help from the list. 

Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1