On Friday morning I arrived in the office and picked up an overnight customer request.
I wanted to turn it around asap to make the customer’s weekend a happy one. Job done. But in the process here's what I learned about how to export a list of certificate expiry dates on your load balancer!
Scripting is one of the fun tasks we get to do and, as I'm Mr Automation here at Loadbalancer.org, I knew it was a task to be completed and sent back to the customer before they got out of bed.
So what was the request? It was as typed below - don't worry, no sensitive information included (GDPR and all that!):
"I wonder if there is a simple way to get a list of certificates with their expiration dates from the load balancer. I see that we could call: https://192.168.93.60:9443/lbadmin/ajax/get_ssl.php?t=cert&v=0 over and over again starting at 0 and going until it runs out of certs. Is there anything better? We keep expiration dates in our database, but we are concerned that some of them may have gotten out of sync."
I put my thinking head on, knew I had done something like this for a previous customer, and allowed my fingers to do their thing!
First I wrote the interface and linked it into the very simple API wrapper so it was secure, didn't take any args and simply returned the data in JSON format.
The script walks the XML for all certificates and then checks if the file is present and, if it isn't present, it will return the JSON below:
So we have the script to read the certificates present, we also have the return data format and now we think: how do we call this? Well, put simply, it's a simple HTTP GET Request as seen below with a cURL example:
Now those who've read my previous blogs will recognise this script is simply the same as that in my APICALL script - only changing it from POST to GET request and removed the need to send any JSON. We only need the output here, but you don't use Linux as you don't have cURL present, so you need another way to call and retrieve the JSON output.
We can use any language that will perform a HTTP GET, so that leaves us with my normal (Powershell) or C#.
Holding my hands up, with no prior hands-on exposure of C# but, knowing the customer used C#, will use this as an example...
...and also because golang is, well, "EASY" to code and make a .exe file for windows, mac or linux!
As you can see from above, golang is kinda 'wow'.
But is it really this simple to write the code? The answer is yes! To my surprise "anyone" with the aptitude and wish to learn can be posting data within an hour (it took me just 10 mins to find and implement this when I looked, and its cross-platform so no more scripts to do things! Go golang!).
So, you have a script, but now you ask about compiling? That's hard right? Well no, its "simply" simple! One would just type go build scriptname.go to build a binary or .exe on Windows and go run scriptname.go to test it!
It had me up and running with my first sensible script in a matter of hours.
Why walk when you can run?
So here we have a customer request made overnight, exceeding expectations in turnaround time, examples shared and I would like to hope everything works as the customer had asked!
It enabled another form of automation - this time for a report that did not exist.
I think that about sums it up. I should really say that not every request of this type can be turned around on the same day - but we do try!
If you have any questions please do not hesitate to ask, and if it all goes horribly wrong then email firstname.lastname@example.org and let us know what happened – so we can do our very best to fix whatever the issue might be! Attaching /var/log/lbadmin.log should be enough to find any problems.