Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function
I used you perl script and found the error =
[EMAIL PROTECTED] tmp]# perl relacl.pl
DBI connect('dbname=template1;port=5432','postgres',...) failed: FATAL:
IDENT
authentication failed for user postgres at relacl.pl line 21
Error in connect to DBI:Pg:dbname=template1;port=5432:
Excellent - we know what is going on now!
And my pg_hba.conf is
# IPv4-style local connections:
hostall all 127.0.0.1 255.255.255.255 trust
hostall all 192.168.0.0 255.255.0.0 trust
trusted for every user.
Ok, what I think has happened is that there is another Pg installation
(or another initdb'ed cluster) on this machine that you are accidentally
talking to. Try
$ rpm -qa|grep -i postgres
which will spot another software installation, you may just have to
search for files called pg_hba.conf to find another initdb'ed cluster
This other installation should have a pg_hba.conf that looks something
like :
local all allident
hostall all 127.0.0.1 255.255.255.255 ident
So a bit of detective work is in order :-)
Mark
After being a detector I found that
[EMAIL PROTECTED] ~]# rpm -qa|grep -i postgres
postgresql-7.4.5-3.1.tlc
postgresql-python-7.4.5-3.1.tlc
postgresql-jdbc-7.4.5-3.1.tlc
postgresql-tcl-7.4.5-3.1.tlc
postgresql-server-7.4.5-3.1.tlc
postgresql-libs-7.4.5-3.1.tlc
postgresql-docs-7.4.5-3.1.tlc
postgresql-odbc-7.3-8.1.tlc
postgresql-pl-7.4.5-3.1.tlc
postgresql-test-7.4.5-3.1.tlc
postgresql-contrib-7.4.5-3.1.tlc
[EMAIL PROTECTED] ~]#
no other pg installation except the pgsql for windows in samba folder which I
think it isn't matter ,is it?
No other pg being run.
[EMAIL PROTECTED] ~]# ps ax|grep postmaster
2228 ?S 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
3308 pts/0S+ 0:00 grep postmaster
[EMAIL PROTECTED] ~]#
Is it possible that it is related to pg_ident.conf ?
Any comment please.
Amrit,Thailand
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function
[EMAIL PROTECTED] wrote: I would suspect a DBI/DBD installation issue, either perl DBI cannot find DBD-Pg (not installed ?) or DBD-Pg cannot find your Pg 7.4.5. I note that FC3 comes with Pg 7.4.6 - did you installed 7.4.5 from source? If so this could be why the perl database modules cannot find it (you may need to rebuild DBD-Pg, telling it where your Pg install is). I installed FC3 from rpm kernel 2.6.9 which already included postgresql 7.4.5 . Suppose that there were some missing component , what should be the missing rpm component which I forgot to install ? Ok - I must be looking at the *updated* FC3 distribution... I may have 'jumped the gun' a little - the situation I describe above will prevent *any* access at all to Pg from webmin. If this is the case then check you have (perl) DBI and (perl) DBD-Pg components installed. If on the other hand you can do *some* Pg admin from webmin, and you are only having problems with the grants then there is something it does not like about the *particular* statement. The way to debug this is to do a tiny perl DBI program that tries to execute the statement : select relname, relacl from pg_class where (relkind = 'r' OR relkind = 'S') and relname !~ '^pg_' order by relname So - sorry to confuse, but let us know which situation you have there :-) best wishes Mark ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function
Mark Kirkwood wrote:
If on the other hand you can do *some* Pg admin from webmin, and you are
only having problems with the grants then there is something it does not
like about the *particular* statement. The way to debug this is to do a
tiny perl DBI program that tries to execute the statement :
select relname, relacl from pg_class where (relkind = 'r' OR relkind =
'S') and relname !~ '^pg_' order by relname
I did a quick check of this case... seems to be no problem running this
statement using perl 5.8.5, DBI-1.42 and DBD-Pg-1.22. You might like to
try out the attached test program that does this (You may have to add a
password in order to connect, depending on your security settings).
Mark
#!/usr/bin/perl -w
#
# relacl.pl : testbed for
#
use DBI;
use strict;
my $db = dbname=template1;port=5432;
my $user= postgres;
my $pwd = ;
my $dsn = DBI:Pg:$db;
my $con;
my $sql = select relname, relacl from pg_class where .
(relkind = 'r' OR relkind = 'S') and relname
!~ '^pg_' .
order by relname;
my $sth;
my @row;
$con = DBI-connect($dsn,$user,$pwd)
or die Error in connect to $dsn: $!\n;
$sth = $con-prepare($sql)
or die Error in prepare : $!;
$sth-execute()
or die Error in execute : $!;
print Relname\t\tRelacl\n;
while ( @row = $sth-fetchrow_array() ) {
print $row[0] . \t . $row[1] . \n;
}
$sth-finish();
$con-disconnect();
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PERFORM] Problem with 7.4.5 and webmin 1.8 in grant function
Ok - I must be looking at the *updated* FC3 distribution...
I may have 'jumped the gun' a little - the situation I describe above
will prevent *any* access at all to Pg from webmin. If this is the case
then check you have (perl) DBI and (perl) DBD-Pg components installed.
If on the other hand you can do *some* Pg admin from webmin, and you are
only having problems with the grants then there is something it does not
like about the *particular* statement. The way to debug this is to do a
tiny perl DBI program that tries to execute the statement :
select relname, relacl from pg_class where (relkind = 'r' OR relkind =
'S') and relname !~ '^pg_' order by relname
So - sorry to confuse, but let us know which situation you have there :-)
best wishes
Mark
I used you perl script and found the error =
[EMAIL PROTECTED] tmp]# perl relacl.pl
DBI connect('dbname=template1;port=5432','postgres',...) failed: FATAL: IDENT
authentication failed for user postgres at relacl.pl line 21
Error in connect to DBI:Pg:dbname=template1;port=5432:
And my pg_hba.conf is
# IPv4-style local connections:
hostall all 127.0.0.1 255.255.255.255 trust
hostall all 192.168.0.0 255.255.0.0 trust
trusted for every user.
Would you give me an idea what's wrong?
Thanks .
Amrit,Thailand
---(end of broadcast)---
TIP 8: explain analyze is your friend
