Screen scraping sucks
At a customer, I've migrated a number of manually-maintained servers to having them be maintained through puppet not so long ago. Since then, some more machines have been added, and getting them up and running properly was a breeze: do a base install, install puppet, sign the certificate, restart puppet, and then wait and twiddle thumbs while puppet did its magic. Easy as pie.
Now, a few months later, we needed to install a number of windows machines for a lab (not my choice), and the person involved asked me to figure out some diskspace so we could start creating images for those.
Not a chance.
Instead, I suggested looking for a configuration management system, similar to puppet. Since we're using Samba 3 to run the Windows network here, dropping everything in Active Directory was not an option. But a short while later, he came back with the note that puppet, in its 2.7 version, actually does support Windows as a platform for the managed machines.
Interesting.
The unfortunate bit was that puppet supports creating files and installing software when it is distributed as an MSI file, but not when it's distributed as a .exe file. This is not unexpected; MSI files can be installed noninteractively; but when something is distributed as a .exe file, it means it needs to be installed interactively; and puppet does not have the ability to interact with GUI software.
The workaround: use something that does have that ability (in my case, autoit), and use an exec block in puppet to make it call those scripts. In effect, that's a bit like screenscraping. Add a creates stanza to the block, so that the installer isn't started again if the software at hand has already been installed. This 'autoit' thing also comes with a recording utility, allowing one to create an initial script by just doing the installation, and having the tool just record stuff.
With that, the machines are installed 99% automated. I say 99%, because there are still some issues:
- Some software ships with an embedded google toolbar and an embedded
google chrome. Not only do we not want that, it also makes automatic
installation a Very Hard problem: if you install the software the very
first time, it asks you whether you want to install Google Toolbar. If
you decline, the rest of the installation is shown, and a registry key
is set. If you then uninstall and reinstall, the Google Toolbar question
isn't shown; instead, the Chrome question is shown. If you decline that,
then the same happens with a different registry key.
Google doesn't actually document where these keys are set, or how it can be disabled for any software that might possibly have embedded toolbars or browsers. Or, well—if it does document it, I certainly didn't find any documentation about it; the fact that google tells me "you're running Linux, you don't need Google Toolbar, go fuck yourself" when I go to the toolbar.google.com website isn't very helpful.
Anyway, the keys are under HKLM\Software\Google. You can't miss them. - This being Windows, sometimes the machine needs to be rebooted after an installation. The Windows Installer software, msiexec.exe, signals this fact by exiting with an exit state of 3010. Unfortunately, puppet doesn't understand that, causing it to mark the installation as failed, and retrying it on the next run. That's annoying.
- Sometimes, telling the machine to postpone rebooting causes the next installation to behave slightly differently, which will cause the autoit script to fail. When that happens, I need to kill autoit, exit the installer for the failed application, and allow puppet to finish. After that, and after a reboot of the machine and restart of puppet, everything works well.
- To be able to install software, Windows may sometimes need to kill some applications, or may need to take focus. This may interfere with the lab readings these machines will be used for, so is not an option. Instead, I've decided not to ever run puppet agent as a service, instead always calling it manually with the '--onetime' option, so it quits once the manifest is applied. Unfortunately, that makes it harder to update things; I'll have to walk by each and every one of the machines if I ever need to add something. I did consider adding that to a login script, but then the user logging in to the machine will most likely not ever have the required privileges to actually do what puppet needs done.
I'll have to think about this some more, I guess. First, it's clear that while puppet does have some Windows functionality, it's not entirely ready yet. And somehow, using autoit to add to Puppet functionality feels like an ugly hack.
We'll see what the future brings.
Most installers have the /silent switch in windows. Try running the /? switch on the exe installer, it usually pops up with a window with the switches that it accepts, this also works on the msiexec installers.
You can cancel most shutdown and reboots by running "shutdown /a"
I found with autoit, that its more reliable with sending keystrokes than using mouse coordinates. If the resolution is different from the recording then the clicks are off.
Lastly, pstools is a handy toolkit on windows for running processes or getting information remotely.
You can use a system like sikuli to automate any UI interaction, including switching off checkboxes to avoid installing google toolbars...
http://sikuli.org/
Perhaps worth investing?
That's not the issue; autoit can also automate switching off checkboxes. The problem is that if a question isn't shown every time, I have to introduce conditionals to check if the google toolbar question is what's shown next, so that my script doesn't wait for things that won't appear.
This is something autoit can do, but it requires work, and is silly.