Thread: php connection failure
Readers, Background: http://news-web.php.net/php.general/327600 Since further configuration, remain unable to connect to the php database. Software system is debian, xfce, postgresql, php. Database created on local machine with directory of web server contentin extant normal user account. Then created another normal user: --ingroup [extant normal user] --no-create-home --disabled-login [new normal user of same name as postgresql new role createdfor this database] Please what is the next investigation to make?
On 8/7/21 11:46 AM, ourdiaspora wrote: > Readers, > > Background: http://news-web.php.net/php.general/327600 > > Since further configuration, remain unable to connect to the php database. Further configuration of what? After the configuration change did you restart the server? Is the pg_hba.conf file the correct one for the database instance? What does: pg_lsclusters show? > > Software system is debian, xfce, postgresql, php. Database created on local machine with directory of web server contentin extant normal user account. Then created another normal user: > > --ingroup [extant normal user] --no-create-home --disabled-login [new normal user of same name as postgresql new rolecreated for this database] > > Please what is the next investigation to make? > > > > -- Adrian Klaver adrian.klaver@aklaver.com
On Saturday, August 7th, 2021 at 8:23 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> > Since further configuration, remain unable to connect to the php database.
>
> Further configuration of what?
>
The postgresql configuration file:
SHOW hba_file;
/etc/postgresql/9.6/main/pg_hba.conf
SHOW config_file;
/etc/postgresql/9.6/main/postgresql.conf
> After the configuration change did you restart the server?
>
Yes; the php web page recognised changes, for example removal of the comment instruction:
"
<html>
<head>
Generic CPAC
</head>
<body>
<?php
//echo '<p>Hello World</p>'
/*successful test of configuration of apache http server*/
phpinfo();
?>
</body>
</html>
"
> Is the pg_hba.conf file the correct one for the database instance?
>
Changes were made to the function 'listen_addressess' to the configuration file shown in above.
> What does:
>
> pg_lsclusters
>
> show?
>
pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
On 8/7/21 1:09 PM, ourdiaspora wrote: > > On Saturday, August 7th, 2021 at 8:23 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >>> Since further configuration, remain unable to connect to the php database. >> >> Further configuration of what? >> > > The postgresql configuration file: > > SHOW hba_file; > /etc/postgresql/9.6/main/pg_hba.conf > SHOW config_file; > /etc/postgresql/9.6/main/postgresql.conf > >> After the configuration change did you restart the server? >> > > Yes; the php web page recognised changes, for example removal of the comment instruction: > " > <html> > <head> > Generic CPAC > </head> > <body> > <?php > //echo '<p>Hello World</p>' > /*successful test of configuration of apache http server*/ > phpinfo(); > ?> > </body> > </html> > " That is the Apache server restarting. I was asking about restarting the Postgres server. Was that done? > >> Is the pg_hba.conf file the correct one for the database instance? >> > > Changes were made to the function 'listen_addressess' to the configuration file shown in above. The connection was reaching the database so the 'listen_addresses' is correct. The issue is with the settings in pg_hba.conf and the connection being attempted. There have been similar problems with various OSes and their handling of localhost/120.0.0.2/::1. So for the machine that is running the Postgres server: 1) OS and version? 2) The contents of /etc/hosts 3) What happens if you do?: psql -d cpacweb -h 127.0.0.1 -U cpaca > > >> What does: >> >> pg_lsclusters >> >> show? >> > > pg_lsclusters > Ver Cluster Port Status Owner Data directory Log file > 9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log > > > > -- Adrian Klaver adrian.klaver@aklaver.com
On 8/7/21 1:09 PM, ourdiaspora wrote: > > On Saturday, August 7th, 2021 at 8:23 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > > Changes were made to the function 'listen_addressess' to the configuration file shown in above. > I should have asked in previous post, what was 'listen_addresses' changed to? -- Adrian Klaver adrian.klaver@aklaver.com
On Saturday, August 7th, 2021 at 10:17 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > On 8/7/21 1:09 PM, ourdiaspora wrote: > > > On Saturday, August 7th, 2021 at 8:23 PM, Adrian Klaver adrian.klaver@aklaver.com wrote: > > > Changes were made to the function 'listen_addressess' to the configuration file shown in above. > > I should have asked in previous post, what was 'listen_addresses' > > changed to? > The postgresql server was restarted, successfully. listen_addresses = 'localhost'
On 8/7/21 3:15 PM, ourdiaspora wrote: > > On Saturday, August 7th, 2021 at 10:17 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> On 8/7/21 1:09 PM, ourdiaspora wrote: >> >>> On Saturday, August 7th, 2021 at 8:23 PM, Adrian Klaver adrian.klaver@aklaver.com wrote: >> >>> Changes were made to the function 'listen_addressess' to the configuration file shown in above. >> >> I should have asked in previous post, what was 'listen_addresses' >> >> changed to? >> > > The postgresql server was restarted, successfully. > listen_addresses = 'localhost' And the answers to these previous questions: So for the machine that is running the Postgres server: 1) OS and version? 2) The contents of /etc/hosts 3) What happens if you do?: psql -d cpacweb -h 127.0.0.1 -U cpaca > > > > -- Adrian Klaver adrian.klaver@aklaver.com
ourdiaspora <ourdiaspora@protonmail.com> writes:
> The postgresql server was restarted, successfully.
> listen_addresses = 'localhost'
I believe on most machines, that would result in the postmaster
only listening on 127.0.0.1, and ::1 if you're IPv6-enabled.
If php is trying to connect to something else, like say the
machine's external IP address, that could be your issue.
regards, tom lane
On Saturday, August 7th, 2021 at 11:20 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
> 1. OS and version?
Same local machine as described
> 2. The contents of /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
> 3. What happens if you do?:
>
> psql -d cpacweb -h 127.0.0.1 -U cpaca
>
psql -d cpacweb -h 127.0.0.1 -U cpaca
psql: could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
sudo /etc/init.d/apache2 status
[ ok ] apache2 is running.
sudo service postgresql status
9.6/main (port 5432): online
On Sunday, August 8th, 2021 at 12:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> If php is trying to connect to something else, like say the
>
> machine's external IP address, that could be your issue.
Excuse the ignorance, but if the instruction in the php file is:
"
...$dbconn = pg_connect("dbname=cpacweb user=cpaca host=localhost")...
"
why should php try to connect to anything except 'localhost', as instructed?
ourdiaspora <ourdiaspora@protonmail.com> writes:
> psql -d cpacweb -h 127.0.0.1 -U cpaca
> psql: could not connect to server: Connection refused
> Is the server running on host "127.0.0.1" and accepting
> TCP/IP connections on port 5432?
Hm --- this suggests that you've got a kernel packet filter (i.e.
software firewall) that is not passing traffic for 5432.
It's not very clear how it worked before if that were in place
previously, but since you've said zero about what the working
configuration looked like, that's the best I've got.
regards, tom lane
On Saturday, August 7, 2021, ourdiaspora <ourdiaspora@protonmail.com> wrote:
SHOW hba_file;
/etc/postgresql/9.6/main/pg_hba.conf
Please post the contents of this file. The one shown at the link is invalid.
David J.
On Saturday, August 7, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
ourdiaspora <ourdiaspora@protonmail.com> writes:
> psql -d cpacweb -h 127.0.0.1 -U cpaca
> psql: could not connect to server: Connection refused
> Is the server running on host "127.0.0.1" and accepting
> TCP/IP connections on port 5432?
Hm --- this suggests that you've got a kernel packet filter (i.e.
software firewall) that is not passing traffic for 5432.
Agreed.
It's not very clear how it worked before if that were in place
previously, but since you've said zero about what the working
configuration looked like, that's the best I've got.
I don’t see where it ever did. Only local connections ever were shown to have worked and nothing has been said the non-local connections stopped working, just that none of the changes to config files got them to work (which makes sense as it doesn’t seem our configuration is at fault, at least not exclusively).
David J.
On Sunday, August 8th, 2021 at 12:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Hm --- this suggests that you've got a kernel packet filter (i.e. > > software firewall) that is not passing traffic for 5432. Don't know anything about that, so perhaps it can be assumed unchanged from whatever the default system configuration is...
On Sunday, August 8th, 2021 at 12:50 AM, David G. Johnston <david.g.johnston@gmail.com> wrote: > On Saturday, August 7, 2021, ourdiaspora <ourdiaspora@protonmail.com> wrote: > > > SHOW hba_file; > > > > /etc/postgresql/9.6/main/pg_hba.conf > > Please post the contents of this file. The one shown at the link is invalid. local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgres peer #host replication postgres 127.0.0.1/32 md5 #host replication postgres ::1/128 md5 local cpacweb cpaca trust
On Saturday, August 7, 2021, ourdiaspora <ourdiaspora@protonmail.com> wrote:
On Sunday, August 8th, 2021 at 12:50 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
> On Saturday, August 7, 2021, ourdiaspora <ourdiaspora@protonmail.com> wrote:
>
> > SHOW hba_file;
> >
> > /etc/postgresql/9.6/main/pg_hba.conf
>
> Please post the contents of this file. The one shown at the link is invalid.
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
local cpacweb cpaca trust
Ok. The first line is just redundant but I see that the last line has been made valid.
The reported error: FATAL: no pg_hba.conf entry for host "::1", user "cpaca", database "cpacweb", SSL off
When put against that pg_hba.conf file doesn’t make sense. That was the crux of the original post - everything here has just caused things to be worse off since now we are seeing not listening errors
David J.
On 8/7/21 4:11 PM, ourdiaspora wrote: > On Saturday, August 7th, 2021 at 11:20 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> > > psql -d cpacweb -h 127.0.0.1 -U cpaca > psql: could not connect to server: Connection refused > Is the server running on host "127.0.0.1" and accepting > TCP/IP connections on port 5432? What did you change listen_addresses from? What if you do?: psql -d cpacweb -U cpaca > > sudo /etc/init.d/apache2 status > [ ok ] apache2 is running. > > sudo service postgresql status > 9.6/main (port 5432): online > > > -- Adrian Klaver adrian.klaver@aklaver.com
On Sunday, August 8th, 2021 at 1:02 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > What did you change listen_addresses from? > New line; same line had hash (#) to comment out. > What if you do?: > > psql -d cpacweb -U cpaca > psql -d cpacweb -U cpaca psql: FATAL: Peer authentication failed for user "cpaca"
On 8/7/21 5:36 PM, ourdiaspora wrote: > > On Sunday, August 8th, 2021 at 1:02 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> What did you change listen_addresses from? >> > > New line; same line had hash (#) to comment out. > >> What if you do?: >> >> psql -d cpacweb -U cpaca >> > psql -d cpacweb -U cpaca > psql: FATAL: Peer authentication failed for user "cpaca" > > So from a previous post of yours I have pasted the pg_hba.conf file below my instructions: 1) Get rid of the first local line . 2) Then for the remaining local line below change peer to trust and restart Postgres. 3) Then repeat: psql -d cpacweb -U cpaca local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgres peer #host replication postgres 127.0.0.1/32 md5 #host replication postgres ::1/128 md5 local cpacweb cpaca trust -- Adrian Klaver adrian.klaver@aklaver.com
ourdiaspora <ourdiaspora@protonmail.com> writes:
> psql -d cpacweb -U cpaca
> psql: FATAL: Peer authentication failed for user "cpaca"
The reason that's able to make a connection to the PG server
is that it's not going through TCP at all, but a Unix socket.
I'd guess at this point that your configuration never worked
for TCP connections --- either localhost or not --- because
your kernel packet filter isn't permitting it. It's a gold
plated certainty that the default packet filter configuration
wouldn't allow traffic to port 5432 from off-machine. Whether
it would allow such traffic from localhost is less certain,
but the symptoms you're showing sure look like yours doesn't.
Saying you haven't touched that configuration doesn't excuse
you from investigating it.
regards, tom lane
On Sunday, August 8th, 2021 at 1:51 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > 1. Get rid of the first local line . > 2. Then for the remaining local line below change peer to trust and > > restart Postgres. Thank you, but repeat error occurred: sudo sudo service postgresql restart [ ok ] Restarting PostgreSQL 9.6 database server: main. psql -d cpacweb -U cpaca psql: FATAL: Peer authentication failed for user "cpaca"
On Sunday, August 8th, 2021 at 2:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ourdiaspora ourdiaspora@protonmail.com writes:
>
> > psql -d cpacweb -U cpaca
> >
> > psql: FATAL: Peer authentication failed for user "cpaca"
>
> It's a gold
>
> plated certainty that the default packet filter configuration
>
> wouldn't allow traffic to port 5432 from off-machine.
A quick ddg search revealed:
sudo ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 ::1:5432 :::* users:(("postgres",pid=21794,fd=3))
Is the correct conclusion from this output, that the port 5432 is open?
ourdiaspora <ourdiaspora@protonmail.com> writes:
> A quick ddg search revealed:
> sudo ss -tulpn
> Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
> tcp LISTEN 0 128 ::1:5432 :::* users:(("postgres",pid=21794,fd=3))
> Is the correct conclusion from this output, that the port 5432 is open?
No. The postgres process is listening, but this has nothing to do with
whether the kernel will allow any packets to arrive there.
On recent Red Hat systems, "man nft" might help you.
Not sure about other Linux variants.
regards, tom lane
On 8/10/21 1:59 AM, ourdiaspora wrote: > > On Sunday, August 8th, 2021 at 1:51 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> 1. Get rid of the first local line . >> 2. Then for the remaining local line below change peer to trust and >> >> restart Postgres. > > Thank you, but repeat error occurred: > > sudo sudo service postgresql restart > [ ok ] Restarting PostgreSQL 9.6 database server: main. > > psql -d cpacweb -U cpaca > psql: FATAL: Peer authentication failed for user "cpaca" Then either: 1) There is another local line with peer that you missed. 2) You changed the wrong pg_hba.conf file. What was the path of the file you changed? What is returned when you do?: ps ax | grep postgres What do you see in: sudo vi /var/log/postgresql/postgresql-9.6-main.log when you do a restart? -- Adrian Klaver adrian.klaver@aklaver.com
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, August 10th, 2021 at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The postgres process is listening, but this has nothing to do with > > whether the kernel will allow any packets to arrive there. > Installed 'nftables'. According to the documentation (https://wiki.debian.org/nftables) there are no filter rules by default,so the assumption is that there is no filtration of packets by the software at the kernel stage. The configuration file '/etc/nftables.conf': #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; } chain forward { type filter hook forward priority 0; } chain output { type filter hook output priority 0; } } Is it correct to interpret this configuration file that filtration is _not_ active?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, August 10th, 2021 at 3:44 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> 1. There is another local line with peer that you missed.
> 2. You changed the wrong pg_hba.conf file.
>
Frow within postgresql 'psql' terminal:
SHOW hba_file;
/etc/postgresql/9.6/main/pg_hba.conf
> What was the path of the file you changed?
>
SHOW config_file;
/etc/postgresql/9.6/main/postgresql.conf
# 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 [OPTIONS]
# host DATABASE USER ADDRESS METHOD [OPTIONS]
# hostssl DATABASE USER ADDRESS METHOD [OPTIONS]
# hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]
#
# (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", "replication", a
# database name, or a comma-separated list thereof. The "all"
# keyword does not match "replication". Access to replication
# must be enabled in a separate record (see example below).
#
# 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.
#
# ADDRESS specifies the set of hosts the record matches. It can be a
# host name, or 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. A host name
# that starts with a dot (.) matches a suffix of the actual host name.
# Alternatively, you can write an IP address and netmask in separate
# columns to specify the set of hosts. Instead of a CIDR-address, you
# can write "samehost" to match any of the server's own IP addresses,
# or "samenet" to match any address in any subnet that the server is
# directly connected to.
#
# METHOD can be "trust", "reject", "md5", "password", "gss", "sspi",
# "ident", "peer", "pam", "ldap", "radius" or "cert". Note that
# "password" sends passwords in clear text; "md5" is preferred since
# it sends encrypted passwords.
#
# OPTIONS are a set of options for the authentication in the format
# NAME=VALUE. The available options depend on the different
# authentication methods -- refer to the "Client Authentication"
# section in the documentation for a list of which options are
# available for which authentication methods.
#
# Database and user names containing spaces, commas, quotes and other
# special characters must be quoted. Quoting one of the keywords
# "all", "sameuser", "samerole" or "replication" 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.
# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
#local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
#local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
local cpacweb cpaca trust
> What is returned when you do?:
>
> ps ax | grep postgres
>
ps ax | grep postgres
5844 pts/6 S+ 0:00 sh -c lynx 'http://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg26968.html'
5845 pts/6 S+ 0:00 lynx http://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg26968.html
29573 ? S 0:00 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.6/main -c
config_file=/etc/postgresql/9.6/main/postgresql.conf
29575 ? Ss 0:00 postgres: 9.6/main: checkpointer process
29576 ? Ss 0:00 postgres: 9.6/main: writer process
29577 ? Ss 0:00 postgres: 9.6/main: wal writer process
29578 ? Ss 0:00 postgres: 9.6/main: autovacuum launcher process
29579 ? Ss 0:00 postgres: 9.6/main: stats collector process
30245 pts/11 S+ 0:00 grep postgres
> What do you see in:
>
> sudo vi /var/log/postgresql/postgresql-9.6-main.log
>
> when you do a restart?
>
For sign-in today via commands below, the log file shows nothing new, only the old errors:
"
psql -d cpacweb -U cpacapsql (9.6.16)
Type "help" for help.
cpacweb=> \q
psql -d cpacweb -h localhost -U cpaca Password for user cpaca:
psql (9.6.16)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
cpacweb=> \q
"
The connection to postgresql seems OK now (thank you), but the php web page continues to fail to connect to the
database:
"
<html>
<head>
Generic CPAC database
</head>
<body>
<?php
$dbconn = pg_connect("dbname=cpacweb user=cpaca host=localhost") or die("Could not connect");
$stat = pg_connection_status($dbconn);
if ($stat === PGSQL_CONNECTION_OK) {
echo 'Connection status ok';
} else {
echo 'Connection status bad';
}
?>
</body>
</html>
"
Returns:
"
Generic CPAC database Could not connect
"
Hello,
On Wed, 2021-08-11 at 11:09 +0000, ourdiaspora wrote:
>
>
> The connection to postgresql seems OK now (thank you), but the php
> web page continues to fail to connect to the database:
>
> "
> <html>
> <head>
> Generic CPAC database
> </head>
> <body>
> <?php
> $dbconn = pg_connect("dbname=cpacweb
> user=cpaca host=localhost") or die("Could not connect");
> $stat = pg_connection_status($dbconn);
> if ($stat === PGSQL_CONNECTION_OK) {
> echo 'Connection status ok';
> } else {
> echo 'Connection status bad';
> }
> ?>
> </body>
> </html>
> "
> Returns:
>
> "
> Generic CPAC database Could not connect
> "
>
I don't know which version of PHP you are running, but can you re-write
the call to pg_connect as a try . . . catch block so that the exact
error message is returned instead of just a "die"?
Are you sure postgres is configured to use port 5432? There is no
PGPORT environment variable set?
Why are you starting postgres with a -c option and no parameters
following?
I assume you know that version 9.6 of postgres is nearly at EoL.
HTH,
Rob
ourdiaspora <ourdiaspora@protonmail.com> writes:
> Installed 'nftables'.
If you didn't have nftables installed already, then it's likely that
packet filtering is being controlled by some other userland API.
Can't help you much on what that is.
regards, tom lane
On 8/11/21 4:09 AM, ourdiaspora wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> For sign-in today via commands below, the log file shows nothing new, only the old errors:
> "
> psql -d cpacweb -U cpacapsql (9.6.16)
> Type "help" for help.
>
> cpacweb=> \q
> psql -d cpacweb -h localhost -U cpaca Password for user cpaca:
> psql (9.6.16)
> SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
> Type "help" for help.
>
> cpacweb=> \q
> "
>
> The connection to postgresql seems OK now (thank you), but the php web page continues to fail to connect to the
database:
Is the Web server/PHP app on the same machine as the Postgres server?
If it is on the same machine what happens if you do?:
$dbconn = pg_connect("dbname=cpacweb user=cpaca") or die("Could not
connect");
--
Adrian Klaver
adrian.klaver@aklaver.com
On 8/11/21 6:10 AM, rob stone wrote: > Hello, > > Why are you starting postgres with a -c option and no parameters > following? I see: /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf This is standard for the Ubuntu packages. > > I assume you know that version 9.6 of postgres is nearly at EoL. > > > HTH, > Rob > > > -- Adrian Klaver adrian.klaver@aklaver.com
On 8/11/21 7:09 AM, Adrian Klaver wrote:
> On 8/11/21 4:09 AM, ourdiaspora wrote:
>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> For sign-in today via commands below, the log file shows nothing new,
>> only the old errors:
>> "
>> psql -d cpacweb -U cpacapsql (9.6.16)
>> Type "help" for help.
>>
>> cpacweb=> \q
>> psql -d cpacweb -h localhost -U cpaca Password for user cpaca:
>> psql (9.6.16)
>> SSL connection (protocol: TLSv1.2, cipher:
>> ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
>> Type "help" for help.
>>
>> cpacweb=> \q
>> "
>>
>> The connection to postgresql seems OK now (thank you), but the php web
>> page continues to fail to connect to the database:
>
> Is the Web server/PHP app on the same machine as the Postgres server?
Should have added previously:
Are you using some form of container/VM on the machine for either server?
>
> If it is on the same machine what happens if you do?:
>
> $dbconn = pg_connect("dbname=cpacweb user=cpaca") or die("Could not
> connect");
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 11th, 2021 at 2:10 PM, rob stone <floriparob@gmail.com> wrote: > > the call to pg_connect as a try . . . catch block so that the exact > Sorry but do not understand "try catch block" > > Are you sure postgres is configured to use port 5432? No, but the impression from previous command terminal output is that this port is being "listened to"
On Wednesday, August 11th, 2021 at 3:09 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
> Is the Web server/PHP app on the same machine as the Postgres server?
>
All programs about this question are installed on a single computer; the intention is to test and learn first on a
localmachine.
> If it is on the same machine what happens if you do?:
>
> $dbconn = pg_connect("dbname=cpacweb user=cpaca") or die("Could not
>
> connect");
>
Am happy to report that connection looks successful, because the php web page now reports:
"
Connection status ok
"
Thank you all very much for the help. Hope that other novices benefit too! :)
On 8/11/21 10:02 AM, ourdiaspora wrote:
>
> On Wednesday, August 11th, 2021 at 3:09 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
>>
>> Is the Web server/PHP app on the same machine as the Postgres server?
>>
>
> All programs about this question are installed on a single computer; the intention is to test and learn first on a
localmachine.
>
>> If it is on the same machine what happens if you do?:
>>
>> $dbconn = pg_connect("dbname=cpacweb user=cpaca") or die("Could not
>>
>> connect");
>>
>
> Am happy to report that connection looks successful, because the php web page now reports:
>
> "
> Connection status ok
> "
That is just working around the problem, which is something is blocking
the TCP port 5432 on localhost. Generally speaking, that should not be
happening. You need to figure out what is doing this or you will
probably be facing more issues down the road. From what you have shown
it seems to be related to the Web application itself. I would try with
pg_connect("dbname=cpacweb user=cpaca host=localhost") and look at the
Web server logs.
>
> Thank you all very much for the help. Hope that other novices benefit too! :)
>
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 11th, 2021 at 3:13 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > Are you using some form of container/VM on the machine for either server? > The machine is a chromebook, GNU/Linux via 'crouton' chroot. Is this the potential cause of blockage of port 5432?
On 8/13/21 1:36 PM, ourdiaspora wrote: > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday, August 11th, 2021 at 3:13 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> >> Are you using some form of container/VM on the machine for either server? >> > > The machine is a chromebook, GNU/Linux via 'crouton' chroot. Is this the potential cause of blockage of port 5432? I would say it is the most likely culprit. I would submit an issue here: https://github.com/dnschneid/crouton/issues and see what they say. -- Adrian Klaver adrian.klaver@aklaver.com