[SOLVED] could not connect to server: Permission denied

[ann]

Can anyone explain what going wrong here? I'm at a loss and the postgres mailing list hasn't come up with and answer.

Any sugestions for a fix or how to debug this would be greatly appreciated.

 

The message in the error_log is...

PHP Warning:  pg_connect() [<a href='function.pg-connect'>function.pg-connect</a>]: Unable to connect to PostgreSQL server: could not connect to server: Permission denied\n\tIs the server running on host "localhost" and accepting\n\tTCP/IP connections on port 5432?

 

The PHP code is...

$dbconn=pg_connect( "dbname=lumbribase host=localhost port=5432 user=webuser" );
$dbconn=pg_connect(dbname=$PG_DATABASE);
if ( ! $dbconn ) {
    echo "Error connecting to the database !<br> " ;
    printf("%s", pg_errormessage( $dbconn ) );
    exit(); }

 

According to the postgres guy's "psql -h localhost lumbribase"  means force postgres to use a TCP connection when making a local connection to postgres and that works fine.  Perl scripts using DBD_PG connect fine. Why is postgres denying permission to connections made through PHP? It's not user or database specific.  It would need to connect to the postgres server to check a users permissions but it's not getting that far.

 

This bit's I know are...

http://xyala.cap.ed.ac.uk/php_info.php say's php's configured for pgsql

 

the port is accepting TCP

[#@xyala]# telnet localhost 5432
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Connection closed by foreign host.
[#@xyala]#

 

pg_hba.conf is currently set up to allow anyone in

[#@xyala]# less /var/lib/pgsql/data/pg_hba.conf
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
host    all         all         127.0.0.1/32          trust
host    all         all         ::1/128               trust

 

postgres.conf is set to listen on all ports

[#@xyala]# grep 'listen' /var/lib/pgsql/data/postgresql.conf
# "pg_ctl reload". Some settings, such as listen_address, require
#listen_addresses = 'localhost' # what IP interface(s) to listen on;
listen_addresses = '*'
[#@xyala]#

 

don't know what should be in this file but I can't think I've ever had to change it before.

[#@xyala]# less /etc/php.d/pgsql.ini
; Enable pgsql extension module
extension=pgsql.so

 

the server I'm going to replace is running the same versions of PHP and postgres http://zeldia.cap.ed.ac.uk/php_info.php

The /etc/php.ini files on the two machines are the same and the /var/lib/pgsql/data/postgresql.conf files are only different because I've set listen_addresses = '*' on the new server (xyala) to see if I can make it work.

 

[btherl]

How about compiling a command line installation of php in a local directory, and see if that works.  If it does, then you've narrowed it down 100% to the php configuration.  And if that works, then you know that installing your own php in apache could fix the problem.

 

The message of "permission denied" for a tcp connection is very strange indeed.  It doesn't make much sense to me either.

[ann]

How about compiling a command line installation of php in a local directory, and see if that works.

 

Thanks, I never knew there was such a thing. I didn't compile a local version because I seem to already have it so tell me if I should have.

 

I wrote this little bit of php

 

<?php
$dbconn=pg_connect("dbname=lumbribase");
if ( ! $dbconn ) {
    echo "Error connecting to the database !<br> " ;
    printf("%s", pg_errormessage( $dbconn ) );
    exit(); }
else {echo "connected", "\n";}

$sqlcom="select * from lib";
$dbres = pg_exec($dbconn, $sqlcom );
if ( ! $dbres ) {
     echo "Error : " + pg_errormessage( $dbconn );
     exit();
}

$do = pg_Fetch_Object($dbres, 2);
$name=$do->name;
echo "and the name is... $name\n";
?>

 

and ran it

[ann@xyala tmp]$ php test.php 
connected
and the name is... Juvenile Earthworm Library

 

(I only made it go and get "Juvenile Earthworm Library" because I didn't believe the "connected")

 

">which php" say's I'm using /usr/bin/php on the command line and I think the configure command details on here http://xyala.cap.ed.ac.uk/php_info.php means the web pages use the same php.

 

Is there a difference in how the command line and web interfaces connect?

[ann]

This is going to be an SELinux issue!  I thought I had SELinux turned off but I've just been trying to check and I think it's running in permissive mode.

 

 
[root@xyala ~]# /usr/sbin/sestatus | grep SELinux
SELinux status:                 enabled
SELinuxfs mount:                /selinux
[root@xyala ~]# /usr/sbin/sestatus | grep mode
Current mode:                   permissive

I'm not sure that means it's in permissive mode but I can't get in front of the box to check what I set in the GUI.

 

I've edited /etc/selinux/config to disable it fully but that needs a reboot to take effect and I can't reboot just at the moment.

 

I'll let you know if it starts working (then again you'll probably hear me screaming about SELinux  )

[btherl]

Ah, that would make sense.  I don't know much about SELinux, so I'll leave that to you to figure out   But it sounds like it can deny access to apache for making tcp connections.

 

Regarding php installations, after compiling php you have several ways to install it.  You can install it as an apache module (something like /usr/lib/php4/apache/php4.so), as a CLI program (/usr/bin/php), or both.  Normally it will run as a module under apache, as that is more efficient and more powerful.

 

I suspect that the difference is more that the user Apache runs under does not have permission to make arbitrary outgoing tcp connections, but your user account does.  So when run from the command line, php can connect, but not when run through apache.

[ann]

Thanks btherl.

 

It was indeed the wonder that is SELinux.  When you've got it properly disabled you get...

 

[root@xyala html]# /usr/sbin/sestatus | grep SELinux
SELinux status:                 disabled

 

... as I'm a dinosaur who can see no purpose for it other than wasting my time, I won't be enabling it again.

[msielski]

Just wanted to post a message for anyone who finds this via Google like I did.

 

If you don't want to be using SELinux then disabling it is an option, but if you prefer the other protection it offers you may just want to enable the specific permission to allow Apache to issue HTTP connections.  As root, running:

 

setsebool -P httpd_can_network_connect 1

 

should allow this.