Skip to content
This repository has been archived by the owner on May 5, 2023. It is now read-only.

file define forces a default path for Exec #2

Closed
geoffdavis opened this issue Apr 12, 2012 · 5 comments
Closed

file define forces a default path for Exec #2

geoffdavis opened this issue Apr 12, 2012 · 5 comments

Comments

@geoffdavis
Copy link

In manifests/file.pp, there is a default path specified for Exec which overrides anything set by the user in site.pp.

Unfortunately, this breaks on Solaris, at least in my environment. Solaris 10 does not ship with curl, so I have added it with the pkgutil provider. This places it the curl binary in /opt/csw/bin/curl.

From looking at the code, the workaround is to put a symlink in /usr/local/bin/curl pointing to /opt/csw/bin/curl, but I'd rather not if I can avoid it.

Can the default Exec path either be parameterized or removed?

@nanliu
Copy link
Contributor

nanliu commented Apr 16, 2012

Ah, would addition of the $::path fact be helpful as the parameter default?

@geoffdavis
Copy link
Author

As a default value, $::path is a good start, but I think that parameterizing the staging class would break in many cases. For example, I don't actually call staging directly from my top-level manifests, but Adrien's magic puppet-enterprise upgrader brings it in with a 'require' statement, as does a module that I'm writing. How does the 'require' function work? Does it play nicely with parameterized classes? If not, parameterizing anything in the top-level staging/manifests/init.pp class may be a non-starter unless it can also modified with a top-scope variable or hiera. Parameterized classes are messy when you have more than one module trying to use them.

It's a pity that the $::path fact doesn't change during runtime when you set the default value of path for all Exec statements. I'd love to just do this in site.pp and be done:

 Exec {
   path => $::osfamily ? { 
     Solaris => '/usr/bin:/opt/csw/bin:/usr/sbin:/opt/csw/sbin:/bin:/sbin',
     default => '/usr/bin:/usr/sbin:/bin:/sbin',
   }
 }

@nanliu
Copy link
Contributor

nanliu commented Apr 17, 2012

You have several options since this module was intended to be used with heira 1 and 2 is preferred.

  1. In hiera.yaml configuration specify %{operatingsystem} as a hierarchy. solaris.yaml will have staging_exec : '/usr/bin...'.

  2. In hiera.yaml enable puppet backend and in data module set conditional similar to above with $staging_exec = '...' the right path conditionally.

  3. declare the staging class before the require in site.pp.

    class { 'staging':
    exec => '...',
    }

@geoffdavis
Copy link
Author

Hmm, like almost everything related to parameterized classes, that third approach seems like a hack that requires on the parser doing "the right thing". But hey if it works, that's probably going to be the approach I go with until I figure out the best way to structure my hiera setup.

nanliu added a commit that referenced this issue Apr 24, 2012
Previously the module hardcoded exec path to simplify the module
dependecy. This patch accepts the facter $::path value instead of a hard
coded path value, and it allows users to specify their own Exec defaults
which will have precedence over the module setting.
@nanliu
Copy link
Contributor

nanliu commented Apr 24, 2012

This is fixed with a way to allow your existing Exec defaults in site.pp to specify exec path in this module. If there's any issues, please reopen.

@nanliu nanliu closed this as completed Apr 24, 2012
cegeka-jenkins pushed a commit to cegeka/puppet-staging that referenced this issue Oct 23, 2017
Previously the module hardcoded exec path to simplify the module
dependecy. This patch accepts the facter $::path value instead of a hard
coded path value, and it allows users to specify their own Exec defaults
which will have precedence over the module setting.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants