On Tuesday, February 18, 2014 3:34:46 PM UTC-6, Jordan Wright wrote: > > I have some Windows systems that I need to configure a user's profile. The > user has to be logged into for the profile to be created. I came up with > the solution below but it seems kinda hacky. >
Indeed. > I assume there is a better way to get the same effect without having a > class inside a class? > It is perfectly normal for one class to *declare* another. It is poor form these days, and never necessary, to nest one class *definition* inside another. The best way to avoid the latter is to put your classes in a module and lay it out in the normal way. See http://docs.puppetlabs.com/puppet/3/reference/modules_fundamentals.html, especially the "Module Layout" section. Puppet will then automagically find the class definition corresponding to each class declaration. > Is there a way to set a stage on a class when using hiera? > Sure. The 'stage' parameter takes an ordinary string value, which hiera can provide. You can either use automatic data binding, or explicit hiera calls. The latter might look like this: class { 'autologon::autologon-internal': stage => hiera('autologon::autologon-internal::stage'), ... } I don't think that really gains you anything, though. Why would it be helpful -- or even advisable -- to set the run stage via hiera data? Also, what do you need a run stage for, anyway? Do you intend to put more classes in it later? For just the one class, you could achieve effect without stages: class autologon ($username, $password) { class {'autologon::autologon-internal': username => $username, password => $password, } reboot { 'user-creation': subscribe => Class['autologon::autologon-internal'] } ... } > I am using Windows 7 x64, Puppet Open Source 3.4.2, and Hiera 1.3.1 > > And I suppose you are running masterless, via 'puppet apply'. What you have now makes some sense for such a context, but not so much for a master/agent setup. > autologon.pp manifest > > class autologon ($username, $password) { > stage { 'user-creation': > before => Stage['main'], > } > class {'autologon-internal': > stage => user-creation, > username => $username, > password => $password, > } > reboot { 'user-creation': > subscribe => Stage['user-creation'] > } > > class autologon-internal ($username, $password) { > user { $username: > ensure => present, > groups => 'Users', > membership => inclusive, > password => $password, > } > registry_value { "HKLM\\software\\microsoft\\windows > nt\\currentversion\\winlogon\\defaultusername": > ensure => present, > type => string, > data => $username, > } > registry_value { "HKLM\\software\\microsoft\\windows > nt\\currentversion\\winlogon\\defaultdomainname": > ensure => present, > type => string, > data => $hostname, > } > registry_value { "HKLM\\software\\microsoft\\windows > nt\\currentversion\\winlogon\\defaultpassword": > ensure => present, > type => string, > data => $password, > } > registry_value { "HKLM\\software\\microsoft\\windows > nt\\currentversion\\winlogon\\autoadminlogon": > ensure => present, > type => string, > data => '1', > } > } > } > > hiera yaml file > > --- > classes: > - autologon > > autologon::username: "myusername" > autologon::password: "mypassword" > > I have serious concerns about this general strategy, though some of them may be mitigated by the context in which you plan to use it. First, autologon is mildly evil in and of itself. If you nevertheless intend to leave these systems set up with autologon enabled then ok, but if that would be an issue then you are playing with fire. If you insist on playing with fire then your approach is incomplete: it needs a way to detect whether autologon is needed, a way to proactively disable it when unneeded, and a way to force the erstwhile autologon user to be logged out once his profile is configured. Furthermore, if either now or in the future you will need to configure multiple profiles on the same machine, then your general approach is inadequate. You can only configure one autologon user at a time, so you need some way to detect which among your multiple profiles need to be created, and to set each in turn for autologon. It is probably doable, but eww. And then, too, Puppet will need to reboot the machine once for each missing profile. And you had better make sure that Puppet will never do this when the machine is in use. And no, scheduling is not in general an adequate solution to that issue. If you are running Puppet as a daemon, and you can accommodate the profile not being configured until some time (up to about Puppet's run interval) after the user first logs in, then you can avoid all the autologon and rebooting nonsense. Instead, let Puppet configure the profile only if it exists. That should be much simpler. Alternatively, if you are on a domain then you could consider using roaming profiles. Or, if you have some suitable machine under your control on which you could create a profile for the user(s), then you might be able to use the User State Migration Tool to create a copy of that profile that you can subsequently install on other machines without the user logging on. (Don't ask me for details on that last; I'm just echoing a suggestion from here: http://community.spiceworks.com/topic/247395-create-a-user-profile-without-logon ). 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/9139a0c1-b526-4786-ba0b-fd3e5313e564%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
