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