Обсуждение: dblink not working in FC5
Recently, I upgraded one of my server from FC4 to FC5. This also upgraded
postgresql to 8.1.3. The upgrade was flawless. Unfortunately, I cannot get
dblink to work in this version of postgresql. I created two fresh databases
and tried... still no luck. I keep getting the following error:
bulbulbo=# select dblink_connect('hostaddr=127.0.0.1 dbname=bulbulfo
user=bulbul password=password');
ERROR: could not establish connection
DETAIL: could not connect to server: Permission denied
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
bulbulbo=# select dblink_connect('dbname=bulbulfo user=bulbul');
ERROR: could not establish connection
DETAIL: could not connect to server: Permission denied
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
My pg_hba.conf is as follows:
----------------------
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 password
host all all 192.168.0.0/24 password
host all all 10.1.2.0/24 password
# IPv6 local connections:
host all all ::1/128 sameuser
--------------------
The error seems to be client authentication error. I researched and found
that the message "could not establish connection" seems to coming from
dblink.c (inside contrib/dblink), and it gets triggred when it is unable to
create connection to the database. I though that this may be happening
because libpq is not working properly. So, I compiled a simple program,
written in C, that uses libpq and that program works fine.
I have kind of hit the roadblock. Any help would be appreciated.
Thanks
Manish
"An informed citizenry is the bulwark of a democracy"
http://www.SUNITI.org : Self-governance for an informed citizen
"Manish Gupta" <ml_gupta@hotmail.com> writes:
> bulbulbo=# select dblink_connect('hostaddr=127.0.0.1 dbname=bulbulfo
> user=bulbul password=password');
> ERROR: could not establish connection
> DETAIL: could not connect to server: Permission denied
> Is the server running on host "127.0.0.1" and accepting
> TCP/IP connections on port 5432?
"Permission denied" seems a bit odd here. Just as a wild guess: do you
have SELinux running in enforcement mode, and if so, does switching it
to permissive mode make this work? (See /usr/sbin/getenforce and
setenforce) Another thing to try is a non-TCP connection, ie, leave out
the hostaddr bit.
regards, tom lane
I was able to solve this issue by disabling SELinux. Still, there has got to be a way to use dblink with SELinux. Thanks Manish "An informed citizenry is the bulwark of a democracy" http://www.SUNITI.org : Self-governance for an informed citizen >From: "Manish Gupta" <ml_gupta@hotmail.com> >To: pgsql-admin@postgresql.org >Subject: [ADMIN] dblink not working in FC5 >Date: Wed, 19 Apr 2006 18:26:48 -0400 > >Recently, I upgraded one of my server from FC4 to FC5. This also upgraded >postgresql to 8.1.3. The upgrade was flawless. Unfortunately, I cannot get >dblink to work in this version of postgresql. I created two fresh databases >and tried... still no luck. I keep getting the following error: > >bulbulbo=# select dblink_connect('hostaddr=127.0.0.1 dbname=bulbulfo >user=bulbul password=password'); >ERROR: could not establish connection >DETAIL: could not connect to server: Permission denied > Is the server running on host "127.0.0.1" and accepting > TCP/IP connections on port 5432? > >bulbulbo=# select dblink_connect('dbname=bulbulfo user=bulbul'); >ERROR: could not establish connection >DETAIL: could not connect to server: Permission denied > Is the server running locally and accepting > connections on Unix domain socket "/tmp/.s.PGSQL.5432"? > > >My pg_hba.conf is as follows: >---------------------- >local all all trust ># IPv4 local connections: >host all all 127.0.0.1/32 password >host all all 192.168.0.0/24 password >host all all 10.1.2.0/24 password > ># IPv6 local connections: >host all all ::1/128 sameuser >-------------------- > > >The error seems to be client authentication error. I researched and found >that the message "could not establish connection" seems to coming from >dblink.c (inside contrib/dblink), and it gets triggred when it is unable to >create connection to the database. I though that this may be happening >because libpq is not working properly. So, I compiled a simple program, >written in C, that uses libpq and that program works fine. > >I have kind of hit the roadblock. Any help would be appreciated. > >Thanks > >Manish > >"An informed citizenry is the bulwark of a democracy" >http://www.SUNITI.org : Self-governance for an informed citizen > > > >---------------------------(end of broadcast)--------------------------- >TIP 4: Have you searched our list archives? > > http://archives.postgresql.org
"Manish Gupta" <ml_gupta@hotmail.com> writes:
> I was able to solve this issue by disabling SELinux.
> Still, there has got to be a way to use dblink with SELinux.
Please file a bugzilla entry at bugzilla.redhat.com against the
selinux-policy-targeted component (or whichever policy you're using)
(NOT against postgresql, else I'll just have to relabel it ...)
Also, did you try a non-TCP connection?
regards, tom lane
Hello Tom, I have filed a bug (# 189764) with fedoraproject. I tried with unix sockets with same results. So, for the time being disabling SELinux seems to be the only solution. Thanks for all the help. Manish > >"Manish Gupta" <ml_gupta@hotmail.com> writes: > > I was able to solve this issue by disabling SELinux. > > Still, there has got to be a way to use dblink with SELinux. > >Please file a bugzilla entry at bugzilla.redhat.com against the >selinux-policy-targeted component (or whichever policy you're using) >(NOT against postgresql, else I'll just have to relabel it ...) > >Also, did you try a non-TCP connection? > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
On Mon, Apr 24, 2006 at 10:18:47 -0400, Manish Gupta <ml_gupta@hotmail.com> wrote: > Hello Tom, > > I have filed a bug (# 189764) with fedoraproject. > > I tried with unix sockets with same results. So, for the time being > disabling SELinux seems to be the only solution. You are usually better off setting permissive mode (setenforce permissive) rather than disabling selinux. In permissive mode files and processes continue to get labelled properly so that you won't have to do a relabel later after you are able to go back to enforcing mode. If you are a bit more ambitious, you can use audit2allow to help create a modified policy that will let you continue to run in enforcing mode.