Charles Hedrick via FreeIPA-users wrote:
> In case anyone else has the same problem, let me document what I did today 
> with our IPA installation (Centos 7.3)

Sorry to hear you had so many problems.

> We started out by installing a primary with a default install, and doing 
> ipa-replica-install with no parameters. That worked fine. We then install a 
> commercial certificate, because I wanted people to be able to use the web 
> tool without having to click through warnings.
> That used 
> That worked fine. However it created a time bomb.
> The first attempt at doing “yum update” failed to update the primary. There 
> was a recent email on this. It can be fixed by changing the nicknames for the 
> certificate to “Server-Cert,” using a process describe in email. That allows 
> update and reboot to work.
> However I just tried installing a third replica. I ran into two issues:
> 1) It blew up at varying points, but most consistently when trying to talk to 
> the CA system. I’m guessing that using the commercial cert confused it, 
> though I didn’t actually diagnose the problem.
> To work around this, I did ldapmodify on
> dn: 
> cn=CA,,cn=masters,cn=ipa,cn=etc,dc=cs,dc=rutgers,dc=edu
> changetype:modify
> delete:ipaConfigString
> ipaConfigString: enabledService
> ipaConfigString: caRenewalMaster
> That makes the primary appear not to be a CA, after which ipa-replica-install 
> works, when specifying --dirsrv-cert-file --http-cert-file --no-pkinit.

Without logs, reproduction steps and a ticket it makes it difficult to
fix this.

> 2) The resulting system looked OK, but ipa-replica-manage -v list XXX showed 
> that it didn’t sync from one of the servers. It looks like a remnant of the 
> failed installs. I had done “ipa server-del” after the failure, but maybe no 
> after all of them. Anyway, I ended up with two entries for the ldap service. 
> On one of the servers the current entry had the wrong dn. I had to do modrdn 
> to fix it.

What was wrong about it?

It's unlikely related to a missing server-del because existing entries
should have prevented a re-install.

> But I still got permission failures. I had to add the dn manually to 
> cn=replication managers,cn=sysaccounts,cn=etc,dc=cs,dc=rutgers,dc=edu. At 
> that point after doing a reinitialize and restarting ipa, things look good.

It's odd that the initial replication succeeded without this. Again logs
would help.

>  The upshot is that doing this kind of thing requires pretty good skills at 
> reverse engineering and doing LDAP configuration. Perhaps it’s reasonable to 
> assume such skills are available anywhere that’s using this in production.

Well, ideally IPA is supposed to do all this for you. There aren't
normally so many hoops to jump through to get a replica install.

FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to