Chef and LDAP Users

Douglas_Garstang · July 30, 2014, 10:39pm

All,

I have a recipe that configures LDAP, and that’s working fine. I have
another recipe that runs afterwards in the run list that tries to configure
individual users authorized_keys file etc.

Chef complains that the user doesn’t exist. However, if I log into the VM
where this happens, I can query the user and everything is fine. If I run
the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I
disabled those. Did not help. I also put a 30 second sleep in. Also did not
help.

I am wondering if this could be some sort of compile/converge issue where
chef is looking at the recipe, and checking if the users exist before it
runs. That could explain why it works a second time, but fails on the first
since LDAP hasn’t been configured yet.

Here’s the second recipe, the one that tries to perform user operations
after LDAP is configured.

include_recipe “foo-ldap”

bag = data_bag(“ssh-keys”)
for item in bag do
user = data_bag_item(‘ssh-keys’, item)
user_id = user[‘id’]
group_id = user[‘group’]

bash "foo" do
    user "#{user_id}"
    code <<-EOF
    touch /tmp/FILE
    EOF
end

directory "/home/#{user_id}" do
    action :create
    owner "#{user_id}"
    group "#{group_id}"
    recursive true
end

directory "/home/#{user_id}/.ssh" do
    action :create
    owner "#{user_id}"
    group "#{group_id}"
    recursive true
end

end

Unfortunately, I’m pretty sure that Noah Kantrowitz, who seems to have a
rather vehement dislike of me personally will probably find fault with this
question. Apologies in advance to readers of that thread if that happens.
He will probably say that I have already asked this question in the IRC
channel. I asked a similar question. He summarily dismissed me when I asked
again with added information.

Regards,
Douglas Garstang

Douglas_Garstang · July 30, 2014, 10:53pm

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However, the
very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I have
another recipe that runs afterwards in the run list that tries to configure
individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into the VM
where this happens, I can query the user and everything is fine. If I run
the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I
disabled those. Did not help. I also put a 30 second sleep in. Also did not
help.

I am wondering if this could be some sort of compile/converge issue where
chef is looking at the recipe, and checking if the users exist before it
runs. That could explain why it works a second time, but fails on the first
since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user operations
after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']
bash "foo" do
    user "#{user_id}"
    code <<-EOF
    touch /tmp/FILE
    EOF
end

directory "/home/#{user_id}" do
    action :create
    owner "#{user_id}"
    group "#{group_id}"
    recursive true
end

directory "/home/#{user_id}/.ssh" do
    action :create
    owner "#{user_id}"
    group "#{group_id}"
    recursive true
end
end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to have a
rather vehement dislike of me personally will probably find fault with this
question. Apologies in advance to readers of that thread if that happens.
He will probably say that I have already asked this question in the IRC
channel. I asked a similar question. He summarily dismissed me when I asked
again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

kallistec · July 30, 2014, 11:00pm

I don’t recall the details but I vaguely remember this being caused by some sort of caching implemented in the library that provides getpwent and such functions. One thing you can try is to call Etc.endpwent in a ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However, the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I have another recipe that runs afterwards in the run list that tries to configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into the VM where this happens, I can query the user and everything is fine. If I run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I disabled those. Did not help. I also put a 30 second sleep in. Also did not help.

I am wondering if this could be some sort of compile/converge issue where chef is looking at the recipe, and checking if the users exist before it runs. That could explain why it works a second time, but fails on the first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to have a rather vehement dislike of me personally will probably find fault with this question. Apologies in advance to readers of that thread if that happens. He will probably say that I have already asked this question in the IRC channel. I asked a similar question. He summarily dismissed me when I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

fujin · July 30, 2014, 11:03pm

I was about to reply back and suggest that Chef may be at the mercy of
the Etc module here, it is potentially cached when the process is
launched

Dan's suggestion to try closing the file may work!

I would try stracing the process and see which system calls are being
issued for the uid/gid lookup that fails, that may give us a hint as
to what part of Chef/Etc module is busted.

cheers,

--aj

