I believe it is actually the lograte script that is causing the
problem - I think it may be something you need to edit in
/etc/logrotate.d/chef-solr but I don't have access to the config at
the moment. For a long time I just ran a cron script that enforced the
correct permissions and bounced the solr server when necessary
Heyas,
I ran into the same problem, it looks like it's the
"chef-client::config" recipe that's doing it... I haven't
figured out why it would do that ...
found this:
%w{run_path cache_path backup_path log_dir}.each do |key|
directory node['chef_client'][key] do
recursive true
owner "root"
group root_group
mode 0755
end
end
Found the problem (for me at least), it's because I was using the
"chef::client" recipe which is deprecated, and loads the
"chef-client::config" recipe which has the problem code in my previous
email.
Switching to "chef-client::default" in the run list appears to have
solved it for me.
I believe it is actually the lograte script that is causing the
problem - I think it may be something you need to edit in
/etc/logrotate.d/chef-solr but I don't have access to the config at
the moment. For a long time I just ran a cron script that enforced the
correct permissions and bounced the solr server when necessary
Heyas,
I ran into the same problem, it looks like it's the
"chef-client::config" recipe that's doing it... I haven't
figured out why it would do that ...
found this:
%w{run_path cache_path backup_path log_dir}.each do |key|
directory node['chef_client'][key] do
recursive true
owner "root"
group root_group
mode 0755
end
end
Found the problem (for me at least), it's because I was using the
"chef::client" recipe which is deprecated, and loads the
"chef-client::config" recipe which has the problem code in my previous
email.
Switching to "chef-client::default" in the run list appears to have
solved it for me.
I believe it is actually the lograte script that is causing the
problem - I think it may be something you need to edit in
/etc/logrotate.d/chef-solr but I don't have access to the config at
the moment. For a long time I just ran a cron script that enforced the
correct permissions and bounced the solr server when necessary
Heyas,
I ran into the same problem, it looks like it's the
"chef-client::config" recipe that's doing it... I haven't
figured out why it would do that ...
found this:
%w{run_path cache_path backup_path log_dir}.each do |key|
directory node['chef_client'][key] do
recursive true
owner "root"
group root_group
mode 0755
end
end
I believe it is actually the lograte script that is causing the
problem - I think it may be something you need to edit in
/etc/logrotate.d/chef-solr but I don't have access to the config at
the moment. For a long time I just ran a cron script that enforced the
correct permissions and bounced the solr server when necessary
Heyas,
I ran into the same problem, it looks like it's the
"chef-client::config" recipe that's doing it... I haven't
figured out why it would do that ...
found this:
%w{run_path cache_path backup_path log_dir}.each do |key|
directory node['chef_client'][key] do
recursive true
owner "root"
group root_group
mode 0755
end
end
Running Chef 0.10.8
I believe if you update to the chef-client cookbook version 1.1.5 it
should be fixed. (This also assumes that you have a recipe by the name
"chef-server" running on the server). Mine looks something like
directory node['chef_client'][key] do
recursive true
if node.recipe?("chef-server")
owner "chef"
group "chef"
else
owner "root"
group root_group
end
mode 0755
end
I've always been a bit confused on how that recipe fix would actually
behave in real life. If your chef server fails in any way, then comes
back up, and chef fails to start how is chef client going to run in order
to fix the permissions? Am I missing a step here?
I believe it is actually the lograte script that is causing the
problem - I think it may be something you need to edit in
/etc/logrotate.d/chef-solr but I don't have access to the config at
the moment. For a long time I just ran a cron script that enforced the
correct permissions and bounced the solr server when necessary
Heyas,
I ran into the same problem, it looks like it's the
"chef-client::config" recipe that's doing it... I haven't
figured out why it would do that ...
found this:
%w{run_path cache_path backup_path log_dir}.each do |key|
directory node['chef_client'][key] do
recursive true
owner "root"
group root_group
mode 0755
end
end
Running Chef 0.10.8
I believe if you update to the chef-client cookbook version 1.1.5 it
should be fixed. (This also assumes that you have a recipe by the name
"chef-server" running on the server). Mine looks something like
directory node['chef_client'][key] do
recursive true
if node.recipe?("chef-server")
owner "chef"
group "chef"
else
owner "root"
group root_group
end
mode 0755
end
I've always been a bit confused on how that recipe fix would actually
behave in real life. If your chef server fails in any way, then comes
back up, and chef fails to start how is chef client going to run in order
to fix the permissions? Am I missing a step here?
Well what I usually do is upload the new cookbook, fix the
permissions, restart the solr server, possibly reindex all the nodes
(if necessary) and manually run chef-client on the chef server.
However sometimes you can get away with not doing this if the recipes
on the chef-server do not use search (or gracefully handle failures).