Chef and LDAP Users


#1

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


#2

Replying to myself. :slight_smile:

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


#3

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. :slight_smile:

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


#4

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 :frowning:

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. :slight_smile:

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


#5

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. :slight_smile:

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


#6

Looks like this is the cause…

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

:frowning:

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. :slight_smile:

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


#7

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

:frowning:

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. :slight_smile:

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


#8

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

:frowning:

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. :slight_smile:

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


#9

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:

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

:frowning:

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. :slight_smile:

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


#10

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:

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

:frowning:

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. :slight_smile:

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


#11

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:

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

:frowning:

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. :slight_smile:

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


#12

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:

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

:frowning:

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. :slight_smile:

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


#13

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 http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


Daniel DeLeo


#14

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:

–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 http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


Daniel DeLeo


#15

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

‘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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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 http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


Daniel DeLeo


#16

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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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
http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


#17

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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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
http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


#18

http://docs.getchef.com/essentials_nodes_chef_run.html

  • 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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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
http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


#19

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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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

http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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


#20

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:
https://gist.github.com/fujin/f0b7dd38b558001c5913

–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

http://docs.getchef.com/resource_common.html#lazy-attribute-evaluation

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