[Freeipa-users] Are replica gpg files reusable?

[Justin Brown]

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.

2) MCollective

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,
too.).

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.

On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden <rcritten at 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:
>>>>
>>>> Hi Rob,
>>>>
>>>> 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.
>
>
> rob
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users