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?
On Thursday, August 16, 2012 3:43:57 PM UTC+2, jcbollinger wrote:
>
>
>
> 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
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cB_v0ZK32woJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
