Hello all,
I'm doing a new install of Fedora 21 and migrating apps and services from my old Fedora 15 machine to it. I've run into the following problem...
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 socket does exist: ~$ ls -l /tmp/.s.P* srwxrwxrwx 1 postgres postgres 0 Feb 15 15:10 /tmp/.s.PGSQL.5432= -rw------- 1 postgres postgres 46 Feb 15 15:10 /tmp/.s.PGSQL.5432.lock It runs fine interactively in a shell.
Any suggestions on how to fix the above two problems or general advice of replacing a yum-installed service with an outside one?
I don't want to run two separate (9.3 and 9.4) servers or to run the 9.4 server on a non-standard port, etc -- I really want anything that uses postgresql to talk to my 9.4 server by default.
---- [*] http://www.enterprisedb.com/products-services-training/pgdownload I know about the pgdg repository but that installs postgresql directly under /usr/ which I don't like, and support for it ends roughly when support for F21 ends and I want a solution that will still work even after F21's official EOL. I was able to use the EDB Postgresql 9.1, 9.2, 9.3 and 9.4 versions on F15 (shipped with 9.0) without any problems.
On 02/22/2015 09:35 AM, Stuart McGraw wrote:
Hello all,
I'm doing a new install of Fedora 21 and migrating apps and services from my old Fedora 15 machine to it. I've run into the following problem...
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
- 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...
- 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 socket does exist: ~$ ls -l /tmp/.s.P* srwxrwxrwx 1 postgres postgres 0 Feb 15 15:10 /tmp/.s.PGSQL.5432= -rw------- 1 postgres postgres 46 Feb 15 15:10 /tmp/.s.PGSQL.5432.lock It runs fine interactively in a shell.
Any suggestions on how to fix the above two problems or general advice of replacing a yum-installed service with an outside one?
I don't want to run two separate (9.3 and 9.4) servers or to run the 9.4 server on a non-standard port, etc -- I really want anything that uses postgresql to talk to my 9.4 server by default.
[*] http://www.enterprisedb.com/products-services-training/pgdownload I know about the pgdg repository but that installs postgresql directly under /usr/ which I don't like, and support for it ends roughly when support for F21 ends and I want a solution that will still work even after F21's official EOL. I was able to use the EDB Postgresql 9.1, 9.2, 9.3 and 9.4 versions on F15 (shipped with 9.0) without any problems.
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.
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
- 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...
- 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.
On Sun, Feb 22, 2015 at 09:35:54 -0700, Stuart McGraw smcg4191@frii.com 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 [*].
What I would is rebuild 9.4 using the source rpm from f22 in f21, then update using the generated rpms.
On 02/22/2015 12:40 PM, Bruno Wolff III wrote:
On Sun, Feb 22, 2015 at 09:35:54 -0700, Stuart McGraw smcg4191@frii.com 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 [*].
What I would is rebuild 9.4 using the source rpm from f22 in f21, then update using the generated rpms.
I hadn't thought of that, thanks! I did that and it worked well. I'd still like to get the EDB postgresql to work because it is more independent of Fedora but now that I have something working, I can work on the problem with the EDB version more leisurely. Thanks much for the suggestion.