Saturday afternoon after a feverish (literally!!) week so let’s log some new stuff to the blog ;)
You may skip this if you want just the tech bytes :P
My love/hate relationship with certificates dates back to Windows Server 2003 times (yes I’m that old :P)
Long story short a “Consultant” was sent to the financial institution where I was a sysadmin. He was the “expert” that was sent to install our Certification authority.
He showed up with a W2K3 handbook printed on many lose A4 pages and 20 minutes into the discussion he stated that we had to install the main CA on one of our DCs. That ended the meeting.
He was never to be spotted again in our office.
I know it sounds a lot BOFH-ish style but it’s what happened :P
Now off to certificates in 2018 and how they can still be tricky ;)
A quick blog post to hopefully help when you are updating PKS from 1.0.x to 1.1.x ;)
I’ve recently spent more time with Customers using Pivotal Container Service® (PKS) so here are some good notes from the field.
If you are using NSX-T there a a couple of things that you need to check.
First thing you’ll need NSX-T 2.1 or 2.2 (at the time of writing it is better to upgrade to the latest version 1.1.5 that supports both ;))
As usual release notes are your friends so here’s an handy link https://docs.pivotal.io/runtimes/pks/1-1/release-notes.html
If you are upgrading from 1.0.x and you “experimented” a lot you may have some stale data in your NSX-T setup.
You could use this script to clean up the ip pools.
Some important notes BEFORE using this script:
- You can do this cleanup only if you have no PKS deployed clusters left.
- Always make sure you’re backing up your NSX-T install frequently ;)
This super tool is provided by my good friend Brice (a real ninja when it comes to PKS ;) ).
To use it populate the variables in the script and execute it AT YOUR OWN RISK.
This will free up some ips for your next setup.
From PKS 1.1.x you have to configure NSX-T in the Director tile (in 1.0.x you had to configure it to “Standard vCenter networking”):
There are some corner cases where your update may seem to work even if you do not configure this so make sure that you do this after configuring the certificates and superuser objects in NSX (as described in here).
When configuring Ops Manager this you may encounter this error:
“Error connecting to NSX IP: The NSX server’s certificate is not signed with the provided NSX CA cert. Please provide the correct NSX CA cert”
I found this when using an NSX-T instance using a self signed certificate.
Examining my certificate I found out this (i just had an hostname and not FQDN or ip in my cert):
So the certificate seems to be malformed.
The script not only creates the superuser and related certificates but it also generates a new cert for the NSX Manager (ie the one above) with a proper FQDN.
Again usual disclaimer: do not DO this in production environments (I assume you have proper certs there!! ;) )
The script uses some environment variables that must be populated in an env file that must be present in the root of the git folder tree that you downloaded.
Just copy the env-example file (in a file named env) and then edit it.
Also make sure that the two variables at the beginning of the script have valid values.
Feel free to reach out to me with your tricks!!