On Wednesday, February 19, 2014 2:23:58 PM UTC-6, Jordan Wright wrote: > > > I guess I should explain my situation a bit. >
The bottom line seems to be that the systems being configured are intended to have exactly one local account in their final state, with autologon enabled on that account, and the problem is to configure the profile of that one account. In order to configure that profile via Puppet running on the target node, it is necessary for the user to be logged in. The general approach you have chosen seems fine for those particulars, though I do still think that you should consider using a domain account with a roaming profile instead of local accounts. By all means, however, do arrange your classes in modules, and do not nest them. As for run stages, these have some hidden costs related to creating unneeded and sometimes unwanted relationships between resources, and they somehow seem to have more appeal to users than I think is warranted. Nevertheless, what you want to do with them -- ensure that the intended user is configured for autologon and is, in fact, logged on -- is a pretty reasonable use. That's especially so given that your 'user-creation' stage must reboot the system if it updates anything. It is still the case that anything you can do in Puppet with run stages you can also do without, but I'm not going to quibble over whether you should or should not use them for the example you presented. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4312ade9-d218-4066-818b-00e621838f39%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
