Hi John, I build a custom function to filter whitelisted. I didn't realized that custom functions can call facter by lookupvar.
Thanks you for your suggestions. Best Regards, eduardo. On 6 jul, 16:34, eduardo <erodr...@gmail.com> wrote: > 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.
