Puppet users - Aug 2012 - Facter scripts and shell environment variables

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.

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.

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.

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.