On 02/22/2015 11:18 AM, jd1008 wrote:
[...]
I have Postgresql-9.3 installed from the Fedora 21 yum repo
in order to satisfy any packages that need postgresql. But
I need to run Postgresql-9.4 so I disabled the yum postgresql
startup via systemd and installed the EDB version of 9.4
into /opt/postgresql [*].
To make the 9.4 one the "system" version, I did two things
1) Replaced the postgresql-9.3 executables in /bin/ with
symlinks to their counterparts in /opt/postgresql/bin/.
2) Added a file to /etc/ld.so.d that adds /opt/postgresql/lib
to the load library cache and ran ldconfig.
That seems to work well, I can run all the Postgresql tools
and everything seems to work correctly, I get the expected 9.4
versions of the tools, etc. Except...
1) It breaks openldap. Apparently one of the libraries in
/opt/postgresql/lib is also used by openldap and is not
compatible. When trying to start the openldap server:
slapd: symbol lookup error: slapcat: undefined symbol:
ber_sockbuf_io_udp
2) Some programs still don't work. For example, a simple
python cgi script using the psycopg2 module to talk to the
database and run under Apache-2.4 that claims it can't find
the postgresql socket "/tmp/.s.PGSQL.5432" even though the
[...]
>
I recall I had run into a similar problem many years ago.
It was solved by putting a shell wrapper around the apps the broke.
In the shell wrapper you set up the not only the execution PATH,
but also the LD_LIBRARY_PATH.
Since the number of packages that can be broken might be
greater than the packages you desire to be in /opt/....
then you might want to not set up symlinks in /bin and /usr/bin.
Instead set up the wrapper shells only for the binaries and libraries
and even the man pages pathways in /bin for the specific package(s)
you prefer; but be sure to name them differently so they do not clash
with existing names in /bin and /usr/bin; just for starting them up from
startup scripts which you are aware of. Those starter scripts will set
up the env variables from the wrapper shell.
This does not always work, because some programs fork and
exec a fixed path in the binaries, a path that might not be what
you want.
Thanks. For one of the problem programs I've found I can
reproduce the problem running it from a command line. However
all my attempts to get it to run by adjusting the environment
have been futile so far and its error messages are not very
helpful. Don't think it is the forking problem you mentioned
because, although it normally runs as a daemon process, it
has a foreground option which I presume disables that.
Anyway, for now I'm using the source rpm from fedora-22
suggested in another message which worked well so I can
look into the problem more leisurely and wrap it (and the
others) once I find the magic incantation.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
