Bug in pg_hba.conf or pg_basebackup concerning replication connections
All,
If I have the following line in pg_hba.conf:
host replication replication all md5
pg_basebackup -x -v -P -h master1 -U replication -D $PGDATA
pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host "216.121.61.233", user "replication"
But, if I change it to "all" users, replication succeeds:
host replication all all md5
... even if the user "postgres" (the only other user in this test) is declared "with noreplication".
I can't figure out what's going wrong here; either HBA is broken and won't accept a replication line unless user is "all", or pgbasebackup is doing something to test a connection as "postgres", even though no such connection attempt shows up in the logs.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco
Import Notes
Reply to msg id not found: 1468200095.53091.1302372523070.JavaMail.root@mail-1.01.com
On 10 April 2011 04:23, Joshua Berkus <josh@agliodbs.com> wrote:
If I have the following line in pg_hba.conf:
host replication replication all md5
pg_basebackup -x -v -P -h master1 -U replication -D $PGDATA
pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host "216.121.61.233", user "replication"
Welcome to the wonderful world of keywords in hba not being specific
to fields. I encountered this problem myself back in Oct 2010 [1]http://archives.postgresql.org/message-id/AANLkTi=q8DZj79OKrWc-kE9zg-rH-1tcQdqbsbKfO1zF@mail.gmail.com and
predicted that it would bite other users. You've been kind enough to
validate that prediction. I submitted a WIP patch aimed at fixing it
just over a week ago [2]http://archives.postgresql.org/message-id/AANLkTin8p0SoN1YJeXO3cgiDLxev67oh4c7VtJ7e0h4O@mail.gmail.com.
Until that patch (or some other solution) goes through, you'll need to
quote "replication" in your hba.conf if you want to use it as a
username.
Cheers,
BJ
[1]: http://archives.postgresql.org/message-id/AANLkTi=q8DZj79OKrWc-kE9zg-rH-1tcQdqbsbKfO1zF@mail.gmail.com
[2]: http://archives.postgresql.org/message-id/AANLkTin8p0SoN1YJeXO3cgiDLxev67oh4c7VtJ7e0h4O@mail.gmail.com
Welcome to the wonderful world of keywords in hba not being specific
to fields. I encountered this problem myself back in Oct 2010 [1] and
predicted that it would bite other users. You've been kind enough to
validate that prediction. I submitted a WIP patch aimed at fixing it
just over a week ago [2].
Well, I'd like to add this to the Open Issues. Given that I managed to
hit this issue pretty much immediately on a blind test, I'm not going to
be even close to the last user who experiences it.
Has this always been an issue if you have users and databases in
pg_hba.conf with the same name?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 04/09/2011 03:18 PM, Brendan Jurd wrote:
On 10 April 2011 04:23, Joshua Berkus<josh@agliodbs.com> wrote:
If I have the following line in pg_hba.conf:
host replication replication all md5
pg_basebackup -x -v -P -h master1 -U replication -D $PGDATA
pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host "216.121.61.233", user "replication"Welcome to the wonderful world of keywords in hba not being specific
to fields. I encountered this problem myself back in Oct 2010 [1] and
predicted that it would bite other users. You've been kind enough to
validate that prediction. I submitted a WIP patch aimed at fixing it
just over a week ago [2].Until that patch (or some other solution) goes through, you'll need to
quote "replication" in your hba.conf if you want to use it as a
username.Cheers,
BJ[1] http://archives.postgresql.org/message-id/AANLkTi=q8DZj79OKrWc-kE9zg-rH-1tcQdqbsbKfO1zF@mail.gmail.com
[2] http://archives.postgresql.org/message-id/AANLkTin8p0SoN1YJeXO3cgiDLxev67oh4c7VtJ7e0h4O@mail.gmail.com
That's a 2000 line patch that looks like it's out of the question now.
But I think this should fix Josh's immediate problem if we want to do it:
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 2def6ce..4306071 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -492,6 +492,8 @@ check_role(const char *role, Oid roleid, char
*param_str)
return true;
}
else if (strcmp(tok, role) == 0 ||
+ (strcmp(tok, "replication\n") == 0 &&
+ strcmp(role,"replication") ==0) ||
strcmp(tok, "all\n") == 0)
return true;
}Incidentally, are walsenders supposed to be able to match any db name
other than 'replication'? If not, I think we have a bug in check_db(),
which is probably missing an "else return false;" in the amwalsender branch.
cheers
andrew
On 04/09/2011 07:11 PM, Andrew Dunstan wrote:
Incidentally, are walsenders supposed to be able to match any db name
other than 'replication'? If not, I think we have a bug in check_db(),
which is probably missing an "else return false;" in the amwalsender
branch.
Sorry, I misread the code. It will fall through. Sorry for the noise.
cheers
andrew
That's a 2000 line patch that looks like it's out of the question now.
But I think this should fix Josh's immediate problem if we want to do it:
I have confirmed that Andrew's patch works.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com