On Thu, Jul 31, 2014 at 11:00 AM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by some sort of caching implemented in the library that provides getpwent and such functions. One thing you can try is to call Etc.endpwent in a ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However, the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I have another recipe that runs afterwards in the run list that tries to configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into the VM where this happens, I can query the user and everything is fine. If I run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I disabled those. Did not help. I also put a 30 second sleep in. Also did not help.

I am wondering if this could be some sort of compile/converge issue where chef is looking at the recipe, and checking if the users exist before it runs. That could explain why it works a second time, but fails on the first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to have a rather vehement dislike of me personally will probably find fault with this question. Apologies in advance to readers of that thread if that happens. He will probably say that I have already asked this question in the IRC channel. I asked a similar question. He summarily dismissed me when I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

Douglas_Garstang · July 30, 2014, 11:09pm

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by
some sort of caching implemented in the library that provides getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However, the
very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <
doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I have
another recipe that runs afterwards in the run list that tries to configure
individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into the
VM where this happens, I can query the user and everything is fine. If I
run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I
disabled those. Did not help. I also put a 30 second sleep in. Also did not
help.

I am wondering if this could be some sort of compile/converge issue
where chef is looking at the recipe, and checking if the users exist before
it runs. That could explain why it works a second time, but fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to have
a rather vehement dislike of me personally will probably find fault with
this question. Apologies in advance to readers of that thread if that
happens. He will probably say that I have already asked this question in
the IRC channel. I asked a similar question. He summarily dismissed me when
I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Douglas_Garstang · July 30, 2014, 11:21pm

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by
some sort of caching implemented in the library that provides getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <
doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I have
another recipe that runs afterwards in the run list that tries to configure
individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into
the VM where this happens, I can query the user and everything is fine. If
I run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so I
disabled those. Did not help. I also put a 30 second sleep in. Also did not
help.

I am wondering if this could be some sort of compile/converge issue
where chef is looking at the recipe, and checking if the users exist before
it runs. That could explain why it works a second time, but fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to
have a rather vehement dislike of me personally will probably find fault
with this question. Apologies in advance to readers of that thread if that
happens. He will probably say that I have already asked this question in
the IRC channel. I asked a similar question. He summarily dismissed me when
I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

adamhjk · July 30, 2014, 11:30pm

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by
some sort of caching implemented in the library that provides getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <
doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I
have another recipe that runs afterwards in the run list that tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into
the VM where this happens, I can query the user and everything is fine. If
I run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so
I disabled those. Did not help. I also put a 30 second sleep in. Also did
not help.

I am wondering if this could be some sort of compile/converge issue
where chef is looking at the recipe, and checking if the users exist before
it runs. That could explain why it works a second time, but fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to
have a rather vehement dislike of me personally will probably find fault
with this question. Apologies in advance to readers of that thread if that
happens. He will probably say that I have already asked this question in
the IRC channel. I asked a similar question. He summarily dismissed me when
I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Douglas_Garstang · July 30, 2014, 11:32pm

Someone, here:

http://lists.opscode.com/sympa/arc/chef/2012-03/msg00335.html

reported:

"I worked around this by calling getent passwd for specific users in a
ruby block or some such. It's hacky, but it worked for my particular
scenario."

Still trying to work out how to do that...

Doug.

On Wed, Jul 30, 2014 at 4:30 PM, Adam Jacob adam@getchef.com wrote:

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by
some sort of caching implemented in the library that provides getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang <
doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I
have another recipe that runs afterwards in the run list that tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into
the VM where this happens, I can query the user and everything is fine. If
I run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so
I disabled those. Did not help. I also put a 30 second sleep in. Also did
not help.

I am wondering if this could be some sort of compile/converge issue
where chef is looking at the recipe, and checking if the users exist before
it runs. That could explain why it works a second time, but fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to
have a rather vehement dislike of me personally will probably find fault
with this question. Apologies in advance to readers of that thread if that
happens. He will probably say that I have already asked this question in
the IRC channel. I asked a similar question. He summarily dismissed me when
I asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

fujin · July 30, 2014, 11:35pm

I believe they're probably referring to shelling out and gathering the
output (at convergence time) of getent, which creates a new process,
thus the glibc 'restart yer daemons' issue is worked around.

You can use Chef's built in shell out helpers or maybe make a user
(L|H)WRP that shells out to getent instead of using the Etc module!

