FAQ
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. 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.

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?

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

--
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/-/RPfPJssVWncJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Jcbollinger at Aug 16, 2012 at 1:44 pm

    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • André Fernandes at Aug 23, 2012 at 1:02 pm
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Aug 27, 2012 at 3:37 pm

    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

    --
    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/-/kuQpaqqa_K4J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 15, '12 at 3:08p
activeAug 27, '12 at 3:37p
posts4
users2
websitepuppetlabs.com

2 users in discussion

Jcbollinger: 2 posts André Fernandes: 2 posts

People

Translate

site design / logo © 2022 Grokbase