Web

Nginx, OCSP stapling, booting, systemd and Debian 9

Noticed these lines in journalctl when nginx didn’t start after a reboot:

Dec 10 17:43:30 mail1 nginx[3485]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/www.example.com/fullchain.pem"
Dec 10 17:43:30 mail1 nginx[3485]: nginx: [emerg] bind() to [<IPv6 address>]:80 failed (99: Cannot assign requested address)
Dec 10 17:43:30 mail1 nginx[3485]: nginx: configuration file /etc/nginx/nginx.conf test failed
Dec 10 17:43:30 mail1 systemd[1]: nginx.service: Control process exited, code=exited status=1
Dec 10 17:43:30 mail1 systemd[1]: nginx.service: Unit entered failed state.
Dec 10 17:43:30 mail1 systemd[1]: nginx.service: Failed with result 'exit-code'.
Dec 10 17:52:35 mail1 systemd[1]: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument

Hmmm…

Drush cron's not so quiet --quiet flag

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.

Let's Encypt SSL Certificates with Exim, Dovecot & NGINX

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.

nginx core module: worker_rlimit_nofile

Configuration file:    nginx.conf
Block:          main
Value type:     number
Default:        none - system determined (see notes section below)
What it does:   sets the value for the maximum file descriptors
                that can be opened by a single worker process
Example:        worker_rlimit_nofile 1024;

NOTES:

When any program opens a file, the operating system (OS) returns a file descriptor (FD) that corresponds to that file. The program will refer to that FD in order to process the file. The limit for the maximum FDs on the server is usually set by the OS. To determine what the FD limits are on your server use the commands ‘ulimit -Hn’ and ‘ulimit -Sn’ which will give you the per user hard and soft file limits. To determine the maximum number of FDs available, use the command ‘sysctl fs.file-max’ or ‘cat /proc/sys/fs/file-max’.