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.
* 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.
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].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
