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
- 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.