Ohai loads user accounts from LDAP directory

For now, the fix in OHAI-166 is the fastest road here. Add:

Ohai::Config[:disabled_plugins] = [ "passwd" ]

To your chef client configuration, and you'll skip this plugin entirely.

Couple users discussing this on irc - have to agree it might make sense to disable it by default as it could pull down a lot of data.

The local login data is very useful to collect. Maybe we just need (an user definable) uid/gid limit above which it will not collect any more login data. The default limit could be as low as 1000.

And (on linux atleast) it could obey values defined in /etc/logins.def

+1 to disabling the passwd plugin by default. It's enough data to knock over solr/indexer on my systems where :disabled_plugins = passwd is missing.

this recently arose in a customer help ticket...
http://help.opscode.com/discussions/problems/624-chef-client-fatal-encodingundefinedconversionerror-xe2-from-ascii-8bit-to-utf-8

I wrote a plugin that reads only the local passwd and group file. So this will solve the problem of sending 1000 user accounts to chef server when using ldap.

However it will not fix the problem with strange characters/encodings.

https://github.com/oscarschneider/ohai_local_passwd

As the utf8 bug is already fixed in OHAI-275 we should go ahead with Oscar Schneider's suggestion.

I've come up with https://github.com/toomasp/ohai/tree/OHAI-165 - which basically detects if there are any /etc/passwd & /etc/group files, if so - reads them and ONLY them, otherwise falls back to the old way of querying Etc.

I suggest that one solution can be get only users that have been logged in the client sometime....maybe mixed getent with /home directory... I don't know how, but I think that important data be these, the logged users sometime, local users and ldap users

+1000

Toomas' code looks sane to me.

Really dislike this "hostile" default behavior of the passwd plugin.

The original code from 2010 OHAI-151 was never intended to enumerate everything defined in NSS passwd + group. Since the "Etc" module dates back to before Ruby 1.8.7, I have to believe the code was never tested in an environment with anything other than local passwd + group files as NSS sources. It doesn't help that the Ruby "Etc" module's documentation is COMPLETELY INACCURATE about what the module does.

It would be really great to get this merged. A lot of people have this plugin disabled because they don't want 500 accounts getting saved to every node.

https://github.com/toomasp/ohai/compare/OHAI-165

Looking at Toomas Pelberg's branch, I'm concerned that it effectively requires you to remove /etc/passwd and /etc/shadow if you want to use NSS. Etc.getpwent just returns nil on my Windows 7 VM, so if /etc/passwd is going to exist everywhere else it seems to me that we're in fact switching from using NSS to reading /etc/passwd ourselves but not being 100% clear that is what is happening because we're leaving the old code.

If there's no use for the Etc code, it should go away, but I would be surprised if there aren't some people out there who want their authentication data to come via NSS, be it LDAP based or something else. Maybe a config setting, maybe separate plugins, not sure.

You're right. I did not notice that before (sad to say as it's pretty obvious). As you state, it says "If /etc/passwd and /etc/group exist, use them otherwise use NSS (via Etc which calls get*ent())."

I've never seen anyone in ~19 years remove /etc/passwd and /etc/group when a non-files NSS source is configured, so IMO, the logic is flawed in the patch (though I'd be happy with it )

I agree that people are very likely to want to be able to get at the non-file NSS sources.

I've no opinion on config settings vs. separate plugins as a solution, but do think that the default should be to not enumerate all of NSS.