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/-/8-ZkAxB8wcoJ.
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.
