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

[Yvonne Lam < >]

Hi Jason,

Sure, here's a gist:  https://gist.github.com/2476162

Because I'm using a data bag for authorized keys, this happens to be a case where it's natural to have the username in ldap and in chef.  Depending on how you want to manage system users with respect to ldap, your mileage may vary. 

Relevant to the thread as a whole, but not necessarily to your question:  A colleague who has dealt with this particular issue quite a bit believes that the behavior of ohai with respect to ldap bootstrap is a *nix-ism, in that if it were to do otherwise, it would break rules about what one can and cannot change in a running process, i.e. going from getting user data from files on local disk to getting it from a service that requires different libraries and shared objects and so forth requires starting a new process.  I'm mentioning this because if this is indeed true (sounds plausible, haven't looked into it, happy to be proven wrong), then we all probably need to get used to double bootstrap or starting new processes in shell/ruby blocks or having chef create users in ldap... 

Yvonne

On Mon, Apr 23, 2012 at 4:54 PM, Jason J. W. Williams < " target="_blank"> > wrote:

Hi Yvonne,

On Fri, Mar 23, 2012 at 9:45 AM, Yvonne Lam < "> > wrote:
> 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.

Do you have an example block that works? We've had this issue for
awhile and have been living with it by double bootstrapping systems,
but it's a show stopper when using Vagrant.

-J