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,

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.

Would that mean that anyone with shell access to the box could run facter and get the passwords?

I guess one would need a well-defined HBAC rule to limit access.


Freeipa-users mailing list

Reply via email to