--aj

On Thu, Jul 31, 2014 at 11:32 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

Someone, here:

chef - [chef] Re: RE: Re: RE: Help..(NOT Fixed!) ohai doesn't reflect ldap users after ldap config in first chef run

reported:

"I worked around this by calling getent passwd for specific users in a
ruby block or some such. It's hacky, but it worked for my particular
scenario."

Still trying to work out how to do that...

Doug.

On Wed, Jul 30, 2014 at 4:30 PM, Adam Jacob adam@getchef.com wrote:

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com wrote:

I don’t recall the details but I vaguely remember this being caused by
some sort of caching implemented in the library that provides getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional. However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang
<doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I
have another recipe that runs afterwards in the run list that tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log into
the VM where this happens, I can query the user and everything is fine. If I
run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue so
I disabled those. Did not help. I also put a 30 second sleep in. Also did
not help.

I am wondering if this could be some sort of compile/converge issue
where chef is looking at the recipe, and checking if the users exist before
it runs. That could explain why it works a second time, but fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to
have a rather vehement dislike of me personally will probably find fault
with this question. Apologies in advance to readers of that thread if that
happens. He will probably say that I have already asked this question in the
IRC channel. I asked a similar question. He summarily dismissed me when I
asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Douglas_Garstang · July 30, 2014, 11:42pm

AJ,

Do you mean the act of shelling out and querying the user is forcing stuff
to be flushed, or do you think they are shelling out to execute the
commands that operate on the user? Ie, shelling out to mkdir
/home/doug/.ssh and so on....?

Doug.

On Wed, Jul 30, 2014 at 4:35 PM, AJ Christensen aj@junglist.io wrote:

I believe they're probably referring to shelling out and gathering the
output (at convergence time) of getent, which creates a new process,
thus the glibc 'restart yer daemons' issue is worked around.

You can use Chef's built in shell out helpers or maybe make a user
(L|H)WRP that shells out to getent instead of using the Etc module!

--aj

On Thu, Jul 31, 2014 at 11:32 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

Someone, here:

chef - [chef] Re: RE: Re: RE: Help..(NOT Fixed!) ohai doesn't reflect ldap users after ldap config in first chef run

reported:

"I worked around this by calling getent passwd for specific users in a
ruby block or some such. It's hacky, but it worked for my particular
scenario."

Still trying to work out how to do that...

Doug.

On Wed, Jul 30, 2014 at 4:30 PM, Adam Jacob adam@getchef.com wrote:

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com
wrote:

I don’t recall the details but I vaguely remember this being caused
by
some sort of caching implemented in the library that provides
getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional.
However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang
<doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I
have another recipe that runs afterwards in the run list that
tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log
into
the VM where this happens, I can query the user and everything
is fine. If I
run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue
so
I disabled those. Did not help. I also put a 30 second sleep in.
Also did
not help.

I am wondering if this could be some sort of compile/converge
issue
where chef is looking at the recipe, and checking if the users
exist before
it runs. That could explain why it works a second time, but
fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems to
have a rather vehement dislike of me personally will probably
find fault
with this question. Apologies in advance to readers of that
thread if that
happens. He will probably say that I have already asked this
question in the
IRC channel. I asked a similar question. He summarily dismissed
me when I
asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

fujin · July 30, 2014, 11:52pm

Shell out to getent, grab the output. The shell out (from Chef,
launching a new process) means that the new process that is launched
will have access to the LDAP information.

It's a timing issue. Because Chef is launched before the ldap update
goes out, it can't see it. If you launch a process from the (blind)
Chef process, that new process will have the LDAP information
available to it.

If you gather the output from it at the correct time (convergence
phase after the LDAP change rolls out), you will be able to use it in
subsequent resource updates, although passing the data itself around
is a little messy.

Gross!

--aj

On Thu, Jul 31, 2014 at 11:42 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

AJ,

Do you mean the act of shelling out and querying the user is forcing stuff
to be flushed, or do you think they are shelling out to execute the commands
that operate on the user? Ie, shelling out to mkdir /home/doug/.ssh and so
on....?

Doug.

On Wed, Jul 30, 2014 at 4:35 PM, AJ Christensen aj@junglist.io wrote:

