WilliamLam.com

Quick Tip - List all open ports on the VCSA / PSC

by // 2 Comments

The list of required ports for both a vCenter Server Appliance (VCSA) and Platform Services Controller (PSC) are pretty well documented here (6.5), here (6.0) and here (5.5) for customers who require this information to setup external connectivity within their networking infrastructure. Having said that, it is may not always be clear on what ports are actually opened as they will usually depend on the type of deployment and the services that are running. Instead, some customers have inquired about getting a list of all open ports directly from the VCSA/PSC to ensure they have the actual configuration which can be used to build firewall rules and/or for auditing purposes.

Today, the only method is to login directly into the VCSA/PSC via SSH (you could also use GuestOps API, so that SSH is NOT required) and fetching this information using iptables. Hopefully, in the future, this can be made available as part of the VAMI API since it already covers some basic inbound firewall rule capabilities. In the mean time, below are examples of how to get all the open ports for both VCSA/PSC

Run the following command to view all open ports on VCSA/PSC:

iptables -L port_filter -n --line-numbers


You will notice in the output above, there is also a chain number on the far left side which is associated with each rule. This chain number can be used to inspect the rule further and some rules include a nice alias to help you identify what the port might be used for.

For example, we can run the following to inspect chain rule #30 and find out this port is being used for syslog. If we want the port number, we simply add the -n option.

iptables -L port_filter 30
iptables -L port_filter 30 -n


Not all of the firewall rules have an alias name and even if they do, it still may not be apparent on what service is opening that particular port. We can actually look at the firewall rule definitions which are located under /etc/vmware/appliance/firewall and you will see a JSON file for each of the VCSA/PSC services that require firewall rules to be opened up. For a given port, you can just grep in this directory to identify the service that is requiring the port.

For example, if we take a look at the vmware-syslog, we see that it requires tcp/udp 514 and tcp 1514 under the "rules" array which defines the list of external ports open. You can ignore the internal ports as those are not exposed to the outside world but used by internal services. In case the services are still not clear, you can always reference the port number back to the documentation which I had linked above to get more details about the particular port.

Configure vRealize Automation to use Platform Services Controller as External Identity Provider

by // 2 Comments

I was doing some research on an inquiry that I had received from a customer who was interested in configuring their vRealize Automation (vRA) instance to use vCenter's Platform Services Controller (PSC) as an External Identity Provider (IDP) rather than the default VMware Identity Manager (vIDM) which vRA supports natively out of the box. vIDM already supports a large number of websso applications as seen here and it itself can also be used as an External IDP to integrate with things like Active Directory Federation Services (ADFS) for example.

For some customers who are more familiar with the PSC, this is a convenient way to unify their authentication between the different vRealize products which support vIDM and integrating that directly with PSC. Since both solutions spoke SAML, it was merely figuring out process on setting up the External IDP using the PSC. In reading some of our internal Wikis and working with one of the vIDM Engineers, since I was stuck on a particular step, I was able to finally get this to work which I have outlined the steps below. I also learned that we had officially supported this since vRA 7.0 which was great to hear as well.

I know there are number of customers who would also like to see the reverse of this configuration, where PSC can use vIDM as an External IDP. I know this is something the PSC team is currently looking into for External IDP support. If this is something that you are interested in or would like to see specific External IDP setup/configuration, feel free to leave a comment.

Pre-Requisite: 

  • Join Platform Services Controller (PSC) to Active Directory (instructions here & here)
  • Join vRealize Automation (vRA) Appliance to Active Directory (instructions here)

In my lab environment, I have deployed an Embedded VCSA 6.5 (this also works with an External PSC) and vRealize Automation 7.2 (this was prior to 7.3 getting released but should work as well).

[Read more...]

Quick Tip - Creating a multiline Dockerfile using heredoc w/variable substitution

by // 1 Comment

I was helping out a fellow colleague yesterday who was having some troubles handling a multiline echo statement within his Dockerfile. There are multiple ways in which you can create multiline Dockerfiles, the web is full of examples from using multiple echo statements (pretty ugly) to using heredocs which is easier to read and manage. The challenge was that he also wanted to substitute some variables into his multiline statement which apparently there were no examples online, at least neither of us could find.

Taking a closer look, I found that we can just leverage Bash's ANSI-C Quoting syntax $'string' to do what we want, which was actually something new to me as well. You can then pass in the variable like you normally would between the strings and that would give you the readability of heredocs and still be able to use Docker variables. I am sure there are other methods with more extensive escapes with single-ticks, but I also prefer a solution that is easy to read and use in case others need to manage it.

Here is a quick sample Dockerfile which demonstrates how this works:

FROM photon:1.0

ARG BASEURL="https://vmware.bintray.com/powershell"

RUN echo $'[powershell]\n\
name=VMware Photon Linux 1.0(x86_64)\n\
baseurl='$BASEURL$'\n\
gpgcheck=0\n\
enabled=1\n\
skip_if_unavailable=True\n '\
>> /etc/yum.repos.d/powershell.repo

CMD ["/bin/bash"]

Basically the echo statement has $'SOME-STRING'$VARIABLE$'SOME-STRING'

If we build and run this Docker image, we can see that we have properly substituted the BASEURL variable into our file as seen in the screenshot below.

docker build -t sample .
docker run --rm -it sample cat /etc/yum.repos.d/powershell.repo


I personally prefer to keep such logic within a separate script which the Dockerfile can reference, but I was also sympathetic to that fact that my colleague wanted to keep things simple and just have everything within the Dockerfile. I figure I would share this in case other comes across this problem as well as benefiting myself as I will probably forget in a months time 🙂