Обсуждение: adding a user library path..

Hi,

I am working on a RHEL 5 box where I do not have any administrative
access. But if need be, I can request the administrator to do some
changes. Currently the following packages are installed on the box:

postgresql.i386,  postgresql-contrib.i386, postgresql-devel.i386,
postgresql-docs.i386, postgresql-libs.i386, postgresql-pl.i386,
postgresql-python.i386, postgresql-server.i386;

all at version 8.1.11-1.el5_1.1.

I have successfully (i think) compiled proj4.6, geos-3.0.0, and
postgis and "installed" them under $HOME (with proper
$LD_LIBRARY_PATH). But postgres server is not aware of this path. How
do I rectify this?

pg_config shows the following (among other parameters):

BINDIR = /usr/bin
INCLUDEDIR = /usr/include
PKGINCLUDEDIR = /usr/include/pgsql
INCLUDEDIR-SERVER = /usr/include/pgsql/server
LIBDIR = /usr/lib
PKGLIBDIR = /usr/lib/pgsql
SHAREDIR = /usr/share/pgsql
SYSCONFDIR = /etc/sysconfig/pgsql

If I understand correctly, the shared libraries for postgis should be
inside $PKGLIBDIR for the server to see them. Is there any userland
configuration (like adding $HOME/usr/local/lib to ~/.psqlrc) that will
solve this?

Again, a userland solution will be helpful unless an administrator's
access is unavoidable!

Thanks in advance,

--
Regards
PK
--------------------------------------
http://counter.li.org  #402424

"P Kapat" <kap4lin@gmail.com> writes:
> If I understand correctly, the shared libraries for postgis should be
> inside $PKGLIBDIR for the server to see them. Is there any userland
> configuration (like adding $HOME/usr/local/lib to ~/.psqlrc) that will
> solve this?

Do you have superuser privs on the database?  If so, you could try
altering the SQL files for postgis etc to reference the shared libraries
where you put them.  But that likely won't work if SELinux is enabled
on the system.

If you don't have superuser then you have no hope of installing these
modules without admin intervention, because you can't execute the CREATE
FUNCTION commands, independently of where the shlibs are.

            regards, tom lane

Thanks Tom,

On Mon, Jun 23, 2008 at 7:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "P Kapat" <kap4lin@gmail.com> writes:
>> If I understand correctly, the shared libraries for postgis should be
>> inside $PKGLIBDIR for the server to see them. Is there any userland
>> configuration (like adding $HOME/usr/local/lib to ~/.psqlrc) that will
>> solve this?
>
> Do you have superuser privs on the database?  If so, you could try
> altering the SQL files for postgis etc to reference the shared libraries
> where you put them.  But that likely won't work if SELinux is enabled
> on the system.

As it happens, I do have superuser privs on the database but (as it
also happens!) SELinux is enabled on this system.

> If you don't have superuser then you have no hope of installing these
> modules without admin intervention, because you can't execute the CREATE
> FUNCTION commands, independently of where the shlibs are.

Two questions in that case:
1. How should the admin go about adding $HOME/usr/local/lib to $PKGLIBDIR?
2. (this is extraneous to the current issue) How is ~/.psqlrc useful
to me? Links to any HOWTOS / Docs will be much appreciated.

>                        regards, tom lane

Regards,
--
Regards
PK
--------------------------------------
http://counter.li.org #402424

"P Kapat" <kap4lin@gmail.com> writes:
> 1. How should the admin go about adding $HOME/usr/local/lib to $PKGLIBDIR?

You don't.  You can try editing the SQL CREATE FUNCTION commands as
I suggested before.  If that doesn't work because of SELinux, you'll
need to get the admin to drop the shlibs into a directory that SELinux
will let Postgres load shlibs from.

Frankly, there's going to be zero interest in any proposal to make this
more flexible, because making it more flexible means opening a
truck-sized security hole.  We don't *want* Postgres loading code from
random places.

            regards, tom lane

On Mon, Jun 23, 2008 at 11:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Frankly, there's going to be zero interest in any proposal to make this
> more flexible, because making it more flexible means opening a
> truck-sized security hole.  We don't *want* Postgres loading code from
> random places.

Hmm.. that makes sense. Unfortunately that leaves me with almost no
options but to request the admin to install the packages globally.
Thanks for clearing the issues.

--
Regards
PK
--------------------------------------
http://counter.li.org #402424