Let's Encrypt with Cloudflare DNS and F5 REST API
Hi all This is a followup on the now very old Let's Encrypt on a Big-IP article. It has served me, and others, well but is kind of locked to a specific environment and doesn't scale well. I have been going around it for some time but couldn't find the courage (aka time) to get started. However, due to some changes to my DNS provider (they were aquired and shut down) I finally took the plunges and moved my domains to a provider with an API and that gave me the opportunity to make a more nimble solution. To make things simple I chose Cloudflare as the community proliferation is enormous and it is easy to find examples and tools. I though think that choosing another provide with an open API isn't such a big deal. After playing around with different tools I realized that I didn't need them as it ended up being much easier to just use curl. So, if the other providers have just a somewhat close resemblance it shouldn't be such a big task converting the scripts to fit. There might be finer and more advanced solutions out there, but my goal was that I needed a solution that had as few dependencies as possible and if I could make that only Bash and Curl it would be perfect. And that is what I ended up with 😎 Just put 5 files in the same directory, adjust the config to your environment, and BAM you're good to go!!😻 And if you need to run it somewhere else just copy the directory over and continue like nothing was changed. That is what I call portability 😁 Find all the details here: Let's Encrypt with Cloudflare DNS and F5 REST API Please just drop me a line if you have any questions or feedback or find any bugs.
Exchange 2016 iApp LTM on newer versions (v14.1 and above)
Hi all, I recently upgraded a existing F5 LTM cluster running 12.1.5.x towards version 15.1.x On the cluster there where several Exchange 2016 iApps (f5.microsoft_exchange_2016.v1.0.2) with all pool monitoring features enabled (IMAPS inbox check). After the upgrade the IMAPS inbox health check with the external monitor "imap_adv_eav" failed. There were several logs regarding authentication errors. After investigation we saw a different behaviour of cURL which is executed withn the external monitor script. This is due to a new version of cURL (7.47.1 instead of 7.25 on 12.1.5). This newer version is in place in all images from 14.1.x till 16.0.x (this is what i tested). SOLUTION: If you want the external monitor to work again, you need to skip the newly added GSSAPI (Kerberos v5) which is build into the newer cURL version. This can be archived by adding the parameter --login-options "AUTH=NTLM" to the curl command in the external script. This will force the system to use NTLM auth like in previous versions and therefor will work as expected again. Greets Markus
