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
Archive powered by MHonArc 2.6.16.