I believe they're probably referring to shelling out and gathering the
output (at convergence time) of getent, which creates a new process,
thus the glibc 'restart yer daemons' issue is worked around.

You can use Chef's built in shell out helpers or maybe make a user
(L|H)WRP that shells out to getent instead of using the Etc module!

--aj

On Thu, Jul 31, 2014 at 11:32 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

Someone, here:

chef - [chef] Re: RE: Re: RE: Help..(NOT Fixed!) ohai doesn't reflect ldap users after ldap config in first chef run

reported:

"I worked around this by calling getent passwd for specific users in a
ruby block or some such. It's hacky, but it worked for my particular
scenario."

Still trying to work out how to do that...

Doug.

On Wed, Jul 30, 2014 at 4:30 PM, Adam Jacob adam@getchef.com wrote:

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com
wrote:

I don’t recall the details but I vaguely remember this being caused
by
some sort of caching implemented in the library that provides
getpwent and
such functions. One thing you can try is to call Etc.endpwent in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional.
However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang
<doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)> wrote:

All,

I have a recipe that configures LDAP, and that's working fine. I
have another recipe that runs afterwards in the run list that
tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log
into
the VM where this happens, I can query the user and everything
is fine. If I
run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching issue
so
I disabled those. Did not help. I also put a 30 second sleep in.
Also did
not help.

I am wondering if this could be some sort of compile/converge
issue
where chef is looking at the recipe, and checking if the users
exist before
it runs. That could explain why it works a second time, but
fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems
to
have a rather vehement dislike of me personally will probably
find fault
with this question. Apologies in advance to readers of that
thread if that
happens. He will probably say that I have already asked this
question in the
IRC channel. I asked a similar question. He summarily dismissed
me when I
asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Douglas_Garstang · July 31, 2014, 12:00am

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess because
that forks a new process too. It would be nice though to call getent in
some fashion, and the parse the output, so that I could be sure that the
group id I am assigning is the correct one for the user. At the moment it's
coming out of a data bag.

Also kinda gross.

Doug

On Wed, Jul 30, 2014 at 4:52 PM, AJ Christensen aj@junglist.io wrote:

Shell out to getent, grab the output. The shell out (from Chef,
launching a new process) means that the new process that is launched
will have access to the LDAP information.

It's a timing issue. Because Chef is launched before the ldap update
goes out, it can't see it. If you launch a process from the (blind)
Chef process, that new process will have the LDAP information
available to it.

If you gather the output from it at the correct time (convergence
phase after the LDAP change rolls out), you will be able to use it in
subsequent resource updates, although passing the data itself around
is a little messy.

Gross!

--aj

On Thu, Jul 31, 2014 at 11:42 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

AJ,

Do you mean the act of shelling out and querying the user is forcing
stuff
to be flushed, or do you think they are shelling out to execute the
commands
that operate on the user? Ie, shelling out to mkdir /home/doug/.ssh and
so
on....?

Doug.

On Wed, Jul 30, 2014 at 4:35 PM, AJ Christensen aj@junglist.io wrote:

I believe they're probably referring to shelling out and gathering the
output (at convergence time) of getent, which creates a new process,
thus the glibc 'restart yer daemons' issue is worked around.

You can use Chef's built in shell out helpers or maybe make a user
(L|H)WRP that shells out to getent instead of using the Etc module!

--aj

On Thu, Jul 31, 2014 at 11:32 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

Someone, here:

chef - [chef] Re: RE: Re: RE: Help..(NOT Fixed!) ohai doesn't reflect ldap users after ldap config in first chef run

reported:

"I worked around this by calling getent passwd for specific users
in a
ruby block or some such. It's hacky, but it worked for my particular
scenario."

Still trying to work out how to do that...

Doug.

On Wed, Jul 30, 2014 at 4:30 PM, Adam Jacob adam@getchef.com wrote:

Yeah - it's beyond our capability to fix. Gotta restart your daemons.

Adam

On Wed, Jul 30, 2014 at 4:21 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Looks like this is the cause...

https://tickets.opscode.com/browse/CHEF-3780

Doug.

On Wed, Jul 30, 2014 at 4:09 PM, Douglas Garstang
doug.garstang@gmail.com wrote:

