[Freeipa-users] Are replica gpg files reusable?

[Dmitri Pal]

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.
>
> 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.

Or we use Cockpit for that matter: 
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/

>
> 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



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.