Hi David,
On Wed, Mar 24, 2010 at 1:29 AM, David Schmitt <da...@dasz.at> wrote:
> On 3/22/2010 9:04 PM, Dan Bode wrote:
>
>> * 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 was talking about **defines**, implying that the low-level sudoers type
> be wrapped in some module code. I should have been more explicit about that.
that is reasonable. I somehow missed the word define in the sentence above.
>
> * 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)
>>
>
> This structure would always use an cmd_alias as "anchor" for defining
> permissions and that cmd_alias would only be allowed a single list of users.
> This would be sufficient in the RPM use-case I described.
>
>
I can also imagine use cases where this would be too limiting. If two
classes wanted to specify the same Cmnd_Alias for two different users sets
(is this use case perhaps less valid that I think it is?).
I am not sure if I want to create limitations on how sudoers files can be
created. I think I would rather allow for flexibility and just accept that
NAMEVAR is only an id for each line.
Should it fail if a resource Sudo_cmd_alias[$name] does not exist?
I also just pushed a new version to master that verifies sudoers lines and
fails before it adds them to the file instead of after :)
>
> 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 puppet-...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com<puppet-dev%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>
regards,
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
