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
< "> > 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 < "> > 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
>> < "> > 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
>>> < "> > 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 < "> > 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:
>>>>> >
>>>>> > 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
>>>>> > < "> (mailto: "> )> 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: "> (mailto: "> )
>>>>> > Cell: +1-805-340-5627
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Douglas Garstang
>>>> http://www.linkedin.com/in/garstang
>>>> Email: ">
>>>> Cell: +1-805-340-5627
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Douglas Garstang
>>> http://www.linkedin.com/in/garstang
>>> Email: ">
>>> Cell: +1-805-340-5627
>>
>>
>
>
>
> --
> Regards,
>
> Douglas Garstang
> http://www.linkedin.com/in/garstang
> Email: ">
> Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.