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
