iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add warning note about using the 'winrm quickconfig -q' command 

A lot of examples out there on the web make use of this command to
configure the instance to allow connections over WinRM. Since the
danger is not immediately obvious and the failure because of its use
intermittent, we should do our best to advise against its use here.
This commit is contained in:
DanHam 2017-10-16 02:45:56 +01:00
parent 26319ee74b
commit c9e6ffa91c
1 changed files with 23 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
website/source/intro/getting-started/build-image.html.md
View File

@ -408,6 +408,29 @@ Start-Service -Name WinRM
Save the above code in a file named `bootstrap_win.txt`. Save the above code in a file named `bootstrap_win.txt`.
-> **A quick aside/warning:**
Windows administrators in the know might be wondering why we haven't simply
used a `winrm quickconfig -q` command in the script above, as this would
*automatically* set up all of the required elements necessary for connecting
over WinRM. Why all the extra effort to configure things manually?
Well, long and short, use of the `winrm quickconfig -q` command can sometimes
cause the Packer build to fail shortly after the WinRM connection is
established. How?
1. Among other things, as well as setting up the listener for WinRM, the
quickconfig command also configures the firewall to allow management messages
to be sent over HTTP.
2. This undoes the previous command in the script that configured the
firewall to prevent this access.
3. The upshot is that the system is configured and ready to accept WinRM
connections earlier than intended.
4. If Packer establishes its WinRM connection immediately after execution of
the 'winrm quickconfig -q' command, the later commands within the script that
restart the WinRM service will unceremoniously pull the rug out from under
the connection.
5. While Packer does *a lot* to ensure the stability of its connection in to
your instance, this sort of abuse can prove to be too much and *may* cause
your Packer build to stall irrecoverably or fail!
Now we've got the business of getting Packer connected to our instance Now we've got the business of getting Packer connected to our instance
taken care of, let's get on with the *real* reason we're doing all this, taken care of, let's get on with the *real* reason we're doing all this,
which is actually configuring and customizing the instance. Again, we do this which is actually configuring and customizing the instance. Again, we do this