Daniel,

Thanks for the tip. Don't think it worked though, with:

rest of LDAP recipe above

ruby_block "close the passwd file in Ruby" do
block do
Etc.endpwent
end
end

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

Still fails below.

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

Doug

On Wed, Jul 30, 2014 at 4:00 PM, Daniel DeLeo dan@kallistec.com
wrote:

I don’t recall the details but I vaguely remember this being
caused
by
some sort of caching implemented in the library that provides
getpwent and
such functions. One thing you can try is to call Etc.endpwent
in a
ruby_block to make sure Chef closes and reopens the password file.

--
Daniel DeLeo

On Wednesday, July 30, 2014 at 3:53 PM, Douglas Garstang wrote:

Replying to myself.

Actually, if I put this, at the very end of the LDAP recipe...

bash "foo1" do
user "root"
code <<-EOF
getent passwd doug > /tmp/foo1
EOF
end

bash "foo" do
user "doug"
code <<-EOF
touch /tmp/FILE
EOF
end

The contents of the file /tmp/foo1 have:

[root@ldap-centos64 tmp]# cat foo1
doug:x:1097:2299:Doug Garstang ops team:/home/doug:/bin/bash

which would tend to indicate to me that LDAP is functional.
However,
the very next bash block fails. Chef reports:

"can't find user for doug"

So, the user seems to exist for the system, but not for chef.

Thanks,
Doug.

On Wed, Jul 30, 2014 at 3:39 PM, Douglas Garstang
<doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)>
wrote:

All,

I have a recipe that configures LDAP, and that's working
fine. I
have another recipe that runs afterwards in the run list that
tries to
configure individual users authorized_keys file etc.

Chef complains that the user doesn't exist. However, if I log
into
the VM where this happens, I can query the user and everything
is fine. If I
run the chef client again, the error does not happen.

I initially thought it might have been a sssd/nscd caching
issue
so
I disabled those. Did not help. I also put a 30 second sleep
in.
Also did
not help.

I am wondering if this could be some sort of compile/converge
issue
where chef is looking at the recipe, and checking if the users
exist before
it runs. That could explain why it works a second time, but
fails on the
first since LDAP hasn't been configured yet.

Here's the second recipe, the one that tries to perform user
operations after LDAP is configured.

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_id = user['id']
group_id = user['group']

bash "foo" do
user "#{user_id}"
code <<-EOF
touch /tmp/FILE
EOF
end

directory "/home/#{user_id}" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

directory "/home/#{user_id}/.ssh" do
action :create
owner "#{user_id}"
group "#{group_id}"
recursive true
end

end

Unfortunately, I'm pretty sure that Noah Kantrowitz, who seems
to
have a rather vehement dislike of me personally will probably
find fault
with this question. Apologies in advance to readers of that
thread if that
happens. He will probably say that I have already asked this
question in the
IRC channel. I asked a similar question. He summarily
dismissed
me when I
asked again with added information.

Regards,
Douglas Garstang

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

kallistec · July 31, 2014, 12:03am

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess because that forks a new process too. It would be nice though to call getent in some fashion, and the parse the output, so that I could be sure that the group id I am assigning is the correct one for the user. At the moment it's coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy attribute Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to run a command that returns the UID.

--
Daniel DeLeo

fujin · July 31, 2014, 12:22am

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:

gist.github.com

https://gist.github.com/fujin/f0b7dd38b558001c5913

example

chef > ShellGetent.passwd 'aj'
aj:x:1337:1337::/home/aj:/usr/bin/zsh
 => ["aj", "x", "1337", "1337", "", "/home/aj", "/usr/bin/zsh\n"]

library.rb

class ShellGetent
  include Chef::Mixin::ShellOut

  class << self
    def passwd(username)
      return if username.nil? || username.empty?
      new.getent(:passwd, username)
    end
  end

This file has been truncated. show original

recipe.rb

directory '/foobar' do
  user lazy {  ShellGetent.passwd 'aj' }
end

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess because that forks a new process too. It would be nice though to call getent in some fashion, and the parse the output, so that I could be sure that the group id I am assigning is the correct one for the user. At the moment it's coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy attribute Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to run a command that returns the UID.

