[chef] Re: Re: Re: Re: Re: Re: Re: Chef Client 10.24.0 not changing permissions on OpenIndiana 151a5.

["Jason J. W. Williams" < >]

It is a symlink and the symlink gets preserved.

On Mon, Apr 22, 2013 at 4:29 PM, Lamont Granquist 
<
 >
 wrote:
>
> Its not a problem of ruby not implementing lchmod, but Solaris/OpenIndiana
> not supporting lchmod.
>
> Symlinks on Solaris are mode 777, everyone has perms to follow the symlink,
> what you can do with the file is determined by the perms on the file, and
> your ability to manage the symlink is determined by your write access to the
> directory.
>
> So a larger problem here is calling template on "/etc/X.cnf" and having it
> be a symlink and then follow that symlink to modify the contents, but to try
> to
> manage the perms on the symlink itself.
>
> Although this bug suggests the behavior is different from what I just stated
> so now I'm a bit confused:
>
> http://tickets.opscode.com/browse/CHEF-3695
>
> I would definitely like to know the result of the -l debug output and know
> what kind of file /etc/X.cnf actually is.  Be useful to know what happens
> when you update the content as well and, if its a symlink, if the symlink
> gets preserved.
>
>
> On 4/22/13 1:50 PM, AJ Christensen wrote:
>>
>> Omnibus installations should be built with a ruby that supports
>> File.lchmod, but I could see how this may be introduced for omnibus
>> installations for a particular platform -- in any case more
>> diagnostics are required.
>>
>> You wouldn't be able to post the debug logs (--log-level) around the
>> WARN line to the ticket as well, thanks?
>>
>> Cheers,
>>
>> AJ
>>
>> On 23 April 2013 08:47, Jason J. W. Williams 
>> <
 >
>> wrote:
>>>
>>> Sure. Can do. I'm running the Omnibus installs. The system Ruby
>>> version is 1.9.2p290.
>>>
>>> -J
>>>
>>> On Mon, Apr 22, 2013 at 1:44 PM, AJ Christensen 
>>> <
 >
>>> wrote:
>>>>
>>>> That's definitely a bug/regression then. :(
>>>>
>>>> What ruby version does your operating system (OI) run? If you can file
>>>> something at tickets.opscode.com with full version details,
>>>> environment details, affected version, I'm sure it will be easy to
>>>> track down.
>>>>
>>>> Cheers,
>>>>
>>>> AJ
>>>>
>>>> On 23 April 2013 08:38, Jason J. W. Williams 
>>>> <
 >
>>>> wrote:
>>>>>
>>>>> Hey AJ,
>>>>>
>>>>> It appeared to be a warning. But it's triggering a :restart action on
>>>>> the service, since the permission attempt is happening each run as if
>>>>> the permission isn't taking.
>>>>>
>>>>> -J
>>>>>
>>>>> On Mon, Apr 22, 2013 at 1:36 PM, AJ Christensen 
>>>>> <
 >
>>>>> wrote:
>>>>>>
>>>>>> It must have been added between 10.24.0 with a backward compatible
>>>>>> fall back -- that is a warning, not an error.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> AJ
>>>>>>
>>>>>> On 23 April 2013 06:29, Jason J. W. Williams
>>>>>> <
 >
>>>>>>  wrote:
>>>>>>>
>>>>>>> Just noticed that Chef Client 10.24.0 reports this error when
>>>>>>> changing
>>>>>>> permissions udner OI 151a5:
>>>>>>>
>>>>>>> [2013-04-22T18:24:29+00:00] INFO: Processing template[/etc/X.cnf]
>>>>>>> action create (X::server line 83)
>>>>>>> [2013-04-22T18:24:29+00:00] INFO: template[/etc/X.cnf] owner changed
>>>>>>> to 70
>>>>>>> [2013-04-22T18:24:29+00:00] WARN: /etc/X.cnf mode not changed:
>>>>>>> File.lchmod is unimplemented on this OS and Ruby version
>>>>>>> [2013-04-22T18:24:29+00:00] INFO: template[/X.cnf] mode changed to
>>>>>>> 600
>>>>>>>
>>>>>>> 10.16.4 didn't have this problem.
>>>>>>>
>>>>>>> -J
>
>