Sqlalchemy and pgpool-II - OperationalError - postgresql

Today I set up pgpool-II on one of my company servers for database replication purposes and I'm trying to connect to it from my application located on another server. Previously it connected to database on the same server where pgpool is now installed without problems - I just needed to provide something like this link in config file:
database: postgresql://user:password#host:port/db_name
I have changed port to the one on which pgpool listens for connections and provided user and password from pcp.conf, but then I get a list of errors after starting app, all of them of the same type:
OperationalError: (OperationalError) unable to open database file None None
Doesn't matter if I'm authenticating as postgresql or pgpool user and if I provide md5 encrypted or plaintext password, errors are the same. How can I properly connect to my database then?

Problem solved days ago, needed to change administrative database in pgpool config from "template1" to "postgres". IDK why it doesn't default to that.

Related

AWS RDS Postgres 11 database Connected to pgAdmin 4

Question
What extra do I get if I fix this and get access to the admin database? (MyDataBaseName normal database works perfectly well)
Do I even need to fix this to use this postgres database for a Django 3.0 project?
Done -> ERROR
I have created a free tear AWS RDS Postgres 11 database.
I allowed external connections at creation and have successfully configured the inbound rules.
Than I have connected to pgAdmin (right click on server groups/create/server)
Than I got 3 database:
MyDataBaseName how I have named my database
postgesql that is auto generated
rdsadmin this is also auto generated,
I have problem with this one that it doesn't opens,
it has a rex x at the database icon
if i click on it it gives the following ERROR message
INTERNAL SERVER ERROR
FATAL: SomeConfigFileName.conf rejects connection for host "host.ip.adders.actully.with.numbers", user "myPersonalUsername", database "rdsadmin", SSL on
FATAL: SomeConfigFileName.conf rejects connection for host "host.ip.adders.actully.with.numbers", user "myPersonalUsername", database "rdsadmin", SSL off
"rdsadmin" is used for internal purposes by AWS. There should be no need to "fix" this.
The only things you are missing is things you aren't allowed to do anyway, and indeed not needing to deal with them yourself is what you are paying Amazon for.
Django shouldn't care. If it demands access to this database, that would be a bug in Django (or a configuration error)

FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user "postgres", database "prod", SSL off

It has been working fine for last several months; and suddenly started noticing this error in application,
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user "postgres", database "prod", SSL off
pg_hba.conf has,
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 0.0.0.0/0 md5
postgresql.conf has,
listen_addresses = '*'
Both file have not been touched/changed for many months.
Has anybody faced similar issue in a running environment ?
I have gone through several connection related issues on stoackoverflow; but they all point to one of these two files being misconfigured. Thats not the issue in this case.
The root cause is found and fixed.
This is what happened (for the benefit of those who might encounter such a strange issue)
Three mysterious entires were found in pg_hba.conf, right at the top of the file
These had reject method configured for user postgres, pgsql & pgdbadm
None of our team members added them
Because these were right at the top, even before "# PostgreSQL Client Authentication Configuration File...." comment starts, we couldn't notice it.
I am still not sure, how these appeared there
It might be some upgrade issue - but we haven't updated Postgres
It might be a partially successful hacking attempt - still investigating this
But to be on safer side, we have changed server credentials and looking into other hardening methods.
It just might save someone a sleepless night, if such an issue occurs, in a perfectly running environment.
I got the same issue. It is a hack. The same thing is described here:
https://dba.stackexchange.com/questions/215834/postgres-9-6-10-pg-hba-conf-altered
I got a new admin postgres user "pgdbadm", which could not be deleted because 3 objects in the template1 database depended on it. After restoring the template1 db from template0 I managed to drop the user.
There were two new rules on the top of the pg_hba.conf file:
host all postgres 0.0.0.0/0 reject
host all pgdbadm 0.0.0.0/0 md5
The rest of the file was the same.
I managed to replicate the hack with no shell access at all by doing the following in pgAdmin 4:
-- creating a new table
create table test(a text);
-- inserting the contents of pg_hba.conf into the table
copy test from '/var/lib/pgsql/data/pg_hba.conf';
-- overwriting the pg_hba.conf file with the contents from the table prepended with one random rule (just to test it)
copy (select 'host all all 127.0.0.1/32 md5' union all select * from test) TO '/var/lib/pgsql/data/pg_hba.conf';
-- cleanup
drop table a;
-- reloading the server config
select pg_reload_conf();
Of course, this was only possible because postgres was set up on an AWS EC2 instance with all ports open, default postgres user, default port, a stupid super-easy to guess password: "asd123". The security logs in the instance were full of attempts to connect on various ports, with various usernames, etc, so it most probably was a random attack.

