But there is still no way to verify that the information in the file is
what postgres saw last. DBAs make mistakes too. A simple way to view
the current access state would be much appreciated.
On Apr 1, 2006, at 1:01 PM, Andrew Dunstan wrote:
Er, how can the file be changed behind the scenes
Er, how can the file be changed behind the scenes? Only if you have
opened up permission to the directory to someone else, or you don't
trust your sysadmins.
Either way you would then have much bigger problems than this.
cheers
andrew
Agent M wrote:
Unfortunately, there is still one serio
Unfortunately, there is still one serious deficiency with the solution
below- it may not be the actual information postgresql is currently
using to determine who can log in and how- the file can be easily
changed behind the scenes and there is currently no way to know.
I (speaking as a DBA) wo
On Thu, Mar 30, 2006 at 10:43:31AM -0500, Andrew Dunstan wrote:
> A.M. wrote:
> >Could postgres offer at least a read-only view of the data in the
> >interim? Ordering could be controlled by line number.
>
> You can get the contents as a single text field like this:
>
> | select pg_read_file|('
On Thu, 2006-03-30 at 12:43, Chris Browne wrote:
> [EMAIL PROTECTED] (Andrew Dunstan) writes:
> > We don't have the luxury of being able just to throw out old stuff
> > because we think it might be neater to do it another way. The current
> > rules for HBA are order dependent. The issue raised as
Chris Browne wrote:
Maybe we could do something like this: if there is a pg_hba.conf
file present, then use it as now and ignore the access rights table
- if someone does GRANT/REVOKE CONNECT while under pg_hba.conf then
process it but issue a warning. Maybe there could also be an initdb
switch t
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> We don't have the luxury of being able just to throw out old stuff
> because we think it might be neater to do it another way. The current
> rules for HBA are order dependent. The issue raised as I understood it
> was not to invent a new scheme but to b
[EMAIL PROTECTED] (Tom Lane) writes:
> If your pg_hba.conf looks like
> hostall all 0.0.0.0/32 md5
> there's not much call to update it dynamically ...
There's one case, where .pgpass got hosed, and you didn't have a
backup of it, and need to assign new passwords...
I once
Not sure about the luxury - iirc there was some change in the format
of pg_hba.conf anyway over the time and beside pgadmin3 I dont see
many tools to edit this file (apart from the usual text editor ;)
Just a FYI, PG Lightning Admin edits the pg_hba.conf as well as the
postgresql.conf remotel
A.M. wrote:
Could postgres offer at least a read-only view of the data in the interim?
Ordering could be controlled by line number.
You can get the contents as a single text field like this:
| select pg_read_file|('pg_hba.conf', 0, 50*1024);
Writing a plperl function that would strip com
Could postgres offer at least a read-only view of the data in the interim?
Ordering could be controlled by line number.
On Thu, March 30, 2006 10:14 am, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
>> Tom Lane wrote:
>>
>>> If your pg_hba.conf looks like
>>> hostall a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If your pg_hba.conf looks like
>> host all all 0.0.0.0/32 md5
>> there's not much call to update it dynamically ...
> There'll be a call to update it once - to 0.0.0.0/0 ;-)
Doh ;-). Should make more effort to check my
Tom Lane wrote:
If your pg_hba.conf looks like
hostall all 0.0.0.0/32 md5
there's not much call to update it dynamically ...
There'll be a call to update it once - to 0.0.0.0/0 ;-)
I guess you proved the point about how easy it is the get wrong ;-)
(sorry,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We don't have the luxury of being able just to throw out old stuff
> because we think it might be neater to do it another way.
Well, we could if there were a groundswell of demand showing that the
pg_hba.conf approach were inadequate (don't think so) o
Andrew Dunstan wrote:
Tino Wildenhain wrote:
...
I dont think it has to be ordered preliminary. Since we are
dealing with subnets and stuff - the ordering already lays
in the data - just like routing tables work: most specific
matches first.
I could think of a solution where pg_hba.conf just
o
Tino Wildenhain wrote:
Andrew Dunstan wrote:
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
so we might have some functions like:
in
Tom Lane wrote:
I'm a bit suspicious of proposals that we move either hba or conf into
SQL tables --- one of the main reasons why they are flat files is so
you can still edit them after you've hosed them to the point that the
database won't start or won't let you in. If you don't have a non-klu
On Wed, 2006-03-29 at 16:20 -0500, Jonah H. Harris wrote:
> Enable the alteration and persistence of postgresql.conf and
> pg_hba.conf configuration parameters via SQL.
Agreed.
I'd also add the seemingly obvious caveat that parameters should be
unique. A common problem is for one person to edit
Andrew Dunstan wrote:
>
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
>
> so we might have some functions like:
>
> insert_hba_rul
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
I'm a bit suspicio
On Wednesday 29 March 2006 17:04, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > ISTM that the first requirement is for a sane API that will handle the
> > fact that HBA lines are ordered. Persistence in itself shouldn't be a
> > big problem - we already do that with some shared
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
I'm a bit suspicious of proposals that we
On 3/29/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
I agree.
--
Jonah H. Harris, Dat
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
so we might have some functions like:
insert_hba_rule(at_position int, connection_type
I'd like to expand this idea with this TODO item. If this is already
on the TODO, please disregard. I'm thinking something like the
following:
Enable the alteration and persistence of postgresql.conf and
pg_hba.conf configuration parameters via SQL.
On 3/29/06, BERTHOULE Emmanuel <[EMAIL PROTE
Hi all,
i would like to work on control setting pg_hba.conf via SQL( cf TODO
List ), and i would know if the pg_hda.conf must be replaced by pg_hba
table ?
Emmanuel BERTHOULE
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
26 matches
Mail list logo
