Re: Facter scripts and shell environment variables

[jcbollinger]

On Wednesday, August 15, 2012 4:12:52 AM UTC-5, André Fernandes wrote:

I'm currently running a puppet master-client setup and using facter to gather information on the client hosts.
However, I've run into a problem when trying to get the deployed apache version for some of the hosts.

My custom fact script is as follows:

Facter.add("apache_version") do
  setcode do
        if File.exist? '/bin/httpd'
            Facter::Util::Resolution.exec('/bin/httpd -v | /usr/local/bin/grep version | /usr/bin/cut -d: -f2 | /usr/bin/tr -d " "')
        end
  end
end

For some of the hosts, the /bin/httpd invocation will give the following error: ld.so.1: httpd: fatal: libssl.so.0.9.8: open failed: No such file or directory
This same command runs without issues on a regular (bash) shell.

This is usually indicative of a bad/missing LD_LIBRARY_PATH environment variable.

That makes sense if you in fact rely on LD_LIBRARY_PATH.  I would not expect the system's httpd to do so.  In any case, that premise should be easy to test.

 

It seems that the Facter::Util::Resolution.exec invocation will spawn a new /usr/bin/sh shell session, with very few environment variables set (LD_LIBRARY_PATH is not one of them).
Cross-checking with working hosts shows no differences, I inclusively have a different facter script that reports the output of 'env' and it's similar for both working and non-working hosts.

So it sounds like you're saying the LD_LIBRARY_PATH was a red herring.  Good.  Nobody ought to be relying on LD_LIBRARY_PATH anyway, at least not in production.

 

Has anyone had a similar issue, or has any idea of how to investigate further/work around the problem. Is there a way to explicitly set environment variables on Facter::Util::Resolution.exec invocations?

If the problem is not in fact (no pun intended) LD_LIBRARY_PATH, as you seem to have shown, then I don't see the point.  Nevertheless, since Facter::Util::Resolution.exec is running the given command via the shell (as is evident because pipes are recognized) you should be able to use the standard mechanism of defining variables before the command:

Facter::Util::Resolution.exec('myvar=needed_value do_something --switch1')

I suspect that the cause for the different behaviours may not be caused by puppet/facter, but by some environmental (OS, shell, apache) issue.

I concur.  For example, it could be a security issue.  The puppet agent must run as a privileged user, but facter may drop privilege.  Odd permissions on the directory containing libssl might then cause httpd to be unable to find it.  Alternatively, you might get a similar effect if SELinux (in enforcing mode) prevented facter from reading the needed directory or file, whether or not facter drops privilege.


John

[André Fernandes]

Thanks for the insight.

I've been investigating a bit deeper and found that this is likely an issue with the build of apache I'm using. 

I've run into the same problem with a "squid version" facter script and found that, in the affected hosts, the squid binary had been compiled with the --enable-ssl --with-openssl=/usr/local/ssl flags. The directory specified in the --with-openssl option is not correct, which makes the execution fail when invoking in a non-interactive shell. I could not verify the compile flags for apache, but it's likely a similar scenario.

Curiously enough,  Facter::Util::Resolution.exec doesn't seem to like shell contructs like ';' and '.' (sourcing a script). I've found that sourcing the .profile file ('. /home/apache/.profile /usr/bin/squid -v') in a non-interactive shell makes it possible to execute the binaries, since it sets all the environment variables that are present in an interactive shell, but running it inside Facter::Util::Resolution.exec has no result (the command aborts with no output).

The 'VAR=value some_command' trick won't work either.

I'm running facter 1.5.8, could this be a bug or am I misinterpreting something?

[jcbollinger]

On Thursday, August 23, 2012 7:56:38 AM UTC-5, André Fernandes wrote:

Thanks for the insight.

I've been investigating a bit deeper and found that this is likely an issue with the build of apache I'm using. 

I've run into the same problem with a "squid version" facter script and found that, in the affected hosts, the squid binary had been compiled with the --enable-ssl --with-openssl=/usr/local/ssl flags. The directory specified in the --with-openssl option is not correct, which makes the execution fail when invoking in a non-interactive shell. I could not verify the compile flags for apache, but it's likely a similar scenario.

Curiously enough,  Facter::Util::Resolution.exec doesn't seem to like shell contructs like ';' and '.' (sourcing a script). I've found that sourcing the .profile file ('. /home/apache/.profile /usr/bin/squid -v') in a non-interactive shell makes it possible to execute the binaries, since it sets all the environment variables that are present in an interactive shell, but running it inside Facter::Util::Resolution.exec has no result (the command aborts with no output).

The 'VAR=value some_command' trick won't work either.

I'm running facter 1.5.8, could this be a bug or am I misinterpreting something?

I don't know about Facter 1.5.8 specifically, but I'm looking at the code for the 1.6.x series, and basically it passes your command to a subshell by means of Ruby's %x{} construct.  That does mean you're probably getting /bin/sh, which may alter behavior a bit vs. bash, even if it's an alias for /bin/bash.  Facter does not appear to expect variable assignments before the command, but it doesn't look like that should be a problem in itself as long as the command is absolute (better) or in the search path.

If you turn on debug logging then perhaps it will give you more information on what's happening.


John