--
Daniel DeLeo

fujin · July 31, 2014, 12:25am

I meant to link to this too re: Mixlib ShellOut:

github.com

chef/chef/blob/main/lib/chef/mixin/shell_out.rb#L29-L39


      
          #--
          # Author:: Daniel DeLeo (<dan@chef.io>)
          # Copyright:: Copyright (c) Chef Software Inc.
          # License:: Apache License, Version 2.0
          #
          # Licensed under the Apache License, Version 2.0 (the "License");
          # you may not use this file except in compliance with the License.
          # You may obtain a copy of the License at
          #
          #     http://www.apache.org/licenses/LICENSE-2.0
          #
          # Unless required by applicable law or agreed to in writing, software
          # distributed under the License is distributed on an "AS IS" BASIS,
          # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
          # See the License for the specific language governing permissions and
          # limitations under the License.
          
          require "mixlib/shellout/helper" unless defined?(Mixlib::ShellOut::Helper)
          require_relative "chef_utils_wiring" unless defined?(Chef::Mixin::ChefUtilsWiring)

This file has been truncated. show original

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess because that forks a new process too. It would be nice though to call getent in some fashion, and the parse the output, so that I could be sure that the group id I am assigning is the correct one for the user. At the moment it's coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy attribute Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to run a command that returns the UID.

--
Daniel DeLeo

Douglas_Garstang · July 31, 2014, 5:59pm

AJ,

Thanks. I'm really not a ruby guy. It will take me considerable time to
work out your gist. I tried this. I thought the call to Mixlib::ShellOut
would fork a new process and therefore get me the correct result. However,
cmd.stdout is empty on the first run, and contains the correct getent
passwd reply on the second run, so I assume it's the same issue...

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do

user = data_bag_item('ssh-keys', item)
user_name = user['id']

execute "create_homedir" do
    command "mkdir /home/#{user_name}"
    creates "/home/#{user_name}"
    action :run
end

log "USER_NAME = #{user_name}"
cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
cmd.run_command
log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
ent_array = cmd.stdout.split(':')
user_id = ent_array[2]
group_id = ent_array[3]

execute "homedir_perms" do
    command "chown #{user_id}.#{group_id} /home/#{user_name}"
    action :run
end

end

On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen aj@junglist.io wrote:

I meant to link to this too re: Mixlib ShellOut:

https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com
wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess
because that forks a new process too. It would be nice though to call
getent in some fashion, and the parse the output, so that I could be sure
that the group id I am assigning is the correct one for the user. At the
moment it's coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy
attribute
Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to
run a command that returns the UID.

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

fujin · July 31, 2014, 6:10pm

You ignored all of my examples and ran the code at Shell Out code at
compile time. It will be executed before the other LDAP stuff is
actually converged.

Don't be such a support vampire bro.

--AJ

On Fri, Aug 1, 2014 at 5:59 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

AJ,

Thanks. I'm really not a ruby guy. It will take me considerable time to work
out your gist. I tried this. I thought the call to Mixlib::ShellOut would
fork a new process and therefore get me the correct result. However,
cmd.stdout is empty on the first run, and contains the correct getent passwd
reply on the second run, so I assume it's the same issue...

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_name = user['id']

execute "create_homedir" do
    command "mkdir /home/#{user_name}"
    creates "/home/#{user_name}"
    action :run
end

log "USER_NAME = #{user_name}"
cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
cmd.run_command
log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
ent_array = cmd.stdout.split(':')
user_id = ent_array[2]
group_id = ent_array[3]

execute "homedir_perms" do
    command "chown #{user_id}.#{group_id} /home/#{user_name}"
    action :run
end
end

On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen aj@junglist.io wrote:

I meant to link to this too re: Mixlib ShellOut:

https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com
wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess
because that forks a new process too. It would be nice though to call getent
in some fashion, and the parse the output, so that I could be sure that the
group id I am assigning is the correct one for the user. At the moment it's
coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy
attribute
Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to
run a command that returns the UID.

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

fujin · July 31, 2014, 6:12pm

Compile the resource collection

