Bug #10626

Facter 'virtual' fact trusts path for lspci and dmidecode

Added by Mark Phillips 6 months ago. Updated 3 months ago.

Status:Duplicate Start date:11/08/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:library
Target version:-
Keywords: Affected Facter version:1.6.3
Branch:
Votes: 0

Description

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:

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')

…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

Related issues

related to Facter - Feature #10232: virtual: Get virtual information from sysfs (no dmidecode... Closed 10/22/2011
duplicates Facter - Bug #5013: Facter assumes path that isn't there always Accepted 10/15/2010

History

#1
Updated by Nigel Kersten 6 months ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee set to James Turnbull

Generally this is because the binaries aren’t in the same location across platforms.

hrm.

commit 051c8437586758870e6898918f10a05b217587c0
Author: James Turnbull 
Date:   Tue Oct 21 09:06:54 2008 +1100

    Removed ENV path setting from virtual.rb

James, do you remember why you removed this?

#2
Updated by Nigel Kersten 6 months ago

  • Project changed from Puppet Enterprise (Public) to Facter
  • Support Urls deleted ()

#3
Updated by Adrien Thebo 6 months ago

In lib/facter/util/manufacturer.rb we have this:

  def self.get_dmi_table()
    case Facter.value(:kernel)
    when 'Linux', 'GNU/kFreeBSD'
      return nil unless FileTest.exists?("/usr/sbin/dmidecode")

      output=%x{/usr/sbin/dmidecode 2>/dev/null}
    when 'FreeBSD'
      return nil unless FileTest.exists?("/usr/local/sbin/dmidecode")

      output=%x{/usr/local/sbin/dmidecode 2>/dev/null}
    when 'NetBSD'
      return nil unless FileTest.exists?("/usr/pkg/sbin/dmidecode")

      output=%x{/usr/pkg/sbin/dmidecode 2>/dev/null}
    when 'SunOS'
      return nil unless FileTest.exists?("/usr/sbin/smbios")

      output=%x{/usr/sbin/smbios 2>/dev/null}
    else
      output=nil
    end
    return output
  end

We could break out the dmi functionality into its own utility class and reuse it for manufacturer and virtual facts.

#4
Updated by Ken Barber 6 months ago

  • Category set to library
  • Target version set to 1.6.x
  • Affected Facter version set to 1.6.3

#5
Updated by James Turnbull 3 months ago

  • Status changed from Needs More Information to Accepted
  • Assignee deleted (James Turnbull)

#6
Updated by Ken Barber 3 months ago

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 :–).

#7
Updated by Ken Barber 3 months ago

  • Status changed from Accepted to Duplicate

#8
Updated by Ken Barber 3 months ago

  • Target version deleted (1.6.x)

Also available in: Atom PDF