Prev: 'replication' keyword on .pgpass (StreamingReplication)
Next: snapshot generation broken again...
From: Magnus Hagander on 7 Jan 2010 03:46
On Thu, Jan 7, 2010 at 09:26, Fujii Masao <masao.fujii(a)gmail.com> wrote:

> 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?...

I certainly think there are a lot of installations out there with a
database named "replication". That doesn't mean it's unacceptable
though.

However, wouldn't it make more logical sense to replace "host/hostssl"
with "replication/replicationssl" rather than overload the database
field?


--
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: Fujii Masao on 7 Jan 2010 04:13
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
>> 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?

Yeah, the password can be supplied in primary_conninfo.

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

Also you can use the environment variable PGPASSWORD.
Is this enough? I was thinking that some people would
complain that only the password for replication cannot
be supplied in .pgpass.

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 04:21
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
> However, wouldn't it make more logical sense to replace "host/hostssl"
> with "replication/replicationssl" rather than overload the database
> field?

Seems good. How about the following formats?

replication user CIDR-address auth-method [auth-options]
replicationssl user CIDR-address auth-method [auth-options]
replication user IP-address IP-mask auth-method [auth-options]
replicationssl user IP-address IP-mask auth-method [auth-options]

Note that "database" field has been removed since it's useless
for replication.

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: Heikki Linnakangas on 7 Jan 2010 07:39
Tom Lane wrote:
> 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?)

As the patch stands there's an extra startup packet, similar to
SSLRequest, in the connection handshake. But I think we should get rid
of that too, and just send an extra "replication=on" option along with
username and other options in the startup packet.

(as Fujii pointed out already, you can have a database called
"replication". But you need to quote it in pg_hba.conf, like you need to
quote "all" and "sameuser/group/role".)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.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: Magnus Hagander on 7 Jan 2010 07:48
On Thu, Jan 7, 2010 at 10:21, Fujii Masao <masao.fujii(a)gmail.com> wrote:
> On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
>> However, wouldn't it make more logical sense to replace "host/hostssl"
>> with "replication/replicationssl" rather than overload the database
>> field?
>
> Seems good. How about the following formats?
>
>  replication     user  CIDR-address  auth-method  [auth-options]
>  replicationssl  user  CIDR-address  auth-method  [auth-options]
>  replication     user  IP-address  IP-mask  auth-method  [auth-options]
>  replicationssl  user  IP-address  IP-mask  auth-method  [auth-options]
>
> Note that "database" field has been removed since it's useless
> for replication.

Hm, no, I think I withdraw my comment about pg_hba.conf. It seems
better to overload the database name here. I'm not particularly keen
on yet another different set of columns, which is what happens when
you remove the database field.

--
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

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