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:
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?
On 23 April 2013 08:47, Jason J. W. Williams email@example.com wrote:
Sure. Can do. I’m running the Omnibus installs. The system Ruby
version is 1.9.2p290.
On Mon, Apr 22, 2013 at 1:44 PM, AJ Christensen firstname.lastname@example.org 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
On 23 April 2013 08:38, Jason J. W. Williams email@example.com wrote:
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.
On Mon, Apr 22, 2013 at 1:36 PM, AJ Christensen firstname.lastname@example.org wrote:
It must have been added between 10.24.0 with a backward compatible
fall back – that is a warning, not an error.
On 23 April 2013 06:29, Jason J. W. Williams email@example.com 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.