On 04/25/2014 12:48 PM, Justin Brown wrote:
This type of behavior is generally beyond what Puppet should do
because it involves two systems retrieving information directly from
one another and the puppet master can't reasonably serve as the
repository of that information. Using a separate tool will likely work
better. There's at least two ways that you could go with this.
1) Script and SSH
The IPA master has a simple script that will just invoke
ipa-replica-setup with the proper options and passwords. The new
replica will get a Puppet exec resource that will SSH into the master,
run the script, scp the resulting replica file, and invoke the replica
install with that info.
The problem with this solution is that credentials are sprinkled all
over the place, and security is not good. Your Puppet manifest will
need SSH credentials/keys, the master script needs IPA credentials,
and the Puppet logs for the exec resource may contain passwords
depending on how you implement it.
You'll need to write a MCollective agent that resides on the replica
and master. The new replica will get a Puppet exec resource that will
run the MCollective agent. The agent will connect to the master and
invoke its half of the agent, which will create the replica file and
read it back to the replica. Then, there's a second Puppet exec
resource that will run ipa-replica-install.
Security is better for a couple of reasons. First, ACLs can be used
with MCollective to limit who can run this agent. Second, there's no
SSH keys/passwords to exchange. Third, we can store the IPA DM and
admin passwords in puppet facts (this works for the previous solution,
Both solutions are pretty simple and will get the job done, but I
think the second one is better but does require MCollective installed
and Ruby knowledge.
Or we use Cockpit for that matter:
On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden <rcrit...@redhat.com> wrote:
Dmitri Pal wrote:
On 04/25/2014 05:06 AM, Petr Spacek wrote:
On 25.4.2014 00:15, Dave Jones wrote:
I was considering installing replicas using puppet. Having
pre-prepared replica files available would be easier than having to
run an ipa-replica-prepare and scp copy.
I had guessed the ldap/kerberos replication would handle the
user/password/DNS updates, and that changing CA certificates would be
the most likely cause of gpg file invalidation.
I'm working on DNSSEC support in FreeIPA right now. It is possible
that replica-file validity will lowered by this work. (We will need to
distribute one new key as part of the replica file so the replica file
will become invalid if the key was changed in meantime. Maybe we will
find some other solution for it, I don't know ...)
May be the solution is to run a cron job on the server that would
prepare a replica file and refresh it under source control every so often?
The downside is you could end up issuing a whole ton of certificates for the
same service, the majority of which aren't being used, and are unrevoked.
Freeipa-users mailing list
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
Freeipa-users mailing list