Jane Doe

Either of these scripts will grab both the IPv4 and IPv6 (if any) addresses assigned to any WAN I’m behind, and, using Linode’s DNS API, will update my DNS records with same and log changes/errors using logger. In effect, it’s a homemade Dynamic DNS updater. Linode’s developing a new API so that’s why  two versions exist.

Download from Bitbucket

To use the script, you need:

1. A Linode API key (for version 3 of Linode’s DNS API) or Personal Access Token (for version 4 of Linode’s DNS API),
2. the domain ID, and
3. the resource (called record in v4) IDs of the DNS records you want to update.

The IDs don’t change, whether you’re using version 3 or version 4.

I use drush to execute cron on my Drupal sites. After upgrading drush from version 5 to version 8, I started receiving empty emails from cron each time drush was executed. Checked my cron entries and everything looked fine. Researched a whole bunch on the Internet. Couldn’t find much of anything about empty emails related to drush so I redirected the output to a log. Sure enough, even with the –quiet option, drush cron still outputs a blank line. Why? I’ve no clue.

Handy One-Liners

This page is a collection of random one-liners I’ve used and wanted to keep track of.

list contents of all crontabs

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

I ran into two issues when setting up Let’s Encrypt SSL certificates on two of my servers - permission issues for Exim and the certbot cron job supplied by the package doesn’t handle the renew very well for nginx, exim or dovecot.

Resolving Exim’s Permission Problems

1. Create a new group. I named it sslcerts. Add the exim user to that group. If you’re not using Debian, adjust the user in the command below.

I ran into a problem with NGINX failing to start on boot/reboot on my Debian 8 (Jessie) server. After reviewing what seemed like a hundred sites to try to find a fix, I stumbled across one solution that worked, but was incredibly inelegant. This was to add:

RestartSec=30s
Restart=on-failure

to nginx.service in the [Service] section using the override.conf. It worked but didn’t fix the underlying problem.

A quick look using journalctl -u nginx showed that the service was failing because the IPv6 address hadn’t been assigned to the network adaptor yet. This caused nginx to fail because it couldn’t bind to the IPv6 port. Here are the log lines: