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
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 jasonjwwilliams@gmail.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.
-J
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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
Sure. I'll run it with -l debug and sanitize.
-J
On Mon, Apr 22, 2013 at 1:50 PM, AJ Christensen aj@junglist.gen.nz 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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.com 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 aj@junglist.gen.nz 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 jasonjwwilliams@gmail.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.
-J
It is a symlink and the symlink gets preserved.
On Mon, Apr 22, 2013 at 4:29 PM, Lamont Granquist lamont@opscode.com 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 jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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 jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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
jasonjwwilliams@gmail.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.
-J
Can you apply the template resource to the target of the symlink and
manage the symlink with a link resource?
On 4/22/13 4:34 PM, Jason J. W. Williams wrote:
It is a symlink and the symlink gets preserved.
On Mon, Apr 22, 2013 at 4:29 PM, Lamont Granquist lamont@opscode.com 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 jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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 jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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
jasonjwwilliams@gmail.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.
-J
We're going to have to work something out because this is a cookbook
that applies on both Linux and Solaris systems. It appears there's a
package we install that makes the location a symlink on the Solaris
systems. Its expected to not exist. What's funny is that this has been
working without incident for a little over a year.
On Mon, Apr 22, 2013 at 4:40 PM, Lamont Granquist lamont@opscode.com wrote:
Can you apply the template resource to the target of the symlink and manage
the symlink with a link resource?
On 4/22/13 4:34 PM, Jason J. W. Williams wrote:
It is a symlink and the symlink gets preserved.
On Mon, Apr 22, 2013 at 4:29 PM, Lamont Granquist lamont@opscode.com
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 jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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
jasonjwwilliams@gmail.com
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 aj@junglist.gen.nz
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
jasonjwwilliams@gmail.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.
-J