[Freeipa-users] FreeIPA master replica generation divorce?

[Rob Crittenden]

root wrote:
> Greetings FreeIPA mailing list:
> Thinking outside of the box for a moment, is it possible to divorce the 
> FreeIPA "master" feature of deploying FreeIPA servers from the FreeIPA 
> cluster which handles everything else?  Keeps it safe and out of harms 
> way, especially considering it has the CA key on it.
> This could be done a couple of different ways.  One would be to just 
> have the master FreeIPA "server" deployed as a VM instance -- we only 
> dust it off and start it up when a new server needs deployment, and shut 
> it back down after it's generated the replica file.  While crude for my 
> environment, this would work really well for a VM based shop.

Interesting. I suppose you *could* do this but you'd have to do a bit of 
manual work to get this done.

When a replica is created the MMR we set up connects the new replica 
with the initial master. You can use ipa-replica-manage to create and 
remove replication agreements, so I don't see why you couldn't 
disconnect from the master and then connect to other installed replicas.

This might be a tad overkill, YMMV. What you definitely want to do is 
back up the CA private key. We create a PKCS#12 file for this purpose. 
It is stored in /etc/dirsrv/slapd-YOUR-DOMAIN/cacert.p12. The password 
for this file is in /etc/dirsrv/slapd-YOUR-DOMAIN/pwdfile.txt.

> The elegant approach for us is to run the FreeIPA replica generation 
> feature on our kickstart+puppet server, where it only generates FreeIPA 
> replica files and simply doesn't handle any FreeIPA requests.
> Since KickStart would most likely need to generate the replica file as I 
> believe the way puppet works prevents it from doing much server side 
> execution, is there a problem with generating replica files willy nilly 
> and then deleting them?  I.E.:  Running ipa-replica-prepare for each 
> server deployed, but simply deleting the gpg file for all servers 
> excluding those being deployed as FreeIPA slave/peer(s).

The gpg files themselves aren't particularly interesting, though they do 
contain quite a bit of secure information. Removing them is probably not 
a terrible idea, they can always be re-generated. But they have no 
impact on a running server.

So you can create and destroy them as much as you like, they have no 
impact until you install them with ipa-replica-install. Creating these 
files just creates the SSL certificates needed for things to work and 
collecting some other critical data needed for the IPA server (e.g. the 
things you answered when you did the initial install). We've been 
tinkering with the idea of doing online replica creation where this gpg 
file won't be necessary but it hasn't gotten much past the "now how 
would we do this?" stage.

> 
> Regardless, taking a step back from specific implementation details, is 
> the general idea sound?  Beyond generating replica files, must there be 
> any other communication between the master server and the other 
> slave/peer(s)?  E.G.:  The master must make updates to 
> ldap/kerberos/etc. as a part of generating the replica file.

Nothing is done with a replica until you install it other than 
incrementing the CA serial number counter.

All other communication between the initial master and the replicas is 
the 389-ds MMR communication, keeping the LDAP servers in sync. Since we 
store everything in LDAP that is all that is required.

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

cheers

rob