Environment variable setting while using a module

[Ugo Bellavance]

Hi,

I'm using the puppetlabs-postgresql module and it works very well, but I want to make it work with a non-standard version of postgresql (from Red Hat Software Collections) because I would like to use Postgresql 9.6 on RHEL 7.  Almost everything is working, but I get errors from some commands that cannot find a shared object.  This is caused by the fact that Software Collections package use non-standard paths for their files.  For example, postgresql binaries are in opt/rh/rh-postgresql96/root/usr/bin/ than /usr/bin/.  Here's the kind of errors I get:

/opt/rh/rh-postgresql96/root/usr/bin/psql: error while loading shared libraries: libpq.so.rh-postgresql96-5: cannot open shared object file: No such file or directory

The modules allows for setting a path for the binaries, but not for the libraries, so it finds the binary, but I would need to set the LD_LIBRARY_PATH.  Since puppet cannot use bash built-in commands, I tried using /bin/bash -c 'export LD_LIBRARY_PATH= but it doesn't work. I guess it a shell of its own and the export doesn't propagate to the original environment.

Does anyone has an idea of what I can do before I ask the maintainers of the module?

Thanks,

Ugo

[Ugo Bellavance]

I think I found a viable solution: 

$ cat /etc/profile.d/enablerh-postgresql96.sh 

#!/bin/bash

source scl_source enable rh-postgresql96

[jcbollinger]

On Friday, March 30, 2018 at 10:32:10 AM UTC-5, Ugo Bellavance wrote:

I think I found a viable solution: 

$ cat /etc/profile.d/enablerh-postgresql96.sh 

#!/bin/bash

source scl_source enable rh-postgresql96

It looks like that's probably the intended solution, so by all means go with it.  In a more general sense, however, LD_LIBRARY_PATH is not a tool for use in a stable configuration.  It is for one-offs, and possibly for for-purpose wrapper scripts.  It is usually a better solution, at least on RedHat-family systems, to add the needed paths to the dynamic linker by dropping an appropriate file in /etc/ld.so.conf.d and running ldconfig.  And it turns out that it's very easy to persuade Puppet to help you with that.

John

[Ugo Bellavance]

On Monday, April 2, 2018 at 10:21:15 AM UTC-4, jcbollinger wrote:

It looks like that's probably the intended solution, so by all means go with it.  In a more general sense, however, LD_LIBRARY_PATH is not a tool for use in a stable configuration.  It is for one-offs, and possibly for for-purpose wrapper scripts.  It is usually a better solution, at least on RedHat-family systems, to add the needed paths to the dynamic linker by dropping an appropriate file in /etc/ld.so.conf.d and running ldconfig.  And it turns out that it's very easy to persuade Puppet to help you with that.

I see.  I discovered that another trick would be to install the *syspaths packages, which put shell scripts in the usual locations of the binaries.  These shell scripts contain the scl_source enable command, plus an exec to the real location of the binary. I haven't tested it yet though.

Thanks,

[Thomas Müller]

Hi Ugo

Am Freitag, 30. März 2018 17:27:28 UTC+2 schrieb Ugo Bellavance:

Hi,

I'm using the puppetlabs-postgresql module and it works very well, but I want to make it work with a non-standard version of postgresql (from Red Hat Software Collections) because I would like to use Postgresql 9.6 on RHEL 7.  Almost everything is working, but I get errors from some commands that cannot find a shared object.  This is caused by the fact that Software Collections package use non-standard paths for their files.  For example, postgresql binaries are in opt/rh/rh-postgresql96/root/usr/bin/ than /usr/bin/.  Here's the kind of errors I get:

/opt/rh/rh-postgresql96/root/usr/bin/psql: error while loading shared libraries: libpq.so.rh-postgresql96-5: cannot open shared object file: No such file or directory

I've used the pl-postgresql module successfully this way:

https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-puppetdb-postgresql-9-5-example-pp

The patch is already included in forge releases.

- Thomas

[Ugo Bellavance]

Hi,

That looks great, but is that in the puppetdb module or in the postgresql module? 

Thanks,

[Thomas Mueller]

I was configuring postgresql SCL for use with the puppetdb module.

the important part  you is the postgresql::globals class that defines all necessary pathes that the postgresql SCL uses.

- Thomas