On Mon, Oct 28, 2013 at 8:42 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Monday, October 28, 2013 2:55:32 AM UTC-5, Klavs Klavsen wrote:
>>
>>
>>
>> Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds:
>>
> [...]
>
>> The format could look something like the following:
>>>
>>> acl { 'c:/windows/temp/tempfile.txt'**:
>>> ensure => present,
>>> permissions => {
>>> 'Administrators' => ['full']
>>> 'bob' => ['mwrx'],
>>> 'SomeDomain\Lisa' => [x10000000,'allow','inherit','**one_level'],
>>> 'S-5-1-18' => ['wrx','deny','inherit_**objects_only','inherit_only']
>>> },
>>> }
>>>
>>> acl { 'c:/windows/temp/locked_dir':
>>> ensure => exact,
>>>
>>>
>> That one throws me.. ensure exact? I would expect 'exact' to be the same
>> as 'present' (which in thise case is kinda odd wording- but so is exact..
>> who would want puppet to "almost" ensure something?
>>
>
>
> I think Klavs has an excellent point there. After some consideration, I
> think I understand what 'exact' is supposed to mean -- that the ACL should
> contain the specified entries *and no others* -- but the perceived need
> for such a thing suggests that the proposed model is too high level.
> Instead of wrapping everything up into a single Acl resource type, I think
> you need a resource type for individual ACEs. That would also allow you to
> ensure some specific entries present in and some others absent from the
> same ACL, without requiring that all wanted entries be enumerated. A model
> inspired by the Concat module might be suitable.
>
Yes, this is indeed the area I was talking about that is needing more
discussion.
Splitting to a resource type for individual ACEs might be beneficial, but
it also might be too verbose. For an absent ACE, I was considering `'bob'
=> []`.
The actual idea on ensure present versus exact (versus the other values)
and Windows is that there are some inherited ACEs. When you specify
permissions, you are specifying explicit ACEs and not inherited ACEs.
Would you always want to specify 'SYSTEM' and 'Administrators' in every acl
or would that get old having to specify for items that are already going to
be inherited? Are there other permissions that may already be there that
you don't want to manage? That's really where the difference between
present and exact came about. In a way of saying, I want to manage this
particular set of permissions, plus any that are already inherited (idea of
present).
If you don't want to have inherited permissions on a particular ACL, that's
where exact would come in.
> Note too that in the Puppet universe, a parameter or value indicating that
> unmanaged resources should be removed is conventionally spelled "purge" or
> "purged".
>
I think I understand, but let me see if I have this correctly:
acl { 'c:/windows/temp/locked_dir':
ensure => purge,
permissions => {
'Administrators' => ['full']
},
}
Any value not in the list above would be purged, correct? Unfortunately, I
avoided this convention specifically due to how it self documents. It
appears to be ensuring that the specified permission is removed, even
though those that understand the convention know this is not the case.
>
> Additionally, although POSIX ACEs are unordered, it is my understanding
> that the order of ACEs within a Windows ACL is significant. If that is
> indeed correct then I don't see how the proposed model accounts for it.
>
Yes, you are correct. We're talking about this and whether the module
should reorder appropriately for the order in some cases. We've talked
about an array instead of a hash for ACEs.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Rob Reynolds
Developer, Puppet Labs
Join us at PuppetConf 2014, September 23-24 in San Francisco
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
