Prev: 'replication' keyword on .pgpass (StreamingReplication)
Next: snapshot generation broken again...
From: Magnus Hagander on 6 Jan 2010 09:11
On Wed, Jan 6, 2010 at 15:02, Alvaro Herrera <alvherre(a)commandprompt.com> wrote:
> Fujii Masao escribió:
>> On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>> > On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote:
>> >> I don't see the use case for it - .pgpass is for single users, not a whole
>> >> cluster. And it does support wildcards, which takes care of the 'all' case.
>> >> In the case of pg_hba.conf we don't know in advance who will actually be
>> >> connecting. But in the case of .pgpass we do, so the extra utility of
>> >> 'sameuser', 'samerole' and 'samegroup' in this case is not apparent to me.
>> >
>> > OK, I might need to focus only on the use of replication, without
>> > being avaricious.
>>
>> The attached patch supports new keyword 'replication' on .pgpass file.
>> This keyword is used to specify the password for the standby server to
>> connect to the primary server.
>
> Would it make more sense to have a separate password file for the
> replication stuff?  Say .pgreplicationpass or whatever.

I haven't read up on the rest of the patch, but where do we put the
rest of the information about the replication master? Like which IP
and port to connect to? Perhaps it could/should go there?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

From: Tom Lane on 6 Jan 2010 11:51
Fujii Masao <masao.fujii(a)gmail.com> writes:
> The attached patch supports new keyword 'replication' on .pgpass file.
> This keyword is used to specify the password for the standby server to
> connect to the primary server.

This strikes me as a completely bad idea. We need get no farther than
the point that it assumes nobody can have a database named "replication"
(although I notice the patch also appears to assume that libpq knows
internally that the connection is for replication --- I thought we were
going to avoid libpq changes for SR?)

I don't see any real strong reason why a .pgpass entry for this purpose
couldn't depend on having "*" in the database field. But the later
comments that the password should be in some other configuration file
altogether are probably an even better idea.

regards, tom lane

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

From: Fujii Masao on 7 Jan 2010 01:19
On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
> I haven't read up on the rest of the patch, but where do we put the
> rest of the information about the replication master? Like which IP
> and port to connect to? Perhaps it could/should go there?

Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo'

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

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

From: Fujii Masao on 7 Jan 2010 03:26
On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> This strikes me as a completely bad idea.  We need get no farther than
> the point that it assumes nobody can have a database named "replication"

Though I might misunderstand your point. My proposal would force the users
who have a database named "replication" to change their .pgpass file and
enclose the "replication" database field in double quote when they upgrade
the Postgres to v8.5. For example;

192.168.1.50:5432:"replication":foo:foopass

The same problem also exists in pg_hba.conf. It's because I introduced
new keyword "replication" in pg_hba.conf to authenticate the standby
server. This restriction is not acceptable? If so, I'd need to consider
an authentication configuration for replication again: introduce new
configuration file? just change the keyword name to "unpopular" one?...

> (although I notice the patch also appears to assume that libpq knows
> internally that the connection is for replication --- I thought we were
> going to avoid libpq changes for SR?)

Yes, but I changed the libpq just a bit; if the conninfo string including
"replication=1" is given to PQconnectdb(), the libpq determines that this
connection is for replication, and puts the replication-request in a startup
packet. This is for a backend to switch to walsender mode when the startup
packet arrives. Otherwise, we would have to authenticate such backend twice
on different context, i.e., a normal backend and walsender. So the settings
for each context would be required in pg_hba.conf. This is odd, I think.

> I don't see any real strong reason why a .pgpass entry for this purpose
> couldn't depend on having "*" in the database field.

Oh, you are right. Since a role cannot use a different password per database,
"*" in the database field seems to be enough.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

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

From: Magnus Hagander on 7 Jan 2010 03:44
On Thu, Jan 7, 2010 at 07:19, Fujii Masao <masao.fujii(a)gmail.com> wrote:
> On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
>> I haven't read up on the rest of the patch, but where do we put the
>> rest of the information about the replication master? Like which IP
>> and port to connect to? Perhaps it could/should go there?
>
> Such information are supplied in the parameter 'primary_conninfo' of
> recovery.conf. For example;
>
>    primary_conninfo = 'host=192.168.1.50 port=5432 user=foo'

So the password can just go there, no?

If an untrusted user has direct read access to your PGDATA directory
(where recovery.conf goes), you've lost already...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

 |  Next  |  Last
Pages: 1 2 3
Prev: 'replication' keyword on .pgpass (StreamingReplication)
Next: snapshot generation broken again...