I recently got MCollective working in my Puppet+Foreman environment but
have found many of the assumptions by the foreman-proxy do not play nice
with the mcollective "Standard Deployment" (using SSL). The primary
difficulty is that the smart-proxy executes the mco command using sudo,
rather than as the foreman-proxy user. I've tweaked my sudoers.d file a
bit to allow foreman-proxy user to execute sudo as itself. Using the
puppetlabs/mcollective module forces the removal of
/etc/mcollective/client.cfg so each user must have their own ~/.mcollective
file to provide the client configuration.
cat /etc/sudoers.d/foreman-proxy
foreman-proxy ALL = NOPASSWD : /usr/bin/puppet cert *
foreman-proxy ALL = (foreman-proxy) NOPASSWD : /usr/bin/mco puppet runonce *
Defaults:foreman-proxy !requiretty
Is there already a feature request in existence, or plan, to disable the
use of sudo when executing a puppet run when the puppet_provider is
mcollective? If not I think I am capable of such a change to the
smart-proxy code, but wanted to check if it was a desired change, or
already being worked before spending time on a PR.
Additionally allowing the command passed to 'mco puppet runonce' seems
worth doing if changes to how the mcollective provider is run. My use case
is that my clients are all configured with noop = true, and having the mco
command run with '–no-noop' would allow only manual runs to make changes.
It seems possible to make such a change and have it be backwards compatible
with the current stable version of smart-proxy.
To support using mco in the "standard deployment" would also require tweaks
to the foreman-proxy puppet module. The
/usr/share/foreman-proxy/{.puppet,.mcollective.d} directories need to be
writable by foreman-proxy, and a certificate needs to be generated. The
way the sudo file is populated would also need to be tweaked. Hopefully
this change to the smart-proxy is possible while still allowing the
foreman-proxy module to manage all the resources necessary to use
mcollective with the 'standard deployment'.
If there's a more "Foreman-friendly" way to use mcollective in the
"standard deployment" without code changes, please let me know.
Thanks,
Hi Trey,
There is this pull request open which might help you, it disables sudo
when the puppet_user is the same as itself. If you're able to address
my comments on there, then we can get it merged:
https://github.com/theforeman/smart-proxy/pull/135
Alternatively, you could look at duplicating the :puppetca_use_sudo
setting for puppet run. We already have one specifically for
:puppetssh_sudo which should really become :puppet_sudo or and apply to
all of the puppet_providers.
Cheers,
···
--
Dominic Cleal
Red Hat Engineering
On 10/04/14 00:40, Trey Dockendorf wrote:
I recently got MCollective working in my Puppet+Foreman environment but
have found many of the assumptions by the foreman-proxy do not play nice
with the mcollective “Standard Deployment” (using SSL). The primary
difficulty is that the smart-proxy executes the mco command using sudo,
rather than as the foreman-proxy user. I’ve tweaked my sudoers.d file a
bit to allow foreman-proxy user to execute sudo as itself. Using the
puppetlabs/mcollective module forces the removal of
/etc/mcollective/client.cfg so each user must have their own
~/.mcollective file to provide the client configuration.
cat /etc/sudoers.d/foreman-proxy
foreman-proxy ALL = NOPASSWD : /usr/bin/puppet cert *
foreman-proxy ALL = (foreman-proxy) NOPASSWD : /usr/bin/mco puppet runonce *
Defaults:foreman-proxy !requiretty
Is there already a feature request in existence, or plan, to disable the
use of sudo when executing a puppet run when the puppet_provider is
mcollective? If not I think I am capable of such a change to the
smart-proxy code, but wanted to check if it was a desired change, or
already being worked before spending time on a PR.
Additionally allowing the command passed to ‘mco puppet runonce’ seems
worth doing if changes to how the mcollective provider is run. My use
case is that my clients are all configured with noop = true, and having
the mco command run with ‘–no-noop’ would allow only manual runs to
make changes.
It seems possible to make such a change and have it be backwards
compatible with the current stable version of smart-proxy.
To support using mco in the “standard deployment” would also require
tweaks to the foreman-proxy puppet module. The
/usr/share/foreman-proxy/{.puppet,.mcollective.d} directories need to be
writable by foreman-proxy, and a certificate needs to be generated. The
way the sudo file is populated would also need to be tweaked. Hopefully
this change to the smart-proxy is possible while still allowing the
foreman-proxy module to manage all the resources necessary to use
mcollective with the ‘standard deployment’.
If there’s a more “Foreman-friendly” way to use mcollective in the
“standard deployment” without code changes, please let me know.
Thanks,
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for posting this Trey, I just had this exact issue on mco 2.7.0 and
your sudoers tweak fixed the problem for me.
···
On Thursday, 10 April 2014 00:40:32 UTC+1, Trey Dockendorf wrote:
>
> I recently got MCollective working in my Puppet+Foreman environment but
> have found many of the assumptions by the foreman-proxy do not play nice
> with the mcollective "Standard Deployment" (using SSL). The primary
> difficulty is that the smart-proxy executes the mco command using sudo,
> rather than as the foreman-proxy user. I've tweaked my sudoers.d file a
> bit to allow foreman-proxy user to execute sudo as itself. Using the
> puppetlabs/mcollective module forces the removal of
> /etc/mcollective/client.cfg so each user must have their own ~/.mcollective
> file to provide the client configuration.
>
> # cat /etc/sudoers.d/foreman-proxy
> foreman-proxy ALL = NOPASSWD : /usr/bin/puppet cert *
> foreman-proxy ALL = (foreman-proxy) NOPASSWD : /usr/bin/mco puppet runonce
> *
> Defaults:foreman-proxy !requiretty
>
> Is there already a feature request in existence, or plan, to disable the
> use of sudo when executing a puppet run when the puppet_provider is
> mcollective? If not I think I am capable of such a change to the
> smart-proxy code, but wanted to check if it was a desired change, or
> already being worked before spending time on a PR.
>
> Additionally allowing the command passed to 'mco puppet runonce' seems
> worth doing if changes to how the mcollective provider is run. My use case
> is that my clients are all configured with noop = true, and having the mco
> command run with '--no-noop' would allow only manual runs to make changes.
>
> It seems possible to make such a change and have it be backwards
> compatible with the current stable version of smart-proxy.
>
> To support using mco in the "standard deployment" would also require
> tweaks to the foreman-proxy puppet module. The
> /usr/share/foreman-proxy/{.puppet,.mcollective.d} directories need to be
> writable by foreman-proxy, and a certificate needs to be generated. The
> way the sudo file is populated would also need to be tweaked. Hopefully
> this change to the smart-proxy is possible while still allowing the
> foreman-proxy module to manage all the resources necessary to use
> mcollective with the 'standard deployment'.
>
> If there's a more "Foreman-friendly" way to use mcollective in the
> "standard deployment" without code changes, please let me know.
>
> Thanks,
> - Trey
>
