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
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
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=krb1.cs.rutgers.edu,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.
rob