[Freeipa-users] freeipa master server disaster recovery

[Rob Crittenden]

root wrote:
> Greetings FreeIPA mailing list:
> I have an FC11 environment setup for testing the FreeIPA implementation 
> of kerberos+ldap w/admin utils.  Our primary purpose for kerberos right 
> now is to provide auth services for coda.  However, once that gnat is 
> squished, we'll of course be using kerberos for various other 
> authentication services as well, and possibly using ldap for all manner 
> of things (top of the list is basic server configuration information).
> So far, FreeIPA is a wonderful product and has very much simplified our 
> deployment.
> My only real disappointment with FreeIPA, in fact, was seeing the notion 
> of a "master server".  Moreover, I have not been able to determine what 
> configuration or crucial data is stored on the master server -- of 
> utmost importance, is _where_ said crucial configuration/data is stored 
> so that we may suitably back it up.
> This of course raises disaster recovery questions.  Such as, in the 
> event of a disaster, is it possible (and advisable?) to somehow 
> "promote" a FreeIPA slave/peer server to "master" status?  Or must we 
> deploy a new server with the same name as the old and then somehow sync 
> up the non-master data from the slave/peer(s)?  Obviously, the best 
> scenario would be that we could do either, as the decision on whether to 
> promote or re-deploy will depend heavily on circumstances surrounding 
> the failure.
> 
> I am assuming the following scenario:
> *) master server goes down
> *) slave/peer(s) continue taking updates, the only exception being no 
> FreeIPA servers may be deployed (correct??)
> *) several days pass
> *) master server is determined irreparable
> At which point, what should we have done prior to this failure, to give 
> us the most options for recovery?
> 
> Are there worse scenarios we can plan for?  Any other actions we can 
> take that might save our bacon down the road?

Glad to hear the freeIPA is filling your needs.

See this bug on promoting a new master: 
https://bugzilla.redhat.com/show_bug.cgi?id=486950

Each IPA server is in fact a complete standalone server. The only 
distinctions about the "master" are:
- It was the first one installed
- It owns the CA private key so only it can generate replicas
- It is the hub for replication

The MMR we set up has each replica talking to this initial master. So if 
it goes down all communication between other replicas is hosed.

All is not lost though. You can use ipa-replica-manage to set up 
additional communication links between your replicas. I don't think I'd 
get too carried away with this though and make each replica talk to 
every other replica.

We just don't set up these additional links by default.

It all depends on your needs, paranoia, etc. Critically though you 
should back up the CA cert and key and stick it in a vault somewhere, 
the kerberos master key too if you're really paranoid (but it exists on 
the replicas too, unlike the CA key).

> Just trying to think ahead.  ;)

Always recommended :-)

> 
> Many thanks for the product, and the support!
> 
> Regards,
> -Don
> Systems Administrator
> {void}

cheers

rob