Comments in the moderation queue: 11

Recently posted comments:

Switching my mail server from ucspi-ssl to s6-networking has been on my TODO list for a while. I haven’t done it yet, but now that s6-networking supports Server Name Indication, I’m intrigued by the idea of letting it handle TLS and networking, and running a much simpler and smaller webserver like publicfile (or httpfile). I’d need at least CGI support, which it looks like I could add with shttpd.

Comment by Amitai Schleier Sat Oct 16 11:17:56 2021

A few days ago I upgraded PHP from 7.3 to 7.4 to keep up with pkgsrc’s default. It went fine, probably. As a result, today I tried an in-place upgrade from MySQL 5.7 to MariaDB 10.4. It wasn’t one. Fortunately I had a quick way to be running MySQL again.

This site’s been database-free for years. If my users can switch their stuff to SQLite, I can get out of the database administrator business. As a first pass, I extracted my own databases (whatever they are) from the system MySQL to a standalone instance running as me.

Comment by Amitai Schleier Mon Sep 20 16:02:39 2021

Deleting Apache again was fun and rewarding all by itself, plus it lent some urgency to reviving my WebDAV service (rarely used though it is) with lighttpd. Steps to success:

  1. Have the lighttpd developers fix a segfault on NetBSD
  2. Ignore the remaining problems for a week
  3. Take a fresh look at my config, notice how it’s not equivalent to what Apache’s had been, and fix that
  4. Ta da!

The mistake was easier to make because photos.theschleiers.com has always been a little clever. It serves the same URLs two different ways: to browsers (by reverse-proxying to Nathan’s photo gallery app), and to WebDAV clients (by not doing that). I still think this cleverness is worth it, especially now that it’s working again.

Here’s my old Apache config and my new lighttpd config.

Comment by Amitai Schleier Thu Nov 5 15:02:53 2020

In September, tired of various annoyances with pound as a reverse proxy, I started sniproxy on non-standard ports (one for plaintext, one for SSL) and began reconfiguring lighttpd sites to be reachable both ways.

Motivations for replacing pound:

  • It’d periodically eat CPU, needing to be restarted
  • Each time I added a new site (especially with SSL), I had to follow what felt like too many steps in too careful an order
  • Because it has to terminate SSL, one of those steps was giving it the site’s cert and private key /!\
  • To listen on IPv6, nearly the entire config would have to be duplicated

Getting the first site running under sniproxy while keeping it running under pound was tricky, because sniproxy by design does a much smaller job. The main trick turned on this bit of (oversimplified) logic: if there’s an X-Forwarded-For request header, we’re running under pound as before; else we’re under sniproxy, and if the URL scheme isn’t already https then we need to redirect.

After a few sites had been reconfigured, I extracted the common lighttpd bits. After a few more, I figured out how to further simplify sniproxy.conf.

The last site to convert was the sole Apache instance, and the fresh tedium of that effort reminded me how much I wanted to get rid of Apache.

Cutover was easy. Once pound was off, the shared lighttpd config became simpler. While I was in there, I tweaked it for better grades from SSL site scanners. A few weeks ago, with sniproxy never once having required my attention, I deleted pound. Here’s my sniproxy.conf.

Since three years ago, when I grudgingly brought back Apache, lighttpd has grown what appears to be a full-featured WebDAV implementation. I eagerly took the liberty of deleting Apache, even though I don’t have lighttpd’s WebDAV working well yet. When this step has become a refactoring, I’ll comment again.

Comment by Amitai Schleier Tue Oct 27 06:14:31 2020
Wow, they sent your childhood piano to you! How wonderful of them!
Comment by Jeff H Fri Sep 18 10:59:10 2020
Taavi continues to exhibit good taste: Nine Bowls of Soup is a solid, solid tune. Hugs and many great wishes for Fineas’s procedures all to go well.
Comment by Markus Silpala Thu May 14 13:22:12 2020
Thanks, I love your podcasts for work. But this has inspired me to commit to playing my piano at least 15 minutes each day.
Comment by Patrick Boland Tue Jan 7 14:48:51 2020

In 1.07, paths are unchanged from the old /var/qmail style.

FWIW, I’ve worked around this for the last 15 years by placing symlinks in /var/qmail, which qmail’s installer happily follows. So /var/qmail paths continue to work, but files are physically installed in sensible locations. For instance:

alias -> /etc/qmail/alias
bin -> /opt/pkg/bin
boot -> /opt/pkg/share/examples/qmail/boot
control -> /etc/qmail/control
doc -> /opt/pkg/share/doc/qmail
man -> /opt/pkg/man
queue -> /var/spool/qmail
users -> /etc/qmail/users

(The qmail package in pkgsrc has done this for 15 years too, because I’m the package maintainer.)

For notqmail 1.08, we intend to address FHS/hier(7) more directly.

Comment by Amitai Schleier Wed Aug 21 09:26:29 2019
This is just me hoping that notqmail hews to convention for where files go, rather than where djb elected to put them.
Comment by Nathan Myers Wed Aug 21 00:47:25 2019
I appreciate the suggestion, but we’re comfortable with the name. It makes clear that this is not DJB’s qmail, so don’t bother him or expect his security guarantee to apply. It’s a bit of wordplay on “netqmail”, the previous community effort. And I think the notqmail logo is funny. All positives :-)
Comment by Amitai Schleier Tue Aug 20 22:40:24 2019