Problem mit Datenbankverbindung über PHP

Hi @ all,

ich versuche bisher vergebens, über ein php-Script eine Datenbankverbindung zu meiner Postgres-DB aufzubauen.
Im Skript steht so etwas, wobei ich aber auch alle möglichen anderen Varianten von Variablenkombinationen probiert/weggelassen habe:

$conn_string=“host=localhost dbname=testdb user=postgres password=’’”;
$conn = pg_connect($conn_string);

Das hier ist die immer gleiche Fehlermeldung:

Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: Ident authentication failed for user “postgres” in …

Die Datenbank “testdb” gehört postgres, beim Login über die Kommandozeile wird kein pwd benötigt.
Wie in diesem Beitrag http://www.pg-forum.de/programmierung/666-datenbankabruf-mit-php-gel-st.html
beschrieben, habe ich die Datei /var/lib/pgsql/data/pg_hba.conf editiert und alle möglichen Zeilen hinzugefügt, u.a. natürlich auch soetwas:
local all all trust
In /etc/init.d/postgresql habe ich die Postgresql-Options mit der Option “-i” versehen:
OPTIONS="${POSTGRES_OPTIONS} -i"
Egal was ich verändere und mit welchen Variablen ich pg_connect aufrufe, es erscheint immer dieselbe Fehlermeldung.
Habt ihr ne Idee, an was es noch liegen könnte? Kann doch nicht so schwierig sein verdammt…
Danke euch im Voraus!
Ingo

Ach so, noch n paar Angaben:
Suse 10.3
Postgresql 8.2.4
PHP 5.2.4

Anmeldung lokal via psql: Verbindung via Socket, es greift ‘lcal’
Anmeldung via PHP: Verbindung via TCP/IP, es greift ‘host’

Wie in diesem Beitrag > http://www.pg-forum.de/programmierung/666-datenbankabruf-mit-php-gel-st.html
beschrieben, habe ich die Datei /var/lib/pgsql/data/pg_hba.conf editiert und alle möglichen Zeilen hinzugefügt, u.a. natürlich auch soetwas:
local all all trust

Es ist nun mal nicht zielführend, via Zufallsgenerator da beliebig was zuzufügen…


Andreas

“host all all trust”
hatte ich auch probiert - kein Erfolg.


sondern?

Ähm, hast du danach den Datenbankserver neu gestartet? Sonst liest er die Einstellungen nicht ein…

cu tb

kein Wunder, es werden 5 Parameter (TYPE DATABASE USER CIDR-ADDRESS METHOD) erwartet.

listen_addresses in der postgresql.conf auch bedacht?

Andreas

Hab ich gemacht, ja:
/etc/init.d/postgresql reload

Die Reihenfolge der Einträge ist auch wichtig. Wenn du “allow” Einträge nach Einträgen schreibst, die den Zugang verbieten, dürfte dein Vorhaben auch nicht von Erfolg gekrönt sein.

Wie akretschmer schon ausführte: am besten beschäftigst du dich etwas mit der Authentifizierung und verstehst das Konzept dahinter. Dann wird alles sehr einfach.

Zwischen ‘all’ und ‘trust’ ist quasi ein Leertab, das wurde hier beim pasten nicht übernommen.
listen_addresses ist meiner Meinung nach defaultmäßig auf localhost, daher hatte ich nichts verändert. Hab’s jetzt mal mit reingenommen und zusätzlich port=5432 in der postgresql.conf eingestellt, bringt aber auch nix. Trotzdem danke.
Als user kann ich übrigens irgendeinen Quatsch angeben, da kommt immer die selbe Fehlermeldung. Nur wenn ich den User komplett weglasse
Bin hier langsam am verzweifeln, gibt’s doch nicht…

Ich kann auch völlig falsche Datenbank- oder Benutzernamen angeben, es kommt immer dieselbe Fehlermeldung.
Ansonsten sieht es so aus:

