Many pre-req file have moved to require TLS 1.2, to address this
downloading these files in the host system will allows this requirement
to be meet even when the guest OS being built does not yet support TLS 1.2.
* downloads dotnet and wmf from a provisioner run by the host OS
* updates dotnet to 4.5.2
* update wmf for powershell 5.1
* adjust install process for wmf to run as SYSTEM
* moves boxstarter and Ruby install into the chocolatey_installs path
Furhter work should be done to validate the downlaod hash and support caching downloads
instead of force each build to download again.
This does not remove the need for downloads by chocolatey when preforming those installs.
The many services that rely on java need to have better limits.
By installing a specific compatible java version early the build
can eliminate churn and provide more consistent enviornments.
The install is failing as the .zip download was not working. Updated link to elaticsearch.co, changed it from http to https, and updated the script to ignore cert errors. All changes were required to make it work (for me at least).
* make guest tools last so pre-reqs are in place
Packer 1.3.x and possibly more does not inject enviornment
variables as expected into `windows-shell` provisioners, moving
script that requires these into a `shell` provisioner.
* do not trust default uploaded windows.iso
Packer in some cases will upload windows.iso from the host
building the VM, since server 2008 needs a specific older
version of tools this can cause problems.
Example issue:
VMware Fusion 11 on macOS Mojave will supply 10.3.x in windows.iso
and will hit https://kb.vmware.com/s/article/55798 due the patch level
expectaions that are intentionally not met for Windows 2008r2.
when requesting glassfish to start in vmware fusion 10 packer get
a non-zero exit code when service is already starting. This look
to be valid to simply ignore.
Let's keep this file even though it's not actively being used.
IMO it's better to have a large collection of working install
scripts that we can use as needed. This will make sure it is
available if needed in the future.
All of the software installation and configuration is occurring
on packer now. Vagrant just brings the box up and adjusts the firewall.
We probably want to do more configuration on the vagrant side to
make it more flexible, but this code is working so I wanted to
commit it.
