- your HAProxy config expects certbot to listen at port 54321. You never configure certbot to do that, so it won't do it, and renewal will not work.
- if renewal did work, the certs HAProxy is reading are never replaced.
Really, there are already good tutorials for HAProxy and certbot out there, why muddy the water with another, broken attempt at one?
If you are setting this up in a test environment and are writing it up as you go, I recommend having screen recording/shell logging so you can afterwards check exactly what you did and write it down (at least that has helped me in the past). If you don't, then you really should do a test run and verify what you do works. Writing up something you did a while ago without replicating it makes it really easy to miss crucial steps.
In the words of Roy Trenneman.... Oh dear oh dear oh dear!
I.. Um. It's different now but I'm pretty sure certs still won't renew, and if they did haproxy wouldn't know about them.
I'm not sure what your motivation is for posting this article but honestly you need a better understanding before trying to give other people technical advice about something.
Edit: also the weirdness persists. Why are you allowing inbound dns requests. Why is your firewall blocking first instead of last. Why are you using sudo for curl that gets piped. Jesus why are you curl|bash at all. I'm pretty sure your cron job is unnecessary and won't even work.
<breathe>... There is still a lot wrong with this but I can't type easily so that will have to do for now
Brother, there's a million ways to skin a cat. The article is already 2000 words long and took me a long time to write/test. Going into huge amounts of detail isn't within the scope of the article.
A appreciate the feedback you posted below, and will be making modifications to the article to address some things I wasn't aware of
But, the setup works. There is no zero downtime. I've been using this setup for my smaller applications for over a year and I've never had downtime. Ever.
Also, I rarely provision in bash and haven't provisioned a server manually for a very long time. I use Ansible. But, regular node developers are unlikely likely to be using Vagrant, Docker, Ansible, Chef etc. I didn't want to include that complexity.
I'll address these issues today. You could have gave the feedback without the ear bashing but I'll take that as you're being "cruel to be kind" :)
The steps you had (I haven't checked for updates) definitely wouldn't produce a working setup - for the reasons I detailed in my other comment.
I'm not saying "this is fundamentally the wrong way to do skin a cat", it seems to be trying to achieve what I consider to be one of the best ways to skin said cat, but the article had (and may still have) actual technical errors that could not produce a skinned cat.
I honestly really appreciate the advice, it's been super helpful. I have now amended the article. I will revisit it tonight and go into a little more detail explaining what everything does.
I hadn't seen pass until after I write this script. The main reason I developed PassMan was mostly for learning and practice and to brush up on my bash scripting.
This project is not intended to be a sample application. As it stands it's a simple starter kit to avoid having to repeat the same configurations for every application. I created it purely for personal use, and decided to share it.
Over time I will be adding more features. Today PouchDB and CouchDB remote replication has been added comply with offline first development practices. Along with a few other tweaks. Next I'll be adding common React components that I use often in my own commercial projects.
It's every growing, and an attempt to get contributors to jump on board to create something that will be beneficial and helpful to all.
Many thanks for your time and help.