Bjarne Blichfeldt via FreeIPA-users wrote: > We are in some trouble here… > > > > ipa-server-4.4.0-14.el7_3.7.x86_64 on rhel7.3 > > 4 x IDM setup. > > > > The directory server on the master CRL server decided to have a fit, > every attempt of starting it results in SEGV and core dump. I have the > dns started but that is all that is running on the server at the moment. > > not event “ipactl –f start” works. It just abort with: > > ipactl -f start > > Skipping version check > > Starting Directory Service > > Failed to start Directory Service: Command '/bin/systemctl start > dirsrv@DOMAINE.service <mailto:dirsrv@DOMAINE.service>' returned > non-zero exit status 1 > > > > An ongoing ticket at redhat does not bring any solution so I am going to > restore server from a backup. Fortunately, it is a vmmware server. > > > > Now while waiting for permissions from the customer to do the swap, I > would love to promote another idm as master-crl but I am a little > confused as how best do this. > > > > In https://access.redhat.com/solutions/2253241 the procedure is: > > on defect server: shutdown pki, reconfigure, start pki - shutdown > httpd, reconfigure httpd, start httpd > > on new sever: shutdown pki, reconfigure, start pki - shutdown httpd, > reconfigure httpd, start httpd > > The note also says: > > NOTE: The procedure described above requires the first CA master to be > reachable by the replica. If this system is no longer available, there > is currently no way to setup a CA clone on any replica. The reason for > this is, that the replica connects to the master to ask for some CA > specific details. A workaround exists by recovering the first master > from a backup and make it available to the replica system for > installation time of the new CA. To avoid replication conflicts the > replication agreements between the master and the replica should be deleted. > > > > In > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/moving-crl-gen-old > > the procedure boils down to: > > ipa-csreplica-manage set-renewal-master > > with the comment: “The command also automatically reconfigures the > previous CA from renewal master to clone.” > > > > > > > > From the above, I take it there is no way to promote another server to > master-crl as long as the dirserver on the original master-crl is down? > > > > > > > > Now, when I boot up the restored server, then what? > > The restored server is ready in an isolated environment and I have > verified that the dirserver and everything starts up as it should. > > The server will be 6 days old. > > > > My thought is, I just boot it and run: > > ipa-replica-manage re-initialize –-from=working-idm > > > > But for peace of mind I would still like to move the master-crl function > to a different server. Could this be done before “ipa-replica-manage > re-initialize”? > > That would give me the freedom to completely scratch the server if > something goes wrong. > > > > > > And for the future: I find this failure to be quite problematic. > > We have an extremely redundant setup, if an idm dies, I just remove it > from the set, rebuild and rejoin. Tried it a couple of times, works > great, nobody notice. > > > > But the master-crl seems to be a real pain. Are the any way to rearrange > things to a more robust setup. Maybe copy some directory contents from > the master-crl to the other servers and then simply reconfigure > > one of the other servers in case of failure? Sort of a cold standby feature. > > > > Any advice is appreciated.
The first question to ask: do you use CRLs? If not then there is not a lot of urgency here. The reason for only allowing one master to generate the CRL is so there isn't a timing issue with replication where two masters can generate two different but otherwise valid CRLs. ipa-csreplica-manage set-renewal-master does not require that other masters be up. This makes a change in LDAP. It also doesn't twiddle the values in the CA, it is just information only showing the server role. So what you probably want to do is to keep your non-working master isolated, then follow the steps in the KB article (and run ipa-csreplica-manage to set its role). You can manually do the steps on the non-working master while its down so that when it comes back up it won't be the renewal master (the CS.cfg and Apache changes). rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