$conn_string=“dbname=test”;
Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: role “wwwrun” does not exist in…

$conn_string=“dbname=test user=postgres”;
Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: Ident authentication failed for user “postgres” in…

$conn_string=“dbname=test user=bloedsinn”;
Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: Ident authentication failed for user “bloedsinn” in…

Installiert habe ich alle Pakete über Yast…

Ein Leertab ist aber keine CIDR-Adresse, gell?

Egal.


Die Meldung ‘Unable to connect to PostgreSQL server: FATAL: Ident authentication failed for user “postgres”’ besagt, daß sich jemand als User ‘postgres’ ausgibt ohne es zu sein. Dieser User ist exakt der, der das PHP ausführt. Und das dürfte halt auch kaum ‘postgres’ sein. Und ja, die Ident-Methode greift hier, nicht ‘Trust’.

Wie ads schon sagte: die Reihefolge ist wichtig. Vielleicht zeigst uns mal Deine pg_hba.conf?


Andreas

Wie ich im anderen Beitrag schon schrieb: es meldet sich der User an, der das PHP ausführt. Also wwwrun. PG entscheidet sich aufgrund Deiner via pg_hba.conf gewählten Sicherheitsrichtlinie (hüstel Trust wolltest Du) aber für Ident, weil das offenbar eher ‘greift’. Und das stellt halt fest, daß sich ‘wwwrun’ versucht, sich als ‘postgres’ auszugeben, und bekommt dafür die rote Karte.

Im übrigen ist es egal, ob man das via YAST, apt-get, yum oder mit ca. 5000 anderen Möglichkeiten installiert hat. Wichtig ist, daß man es konfiguriert.

Andreas

Voila die pg_hba.conf.
Ich gebe zu, sie endet chaotisch.
Danke im Voraus.


PostgreSQL Client Authentication Configuration File

===================================================

Refer to the “Client Authentication” section in the

PostgreSQL documentation for a complete description

of this file. A short synopsis follows.

This file controls: which hosts are allowed to connect, how clients

are authenticated, which PostgreSQL user names they can use, which

databases they can access. Records take one of these forms:

local DATABASE USER METHOD [OPTION]

host DATABASE USER CIDR-ADDRESS METHOD [OPTION]

hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]

hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]

(The uppercase items must be replaced by actual values.)

The first field is the connection type: “local” is a Unix-domain socket,

“host” is either a plain or SSL-encrypted TCP/IP socket, “hostssl” is an

SSL-encrypted TCP/IP socket, and “hostnossl” is a plain TCP/IP socket.

DATABASE can be “all”, “sameuser”, “samerole”, a database name, or

a comma-separated list thereof.

USER can be “all”, a user name, a group name prefixed with “+”, or

a comma-separated list thereof. In both the DATABASE and USER fields

you can also write a file name prefixed with “@” to include names from

a separate file.

CIDR-ADDRESS specifies the set of hosts the record matches.

It is made up of an IP address and a CIDR mask that is an integer

