Dropping "Run puppet" button with a replacement using remote execution plugin




would anyone be against if we drop the “Run puppet” button from host detail page and bulk action menu? I know it still works if correctly configured, but given how complicated it is, I’d propose to support just one way of running puppet on demand, which would be through remote execution plugin. It would look like

this. As long as you have Foreman’s SSH key deployed to hosts, it will run out of the box. People using mcollective could easily write a job template that would trigger something like mco puppet runonce and link it to “run puppet” feature.

It also means we’d need to drop some API endpoints, which is not backwards compatible change.

I started working on it but before I get too far, I’d like to know if there is some showstopper.

Dropping Puppet 3 in the proxy

I would appreciate this.
Getting the “run puppet” button to work correctly is quite a headache and my users here usually are quite confused about the differences and why those two things work differently.


I think we can safely remove this. My only concern is that we should provide documentation on how to set up similar permissions, e.g. how can you allow users to only run puppet on hosts and not arbitrary commands.


Does this cover it well enough?

EDIT: I see we need to update the permission name though :slight_smile:


Yeah same permission granularity would be a must for us and as long as it supports mcollective/choria we’d be fine.

I’m not familiar with the remote execution plugin would it add the ability to force batching and batch interval etc on puppet runs executed via bulk actions?


Yes if you used the regular template that we ship. See description of concurrency level and time span. If you build a template that run mco, then the execution gets out of our hands. But if mco supports that as an argument, it would be possible to pass this value or define template input where user could set the batch size.


There is at least one scenario (which we are using right now) where the remote execution plug-in might not be able to replace the “Run Puppet” button. We are using the Puppet run provider “puppet_proxy_customrun” to execute a web hook, which connects to a API on a remote server, which then triggers a Puppet run on the remote foreman node. Our Foreman Servers/Proxies don’t have the ability to connect to the all our Puppet nodes directly via ssh or mco right now out of compliance reasons …

I think the only solution, to do the same thing with remote execution, might be a new (custom?) provider type which emulates the buttons custom run function.


I think that’s in fact very similar to the mco case I described above. You could write a job template and run that against the host, where you have smart proxy today. The content of this job template would be the same thing, you today call via customrun, the webhook. The only difference is the HTTP vs SSH for this communication, would that be a concern?

Note custom job template can be easily linked to the new “Run puppet” button. In this case it would require target host as user input, so one would need to go through the job invocation form. This would probably be less convenient.

Also could you please describe a bit more how does the web hook triggers the puppet run? Why is that considered safer than SSH/mco? I can understand sometimes the active connection is impossible since the host does not have accessible IP, but that shouldn’t be a problem with mco.


Thanks for your response. Using a job template and run it against one node e.g. the smart proxy to trigger the web hook is indeed less convenient, especially when you want to execute a puppet run on multiple hosts (which can be currently done easily by simply selecting the puppet nodes on the hosts page)

We are not using mco currently. Our puppet nodes are only accessible via a ssh bastion host, which I can not ssh into from our Foreman servers (security policies). However I can use a Web API to trigger certain jobs on that bastion host (like the execution of a puppet run on a remote server). I would not say that this is certainly more secure than using mco or ssh directly, but we are a big organization and sometimes we have to make a compromise to getting things done.

I think it would be possible for us, to get the permission to log-in to the bastion host directly from our Foreman servers to create a ssh tunnel via the bastion host to the puppet clients. This would enable us to use the remote exec plugin …



At the moment we are using ‘customrun’ I also think that is the only way you need to support it in Foreman as the DevOpps users can write their own script to run ‘puppet agent -t $OPTION’ on the supplied host name. In my case I am using bolt to run the remote command or just nohup if it is to run on the local host. No need to worry so much about mcollective as it has been deprecated. But for anyone still using mcollective your example should work fine wrapped up into a customrun script.

I see no major issues if you can give us developers / users some examples on how we can port our code over to the ‘new way’ of doing Run puppet.


mcollective has/will become choria (https://choria.io) still very much supported although separate from puppetlabs now.
I certainly don’t intend to stop using mcollective but as you say if we can write our own execution templates it should be fine.


Hi Marek,

I’m an newbie to foreman and I would like to know how it is possible to extend the “Schedule remote Job” drop-down list by the entry “Run Puppet Once” ?
Can you give me a hint ?
Best regards



it’s work in progress right now. This is the PR [1] that first needs to get in, then new remote execution plugin needs to be released. I’ll need to find some time to finish it.

[1] https://github.com/theforeman/foreman_remote_execution/pull/407


Hi Marek,

thank you for your answer. I will wait for the release then.

Best regards