On Wed, Mar 17, 2010 at 1:51 AM, David Schmitt <[email protected]> wrote:
> On 3/17/2010 5:25 AM, Dan Bode wrote: > >> Hi All, >> >> I have been working on a type/provider for sudoers and would appreciate >> any feedback. >> >> It can be found at: >> >> http://github.com/bodepd/puppet-sudo >> >> There are some slight limitations documented in the README. >> >> Plenty of examples in the tests directory to get people started. >> >> It's a pretty interesting example of how to push the boundaries of >> parsedfile. >> >> I anxiously await your criticisms :) >> >> > > uuuh, shiny :-) > > * It'd probably be nice to build the default file from resources in an > optional class instead of shipping a default that has to be overridden and > cannot be cleaned by the type (it has continuation lines). > good point. or I could just get around to fixing the continuation stuff (I know how, I just need to do it) > > * Overloading the type with the three different types of records confuses > me. Perhaps defines for each of the three types could improve the situation? > This is not possible with parsedfile. Parsedfile is not able to synchronize reading/writing of a file from multiple resource types. Any attempt would leave the final file in an undefined state. Some way to synchronize writes between different types would have to be implemented (non-trivial) Another problem with this is ordering. A common use case is to ensure that a user spec occurs after some alias is defined. It would be harder to implement this with multiple resource types. Luke has some ideas about how this feature could work, I still need to discuss further with him. The gist of it would be to allow parsedfile to support more than one record array. > * I'm sure you could improve on the design of the "Puppet NAMEVAR" stuff > on users entries. I guess the problem there is that the "meat" of the > sudoers file are (user, command) tuples which can be either specified from > the command side (by a module) or the user side (by the site configuration). > What about the following structure: > > only the user spec (user, host, command tuple) is using comment as the namevar. This is because these lines do not have a single element that determines uniqueness. | # site configuration > | sudo_user_alias { 'sw_managers': users => [ 'dan', 'dave' ]; } > | > Aliases already use their name as the NAMEVAR. > | # rpm module > | sudo_cmd_alias { 'SOFTWARE': commands => [ '/bin/rpm', ... ]; } > | sudo_permission { 'SOFTWARE': users => [ 'sw_managers' ]; } > Could you give an example of how you see this working? (ie: what determines uniqueness for user specs/sudo_permission in this example) > > > Best Regards, David > -- > dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at > Klosterneuburg UID: ATU64260999 > > FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
