Issue #10626 has been updated by Ken Barber.
This is a bigger issue then just the virtual case ... and incidentally an old
and duplicate one (see #5013) :-).
PS. Incidentally - and I know this isn't necessarily the issue but dmidecode
only works for root:
$ dmidecode
# dmidecode 2.11
/dev/mem: Permission denied
Because of access to /dev/mem. Which is another bigger problem :-).
----------------------------------------
Bug #10626: Facter 'virtual' fact trusts path for lspci and dmidecode
https://projects.puppetlabs.com/issues/10626#change-55046
Author: Mark Phillips
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version: 1.6.x
Keywords:
Branch:
Affected Facter version: 1.6.3
Whilst writing a manifest today I couldn't fathom out why 'facter is_virtual'
was returning false on an ESX guest.
It turns out that 'lspci' and 'dmidecode' are listed without a path in the fact
code:
<pre>
root@mgrl002:/opt/puppet/lib/ruby/site_ruby/1.8/facter# grep -E
'lspci|dmidecode' virtual.rb
output = Facter::Util::Resolution.exec('lspci')
output = Facter::Util::Resolution.exec('dmidecode')
</pre>
...this works on the assumption that the PATH is already set correctly before
running. Yes, it works fine under normal Puppet running as a root, but I'm sure
a circumstance could arise where the PATH isn't correct. Surely it would be
better to fully qualify the binaries before running? What if root has a path
that presents a different (rogue?) tool before the proper version?
Thanks
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
