Re: A local replication entry

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, it is using the pg_hba.conf I thought. I edited the pg_hba.conf file and changed the line I thought pg_basebackup should be using from "trust" to "fake_it" and issued a reload. I saw an "invalid authentication method 'fake_it'" reported in the pg_log/postgresql-Wed.log file. To confirm that it really was using the correct pg_hba.conf file and I stopped the database and tried to start it again. That start did fail with:

<timestamp> % LOG: invalid authentication method "fake_it"
<timestamp> % CONTEXT: line 101 of configuration file "/var/lib/pgsql/9.3/data/pg_hba.conf"
<timestamp> % FATAL: could not load pg_hba.conf

So, it really is using the correct pg_hba.conf.

Allow me to note, in closing, that this particular VM: csgha2 has been a problem child since it was built, and many things have been broken on it. I don't know if this is another one of the very hard-to-solve problems or not. I may try this on another of my sandbox systems. Still I need to know why this is failing.

On 10/29/2014 12:20 PM, Tom Lane wrote:
John Scalia <jayknowsunix@xxxxxxxxx> writes:
I thought you might be correct, Tom, but I double-checked the postgresql.conf file and listen_addresses = "*". I had forgotten to look to see if netstat reported:
tcp    0    0    0.0.0.0:5432            0.0.0.0:*        LISTEN
But even with that established, the pg_basebackup using:
/usr/pgsql-9.3/bin/pg_basebackup -D - -h 127.0.0.1 -Ft -z -c fast -l hourly.backup > backup_file.gz                or
/usr/pgsql-9.3/bin/pg_basebackup -D - -h 127.0.0.1 -U postgres -Ft -z -c fast -l hourly.backup > backup_file.gz
are still failing with:
pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host "127.0.0.1", user "postgres", SSL off
The line from the pg_hba.conf file currently reads:
host    replication    postgres    127.0.0.1/32    trust
I really don't see where the problem is, and I know I've done a reload after every change in the pg-hba.conf.
Everything that you've said looks fine, so the problem is somewhere you're
not looking :-(.  At this point, I'd wonder if the pg_hba.conf file you're
changing is the same one the postmaster is reading.  You might try
confirming that directly by inserting a syntactically-incorrect entry and
seeing if the postmaster bleats about it to the postmaster log when you
issue a reload.

			regards, tom lane




--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux