Support the short local ACL form in pg_hba.conf

[ideasasylum]

See issue #101

[jhoblitt]

There is some similarity to (my) this pull request in terms of supporting 4 position configuration lines. #72

I think that this pull request should be merged if we're not going to change the parameters to postgresql::config::beforeservice but I still feel that it's really non-orthogonal to have all of these configuration parameters: ip_mask_deny_postgres_user, ip_mask_allow_all_users, ipv4acls, & ipv6acls. It would be much cleaner to merge all of the access related parameters into a single 'acls' or the like.

[antaflos]

It would be much cleaner to merge all of the access related parameters into a single 'acls' or the like.

+1 on that. That way we could also control the ordering of the different ACLs.

[ideasasylum]

ah, I should have checked the pending pulls. I just did the simplest thing which could possibly work to fix my problem.

To be honest, I was quite surprised that the ACL strings were being split. It seems that they could have been dumped directly into pg_hba.conf without being split into parts?

[jhoblitt]

If we're going to redesign the API, an array of hashes might be more
flexible. eg.

$acls = [
{
type => 'local',
db => 'foo',
user => 'bar',
method => 'ident',
},
{
type => 'host',
db => 'all',
user => 'all',
cidr => '::1/128',
method => 'md5',
},
]

Then if (my) this pull request
#96 for passing in
an external template gets merged, users will have a lot of power over
how pg_hba.conf is written.

On 01/29/2013 01:25 PM, Jamie Lawrence wrote:

ah, I should have checked the pending pulls. I just did the simplest
thing which could possibly work to fix my problem.

To be honest, I was quite surprised that the ACL strings were being
|split|. It seems that they could have been dumped directly into
pg_hba.conf without being split into parts?

—
Reply to this email directly or view it on GitHub
#102 (comment).

[kbarber]

The pull request #120 provides a defined resource for managing pg_hba rules now, in the spirit of providing full functionality - but still providing backwards compatibility. This PR may no longer apply, or perhaps would need some mods if #120 goes ahead, and I'm interested in any opinons on it.

[kbarber]

Closing this, now #120 is merged and no one has commented.

[ideasasylum]

Yes, #120 is much better. As I said, I was doing the minimal amount of work to support my use case. #120 seems like a much better approach in general

[kbarber]

Good to hear @ideasasylum ... we'll be pushing a new update to the forge soon with that patch. Feel free to raise any more PRs or bugs if you see any related to this problem in general.