(between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies

the number of significant bits in the mask. Alternatively, you can write

an IP address and netmask in separate columns to specify the set of hosts.

METHOD can be “trust”, “reject”, “md5”, “crypt”, “password”,

“krb5”, “ident”, “pam” or “ldap”. Note that “password” sends passwords

in clear text; “md5” is preferred since it sends encrypted passwords.

OPTION is the ident map or the name of the PAM service, depending on METHOD.

Database and user names containing spaces, commas, quotes and other special

characters must be quoted. Quoting one of the keywords “all”, “sameuser” or

“samerole” makes the name lose its special character, and just match a

database or username with that name.

This file is read on server startup and when the postmaster receives

a SIGHUP signal. If you edit the file on a running system, you have

to SIGHUP the postmaster for the changes to take effect. You can use

“pg_ctl reload” to do that.

Put your actual configuration here

----------------------------------

If you want to allow non-local connections, you need to add more

“host” records. In that case you will also need to make PostgreSQL listen

on a non-local interface via the listen_addresses configuration parameter,

or via the -i or -h command line switches.



\

TYPE DATABASE USER CIDR-ADDRESS METHOD

“local” is for Unix domain socket connections only

local all all ident sameuser

IPv4 local connections:

host all all 127.0.0.1/32 ident sameuser

IPv6 local connections:

host all all ::1/128 ident sameuser
#-----------------hinzugefügte Zeilen:--------------------------------
host all all trust
host all all trust
local all all trust
local all all ident

Allow any user on the local system to connect to any database under

any database user name using Unix-domain sockets (the default for local

connections).

TYPE DATABASE USER CIDR-ADDRESS METHOD

local all all trust

The same using local loopback TCP/IP connections.

TYPE DATABASE USER CIDR-ADDRESS METHOD

host all all 127.0.0.1/32 trust

The same as the last line but using a separate netmask column

TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

host all all 127.0.0.1 255.255.255.255 trust

Allow any user from any host with IP address 192.168.93.x to connect

to database “postgres” as the same user name that ident reports for

the connection (typically the Unix user name).

TYPE DATABASE USER CIDR-ADDRESS METHOD

host postgres all 192.168.93.0/24 ident sameuser

Allow a user from host 192.168.12.10 to connect to database

“postgres” if the user’s password is correctly supplied.

TYPE DATABASE USER CIDR-ADDRESS METHOD

host postgres all 192.168.12.10/32 md5

In the absence of preceding “host” lines, these two lines will

reject all connection from 192.168.54.1 (since that entry will be

matched first), but allow Kerberos 5 connections from anywhere else

on the Internet. The zero mask means that no bits of the host IP

address are considered so it matches any host.

TYPE DATABASE USER CIDR-ADDRESS METHOD

host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 krb5

Allow users from 192.168.x.x hosts to connect to any database, if

they pass the ident check. If, for example, ident says the user is

“bryanh” and he requests to connect as PostgreSQL user “guest1”, the

connection is allowed if there is an entry in pg_ident.conf for map

“omicron” that says “bryanh” is allowed to connect as “guest1”.

TYPE DATABASE USER CIDR-ADDRESS METHOD

host all all 192.168.0.0/16 ident omicron

If these are the only three lines for local connections, they will

allow local users to connect only to their own databases (databases

with the same name as their database user name) except for administrators

and members of role “support”, who can connect to all databases. The file

$PGDATA/admins contains a list of names of administrators. Passwords

are required in all cases.

TYPE DATABASE USER CIDR-ADDRESS METHOD

local sameuser all md5
local all @Administratoren md5
local all +support md5


AAAAAAAAHHH ich geh kaputt es funzt!
Lag an der Reihenfolge…
Boah is das geil…
Habe eben noch ganz oben eine Zeile
“local all all trust”
eingefügt, quasi vor allen anderen Einträgen dieser Art.
Fettes Dankeschön an alle!

Wie wäre es mal mit lesen? Hier konkret die Antwort von ads mit dem Hinweis, daß die Reihenfolge wichtig ist.
Deine ersten 2 Einträge, local und host, matchen beide für den lokalen Rechner (ich vermute mal, bei PHP greift der host-Eintrag). Na, jedenfalls sind beide ‘ident sameuser’. Also, PG prüft via den Ident-Dienst, ob der aufrufende Prozeß dem selben User gehört. Damit erklärt sich glasklar Dein Fehlerbild.

Nun klar, was zu tun ist?


Andreas

Jo wie oben gesagt, thx, jetzt passt’s und danke für die Mühe.

Êðàñèâûå äåâóøêè èùóò ñåêñ. Áåç îáÿçàòåëüñòâ, ðàäè óäîâîëüñòâèÿ! Ðåãèñòðàöèÿ ñåêñ çíàêîìñòâà îíëàéí