What’s running on the firewall? A big list follows, with discussion.

• ACPId - reports on thermal performance
• atd - executes delayed jobs via at
• cron - executes repeating jobs, like the local backup, the remote backup, and the automated package updater.
• dbus-daemon - nearly useless, but Linux more or less requires it
• ddclient - dynamic DNS client updater, fires off an update when we get a new external address
• dhclient - DHCP client, gets external address from the fiber ISP
• dhcp6c - DHCPv6 client, not currently in use but plausible
• dhcpd - DHCP server, for handing out addresses on the inside network. Has a failover arrangement with another server
• getty - console management
• irqbalance - a daemon on SMP Linux systems that evens out load across cores
• postfix - handling local mail.
• radvd - IPv6 routing advertisements
• rsyslogd - the reliable syslog daemon
• snmpd - statistics reporting
• sshd - SSH daemon, allows access only from internal IPs
• systemd-udevd - last remnant of systemd, managing device names
• unbound - DNS caching resolver
• vnstatd - network bandwidth monitor

Not appearing because they are kernel tasks:

• interface configuration
• wireguard tunnels
• routing
• firewalling
• IPv6 tunnel

I will get around to discussing them at a later date.

What’s not running on the firewall?

• apache, nginx, or any other webserver
• postgresql, mariadb, or any other database
• mail service for other machines. This one is a toss-up: mail service is relatively low-impact for modern hardware and low (single family) volumes. But it has a lot of moving parts and implies lots of storage, which impacts backup/restore time. As much as possible, I’d like the restoration process for this firewall to be fast. So mail is on a different, more resilient server.
• an authoritative DNS server. unbound looks to many other sources, but it isn’t the source of my DNS authority for internal or external networks. This is more of a toss-up than mail, because DNS service is quite small.
• systemd. We’re using sysvinit because it is much smaller, has fewer moving parts, and does not annoy me anywhere near as much.
• daemontools, or a similar service manager. daemontools is great for semi-reliable services, because it will fire them back up again when they terminate. On a firewall, though, I want everything to be so reliable that any premature death is a major pain point that indicates I need to fix it ASAP.