On Mon, 2015-02-23 at 06:57 -0800, Chris Price wrote:
> On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
> <eric.soren...@puppetlabs.com> wrote:
>
> Hi Brice! This project is really cool, thanks for taking it
> on. I have a few comments about requirements and design that I
> hope can save some work and make it easier to include this
> upstream once it's done.
>
>
> I went back and surveyed redmine, jira, and ask.pl.com for
> bugs around auth.conf to see what people have run into over
> the years ( https://www.google.com/search?q=site%
> 3Apuppetlabs.com+auth.conf&gws_rd=ssl ), and from those
> results plus recalling conversations with #puppet there seem
> to be a few general categories that we should examine when
> designing a replacement
>
>
> First, I don't think you need to try to make it compatible
> with the existing auth.conf format. It'd be good to take the
> opportunity to move to a structured data format that is easier
> to read and write programmatically,
>
>
> It would be cool if we could figure out a way to represent the rules
> in HOCON, since that's the format we're using for pretty much all of
> our new config files going forward. That way, the same modules and
> tooling that we're building up around that data format could be used
> on the auth stuff, and the syntax would start to look more consistent
> and familiar compared to other new puppet config files. Since HOCON
> is basically a superset of JSON I'm thinking that maybe the rules
> could be written as basically a big array of maps. It'd be a little
> more verbose than the existing syntax, but I think the tradeoffs might
> be worth it.
How about this:
rules {
"/path/to/first/resource" {
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
}
"^/path/to/(.*)/" {
type = regex
deny = "badhost.domain.com"
allow = [ "$1.domain.com", "goodhost.domain.com" ]
}
}
Since in HOCON objects are merged together when including another
"rules" object its properties would add. The only downside is that the
Config library (the HOCON java support) doesn't seem to support globbing
on include.
What I'm not sure is if hocon respects order of object keys (which might
matters to some for rules ordering).
But it's a much more nicer syntax than using an array:
rules = [
{
endpoint = "/path/to/resource"
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
},
...
]
which is much jsonesque,but might be more correct if order matters,
IMHO.
> (This is presuming, of course, that we don't find some other existing
> model that we like, as Eric suggested.)
Of course, keep me posted if anyone finds something interesting.
--
Brice Figureau <brice-pup...@daysofwonder.com>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/1424774907.9269.22.camel%40arsenic.daysofwonder.com.
For more options, visit https://groups.google.com/d/optout.
