Search Results for: ovftool

VCSA 6.5 CLI Installer now supports new ovftool argument pass-through feature

11.30.2016 by William Lam // 2 Comments

I had recently discovered a really cool new feature that has been added into the vCenter Server Appliance (VCSA) 6.5 CLI Installer while helping out a fellow colleague. For those of you who have not worked with the VCSA before, you can deploy it using one of two methods: 1) Guided UI Installer 2) Scripted CLI installer. The latter approach is great for Automation purposes as well as being able to quickly spin up a new VCSA as the UI wizard can get tedious once you have done it a few times. The VCSA CLI Installer reads in a JSON configuration file which defines what you will be deploying whether that is an Embedded, PSC or VC node and its respective configuration (networking, password, etc).

In VCSA 6.5, the CLI Installer introduces a new option in the JSON schema called ovftool.arguments. Here is the description of what this new option provides:

Use this subsection to add arbitrary arguments to the OVF Tool
command that the script generates. You do not need to fill it out in
most circumstances.

First of all, I just want to mention that this option should not be required for general deployments but it may come in handy for more advanced use cases. Behind the scenes, the CLI Installer takes the human readable JSON and translates that to a set of OVF properties that are then sent down to ovftool for deployment. Not every single option is implemented in the JSON and for good reason as those level of details should be abstracted away from the end users. However, there may be cases where you may need to invoke a specific configuration or trigger a specific ovftool option and this would allow you to provide what I am calling a "pass-through" to ovftool.

Let me give you one concrete example on how this could be useful and how we can take advantage of this new capability. Since the release of VCSA 6.0, when you enable SSH and you login, you will notice that you are not placed in a regular bash shell but rather a restricted appliancesh interface. From an Automation standpoint, it was some what painful if you wanted to change the default as this feature is not implemented within the JSON configuration file. This meant that if you wanted the bash shell to be the default, you had to either change it manually as part of a post-deployment or you would have to by-pass the native CLI Installer and manually reverse engineer the required set of OVF properties needed for the deployment which is also not ideal.

[Read more...]

Default hashing algorithm changed in OVFTool 4.2 preventing OVF/OVA import using vSphere C# Client

11.18.2016 by William Lam // 11 Comments

After upgrading my home lab recently to vSphere 6.5, I also updated some of the related utilities such as the various SDKs and CLIs. One of the CLIs that I had updated was the latest version of OVFTool which is now at 4.2. I use OVFTool extensively to automate various Virtual Machine deployments (import/export). While testing out a new OVA that I had been working on, I needed to verify that it also worked with previous release of vSphere like vSphere 6.0 Update 2. I happen to have the vSphere C# Client open and connected to a vCenter Server and when I tried to import the newly created OVA, but it failed with the following error message:

The following manifest file entry(line1) is invalid: SHA256

I was pretty surprised by this since I went through this exact same workflow a couple of days ago without any problems. The only change that had happened was OVFTool and error seems to indicate an issue with the hashing algorithm. I ran OVFTool again using just the --help option to check what the default SHA hashing algorithm was, it was SHA256. I then compared that to an older version of OVFTool and it looks like the default had changed from SHA1 to SHA256.

From a security standpoint, this is a positive change as SHA1 is no longer considered a secure hashing algorithm and a stronger version should be used. It also turns out that the vSphere C# Client can only support SHA1 which is why I received the error after upgrading to the new version of OVFTool. Luckily, this is NOT a problem when using the vSphere Web Client or the vSphere HTML5 Client and only affects the vSphere C# Client. If you do need to use the vSphere C# Client for importing OVF/OVAs exported from the latest version of OVFTool, the workaround is quite simple, just override the default hashing algorithim when exporting by adding the additional CLI option:

--shaAlgorithm=sha1

Quick Tip - Using ovftool to connect to vCloud Director behind a 2-Factor Authentication portal

06.08.2015 by William Lam // 2 Comments

A couple of months back I ran into an issue while trying to upload a couple of files to VMware's internal OneCloud environment which uses vCloud Director. The issue that I encountered was that our OneCloud environment no longer supported basic username/password authentication, which I hoping to automate using ovftool. Instead, it is now front-ended with VMware Application Manager which requires 2-Factor Authentication (2FA) and once authenticated, a SAML token is then passed to vCloud Director which then automatically logs you in.

The problem with this is that ovftool can not be used to directly login to vCloud Director as it does not have support for 2FA, which makes automating operations against our OneCloud environment pretty difficult. After spending a few days looking for an alternative and not having any luck, my last hope was to reach out to the ovftool developers to see if they had seen this before.

After a few email exchanges, although ovftool does not support 2FA, you can however get this to work using session ticket authetnication which it does support using either the --I:sourceSessionTicket or --l:targetSessionTicket option. To get more details on these options, you can run the following ovftool command:

ovftool --help integration

In order to use this session ticket mechanism to authenticate into a 2FA environment, you must first login manually using a web browser. Once you have successfully logged in, you will need to either use browser developer tool or something like Firebug to record the authenticated vCloud Director cookie which will then be passed to ovftool.

In this example, I am using Chrome and you can find the Developer Tools by going to Options->More Tools->Developer Tools. Next, refresh the webpage so you are able to see the web requests between your browser and vCloud Director. Now navigate to Network->Cookies option and select any one of the requests to the left of the screen such as "amf".

What you will be looking for is the value to the cookie named "vcloud_session_id" which is is the authenticated session that we will use to provide to ovftool. Once you have that value, you can then specify the connection to ovftool using the following:

ovftool --I:targetSessionTicket=[VCLOUD_SESSION_ID_VALUE] vcloud://...

I had known that ovftool supported session based tickets, however I did not realize it could be used to authenticate behind a 2FA solution like VMware Application Manager. For folks interested in using ovftool and session based tickets directly with vSphere, check out this awesome post by my good friend Jake Robinson who demonstrates this using PowerCLI, ovftool and the AcquireCloneTicket() vSphere API method.