helm-charts
helm-charts copied to clipboard
[Multinodes] no pg_hba.conf entry
Hi,
When setting up TimescaleDB Multinode, I get the following error when trying to connect from a Cluster IP
no pg_hba.conf entry for host "10.2.0.X", user "postgres", database "postgres", SSL off
The steps to reproduce are as follow (I've followed this tutorial https://praveenperera.com/blog/install-timescale-2-0-on-kubernetes)
- I clone the repository, and use timescaledb-kubernetes/charts/timescaledb-multinode/
- I update templates/svc-timescaledb-access.yaml with spec type to
ClusterIp
- I run
helm install timescale-db timescaledb-multi-charts --namespace=default
with the charts in ./timescaledb-multi-charts - Once all pods are created and everybody seems fine, I try to connect from another pod I create on purpose with
kubectl run -i --tty --rm psql --image=postgres --restart=Never -- bash -il
- Within the pod, I try to run
psql -U postgres -h timescale-db-timescaledb.default.svc.cluster.local postgres
and I get the following errorpsql: error: connection to server at "timescale-db-timescaledb.default.svc.cluster.local" (10.3.240.X), port 5432 failed: FATAL: no pg_hba.conf entry for host "10.2.0.X", user "postgres", database "postgres", SSL off
I'm a little bit lost on how to fix the pg_hba.conf...
Thanks!
Hi,
Actually, it appears to be working well with the following configuration
image:
# Image was built from
# https://github.com/timescale/timescaledb-docker-ha
repository: timescale/timescaledb-ha
tag: pg12.5-ts2.0.0-p0
pullPolicy: IfNotPresent
This image is one year old as mentionned here https://hub.docker.com/layers/timescale/timescaledb-ha/pg12.5-ts2.0.0-p0/images/sha256-6290f40c087534acc351a62d4c05a122b3bfd73dd72e5865a6214e4c3471dd1b?context=explore
I've done some tests with pg13.x or pg14.x release, I was facing the same pg_hba.conf issue... Anything to do to get some recent version?
SSL off
Not sure if this is the root cause or a symptom, but what happens if you force SSL on (use sslmode=require
)?
psql "host=timescale-db-timescaledb.default.svc.cluster.local dbname=postgres user=postgres sslmode=require"
Also, does it work if you connect from your local system, not from K8s?
Hi @alexeyklyukin ,
Indeed, this might be the root cause...
For instance, when I get the access pod logs through kubectl logs -f timescale-db-timescaledb-access-0
I get the following results (sample below)...
2022-03-01 17:13:17 UTC [2155]: [621e542d.86b-1] [unknown]@[unknown],app=[unknown] [00000] LOG: connection received: host=10.2.0.186 port=42914
2022-03-01 17:13:17 UTC [2155]: [621e542d.86b-2] postgres@postgres,app=[unknown] [28000] FATAL: no pg_hba.conf entry for host "10.2.0.186", user "postgres", database "postgres", no encryption
However, I can't see on multinode values.yaml
anything about ssl configuration, and there is no equivalent of configmap-pgbouncer.yaml
.
Hi,
I just had a look on the hb_pga.conf
on the main server, we have on pg14.2-ts2.6.0-latest
the following configuration
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
On the pg12.5-ts2.0.0-p0
there is the following hb_pga.conf
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
host all all all md5
As user postgres don't have sudo user rights within the container, the pg14.2-ts2.6.0-latest
hb_pga.conf cannot be updated.
@gchicoye you sure the is no
hostssl all all all md5
in the first image?
100% sure, I've just done a recheck
I have the same issue, any solution?
Multinode helm chart is deprecated and not supported anymore. If you want to see this chart supported then we are looking for community maintainers - https://github.com/timescale/helm-charts/tree/master/charts/timescaledb-multinode#call-for-maintainers
I am closing this issue as TimescaleDB-Multinode helm chart is no longer maintained and deprecated. We are looking for potential community maintainers who could help us in getting that helm chart working again. If you wish to become a maintainer, please contact us on slack.
Keep in mind that TimescaleDB is not and will not be dropping multinode setup. Deprecation is only about helm chart.