Re: Perl Script and Postgres DB running via Apache Web Server

Поиск
Список
Период
Сортировка
От Mark Dalphin
Тема Re: Perl Script and Postgres DB running via Apache Web Server
Дата
Msg-id 38BC0084.8B854CB3@amgen.com
обсуждение исходный текст
Ответ на Perl Script and Postgres DB running via Apache Web Server  (Carla J Breuker <carlajb@juno.com>)
Список pgsql-admin
Hi Carla and Chris,

> I have the following Perl Script (with Postgres code):
>
> [ stuff deleted]

> This Script will run from the command line, and inserts values into the
> existing DB and table. When it is run via the web browser, nothing happens
> (browser hangs). The script is in the /usr/local/httpd/cgi-bin directory,
> owned by a user (not root), and has 755 permissions. We have exhaustively
> searched perl, cgi, postgres, and apache documentation both printed and
> web-based, and cannot determine how to correct this problem. We suspect that
> it may be a permissions / execution rights for the httpd, but we are stumped.
> Any help will be greatly appreciated. Thanks, -Carla and Chris :)

I suspect the problem is not "who owns the script", but rather "who runs the
script".  Usually your httpd runs as user "nobody", who also happens to have
very few permissions for anything on your system.  Meanwhile, your Postgres
database table was create by you and probably doesn't include permissions for
user "nobody" to even "SELECT" the table, much less modify it.

Guessing here, but you probably don't have a Postgres user named "nobody" (see
"createuser") nor have you granted permissions on any tables to user "nobody"
(see the SQL command "grant").  As user "nobody" usually has no login account
for security reasons, you may wish to experiment with permissions by using two
standard login accounts to see who can read what and when.

For what it is worth, I often find with this kind of problem (CGI scripts that
mis-behave especially when interacting with a database) that changing my httpd
logging "up" from a level of "warn" to "debug" and then reading both the httpd
log and the postgresql log file helps greatly in tracking down the problem.

Hope this helps,
Mark

--
Mark Dalphin                          email: mdalphin@amgen.com
Mail Stop: 29-2-A                     phone: +1-805-447-4951 (work)
One Amgen Center Drive                       +1-805-375-0680 (home)
Thousand Oaks, CA 91320                 fax: +1-805-499-9955 (work)




В списке pgsql-admin по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [ADMIN] Why idex scan not used?
Следующее
От: bangh
Дата:
Сообщение: RE:Perl Script and Postgres DB running via Apache Web