Re: [Puppet-dev] Clojure authorization system for SERVER-111...
Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great. On Mon, Feb 23, 2015 at 9:57 AM, Chris Price ch...@puppetlabs.com 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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great. Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :) On Mon, Feb 23, 2015 at 9:57 AM, Chris Price ch...@puppetlabs.com 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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
That works. I just put in a feature request against Hiera for a HOCON native back end :-D. Also, if you'd pop out some native types that can manipulate these things, that would be nifty. While I'm at it, 'include' statements should be available in all config files since includes concat for ordering files in Puppetand we do like Puppet for managing our configs. ;-) Trevor On Mon, Feb 23, 2015 at 11:47 AM, Chris Price ch...@puppetlabs.com wrote: On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great. Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :) On Mon, Feb 23, 2015 at 9:57 AM, Chris Price ch...@puppetlabs.com 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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups Puppet
[Puppet-dev] Re: Clojure authorization system for SERVER-111...
On 2015-23-02 17:47, Chris Price wrote: On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com wrote: Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great.. Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :) Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains. - henrik On Mon, Feb 23, 2015 at 9:57 AM, Chris Price ch...@puppetlabs..com mailto:ch...@puppetlabs.com wrote: On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson eric.soren...@puppetlabs.com mailto: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 http://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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tel:%28410%29%20541-6699 tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com
Re: [Puppet-dev] Re: Clojure authorization system for SERVER-111...
Hmmcan we push some of this down into Environments? It would be nice to have different auth.conf's (and the others) per environment so that I don't have to bust out my regex-fu every time. Thanks, Trevor On Mon, Feb 23, 2015 at 12:22 PM, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-23-02 17:47, Chris Price wrote: On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com wrote: Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great.. Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :) Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains. - henrik On Mon, Feb 23, 2015 at 9:57 AM, Chris Price ch...@puppetlabs..com mailto:ch...@puppetlabs.com wrote: On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson eric.soren...@puppetlabs.com mailto: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 http://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. confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+ auth.confgws_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. (This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.) -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/ CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/ CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail. gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tel:%28410%29%20541-6699 tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs% 2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs% 2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ% 40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are
Re: [Puppet-dev] Re: Clojure authorization system for SERVER-111...
On Feb 23, 2015, at 9:22 AM, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-23-02 17:47, Chris Price wrote: Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :) Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains. Do you mean the rules that these services themselves model? (Like mapping objects to permission levels in RBAC) Because that is a very different data model that I wouldn't expect to render in a config file format at all. On the other hand these services _should_ be able to use the auth.conf replacement to control access their HTTP endpoints, though. Right now all the clj services just have simplistic certificate whitelists. Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/7685A807-C0C7-4C49-9035-3EE9BE191227%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
On Mon, Feb 23, 2015 at 9:39 AM, Trevor Vaughan tvaug...@onyxpoint.com wrote: That works. I just put in a feature request against Hiera for a HOCON native back end :-D. Good idea! Also, if you'd pop out some native types that can manipulate these things, that would be nifty. This should probably be considered 'beta' quality right now, as we're actively working on improving the back-end library that is used to manage the config files so that it does a better job of retaining formatting when you round-trip a config file to/from disk, but here's the module we intend to use for managing these files: https://github.com/puppetlabs/puppetlabs-hocon While I'm at it, 'include' statements should be available in all config files since includes concat for ordering files in Puppetand we do like Puppet for managing our configs. ;-) Interesting. HOCON does support that but I don't think our Ruby library does yet, because we weren't really sure whether people would want to use it. -- 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/CAMx1Qf%2BRO6KM5pHjjF-yWog%2B5yxeJpJ%3DRLoUeC5E3P1CbDJD_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
Well, without 'include' statements, you'd better add some ordering to your puppetlabs-hocon module. Currently, auth.conf is order dependent and I don't really see how you're going to change that (so you probably need ordering anyway). I suppose you could add some systemd-like before/after/depends syntax. Thanks, Trevor On Mon, Feb 23, 2015 at 4:21 PM, Chris Price ch...@puppetlabs.com wrote: On Mon, Feb 23, 2015 at 9:39 AM, Trevor Vaughan tvaug...@onyxpoint.com wrote: That works. I just put in a feature request against Hiera for a HOCON native back end :-D. Good idea! Also, if you'd pop out some native types that can manipulate these things, that would be nifty. This should probably be considered 'beta' quality right now, as we're actively working on improving the back-end library that is used to manage the config files so that it does a better job of retaining formatting when you round-trip a config file to/from disk, but here's the module we intend to use for managing these files: https://github.com/puppetlabs/puppetlabs-hocon While I'm at it, 'include' statements should be available in all config files since includes concat for ordering files in Puppetand we do like Puppet for managing our configs. ;-) Interesting. HOCON does support that but I don't think our Ruby library does yet, because we weren't really sure whether people would want to use it. -- 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/CAMx1Qf%2BRO6KM5pHjjF-yWog%2B5yxeJpJ%3DRLoUeC5E3P1CbDJD_Q%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAMx1Qf%2BRO6KM5pHjjF-yWog%2B5yxeJpJ%3DRLoUeC5E3P1CbDJD_Q%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoUMmPiWEhZqUkLZOrf-GueKyNN%2BEHewF10Jcm1P6VkR0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
Hi Eric, Thanks for your comments, those will be very helpful. See below for some answers/comments. On 23/02/2015 06:18, Eric Sorenson wrote: On Feb 16, 2015, at 2:01 AM, Brice Figureau brice-pup...@daysofwonder.com mailto:brice-pup...@daysofwonder.com wrote: Hi, Following a conversation I had with Kevin and Deepak at last Ghent Contributor summit about solving SERVER-111[*], I started working on a clojure port of the Puppet authorization system (since I wrote a large part of it, I felt I was kind of best placed to start this). For the moment all the code is hosted in its own project on my github account (because that was simpler than abusing another trapperkeeper project as a PR for repeated development): https://github.com/masterzen/trapperkeeper-authorization It's a work in progress with only the following working basic functionalities at the moment: * various ip, host, wildcard, regex, opaque, backreference authorization entries creation/matching (ACE) * authorization entry list (ACL) creation and matching All those features should be fully compatible with the way Puppet authorization system works. 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. Cool :) I went back and surveyed redmine, jira, and ask.pl.com http://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.confgws_rd=ssl https://www.google.com/search?q=site:puppetlabs.com+auth.confgws_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 Definitely, I'm open to suggestions. First, I don't think you need to try to make it compatible with the existing auth.conf format. It's relatively easy to support, so that was my first target which also would allow forward compatibility for the puppet-server. In other answer to your e-mail Henrik mentioned HOCON. I'm a huge fan of HOCON (using it in my $work project since one of the very first release), I will definitely add support for it. I will post my HOCON format proposal here later this week. It'd be good to take the opportunity to move to a structured data format that is easier to read and write programmatically, which addresses issues like Branan's PR https://github.com/puppetlabs/puppet/pull/1353 where the goal was to have different parts of the module codebase manage snippets of auth.conf. Well this PR was a bit more than that, I read the thread correctly. To solve auth.conf generation issue we could just allow to have an include directive (supporting glob'ing), allowing to read fragments with maybe the possibility to merge fragments with the same resource (since the allow/deny ordering is fixed and not based on the file ordering). I think HOCON supports include out of the box. Second, the main UX problem w/ auth.conf seems to be difficulty tracking down why a particular request is being denied. I think this has improved over time but I know it's incredibly frustrating to just get the 403 error on the client and not be able to check the master's logs to see why each set of 'permit' rules was not allowed. So it'd be awesome to start out with easy discoverability/debugging as first class objectives. The version I'm working on gives the exact same error message as the current Puppet version which gives the URI, the method, the incoming certname and IP address, along with the rule file name and line. I don't think we can do much better (feel free to let me know if there's information we should add in case of a deny). (Meta-question: are we sure there's not an existing model -- either a reusable codebase or simply a config syntax -- that we can use directly, rather than reinventing a wheel? The ones I'm most familiar with are apache mod_access and Netscaler content-switching rules, which aren't great examples, but surely this problem has arisen before.) I've checked if there was java or clojure library to implement this, but couldn't find anything. In fact beside Apache, Nginx or TCPwrappers, I don't think there are lot of host based ACL systems out there. We can't really use the first two formats because those are very different than our use case (and cover lots of things we don't really need). The last one looks like auth.conf IMHO. Last, as a quick summary of some functional requirements, I'd like make sure an implementation: - doesn't rely on puppet-specific paths and could be re-used across other services like puppetdb (auth.conf has some implicit magic because IIRC the rules do not see the environment part of the path) Yes that's the design I was aiming to, nothing related to Puppet. I planned to have a puppet mode to support environment, but not in the
Re: [Puppet-dev] Puppet Dev Status -- week ending Feb 21
On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage. Even if we kept it in $vardir/ssl, this would mean the path is /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please note the agent and master vardir's in the specification). Is your concern that SSL data remain in $vardir/ssl or that they remain in /var/lib/puppet/ssl ? -Jeff -- 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/CAOXx1vFymTmFpHe9Fttj%3D9dwvFwXFZNZqUyGMmPBRTzykxP0Ew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Thoughts on Module Namespace Conflicts
The use case I think for having multiple modules of the same name
available is quite limited. I don't think anyone would claim best
practice if they had two apache modules in their modulepath.
I also think there is another component which is versioning. Right now
there is no system for a profile module to know what version of e.g.
rabbitmq is installed. This means it just assumes one and fails if the
rabbitmq class takes different parameters now. One terrible workaround
for this is for classes to accept a 'rabbitmq_module_version' parameter
and then switch on it inside the class. This workaround is actually
used.
So I think as long as we're discussing how to make module owner
detectable, requireable, whatever, that we should involve versioning as
well, because bumping minor or major versions of utility modules like
postgres, mysql, rabbitmq happens a lot.
One case that actually happens where there is a want for two different
modules by the same name, is when an organization is migrating. An org
that is moving from example42-apache to puppetlabs-apache isn't gonna
want to have a flag day where everything is broken. They don't really
want to play move hosts one by one out of an environment into a testing
environment then into a 'done' environment. This is where being able to
have two modules of the same name could be really useful.
Erik proposed allowing modules to specify an interface, then other
modules could implement that interface. I don't think that is a likely
outcome. I think when we have two modules that both manage 'apache' the
only reason one hasn't totally taken over the other is because they have
different underlying ideas about how to manage apache. I.e. what the
inputs are and what the scope of the outputs are.
We on the openstack infrastructure team have even gone so far as to fork
an old version of the apache module to openstackinfra-httpd. This is
0.0.4 of the pl-apache module and takes wildly different inputs. There
are three reasons for the fork. One, this module takes a template, fills
it out, and dumps it in a vhost. Clean and simple. The way we think it
should be. Two, now that we have forked we can update the codebase,
clean it up, and fix bugs. Three, with the module now living as 'httpd'
in our module path, we, or others consuming our infra, can use a modern
version of the apache module for whatever they need.
As a final thought. One way to deal with this problem is to socialize
the requirement of a new metadata file (yay) called something like
manifests/properties.pp. This file would have all the data in
metadata.json. But since it is readable by puppet we could end up with
code that looks like this in our profiles:
class profile () {
case $::apache::properties::author {
'puppetlabs': {
// do some apache stuff the puppetlabs way
}
'example42': {
// do some apache stuff the example42 way
}
'default': { fail(please stop writing your own apache module) }
}
}
And the technique for handling multiple versions of the same module is
basically exactly the same. The cool part of this is that it requires no
code changes to puppet core. The bad part is we'd have to socialize it
and thats really hard.
--
Spencer Krum
n...@spencerkrum.com
On Fri, Feb 20, 2015, at 04:34 PM, Henrik Lindberg wrote:
On 2015-20-02 20:51, Wil Cooley wrote:
In some ways, this is a lot like environments, but unlike environments,
which are unique at the node-level, these allow the use of multiple
module-sets and are scoping for entities at the manifest-level. As I
understand environments, they can (and probably usually should) be
relatively isolated from each other; the purpose of namespaced
module-sets is to allow addressing without isolation. Maybe this is what
Henrik's last message in this thread is getting at when he says:
I have claimed on many occasions that an environment is just like a
module (with higher privileges / precedence). The set of available
modules should be more of a repository kind of thing that the loader
resolves modules from.
I meant that an environment can be seen as a module. Instead of having a
modulepath, it should list all the modules that it requires (those
modules in turn can require other modules). When a module is needed it
should be resolved against a repository of modules. Such a repository
could be implemented many ways; one being that it is just the modules
now on the modulepath.
The main difference is that the resolution from name to actual module is
now free from implementation concerns.
Currently the dependencies that are expressed are between the containers
of logic (the module depends on another specific module with a specific
implementations e.g. puppetlabs/stdlib). This is simple but not very
flexible. It would be far better if the requirements were established
based on what is actually required from that module - say that it needs
a
Re: [Puppet-dev] Clojure authorization system for SERVER-111...
On Mon, Feb 23, 2015 at 1:30 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Well, without 'include' statements, you'd better add some ordering to your puppetlabs-hocon module. Currently, auth.conf is order dependent and I don't really see how you're going to change that (so you probably need ordering anyway). Agree, ordering will be important for a use case like auth.conf. -- 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/CAMx1QfLhN7GYKL3OownsoEAiN3TMO6cWJuAupXJwYBnLu8mqLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] [announce] beaker 2.5.0 released
More details here: https://github.com/puppetlabs/beaker/blob/master/HISTORY.md#LATEST High Fives! -- 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/f3c37885-8220-4454-a5f9-9a26774639e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet Dev Status -- week ending Feb 21
HmmI suppose it might not matter as much so long as we get people used to using 'puppet config print ssldir'. That said, the SSL directory is one of those critical items to back up on your system and the principal of least surprise would be nice here. Honestly using /etc/pki (RHEL) or /etc/ssl (Deb) would be nice, but it's not part of the FHS so probably not a good choice. So, in the end, I'll just use puppet config print ssldir and you can place it wherever makes sense to you. Thanks, Trevor On Mon, Feb 23, 2015 at 5:17 PM, Jeff McCune j...@puppetlabs.com wrote: On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage. Even if we kept it in $vardir/ssl, this would mean the path is /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please note the agent and master vardir's in the specification). Is your concern that SSL data remain in $vardir/ssl or that they remain in /var/lib/puppet/ssl ? -Jeff -- 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/CAOXx1vFymTmFpHe9Fttj%3D9dwvFwXFZNZqUyGMmPBRTzykxP0Ew%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAOXx1vFymTmFpHe9Fttj%3D9dwvFwXFZNZqUyGMmPBRTzykxP0Ew%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoWKdw5xNJgNS79No9iqkBjWqwr%3D0YcQio%3DYjhi%3DG%2BXJvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
