/var might be mounted with noexec options

[ghost]

Since /var might be mounted with the noexec option there should be a way to set the variable $script_path to a different value. I'm not sure if the following diff is the best way to do it, though:

diff --git a/manifests/setup.pp b/manifests/setup.pp index 8d36478..0707467 100644 --- a/manifests/setup.pp +++ b/manifests/setup.pp @@ -25,7 +25,11 @@ class concat::setup { default => 'concatfragments.sh' }

• $script_path = "${concatdir}/bin/${script_name}"
• if $::concat_script_path {
• $script_path = $::concat_script_path
• } else {
• $script_path = "${concatdir}/bin/${script_name}"

• }

  $script_command = $::kernel ? { 'windows' => "ruby.exe ${script_path}",

[jhoblitt]

The best approach would likely be to override the concat_basedir fact. https://github.com/puppetlabs/puppetlabs-concat/blob/master/lib/facter/concat_basedir.rb

[ghost]

Obviosly something like cat /etc/facter/facts.d/concat_basedir.sh

!/bin/sh

echo 'concat_basedir'='/usr/local/puppet'

works like a "charm". It just feels wrong to me to move everything to another destination because a script is not executable. What's wrong with my suggested / sketched solution where one can just set a line in a manifest like this:

$concat_script_path = '/usr/local/puppet'

[jhoblitt]

The current incarnation of concat::setup is not intended to be explicitly included by the end user into a manifest. That is why it prints a warning message if you do so. That class is planned to be removed completely when this module is rewritten as a native type/provider, which is why it's been deprecated as a public entry point/API. This module is widely used and thus is very sensitive to API changes.

Setting an alternative location for the aggregation script would best be done as a [new] fact but I'm not particularly keen on the idea as:

• There is an existing robust solution to the issue your experiencing by setting the concat_basedir fact.
• Since the planned rewrite of this module will no longer have an aggregation script at all, I'm hesitant to extend the public API to control an implementation detail that is planned to be changed.
• I suspect mounting /var as noexec is rather uncommon as presumably there are applications that rely on being able to create executable scripts/code under /var/tmp.

However, I'd be willing to bless such a feature if there was a compelling argument for it.

[igalic]

I think it's most sensible to install the script in /usr/local/bin or /usr/local/sbin/

[apenney]

I feel we should hold of adapting the API considering the plans for a type/provider (And I will attempt to write this if nothing happens to stop me in late Feb). It's uncommon enough to use noexec that I'm ok with just adjusting basedir for now. I would hate to start trying to guess other places we could safely write into (not everything even has a /usr/local/ out of the box). I'd rather document the workaround of overwriting concat_basedir.

[jhoblitt]

Also note that ./bin & ./sbin are for scripts/executables that are intended for public consumption -- this is the equivalent of making an API as public. The aggregation script has absolutely no CLI API and/or behaviour guarantees and is private to the concat module. 'private' applications typically are installed under ./share or ./libexec.

[igalic]

libexec can't be found on Ubuntu systems. share should be locatable on pretty much every (Unix) system.

[chelnak]

Hello! We are doing some house keeping and noticed that this issue has been open for a long time.

We're going to close it but please do raise another issue if the issue still persists. 😄