On Mon, Oct 28, 2013 at 2:59 PM, John Bollinger
<john.bollin...@stjude.org>wrote:
>
>
> On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote:
>
>>
>>
>>
>> On Mon, Oct 28, 2013 at 8:42 AM, jcbollinger <john.bo...@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'
>> => []`.
>>
>>
>
> But I think you need to do it. Individual ACEs are for the most part what
> users want to manage. In fact, consider that every file on an NTFS file
> system has an ACL no matter what. How then do the standard ensure =>
> 'present' and ensure => 'absent' even make sense for a resource type
> modeling the Acl itself? Puppet can neither remove file ACLs nor create
> them; it can only manipulate them. What you are ensuring absent or present
> are individual ACEs, so the model should attach the 'ensure' parameter to
> individual ACEs.
>
> Moreover, if ACEs are separate resources then they can be decentralized.
> Suppose, for instance, that a module managing some application needs to
> create a local user and grant that user permissions to access some system
> directory. All is good if it can just drop an appropriate ACE in place,
> but it's an awful mess if the module needs to manage a whole ACL of a
> directory that doesn't belong to it. Especially so when you consider that
> no resource can be declared more than once.
>
How would this model look? Noting that last items about a resource being
declared more than once.
[...snip...]
--
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 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/CAMJiBK7_isyJ7ZaccS6XmgQ_6uEcDJT-Ch%2BezV5V7i1UqbDWqw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
