I've seen some tickets about
the --foreman-proxy-plugin-remote-execution-ssh-remote-working-dir
operative being ignored, but thought that they had been fixed.
I'm running Foreman 1.13 final (through a Katellite 3.2 RC install) from
the following install command today:
> I've seen some tickets about
> the --foreman-proxy-plugin-remote-execution-ssh-remote-working-dir
> operative being ignored, but thought that they had been fixed.
>
> I'm running Foreman 1.13 final (through a Katellite 3.2 RC install) from
> the following install command today:
>
> foreman-installer --scenario katello --enable-capsule
> --foreman-initial-organization Innes --foreman-initial-location Laptop
> --enable-foreman-proxy-plugin-remote-execution-ssh
> --enable-foreman-plugin-remote-execution
> --foreman-proxy-plugin-remote-execution-ssh-remote-working-dir
> /opt/foreman-scripts
>
> but am still seeing remote commands pushed to the /var/tmp folder on my
> clients.
>
> Have I missed something?
Hi,
No, it seems we've missed the change in puppet modules in 1.13. I've
opened an issue request to cherry-pick the change to 1.13.1 here http://projects.theforeman.org/issues/16886
Thanks for the report
– Ivan
···
>
> Cheers
>
> D
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
We are still seeing this problem in Foreman 1.18.1. Is there a workaround, patch, etc. to allow an alternative remote working directory? Our CIS configuration requires that /tmp and /var/tmp be noexec.
Another client directory was created and owned by the remote user, Foreman is configured correctly to use that directory but does not. Foreman without remote execution capability is not a scalable solution. Our situation is not unique, many sites require either CIS or PCI-DSS configurations, both stipulate noexec /tmp and /var/tmp.
I haven’t seen the issue for a while now (possibly since 1.13.1 as indicated by iNecas). Can confirm that the remote_working_dir is being used as expected by my 1.19.0 system and clients - tested this afternoon.
