In case anyone else has the same problem, let me document what I did today with our IPA installation (Centos 7.3)
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. 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. 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. 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. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
