I am having an issue with my Chef run logic. As part of the initial build
of a system, I install and configure sssd to authenticate to LDAP. That
step works. Later in the run I start to deploy files with the template
LWRP, and some of the owners are LDAP users. This is where the Chef run
fails.
I can confirm, by logging into the server directly after the first chef run
fails, that LDAP authentication is working correctly, and I can see the
user in question. If I immediately run chef-client at that point, it
finishes correctly.
Is there some reason that I need to restart the chef run after the initial
setup of sssd, or am I missing a step?
I ran into this issue before. It has to do with ohai needing to be
reloaded once LDAP has been configured. Basically ohai pulls all of the
available users, THEN you configure LDAP, so the user list in ohai is out
of date. I never could fix it in Chef10, and by the time we had migrated
to Chef11 we had simply baked the LDAP configuration into our Amazon AMI.
A workaround at the time I had come up with just so the initial chef-client
run would complete was anything that relied on ldap users I wrapped around
an if statement like:
if node["etc"]["passwd"].attribute?("username")
do stuff
end
I believe the "right" way was to do it like this:
configure ldap
....
ohai "reload_passwd" do
action :run
end
But like I said in Chef10 I couldn't get that to work and by 11 it was
obsoleted so never pursued it more.
Hope this helps.
On Wed, Aug 19, 2015 at 9:19 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
I am having an issue with my Chef run logic. As part of the initial build
of a system, I install and configure sssd to authenticate to LDAP. That
step works. Later in the run I start to deploy files with the template
LWRP, and some of the owners are LDAP users. This is where the Chef run
fails.
I can confirm, by logging into the server directly after the first chef
run fails, that LDAP authentication is working correctly, and I can see the
user in question. If I immediately run chef-client at that point, it
finishes correctly.
Is there some reason that I need to restart the chef run after the initial
setup of sssd, or am I missing a step?
Thanks for the quick response. I found some old posts about it, that
pointed me in the same direction. I am trying that now.
On Wed, Aug 19, 2015 at 9:49 AM John Rowe jdrowe@gmail.com wrote:
I ran into this issue before. It has to do with ohai needing to be
reloaded once LDAP has been configured. Basically ohai pulls all of the
available users, THEN you configure LDAP, so the user list in ohai is out
of date. I never could fix it in Chef10, and by the time we had migrated
to Chef11 we had simply baked the LDAP configuration into our Amazon AMI.
A workaround at the time I had come up with just so the initial
chef-client run would complete was anything that relied on ldap users I
wrapped around an if statement like:
if node["etc"]["passwd"].attribute?("username")
do stuff
end
I believe the "right" way was to do it like this:
configure ldap
....
ohai "reload_passwd" do
action :run
end
But like I said in Chef10 I couldn't get that to work and by 11 it was
obsoleted so never pursued it more.
Hope this helps.
On Wed, Aug 19, 2015 at 9:19 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
I am having an issue with my Chef run logic. As part of the initial
build of a system, I install and configure sssd to authenticate to LDAP.
That step works. Later in the run I start to deploy files with the
template LWRP, and some of the owners are LDAP users. This is where the
Chef run fails.
I can confirm, by logging into the server directly after the first chef
run fails, that LDAP authentication is working correctly, and I can see the
user in question. If I immediately run chef-client at that point, it
finishes correctly.
Is there some reason that I need to restart the chef run after the
initial setup of sssd, or am I missing a step?
The reload of Ohai did not fix the problem I am seeing. I do see that
there is a cookbook out there to restart chef in the middle of a run
(keenlabs/chef-restart). Does anyone have experience with that method, or
is there something else I should do? Perhaps this is a bug? I can ignore
the file creation, as it will work on the next client run. However, there
are other cookbooks that fail as well (creating mounts that are owned by an
LDAP user, for instance).
On Wed, Aug 19, 2015 at 10:01 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
Thanks for the quick response. I found some old posts about it, that
pointed me in the same direction. I am trying that now.
On Wed, Aug 19, 2015 at 9:49 AM John Rowe jdrowe@gmail.com wrote:
I ran into this issue before. It has to do with ohai needing to be
reloaded once LDAP has been configured. Basically ohai pulls all of the
available users, THEN you configure LDAP, so the user list in ohai is out
of date. I never could fix it in Chef10, and by the time we had migrated
to Chef11 we had simply baked the LDAP configuration into our Amazon AMI.
A workaround at the time I had come up with just so the initial
chef-client run would complete was anything that relied on ldap users I
wrapped around an if statement like:
if node["etc"]["passwd"].attribute?("username")
do stuff
end
I believe the "right" way was to do it like this:
configure ldap
....
ohai "reload_passwd" do
action :run
end
But like I said in Chef10 I couldn't get that to work and by 11 it was
obsoleted so never pursued it more.
Hope this helps.
On Wed, Aug 19, 2015 at 9:19 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
I am having an issue with my Chef run logic. As part of the initial
build of a system, I install and configure sssd to authenticate to LDAP.
That step works. Later in the run I start to deploy files with the
template LWRP, and some of the owners are LDAP users. This is where the
Chef run fails.
I can confirm, by logging into the server directly after the first chef
run fails, that LDAP authentication is working correctly, and I can see the
user in question. If I immediately run chef-client at that point, it
finishes correctly.
Is there some reason that I need to restart the chef run after the
initial setup of sssd, or am I missing a step?
I believe this is a longstanding issue that doesn't really have a fix.
https://tickets.opscode.com/browse/CHEF-3780
Because of limitations in the underlying C libraries, changes to
nsswitch.conf won't be available in the current chef-client run. Error
handling followed by a second run is probably what's required here.
Matt Moretti
On Wed, Aug 19, 2015 at 10:58 AM, Alan Thatcher alanwthatcher@gmail.com
wrote:
The reload of Ohai did not fix the problem I am seeing. I do see that
there is a cookbook out there to restart chef in the middle of a run
(keenlabs/chef-restart). Does anyone have experience with that method, or
is there something else I should do? Perhaps this is a bug? I can ignore
the file creation, as it will work on the next client run. However, there
are other cookbooks that fail as well (creating mounts that are owned by an
LDAP user, for instance).
On Wed, Aug 19, 2015 at 10:01 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
Thanks for the quick response. I found some old posts about it, that
pointed me in the same direction. I am trying that now.
On Wed, Aug 19, 2015 at 9:49 AM John Rowe jdrowe@gmail.com wrote:
I ran into this issue before. It has to do with ohai needing to be
reloaded once LDAP has been configured. Basically ohai pulls all of the
available users, THEN you configure LDAP, so the user list in ohai is out
of date. I never could fix it in Chef10, and by the time we had migrated
to Chef11 we had simply baked the LDAP configuration into our Amazon AMI.
A workaround at the time I had come up with just so the initial
chef-client run would complete was anything that relied on ldap users I
wrapped around an if statement like:
if node["etc"]["passwd"].attribute?("username")
do stuff
end
I believe the "right" way was to do it like this:
configure ldap
....
ohai "reload_passwd" do
action :run
end
But like I said in Chef10 I couldn't get that to work and by 11 it was
obsoleted so never pursued it more.
Hope this helps.
On Wed, Aug 19, 2015 at 9:19 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
I am having an issue with my Chef run logic. As part of the initial
build of a system, I install and configure sssd to authenticate to LDAP.
That step works. Later in the run I start to deploy files with the
template LWRP, and some of the owners are LDAP users. This is where the
Chef run fails.
I can confirm, by logging into the server directly after the first chef
run fails, that LDAP authentication is working correctly, and I can see the
user in question. If I immediately run chef-client at that point, it
finishes correctly.
Is there some reason that I need to restart the chef run after the
initial setup of sssd, or am I missing a step?
Thanks, I did find that. Since this is really only applicable to new
builds for me, I just put a reboot of the node in after the first time that
sssd is set up for now.
On Wed, Aug 19, 2015 at 1:45 PM Matthew Moretti werebus@gmail.com wrote:
I believe this is a longstanding issue that doesn't really have a fix.
https://tickets.opscode.com/browse/CHEF-3780
Because of limitations in the underlying C libraries, changes to
nsswitch.conf won't be available in the current chef-client run. Error
handling followed by a second run is probably what's required here.
Matt Moretti
On Wed, Aug 19, 2015 at 10:58 AM, Alan Thatcher alanwthatcher@gmail.com
wrote:
The reload of Ohai did not fix the problem I am seeing. I do see that
there is a cookbook out there to restart chef in the middle of a run
(keenlabs/chef-restart). Does anyone have experience with that method, or
is there something else I should do? Perhaps this is a bug? I can ignore
the file creation, as it will work on the next client run. However, there
are other cookbooks that fail as well (creating mounts that are owned by an
LDAP user, for instance).
On Wed, Aug 19, 2015 at 10:01 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
Thanks for the quick response. I found some old posts about it, that
pointed me in the same direction. I am trying that now.
On Wed, Aug 19, 2015 at 9:49 AM John Rowe jdrowe@gmail.com wrote:
I ran into this issue before. It has to do with ohai needing to be
reloaded once LDAP has been configured. Basically ohai pulls all of the
available users, THEN you configure LDAP, so the user list in ohai is out
of date. I never could fix it in Chef10, and by the time we had migrated
to Chef11 we had simply baked the LDAP configuration into our Amazon AMI.
A workaround at the time I had come up with just so the initial
chef-client run would complete was anything that relied on ldap users I
wrapped around an if statement like:
if node["etc"]["passwd"].attribute?("username")
do stuff
end
I believe the "right" way was to do it like this:
configure ldap
....
ohai "reload_passwd" do
action :run
end
But like I said in Chef10 I couldn't get that to work and by 11 it was
obsoleted so never pursued it more.
Hope this helps.
On Wed, Aug 19, 2015 at 9:19 AM Alan Thatcher alanwthatcher@gmail.com
wrote:
I am having an issue with my Chef run logic. As part of the initial
build of a system, I install and configure sssd to authenticate to LDAP.
That step works. Later in the run I start to deploy files with the
template LWRP, and some of the owners are LDAP users. This is where the
Chef run fails.
I can confirm, by logging into the server directly after the first
chef run fails, that LDAP authentication is working correctly, and I can
see the user in question. If I immediately run chef-client at that point,
it finishes correctly.
Is there some reason that I need to restart the chef run after the
initial setup of sssd, or am I missing a step?