On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote:
Hi john, This data are need for check a valid users on nodes. We are
pretending massive load accounts by ENC. The batch (json) is prepare
by external program which, in our scenario is a normal way to create
accounts. But users can create new accounts by 'hand' when they log in
because they have sudo, for those new ones we want to set disable
(nologin). Meanwhile there are a set of user admins (we are) which
should be not disable even when they are not into batch json.
They are into whitelist (admin,deploy,etc,etc) , so they should be
exclude at checkout for disable accounts. That is done by the facter.
As you can see it's non-normal scenario.
Yes. Here's what I think you're saying:
1) Your ENC is going to feed data for a large number of users to the
puppetmaster, either via a class parameter or via a global variable.
2) Your custom fact is going to report to the puppemaster some or all of
the known system users, excluding all users on the whitelist
3) Some class is going to combine the data from these sources to generate
User resources that manage the ENC-specified and discovered users to, among
other things, disable login for the users that do not appear in the first
I still don't see the point of relying on a client-side whitelist, though.
Why do you need to filter whitelisted users from the fact value on the
client side? Why can't you do it on the master instead?
Do you see any problem about solution based on run stages ?.
As I said before, run stages cannot overcome the problem of ensuring the
whitelist is up to date on the client when facter runs. Unless you can
tolerate use of an outdated file, an external client-side whitelist simply
will not work.
If you are using pluginsync (recommended) then possibly you could cook the
whitelist entries directly into the custom fact code. That's ugly, but
it's your best bet for ensuring that the custom fact uses an up-to-date
Overall, though, I think your plan runs very much against the Puppet
grain. I have been known sometimes to admonish folks that "Puppet is not a
script engine," but never before have I heard a deployment plan that tried
so hard to use it as one. If you continue this way then I don't think
you'll be satisfied with the result. It may be worthwhile to consider
other configuration management systems.
From a higher perspective, if you're fighting node admins who have
sufficient privilege to manage users then you have chosen a losing game.
If you give *me* that much access to a box then it's mine. Do not give
administrative privileges to people you do not trust.