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

[Lamont Granquist < >]

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