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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to