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
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 e
> > > > 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 remo
> -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
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 thi
* 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
* 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 d
> -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 functional
* 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 funda
> -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" 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 the situation
> -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
&
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
fundament
> > >>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 co
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 f
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 t
> > 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
> -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 a
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 too
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 ti
On Mon, Aug 01, 2005 at 12:28:55AM -0400, Tom Lane wrote:
> Bruce Momjian 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 sur
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 a
> > > 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
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 administr
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
> -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 wil
Bruce Momjian 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 change shared_buf
Bruce,
On 7/31/05 5:33 PM, "Bruce Momjian" 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
sounds very useful
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
>
>
>
Luke Lonergan wrote:
> Bruce,
>
> On 7/31/05 6:58 AM, "Bruce Momjian" 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. W
-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 w
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 tha
Bruce,
On 7/31/05 6:58 AM, "Bruce Momjian" 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 pg_shadow
> curren
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 l
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?
Ye
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
--
-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
> capabiliti
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 of
-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 configu
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
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.
>
>
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
administ
42 matches
Mail list logo
