WilliamLam.com

Quick Tip - Certificates in Apple Keychain causes Terraform init to fail with Registry service unreachable

by // 1 Comment

I have been struggling with an interesting Terraform issue on my MacOS system where running the "init" operation would throw the following error:

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...

Registry service unreachable.

This may indicate a network issue, or an issue with the requested Terraform Registry.

Error: registry service is unreachable, check https://status.hashicorp.com/ for status updates

This was extremely frustrating to debug which I had filed a Github issue here. From what I have gathered, this actually had nothing to do with connectivity to the HashiCorp endpoint which works perfectly but probably was related to some other issue. What was even more strange was that using "sudo" which another user reported in an older issue allowed the operation to go through. I was also not having this problem on my other MacOS system, so I knew this was probably environmental but was running out of ideas to try.

I took another look this past weekend while doing some testing and I stumbled onto this thread here which the user found the real root cause. It looks like certain certificates within Apple Keychain Access, possibly related to Microsoft Remote Desktop that have expired was actually causing the problem. When I took at look at the Keychain Access login->certificates, I saw a number of certificates which had expired but were still marked trusted. After removing these entries (although this can be automated using the security utility, it was not trivial given the lack of arguments to quickly list out expired certificates), that I simply used the UI to delete the entries.

Once all the expired certificates were removed, I was able to successfully perform the Terraform init operation! I have already shared this update in my Github issue and hopefully this error message can be improved in the future as it was very miss-leading on the actual issue.

Using vRO REST API to execute a workflow with SDK objects

by // 3 Comments

I was working on something last week which involved vRealize Orchestrator and I wanted to execute a vRO worklfow but rather than using the UI, I wanted to use the vRO REST API. Although there are a couple of blog posts such as this one which demonstrates how to use the vRO REST API, they all use a very simple workflow that only contains string inputs. In my opinion, this does not actually reflect practical workflows which usually contains a mix of strings but also SDK-based objects like vSphere VMs, ESXi hosts, Networks, etc.

It actually took me awhile to wrap my head around how to call these more complex workflows using the vRO REST API and after a ton of trial/error and some help from Kasey Linden and one of the vRO Engineers, I now have a method in which users can follow to identify the required payload for a given vRO workflow when using the vRO REST API. The instructions below is using the latest vRO 8.0.1 release which has a new HMTL5 UI, it has been awhile and I am not sure when this new UI was introduced but the instructions may work for older clients but I would recommend standing up the latest version for developing your automation.

Step 1 - Retrieve the vRO workflow ID by selecting the workflow in the vRO UI. In the example below, my Tag a VM workflow ID is 9d95c7f5-a563-413f-af42-fd7e09275216

[Read more...]

How to deploy the vCenter Server Appliance (VCSA) with a custom MAC Address?

by // 8 Comments

I recently had a question that came in from our field where a customer needed to deploy the vCenter Server Appliance (VCSA) with a specific MAC Address which was a requirement to ensure property connectivity within their network. This type of network requirement is not really new or unique, it is a common practice used to ensure only valid VMs with a static DHCP reservation can actually connect to a specific network but it certainly was the first time I had heard of this request for the VCSA.

With the default VCSA installer workflow, there is currently not a way to modify the network MAC Address which is automatically generated after the deployment of the OVA. Having said that, I have spent quite a bit of time exploring the various non-standard methods of deploying the VCSA in the past (see here, here and here) and with that information, you definitely can affect the MAC Address while still maintaining a valid VCSA deployment. With a bit of trial/error, there are two options depending if you are deploying the VCSA directly to an ESXi host (for initial setup) or to an existing vCenter Server. To demonstrate how this works, I have created a basic shell script called VCSAStaticMACAddress.sh which you can easily adapt to for a Windows-based environment.

The trick is that when you deploy to a vCenter Server endpoint, the required OVF properties are persisted which would allow you to only deploy the VCSA but not actually power it on and there you can easily augment a number of settings including the MAC Address. In the case of deploying directly to an ESXi host, OVF properties are not persisted and hence a challenge if you wish to make changes prior to powering on the VM. In earlier versions, it was possible to set these OVF properties by way of using the extraConfig property of the VM but it looks like this trick no longer works and requires a slight variation of the workflow which is described in the instructions below.

[Read more...]