The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #13396

Facter not working with recent net-tools

Added by Stefan Schulte about 4 years ago. Updated about 3 years ago.

Status:Merged - Pending ReleaseStart date:03/25/2012
Priority:HighDue date:
Assignee:-% Done:

0%

Category:util_ip
Target version:1.6.18
Keywords: Affected Facter version:
Branch:https://github.com/puppetlabs/facter/pull/386

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

Facter does not work at all with recent net-tools package on gentoo (and probably other OS as well)

# facter
Error: No such file or directory - /sbin/ifconfig -a
#

puppet therefore also does not work anymore

# puppet apply -v -e 'notify { "Hello World": }'
Could not run: Could not retrieve facts for host.example.com: No such file or directory - /sbin/ifconfig -a

sys-apps/net-tools-1.60_p20111120203157 does work while sys-apps/net-tools-1.60_p20120127084908 (latest in portage tree) does not. I found the following commit in the net-tools repository that is causing the error.

Apperently ifconfig has moved to /bin so facter does not find it anymore.

commit 36b541c9f3efe55c5871674ee926be8b20339497
Author: Mike Frysinger 
Date:   Fri Dec 2 16:19:08 2011 -0500

    ifconfig/route: move to /bin
    
    These tools provide quite a bit of good information which is available
    to non-root users, so let's move them to /bin for people to use.
    
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Current workaround: Create a symlink from /sbin/ifconfig to /bin/ifconfig


Related issues

Related to Facter - Bug #18756: wront regex in util/ip.rb Merged - Pending Release

History

#1 Updated by Krzysztof Wilczynski about 4 years ago

Hi,

[…]

Current workaround: Create a symlink from /sbin/ifconfig to /bin/ifconfig

I don’t like work-around problems like that :)

Perhaps its the time to include simple “which” in Util in Facter?

Quick tackle: https://gist.github.com/2205072

KW

#2 Updated by Chris Price about 4 years ago

  • Status changed from Unreviewed to Accepted
  • Priority changed from Normal to High

#3 Updated by Stefan Schulte about 4 years ago

Krzysztof Wilczynski wrote:

I don’t like work-around problems like that :)

Perhaps its the time to include simple “which” in Util in Facter?

Quick tackle: https://gist.github.com/2205072

KW

Most facts handle this by just letting the shell do the job. So to be consistent with other facts this is a possible fix

-    output = %x{/sbin/ifconfig}
+    output = Facter::Util::Resolution.exec('ifconfig -a')

But I generally don’t like two things about this approach

  • we rely on the PATH variable so the code may break if you run this as a non-root user or if you have . in path and running facter in the wrong directory
  • for each command we want to execute we do a second shell invocation to run which $command just to check if we find an executeable.

I personally like the idea of implementing our own which command in pure ruby (and maybe with a fixed array of paths where we expect to find the executable).

#4 Updated by Stefan Schulte about 4 years ago

FYI: I’ve opened a request #13678 to refactor Puppet::Util::Resolution.exec

#5 Updated by Krzysztof Wilczynski about 4 years ago

Hi,

[…]

I personally like the idea of implementing our own which command in pure ruby (and maybe with a fixed array of paths where we expect to find the executable).

+1

We could purge current PATH and set our own as well. On Linux, there is only a finite number of places where binaries can be, and if you have non-standard tree (or use Fedora :-P), then its your problem (which you would kindly report back to us, I hope).

P.S. Not having a fully-qualified paths can be a potential security issue as somebody pointed out to me.

KW

#6 Updated by Ken Barber about 4 years ago

Krzysztof Wilczynski wrote:

Hi,

[…]

I personally like the idea of implementing our own which command in pure ruby (and maybe with a fixed array of paths where we expect to find the executable).

+1

We purge could purge current PATH and set our own as well. On Linux, there is only a finite number of places where binaries can be, and if you have non-standard tree (or use Fedora :-P), then its your problem (which you would kindly report back to us, I hope).

P.S. Not having a fully-qualified paths can be a potential security issue as somebody pointed out to me.

KW

Agreed – having control of the ‘which’ functionality gives us more choices and power (mhwahaha). I’ve even considered the possibility to allow users to override PATH in our oft-spoken-of-perhaps-done-in-the-future facter config file :–). Its a good idea without a doubt.

#7 Updated by Krzysztof Wilczynski about 4 years ago

Hi,

+1

P.S. Facter configuration file is like Loch Ness monster :)

KW

#8 Updated by Marc Richter over 3 years ago

Guys, did you forget about this one? Current facter still don’t work properly with recent net-tools. That an (ugly) workarround is available is good. That you think about two facter improvements ( “facter config file” and “change which bahavior” ) is great, but that future plans do not solve this quite-easy-to-solve bug. Please fix facter to determine if /sbin/ifconfig or /bin/ifconfig is to be used. Thank you! :)

#9 Updated by Dennis Sivia over 3 years ago

Created Pull Request 385 to address the issueHelp

#10 Updated by Anonymous over 3 years ago

  • Category set to util_ip
  • Status changed from Accepted to Merged - Pending Release
  • Target version set to 2.0.0
  • Branch set to https://github.com/puppetlabs/facter/pull/386

Merged into master as 67454ff.

This should be released in 2.0.0.

Thanks again for the contribution!

-Jeff

#11 Updated by Adrien Thebo about 3 years ago

  • Target version changed from 2.0.0 to 1.6.18

Merged into 1.6.x as 891a148.

This should be released in 1.6.18 and 1.7.

Thanks again for the contribution!

-Adrien

#12 Updated by David Kowis about 3 years ago

I didn’t see this in the 1.7.0 Release Notes. Did it actually make it in?

Thanks, David

#13 Updated by Anonymous about 3 years ago

David Kowis wrote:

I didn’t see this in the 1.7.0 Release Notes. Did it actually make it in?

Thanks, David

Yes, sorry we didn’t call it out explicitly in the release notes. This issue is fixed in patch 891a148 and it is included in the 1.7.0 release.

Hope this helps, -Jeff

Also available in: Atom PDF