While going through the latest lab upgrade round, I found myself running into an error when upgrading NSX. The NSX Edge Transport Nodes (ETN) upgrade successfully, however, the NSX Host Transport Nodes (HTN) portion fails.
Not that the solutions is so special but it had me running around a bit, therefore I wanted to share.
The upgrade returns the following error:
A general system error occurred: Image is not valid. Component NSX LCP Bundle(NSX LCP Bundle(4.1.0.2.0-8.0.21761693)) has unmet dependency nsx-python-greenlet-esxio because providing component(s) NSX LCP Bundle(NSX LCP Bundle(4.1.0.2.0-8.0.21761693)) are obsoleted.
At the same time the same error is listed on vCenter:
NSX LCP upgrade error on vCenter
When analysing the vLCM configuration, there was nothing that pointed to the fact that the NSX LCP Bundle was causing an issue.
Are you tired of constantly typing the password when executing cell-management-tool commands on VCD cells? Here is a quick tip on how to use the cell-management-tool without using credentials.
There is an option -i that allows you to execute commands using the pid (process id) instead of providing the system-administrator credentials.
How does it work?
first you retrieve the pid number
the -i option allows you to use the pid number to bypass the authentication (you were logged on with a user with administrative permissions anyway)
The following will display the activity (-t, or –status) on the VCD cell. If not using the pid method, one would use -u for the username, and then be prompted for the password.
You can find the cell-management-tool command line reference here (VCD 10.4).
Let’s take a look how it would normally work:
retrieve the pid number
Default
1
2
cat/var/run/vmware-vcd-cell.pid
24663
Now we will use the pid number as a parameter to execute the command:
Default
1
2
cd/opt/vmware/vcloud-director/bin
./cell-management-tool cell-i24663-t
Let’s do some small optimization now. We will combine the two command into a one-liner. This will retrieve the pid at execution time.
Happy to share this quick tip. Now you can also execute the cell-management-tool without using credentials, and maybe be a less frustrated, having to type that password over and over again 😀 !
DO NOT USE -p option
The -p option allows you to specify your password on the command line. However, this will be shown in plain text, and will be stored in the cli history. Other system administrators might be seeing this history, and therefore also this password.
To be honest, I have been complaining some over the last year, or so, about the NSX Advanced Load Balancer documentation. Mostly that it was not easy to be found, and one was having to fall back on the avinetworks.com site, which was not great either.
On docs.vmware.com the navigation links were not existing. However, if and when you knew the page titles, you could search for them through search engines. That showed that a lot of those documentation pages were there, in fact, but only not visible with non-existing links.
However, since a couple weeks, there is a banner on the avinetworks.com site that 22.1.4 is the latest release that was documented on avinetworks.com.
NSX ALB documentation deprecation on avinetworks.com
This means that the single source of truth will be on the NSX Advanced Load Balancer page on docs.vmware.com (the link does redirect you to that location 😀).
Quick tip: if you want to search within a site through a browser, e.g. chrome, use the following as an example:
Are you setting up TrueSSO? Are you looking to use signed certificates to secure the communication between the Connection Server and the Enrollment Server?
Try to find the documentation on using signed certificates to secure that communication. I challenge you, you will not find it easily.
What and why?
You are allowing access to the Unified Access Gateway from the internet. You will want those services to have signed certificates to secure the communication, which will turn that icon in the Horizon client green. To enable end-to-end signed communication, you will need to make sure that you have certs all the way. In the end you are creating tunnels to backend services.
On top of that you want to add TrueSSO in the equation as you want a seamless sign-on experience. This means more certificates. You follow the guides (and all the blog posts that are built using this information), so you are almost there.
However, one step is exporting the ‘vdm.ec’ certificate from the Connection Server and import it on the Enrollment Server. That is exactly where the information is missing or at least hard to be found. None of them actually talk about CA signed certificates for this. You are doing this kind of effort to get all those components (Microsoft) CA signed. Don’t you think that you should use signed certificates here as well, if . I think so!
Where can I find the documentation
Here is the documentation on the VMware websites on setting up TrueSSO:
A client of mine was looking on how to update the maximum failed OS login attempts because they were having an issue with the monitoring solution locking the root user account on the VMware Unified Access Gateway 2212. This version of the UAG is based on photon OS 3.0.
He asked me to verify where to change the configuration to update the maximum failed OS login attempts. This is normally set at UAG deploy time and there is no option to change it afterwards easily.
Be aware that this is a rather unconventional change because these values shouldn’t be changed from the default, especially if you want to be compliant with CIS audits for example.
This is the default and also the line that you need to change
Change the deny=3 to the maximum value you want. If you change it to 0 (zero) it will never deny based on the maximum failed OS login attempts for all local users
even_deny_root
Leave it out if it shouldn’t deny the root user being locked out on the maximum failed OS login