The chef-client identifies each resource in the node object and builds
the resource collection. All libraries are loaded (to ensure that all
language extensions and Ruby classes are available). And then all
attributes are loaded. And then all lightweight resources are loaded.
And then all definitions are loaded (to ensure that any
pseudo-resources are available). Finally, all recipes are loaded in
the order specified by the expanded run-list; each action specified in
each recipe is identified before any Ruby code within a recipe is
evaluated.

Converge the node

The chef-client configures the system based on the information that
has been collected. Each resource is executed in the order identified
by the run-list, and then by the order in which each resource is
listed in each recipe. Each resource in the resource collection is
mapped to a provider. The provider examines the node, and then does
the steps necessary to complete the action. And then the next resource
is processed. Each action configures a specific part of the system.
This process is also referred to as convergence.

Run the ShellOut code during convergence after the LDAP code has
converged (instead of at compile time as your example inaccurately
attempts to represent mine)

YMMV

--aj

On Fri, Aug 1, 2014 at 6:10 AM, AJ Christensen aj@junglist.io wrote:

You ignored all of my examples and ran the code at Shell Out code at
compile time. It will be executed before the other LDAP stuff is
actually converged.

Don't be such a support vampire bro.

--AJ

On Fri, Aug 1, 2014 at 5:59 AM, Douglas Garstang
doug.garstang@gmail.com wrote:
AJ,

Thanks. I'm really not a ruby guy. It will take me considerable time to work
out your gist. I tried this. I thought the call to Mixlib::ShellOut would
fork a new process and therefore get me the correct result. However,
cmd.stdout is empty on the first run, and contains the correct getent passwd
reply on the second run, so I assume it's the same issue...

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_name = user['id']

execute "create_homedir" do
    command "mkdir /home/#{user_name}"
    creates "/home/#{user_name}"
    action :run
end

log "USER_NAME = #{user_name}"
cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
cmd.run_command
log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
ent_array = cmd.stdout.split(':')
user_id = ent_array[2]
group_id = ent_array[3]

execute "homedir_perms" do
    command "chown #{user_id}.#{group_id} /home/#{user_name}"
    action :run
end
end

On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen aj@junglist.io wrote:

I meant to link to this too re: Mixlib ShellOut:

https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com
wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess
because that forks a new process too. It would be nice though to call getent
in some fashion, and the parse the output, so that I could be sure that the
group id I am assigning is the correct one for the user. At the moment it's
coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy
attribute
Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to
run a command that returns the UID.

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Douglas_Garstang · July 31, 2014, 6:12pm

AJ,

That's because I don't understand your example. I thought I'd try something
simple I could understand first. I would really benefit from some
documentation clearly describing the difference between compile and
converge, which also provides use cases with examples. I think a lot of
people could benefit from that.

Douglas.

On Thu, Jul 31, 2014 at 11:10 AM, AJ Christensen aj@junglist.io wrote:

You ignored all of my examples and ran the code at Shell Out code at
compile time. It will be executed before the other LDAP stuff is
actually converged.

Don't be such a support vampire bro.

--AJ

On Fri, Aug 1, 2014 at 5:59 AM, Douglas Garstang
doug.garstang@gmail.com wrote:
AJ,

Thanks. I'm really not a ruby guy. It will take me considerable time to
work
out your gist. I tried this. I thought the call to Mixlib::ShellOut would
fork a new process and therefore get me the correct result. However,
cmd.stdout is empty on the first run, and contains the correct getent
passwd
reply on the second run, so I assume it's the same issue...

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_name = user['id']

execute "create_homedir" do
    command "mkdir /home/#{user_name}"
    creates "/home/#{user_name}"
    action :run
end

log "USER_NAME = #{user_name}"
cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
cmd.run_command
log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
ent_array = cmd.stdout.split(':')
user_id = ent_array[2]
group_id = ent_array[3]

execute "homedir_perms" do
    command "chown #{user_id}.#{group_id} /home/#{user_name}"
    action :run
end
end

On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen aj@junglist.io wrote:

I meant to link to this too re: Mixlib ShellOut:
https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io
wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com
wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess
because that forks a new process too. It would be nice though to
call getent
in some fashion, and the parse the output, so that I could be sure
that the
group id I am assigning is the correct one for the user. At the
moment it's
coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy
attribute

Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to
run a command that returns the UID.

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