Heroku Postgres can't connect from heroku app

So I have a go rest api running on Heroku. I had the free tier version but now we have moved the app to production and upgraded to a standard-0 database. None of my code changed the only thing that changed were environmental variables to connect to the database. However, when I try to connect to the database I get this error:
[BRONZE] [5-1] sql_error_code = 28000 FATAL: no pg_hba.conf entry for host "54.234.***.***", user "ub21ndj3*****", database "d8useg2o3****", SSL off
From my understanding its an SSL issue. What I don't understand is my app is running on Heroku servers so I shouldn't need to create a tls config to connect to the database and the same code was working with the previous database. Would there be another issue why I'm getting this error?
Heroku's standard databases and above require SSL connections as of April, 2016. You can see the Changelog entry here. You were able to use the same application code on a hobby database because they do not have the same restriction.

Couldn't drop staging_database : #<PG::ConnectionBad: FATAL: no pg_hba.conf

For a system that I am using, I run into the problem pasted on the title when I try to drop a database and recreate it. More specifically, this is the exact problem that I am facing:
Couldn't drop staging_databse : #<PG::ConnectionBad: FATAL: no pg_hba.conf entry for host xxx.xx.xxxx.xxx, user "ruby", database "postgres", SSL off
I've done some research regarding this problem and it seems that the solution is simply to turn on SSL. I've consulted Postgresql Documentation on pg_hba.conf but I'm unable to find this configuration file.
I typed in locate postgresql and I noticed that there is a postgresql-client-9.2 installed on the system. From what I have determined, I won't find this pg_hba.conf file because the client doesn't have it. I've also looked for the postgresql.conf file on SSL according to the official documentation but this file is not included either.
Finally, the documentation shows me this configuration option of the pgsql 9.2 client shown below:
libpq reads the system-wide OpenSSL configuration file. By default,
this file is named openssl.cnf and is located in the directory reported by
openssl version -d. This default can be overridden by setting environment
variable OPENSSL_CONF to the name of the desired configuration file.
However, this too isn't in my system. I've run the linux find command and this file doesn't seem to be there. I've run out of leagues and I have a sneaking suspicion that I am overlooking something very simple. Is there any other leads I can go on? Thanks.
Based on this message and the rest of the context:
FATAL: no pg_hba.conf entry for host xxx.xx.xxxx.xxx, user "ruby", database "postgres", SSL off
It looks plausible that:
you're connecting to a remote PostgreSQL instance which you don't administrate because you're acting as developer, not admin.
the db management layer tries to connect to the database named postgres in order to drop another database (staging_database) . It's necessary indeed because we can't drop a database when we're connected to it (in fact, a database can't be dropped when anyone is connected to it).
the admin policy established by the remote pg_hba.conf is such that your login and IP address together are not allowed to connect to the database named postgres
These facts combined together imply that you're missing the necessary rights to drop your database, even if indirectly.
At this point you want to submit the problem to the admin responsible for that PostgreSQL server.

Problems with PostgreSQL and ESRI Geoportal Installation on CentOS

I am installing geoportal 1.2.4 on CentOS from the command line terminal...during my installation I am receiving a fatal ident error message for my user geoportal. The pg_hba.conf file has been altered to follow my credentials accordingly, yet I am consistently receivng this error for both the default user postgres and my created user geoportal.
I have created a geoportal db with geoportal user with a password. Trust and md5 authentication methods have been explored in this configuration. I have also installed the ident server, with no avail.
I am able to connect to the geoportal db as postgres user. Below is a screen shot of the error which is returned for both the postgres and geoportal user.....
A look at the PostgreSQL user manual would be well advised here, particularly pg_hba.conf and the rest of the client authentication chapter.
You're trying to use ident authentication but the user ID doesn't match or the ident daemon isn't running.
You probably want md5 password authentication instead.