Re: HBA files w/include support?
Re: HBA files w/include support?
От:
Magnus Hagander <magnus@hagander.net>
Дата:
On Fri, Feb 14, 2014 at 3:32 PM, Bruce Momjian <bruce@momjian.us> wrote:
-- On Thu, Feb 13, 2014 at 11:28:45PM -0600, Jerry Sievers wrote:In an ideal world we would have a tool where you could plug in a
> > One issue with this is that pg_hba.conf is order sensitive, which could
> > become a trap for the unwary if includes are used carelessly.
>
> Indeed.
>
> The other thing that comes to mind, is that as opposed to
> postgresql.conf and the include scenario there... one can do show all or
> query from pg_stat_activity just to see what setting they ended up
> with.
>
> I'm not aware of any way to probe what hba rules are loaded at runtime
> and thus, debugging hba config changes not really possible.
username, database, IP address, and test pg_hba.conf file and it would
report what line is matched.
I almost wrote a function you could call to do that a while back. I never finished it though :)
It's not all that hard to do, but requires some minor refactoring of how the HBA code works.
What would also be useful would be to be able to use such a function/tool against a different file than the current HBA one, to verify *before* you reload...
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Re: HBA files w/include support?
От:
Fabrízio de Royes Mello <fabriziomello@gmail.com>
Дата:
On Fri, Feb 14, 2014 at 12:36 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> * Bruce Momjian (bruce@momjian.us) wrote:
> > In an ideal world we would have a tool where you could plug in a
> > username, database, IP address, and test pg_hba.conf file and it would
> > report what line is matched.
>
> That's not a bad idea, but we don't expose the logic that figures that
> out today.. It would, perhaps, not be horrible to duplicate it, but
> then we'd need to make sure that we update both places if it ever
> changes (not that it's changed much in oh-so-many-years). Perhaps
> another candidate to be a GSoC project.
>
I would like to participate the GSoC this year as a student.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
Re: HBA files w/include support?
От:
Jeff Janes <jeff.janes@gmail.com>
Дата:
On Fri, Feb 14, 2014 at 6:33 AM, Bruce Momjian <bruce@momjian.us> wrote:
Do we want a TODO for this?On Fri, Feb 14, 2014 at 03:28:23AM -0500, Stephen Frost wrote:
> Bruce,
> Having @include and directory.d-style capabilities for pg_hba.conf *and*
> pg_ident.conf would make managing larger environments much better.
> There has been some talk about providing those capabilities via tables
> in the catalog, but I'm not aware of anyone working on it and it'd
> certainly be quite a bit more work than adding include/dir.d options.
If we are assembling a wish-list, I've often wanted the opposite of an include. I want the ability to encapsulate the contents of pg_hba.conf directly into postgresql.conf. So instead of giving a filename to hba_file, optionally give a multi-lined string with some kind of here-doc like mechanism, or something like that.
When I set up a forked dev environment and then eventually want to compare the diverged dev setup back to production, I often forget to compare the pg_hba.conf file.
Cheers,
Jeff
Re: HBA files w/include support?
От:
Jeff Janes <jeff.janes@gmail.com>
Дата:
On Sunday, February 16, 2014, Jim Nasby <jim@nasby.net> wrote:
On 2/14/14, 1:06 PM, Jeff Janes wrote:On Fri, Feb 14, 2014 at 6:33 AM, Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>> wrote:
On Fri, Feb 14, 2014 at 03:28:23AM -0500, Stephen Frost wrote:
> Bruce,
> Having @include and directory.d-style capabilities for pg_hba.conf *and*
> pg_ident.conf would make managing larger environments much better.
> There has been some talk about providing those capabilities via tables
> in the catalog, but I'm not aware of anyone working on it and it'd
> certainly be quite a bit more work than adding include/dir.d options.
Do we want a TODO for this?
If we are assembling a wish-list, I've often wanted the opposite of an include. I want the ability to encapsulate the contents of pg_hba.conf directly into postgresql.conf. So instead of giving a filename to hba_file, optionally give a multi-lined string with some kind of here-doc like mechanism, or something like that.
When I set up a forked dev environment and then eventually want to compare the diverged dev setup back to production, I often forget to compare the pg_hba.conf file.
So is this just to avoid having to diff 2 files instead of one?
It is not so much doing two diffs, as remembering to do two diffs, that I would like to avoid. pg_hba.conf is very easy to forget about. I guess if I spent more time worrying about it, then that is the one I would remember and postgresql.conf is the one I'd forget.
Cheers,
Jeff
