Dave Page wrote:
With this change, editing ph_hba.conf by hand should only be done when
the database is down...
Don't tell me, tell all the users that log bugs when their changes get
lost because they didn't read that bit of the manual for whatever
version this might or might not end up
Magnus Hagander wrote:
I fail to see how this is better than just editing the
file. Because
it basically *is* a file editing function limited to
pg_hba.conf.
Perhaps what we need is a file reader/writer that is
hardcoded to the
pg_hba.conf file?
It allows
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 01:35
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
I am thinking we will need load_pg_hba() and write_pg_hba
Bruce Momjian wrote:
Dave Page wrote:
The problem is, pg_hba.conf might be editted via the OS unlike the text
version of pg_shadow which is only editted via the server, which would
make appropriate locking nigh-on impossible afaics.
Unless you're advocating only allowing pg_hba modifications
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 01:35
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
I am thinking we will need
I am thinking we will need load_pg_hba() and write_pg_hba() that
will load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about the
situation
where dba #1 updates the pg_hba table, at the same time as
dba #2 is
editting pg_hba.conf in
Andreas Pflug wrote:
Bruce Momjian wrote:
Dave Page wrote:
The problem is, pg_hba.conf might be editted via the OS unlike the text
version of pg_shadow which is only editted via the server, which would
make appropriate locking nigh-on impossible afaics.
Unless you're advocating only
On Mon, Aug 01, 2005 at 12:28:55AM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Luke Lonergan wrote:
Has there been any agreement or a concept for remote reboot?
Reload of config file and rotate log files were part of the original
patch that I will try to apply.
Magnus Hagander wrote:
I am thinking we will need load_pg_hba() and write_pg_hba() that
will load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about the
situation
where dba #1 updates the pg_hba table, at the same time as
dba #2 is
Bruce Momjian wrote:
Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
GUCs with pg_settings is the GUC like a table, but with comments that
exceed config_generic.long_desc.
Well, pg_hba.conf is ordered,
From a text editor user's view, postgresql.conf is ordered
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:18
To: Bruce Momjian
Cc: Dave Page; Tom Lane; PostgreSQL-development
Subject: RE: [HACKERS] Remote administration functionality
It allows remote administration, and by using columns
The difference is that if the other admin edited it in vi
*last week*
it will still break with your way, unless every admin
always rembers
to do
load_pg_hba() before doing *anything at all*.
Yes, good point. In thinking about this, I think we are
better having the load()
Andreas Pflug wrote:
Bruce Momjian wrote:
Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
GUCs with pg_settings is the GUC like a table, but with comments that
exceed config_generic.long_desc.
Well, pg_hba.conf is ordered,
From a text editor user's
Magnus Hagander wrote:
The difference is that if the other admin edited it in vi *last week* it
will still break with your way, unless every admin always rembers to do
load_pg_hba() before doing *anything at all*.
What if you send patches over the wire rather than the whole or
subsets of the
The problem is, pg_hba.conf might be editted via the OS unlike the text
version of pg_shadow which is only editted via the server, which would
make appropriate locking nigh-on impossible afaics.
Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf couldn't be
Stephen Frost [EMAIL PROTECTED] writes:
Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
pg_authid or whatever it is now :).
(1) pg_hba.conf is fundamentally order-sensitive; SQL tables are
fundamentally
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:41
To: Bruce Momjian
Cc: Andreas Pflug; Dave Page; Tom Lane; Magnus Hagander;
PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
The problem
Dave Page dpage@vale-housing.co.uk writes:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
I am thinking we will need load_pg_hba() and write_pg_hba() that will
load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about
-Original Message-
From: Douglas McNaught [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:16
To: Dave Page
Cc: Bruce Momjian; Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
Dave Page dpage@vale-housing.co.uk
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
pg_authid or whatever it is now :).
(1) pg_hba.conf is fundamentally
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:51
To: Dave Page
Cc: Bruce Momjian; Andreas Pflug; Tom Lane; Magnus Hagander;
PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
This isn't actually
* Dave Page (dpage@vale-housing.co.uk) wrote:
This isn't actually an argument against my proposal. The
admin doesn't
edit pg_shadow using vi because it's understood to be 'owned' by the
database. The same would be true of 'pg_hba' in my solution.
Only if it were moved to a different
* Dave Page (dpage@vale-housing.co.uk) wrote:
Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
pg_authid or whatever it is now :).
Because the admin doesn't edit pg_shadow using vi or some other
Magnus Hagander wrote:
The difference is that if the other admin edited it in vi
*last week*
it will still break with your way, unless every admin
always rembers
to do
load_pg_hba() before doing *anything at all*.
Yes, good point. In thinking about this, I think we are
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:36
To: Magnus Hagander
Cc: Dave Page; Tom Lane; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
Uh, not sure why it would be harder. What system would
I fail to see how this is better than just editing the
file. Because
it basically *is* a file editing function limited to
pg_hba.conf.
Perhaps what we need is a file reader/writer that is
hardcoded to the
pg_hba.conf file?
It allows remote administration, and by
-Original Message-
From: [EMAIL PROTECTED] on behalf of Steve Atkins
Sent: Sun 7/31/2005 5:35 AM
To: PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
So, while I can see the attraction of being able to futz with the
database security configuration
Bruce Momjian wrote:
I think the group generally would like a
higher-level API that allows something like:
SET GLOBAL log_statement = 'mod';
This is the typical Core point of view. Any function not usable from
psql can't be ok. So until psql isn't enabled to SET GLOBAL, the rest
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Sun 7/31/2005 4:39 AM
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Remote administration functionality
The idea of the patch was to give applications the full unix I/O
Bruce Momjian wrote:
o ...
o recycle log files
o ...
All these items are on the TODO list already.
Didn't find this on the TODO, what does it mean? Is it what
pg_logfile_rotate() does since my very first logger subprocess posts?
Regards,
Andreas
Andreas Pflug wrote:
Bruce Momjian wrote:
o ...
o recycle log files
o ...
All these items are on the TODO list already.
Didn't find this on the TODO, what does it mean? Is it what
pg_logfile_rotate() does since my very first logger subprocess posts?
Yes, I think
Dave Page wrote:
The idea of the patch was to give applications the full unix I/O
capabilities, allowing them to program these functions into
administration applications. I think the group generally would like a
higher-level API that allows something like:
SET GLOBAL
Bruce,
On 7/31/05 6:58 AM, Bruce Momjian pgman@candle.pha.pa.us wrote:
TODO has:
o Allow pg_hba.conf settings to be controlled via SQL
This would require a new global table that is dumped to flat file
for
use by the postmaster. We do a similar thing for
Dave Page wrote:
The best I have come up with is functions similar to:
SELECT pg_set_hba_line(20, 'hostssl all all 192.168.1.1/32 md5');
SELECT pg_add_hba_line(19, '# Allow global access for Dave''s test
workstation');
SELECT pg_delete_hba_line(24);
However, there are a couple of things
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Sun 7/31/2005 2:58 PM
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
I was thinking of a global table that can be modified
Luke Lonergan wrote:
Bruce,
On 7/31/05 6:58 AM, Bruce Momjian pgman@candle.pha.pa.us wrote:
TODO has:
o Allow pg_hba.conf settings to be controlled via SQL
This would require a new global table that is dumped to flat file
for
use by the postmaster.
Dave Page wrote:
-Original Message- From: Bruce Momjian
[mailto:[EMAIL PROTECTED] Sent: Sun 7/31/2005 2:58 PM To: Dave
Page Cc: Tom Lane; Magnus Hagander; PostgreSQL-development Subject:
Re: [HACKERS] Remote administration functionality
I was thinking of a global table
Bruce,
On 7/31/05 5:33 PM, Bruce Momjian pgman@candle.pha.pa.us wrote:
Reload of config file and rotate log files were part of the original
patch that I will try to apply. I am not sure how remote restart would
work.
Reload of config, refresh of IPC structures should be equivalent. It all
Bruce Momjian pgman@candle.pha.pa.us writes:
Luke Lonergan wrote:
Has there been any agreement or a concept for remote reboot?
Reload of config file and rotate log files were part of the original
patch that I will try to apply. I am not sure how remote restart would
work.
Remote reboot to
Let me try to outline where I think our goals are for remote
administration. I will not comment on Dave's analysis of the patch
review process, but I think he has some valid points that this patch was
not treated properly.
Basically, I think everyone wants remote administration. Remote
On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote:
Let me try to outline where I think our goals are for remote
administration. I will not comment on Dave's analysis of the patch
review process, but I think he has some valid points that this patch was
not treated properly.
On Sat, Jul 30, 2005 at 09:35:16PM -0700, Steve Atkins wrote:
On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote:
Let me try to outline where I think our goals are for remote
administration. I will not comment on Dave's analysis of the patch
review process, but I think he has
42 matches
Mail list logo
