Re: [Freeipa-users] Are replica gpg files reusable?
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. 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. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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 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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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 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@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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? Petr^2 Spacek On 24 Apr 2014, at 23:40, Rob Crittenden wrote: Dave Jones wrote: Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ‘master’ IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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 ...) Petr^2 Spacek On 24 Apr 2014, at 23:40, Rob Crittenden wrote: Dave Jones wrote: Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ‘master’ IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
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. Again, thank you for speedy response and clarification! Cheers, Dave On 24 Apr 2014, at 23:40, Rob Crittenden wrote: > Dave Jones wrote: >> Hi, >> >> Should the replica gpg created by ipa-replica-prepare be re-created when >> there have been trivial changes such as adding/modifying a >> user/group/password on the IPA server? >> >> What change of condition(s) in the ‘master’ IPA host would prevent reuse of >> a previously prepared replica gpg file, or otherwise render it invalid? > > I'm assuming there is some specific scenario you have in mind. > > Typically a replica file is not needed after a master is installed. The only > exception is if you install without a CA and then decide to use > ipa-ca-install to add it later. > > We generally recommend that a replica be installed fairly soon after > preparation of the file, days, not months, but even then it may still be > viable. > > As for data modification (users, groups, etc) it should have no impact > whatsoever. Once a replica is installed it is a full IPA master and the > 389-ds replication protocol will keep it in sync. > > rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
Dave Jones wrote: Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ‘master’ IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