fujin · July 31, 2014, 6:13pm

See previous post.

--aj

On Fri, Aug 1, 2014 at 6:12 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

AJ,

That's because I don't understand your example. I thought I'd try something
simple I could understand first. I would really benefit from some
documentation clearly describing the difference between compile and
converge, which also provides use cases with examples. I think a lot of
people could benefit from that.

Douglas.

On Thu, Jul 31, 2014 at 11:10 AM, AJ Christensen aj@junglist.io wrote:
You ignored all of my examples and ran the code at Shell Out code at
compile time. It will be executed before the other LDAP stuff is
actually converged.

Don't be such a support vampire bro.

--AJ

On Fri, Aug 1, 2014 at 5:59 AM, Douglas Garstang
doug.garstang@gmail.com wrote:
AJ,

Thanks. I'm really not a ruby guy. It will take me considerable time to
work
out your gist. I tried this. I thought the call to Mixlib::ShellOut
would
fork a new process and therefore get me the correct result. However,
cmd.stdout is empty on the first run, and contains the correct getent
passwd
reply on the second run, so I assume it's the same issue...

include_recipe "foo-ldap"

bag = data_bag("ssh-keys")
for item in bag do
user = data_bag_item('ssh-keys', item)
user_name = user['id']

execute "create_homedir" do
    command "mkdir /home/#{user_name}"
    creates "/home/#{user_name}"
    action :run
end

log "USER_NAME = #{user_name}"
cmd = Mixlib::ShellOut.new("getent passwd #{user_name}")
cmd.run_command
log ">>>>>>>>>>>>>>>>>>>>>>>>>>> NODE_DATA  = #{cmd.stdout}"
ent_array = cmd.stdout.split(':')
user_id = ent_array[2]
group_id = ent_array[3]

execute "homedir_perms" do
    command "chown #{user_id}.#{group_id} /home/#{user_name}"
    action :run
end
end

On Wed, Jul 30, 2014 at 5:25 PM, AJ Christensen aj@junglist.io wrote:

I meant to link to this too re: Mixlib ShellOut:

https://github.com/opscode/chef/blob/master/lib/chef/mixin/shell_out.rb#L29-L39

'git grep shell_out' in the Chef codebase, haha! You'll see all of the
places this is used.

--aj

On Thu, Jul 31, 2014 at 12:22 PM, AJ Christensen aj@junglist.io
wrote:

If you 'include Chef::Mixin::ShellOut' in a custom library, you can
use #shell_out! there.

using the lazy attribute evaluator and the Mixin ShellOut classes'
shell_out!() functionality, something like this outta' work:
example · GitHub

--aj

On Thu, Jul 31, 2014 at 12:03 PM, Daniel DeLeo dan@kallistec.com
wrote:

On Wednesday, July 30, 2014 at 5:00 PM, Douglas Garstang wrote:

AJ,

Thanks. One more question... shelling out in chef and grabbing the
output... has never been an easy task... best approach?

I was able to do this just now with the execute resource, I guess
because that forks a new process too. It would be nice though to
call getent
in some fashion, and the parse the output, so that I could be sure
that the
group id I am assigning is the correct one for the user. At the
moment it's
coming out of a data bag.

Also kinda gross.

Doug
Well, it’ll be a little gross, but I think you’ll have to use a lazy
attribute

Common Resource Functionality

In the code block you give to lazy, you can use backticks or %x to
run a command that returns the UID.

--
Daniel DeLeo

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Topic		Replies	Views
LDAP user not available after SSSD setup on RHEL Chef Infra (archive)	5	485	August 19, 2015
RE: Help..(NOT Fixed!) ohai doesn't reflect ldap users after ldap config in first chef run Chef Infra (archive)	2	261	March 22, 2012
Ldap users (after ldap config) in chef run Chef Infra (archive)	0	211	March 21, 2012
Chef-server LDAP integration issues Chef Infra (archive)	1	418	June 21, 2018
RE: (NOT Fixed!) ldap users (after ldap config) in chef run Chef Infra (archive)	0	228	March 21, 2012

Chef and LDAP Users

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

rest of LDAP recipe above

Still fails below.

Related Topics