On Fedora 20 virtual machines biosdevname command
'Returns 4 if running in a virtual machine.'
This patch:
- Uses the biosdevname command return value to detect if virtual
- Uses /sys/net to get interface names - Might be better solution
- Leaves unchanged the original 'bare metal' case - I wonder what for
though?
Tested with Fedora Cloud image adapted for vagrant-libvirt
Fixes issue #4104
This commits adds a new config setting `config.vm.box_server_url` to set
the URL of a local VagrantCloud instance in the Vagrantfile. If the
environment variable `VAGRANT_SERVER_URL` is set, it will still be
preferred.
Removed dependency upon netdom which is not always available on all Windows versions. This implementation that uses PowerShell and WMI should work on all OS and PowerShell versions.
Fixed another issue where host renames would always happen when the hostname was longer than 15 characters. The COMPUTERNAME environment variable only returns the first 15 characters so we no longer use that to check the current host name.
As this is nested in a powershell variable $command, it must be escaped
otherwise it is evaluated when the variable is created, giving an error that
"The term 'True' is not recognized as the name of a cmdlet, function,
script". This prevented using a puppet.working_directory on Windows.
Reboot the Windows guest after renaming the computer so changes take affect immediately before attempting to provision the box.
- Changed rename from wmic to netdom since netdom seems to work correctly in Windows 2008R2 and newer OSs.
- Fixed Windows guest error translations, the wrong namespace was specified in the yaml file.
Running Windows guest commands through a scheduled task were not returning the correct exit codes, they were only returning 1 or 0. This has negative consequences especially for Puppet which can return an exit code of 2 for partial success.
Since we're running an executable from inside a powershell encoded command we need to ensure we explicitly propagate the exit code to the original caller just like a regular PowerShell script - in this case cmd /c which in return is called from a scheduled task.
OS X's `xargs` does not support the `-r` flag (which means "do not
execute the command even once if there are no arguments"), but
behaves by default as if it was specified.
You can verify this yourself with this test:
$ touch zero-length-file
$ xargs echo <zero-length-file
If `echo` is executed, you will see a blank line. If it is not
executed (i.e. `-r` is specified or the behavior is implied) then
you will see no blank line.