John I really appreciate all your effort to help me.
You are very close to my scenario (points 1 , 2 , 3)
> 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?
Ok, i'm going to re-check it.
> 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
> whitelist.
Well this way i'll have to change a facter whenever whitelist change.
The up-to-date is not critical between cycle agent (30 min) in this
case.
> 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.
Agree, i'm taking note from you and from book 'Pulling Strings with
Puppet' when say :
Caution ➡ Puppet is probably not ideal to populate large numbers of
users and groups to provide user access for nodes and applications.
Puppet is best used to populate nodes with users for running
applications and services, systems administration, and management.
> 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.
Agree too John , but i have not choice , it's an scenario created by
my employers.
Thanks you. I'm going to recheck filter whitelisted.
Best Regards,
eduardo.
On 6 jul, 15:26, jcbollinger <john.bollin...@stjude.org> wrote:
> 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
> source.
>
> 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
> whitelist.
>
> 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.
>
> John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
