Обсуждение: 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