Feature #1893

Package resource unable to find gem binary in alternate path

Added by Michael Brannigan over 3 years ago. Updated about 2 years ago.

Status:Closed Start date:01/26/2009
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:-
Affected Puppet version:0.24.7 Branch:
Keywords:
Votes: 0

Description

In our environment, ruby is installed under /opt/local/bin. When I use the gem provider, I get the following error message:

Jan 26 11:17:37 HOST puppetd[25024]: [ID 702911 daemon.error] Could not
prefetch package provider 'gem': Could not list gems: Execution of 'no gem
in /bin /sbin /usr/bin /usr/sbin /usr/local/sbin /usr/local/bin list --local'
returned 1:

Everything is fine if I create a symlinks for /opt/local/bin/ruby and /opt/local/bin/gem in /usr/local/bin. /opt/local/bin is in the system PATH.

Would it be possible to have a configuration option to provide a search path for puppetd or perhaps a path attribute on the Package resource? I tried a few things as a work-around and I can’t seem to munge the search path for the puppetd process.

Thanks! —– Mike Brannigan

History

#1
Updated by Luke Kanies over 3 years ago

  • Status changed from Unreviewed to Rejected

Try the ‘path’ setting in puppet.conf; please reopen if that does not work.

#2
Updated by Michael Brannigan over 3 years ago

  • Status changed from Rejected to Re-opened

I put the following into puppet.conf on the client:

[main]
        path = /bin:/usr/bin:/sbin:/usr/sbin:/usr/ccs/bin:/opt/local/bin:/opt/csw/bin

[puppetd]
        ignorecache = true
        server = HOSTNAME

I still have the same message:

Jan 27 11:10:27 svs030 puppetd[4749]: [ID 702911 daemon.error] Could not
prefetch package provider 'gem': Could not list gems: Execution of 'no
gem in /bin /sbin /usr/bin /usr/sbin /usr/local/sbin /usr/local/bin
list --local' returned 1:

I also tried changing /etc/puppet/puppet.conf to read like this with the same result:

[puppetd]
        ignorecache = true
        server = HOSTNAME
        path = /bin:/usr/bin:/sbin:/usr/sbin:/usr/ccs/bin:/opt/local/bin:/opt/csw/bin

#3
Updated by Michael Brannigan over 3 years ago

I checked the PATH within the running puppetd process with pargs -e:

envp[9]: PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin

However, PATH is configured in my environment just fine:

/bin:/sbin:/usr/bin:/usr/sbin:/opt/csw/bin:/opt/csw/sbin:/usr/sfw/bin:/usr/sfw/sbin:/opt/local/bin:/opt/local/sbin:/opt/pgsql/bin:/usr/ccs/bin

It’s interesting that puppetd did pick up the MANPATH set within /etc/profile, but does not pick up PATH…

From /etc/profile:

MANPATH=/usr/man:/usr/share/man:/opt/csw/man:/opt/csw/share/man:/usr/sfw/man:/usr/sfw/share/man:/opt/local/man:/opt/pgsql/man
export MANPATH

From pargs -e:

envp[3]: MANPATH=/usr/man:/usr/share/man:/opt/csw/man:/opt/csw/share/man:/usr/sfw/man:/usr/sfw/share/man:/opt/local/man:/opt/pgsql/man

It’s as if PATH is being overwritten by something within puppetd?

#4
Updated by Luke Kanies over 3 years ago

  • Status changed from Re-opened to Closed

This is probably a Facter bug – there was one filed where Facter is clobbering the PATH. The bug was fixed in 1.5.3, I think, so if you’re running 1.5.2 you might be being hit by it. Try up- or down-grading.

Also available in: Atom PDF