antipaucity

fighting the lack of good ideas

update: keeping your let’s encrypt certs up-to-date

Last year I posted a simple script for keeping your Let’s Encrypt SSL certificates current.

In conjunction with my last post sharing the “best” SSL configs you can use with Apache on CentOS, here is the current state of the cron’d renewal script I use.

systemctl stop httpd.service
systemctl stop postfix
~/letsencrypt/letsencrypt-auto -t -n --agree-tos --keep --expand --standalone certonly --rsa-key-size 4096 -m user@domain.tld -d domain.tld
# you can append more [sub]domains to a single cert with additional `-d` directives ([-d otherdomain.tld [-d sub.domain.tld...]])
#...repeat for every domain / domain group
systemctl start httpd.service
systemctl start postfix

I have this script running @weekly in cron. You should be able to get away with doing it only every month or two .. but I like to err on the side of caution.

I’m stopping and starting Postfix in addition to httpd (Apache on my system) for only two reasons: first, I am using some of the LE-issued certs in conjunction with my Postfix install; second, because I don’t know if Dovecot and my webmail system need to make sure Postfix is restarted if underlying certs change.

automatically extract email attachments with common linux tools

I had need to automatically process emails to a specific address to pull attachments out, and this is how I did it:

$ yum install mpack

$ cat extract-attach.sh 
#!/bin/bash
rm -rf ~/attachtmp
mkdir ~/attachtmp
mv ~/Maildir/new/* ~/attachtmp
cd ~
munpack ~/attachtmp/*
rm -rf ~/attachtmp

$ crontab -l
*/5 * * * *	~/extract-attach.sh

Why, you may ask? Because I get a report a few times per day to the email address in question.


Note – this runs in my crontab every 5 minutes on a CentOS 6 x64 server; I’m sure the process is similar/identical on other distros, but I haven’t personally tried.

don’t implement your scheduler in a pure queue design

Recently came across a seriously funky issue with one of HP’s products (don’t laugh – I know there’s loads of funkiness in HP tools).

HP Cloud Service Automation (3.1) allows you to schedule requests in the future. It also allows you schedule end dates for subscriptions.

That’s neat.

Here’s the problem: if you delete a Service Offering (which allows something to be requested in the CSA catalog) while an active subscription is using it – any active subscriptions get delinked, and become unmanageable with the tool.

Now the dopey scheduler comes into play.

CSA’s scheduler works by putting all future items into a FIFO queue. What this ends up meaning is that if you have an item that fails (because, for example, you’re now past a scheduled end date, but the subscription is unlinked from an offering, so it can’t unprovision it), all other pending items fail, too. Even ones that should happen “immediately” – because “immediately” is still added to the scheduling queue… behind the erroring item(s). And since those items have errored, nothing can move forward.

This is stupid. (And yes – RFEs have already been filed over these problems in the product.)

Instead, have the scheduler put all items into a table – at the appointed time, iterate through the table and run everything you can – if it won’t run, flag it as an error, and move on.

This is how cron works. Why would you not use a commonly-accepted, reliable way of doing things? Oh yeah – you’re HP.

If you’re planning to write something for your product/software/tool – see if anyone else has done it before, and then try to mimic methods that work… please!