[chef] Re: RE: Re: RE: Re: RE: ohai, number ldap accounts

[AJ Christensen < >]

Yo,

I would suggest managing your systems into the required state instead
of relying on the state of a centralized user directory, that is to
say: do not store the users required for convergence in LDAP -- unless
you are inserting them into LDAP with Chef, too. Even then I would
suggest redoubling your familiarity with LDAP, libnss-ldap and the
LDAP related PAM modifications.

I'm mostly confident others have managed libnss-ldap at high scale
without problems. I choose a more pragmatic approach these days
(system users & operators via databags), with state clearly defined
within the management bounds of Chef.

With more than 1,000 users I can see databags getting out of hand, and
perhaps another tool (or knife plugin) to be created for managing
those data bag files. It would be trivial to emit data-bag
configurations for users based on a template similar to the 'adduser'
functionality, even from a web service. Even from a web service
talking to LDAP, or a combination of back ends across multiple legacy
platforms.

On 30 March 2012 05:52, Van Fossan,Randy 
<
 >
 wrote:
> Since I have disabled the password plugin in Ohai, my nagios recipe now 
> fails as the owner and group on a remote_directory resource is from ldap.

I thought I had read 2+ posts back that the ohai 'passwd' plugin has
*nothing* to do with remote_directory (or directory, or file),
providers -- they use the Etc ruby module to getent, getgrent,
getpwent, etc. That is my recollection of the code as well. To be
sure, check it yourself.

I hope this helps your drawing board a little.

--AJ

>
> Back to the drawing board!  :(
>
>  Randy
>
> -----Original Message-----
> From: Andrea Campi 
> [mailto:
 
> Sent: Thursday, March 29, 2012 3:20 AM
> To: 
> 
 
> Cc: 
> 
 ;
>  
> 
 ;
>  
> 
 
> Subject: [chef] Re: RE: Re: RE: ohai, number ldap accounts
>
> On Wed, Mar 28, 2012 at 6:52 PM, Van Fossan,Randy 
> <
 >
>  wrote:
>> That is good news.   I need to incorporate that in the chef-client 
>> cookbook so that when the node is bootstrapped, it doesn't pull the data 
>> in after the first run.   Anyone, Know how I can incorporate the plugin 
>> disable when doing a bootstrap?   I do not want to delete the plugin as 
>> there may be reason to use it in the future or on a particular node.
>
> I see you're making progress incorporating this into the chef-client 
> cookbook, that's good.
> However both you and Ian were also asking about bootstrap, and I didn't see 
> a reply about that.
>
> knife bootstrap uses a distro-specific template file that you can specify 
> with -d DISTRO.
> Those files live inside the chef gem, in the lib/chef/knife/bootstrap 
> directory. You can also look at them on GH [1].
>
> To start customizing them, just copy them to your chef-repo:
> ${CHEF_REPO}/.chef/bootstrap/
>
> You will find something like this:
>
> (
> cat <<'EOP'
> <%= config_content %>
> EOP
> ) > /etc/chef/client.rb
>
>
> Changing that to:
>
> (
> cat <<'EOP'
> <%= config_content %>
>
> Ohai::Config[:disabled_plugins] = [ "passwd" ] EOP
> ) > /etc/chef/client.rb
>
> should be what you need.
>
>
> Then of course if you use the chef-client, you will still need to make sure 
> it does the right thing. But this will take care of the first run.
>
> Hope this helps.
> Andrea
>
>
> 1: https://github.com/opscode/chef/tree/master/chef/lib/chef/knife/bootstrap
>