I did some home networking! Four years ago. I installed some networking equipment in a closet, ran a bunch of Ethernet cable, and ceiling-mounted a Wi-Fi access point. The closet box looks like this (click pics for a bigger size):

And here’s an annotated version:

But let’s back up a bit…

Why???

Two primary reasons.

The first is that our router was in our living room and I wanted it to be less conspicuous.

The second is that I wanted to run Ethernet cable because I don’t like Wi-Fi. Before this house I lived in semi-dense apartments and condos for fifteen years and sometimes had Wi-Fi problems. Nothing terrible, just an occasional annoyance. Things like Wi-Fi speakers or a Nest camera dropping offline, presumably due to lots of access points using the same limited spectrum (using a phone app to view Wi-Fi networks would show a handful of networks with strong signals).

Also, it’s maybe silly but I still have a Linux desktop computer and it’s nice to not have to spend any effort making Wi-Fi work in Linux.

What About Mesh Networks or Range Extenders?

Mesh networks are all the rage these days. I don’t have experience with them. I suspect they work well. They do use additional bandwidth, though, because data is transmitted over multiple hops. And yeah, hopefully transmitted at lower power and that should reduce interference. But there’s still overall more data transmission.

Basically nothing beats a physical Ethernet connection. And any traffic you can remove from the wireless network will increase the experience of the remaining wireless devices because there’s less contention.

My house has a fairly accessible crawlspace and attic, so running cable isn’t terrible. And I’m planning on living here for a while so it seemed worth the effort.

So What Exactly Did I Do?

The picture above shows a structured media enclosure (or structured media center). It’s a big box that you can mount stuff in. This one is sized to fit between 16″ studs. I cut a big rectangular hole in the drywall in a downstairs closet and screwed it to the studs. I had an electrician wire up two duplex power receptacles. The cabinet contains the fiber to Ethernet media converter (called an optical network terminal), our router, an Ethernet switch, a SmartThings hub, and an Ethernet punch-down block.

I ran our incoming fiber cable to the cabinet and I ran four Cat 6A Ethernet cables from the cabinet to the office and four to the upstairs (TV in bonus room, an access point, and two spares). I luckily found an existing conduit running between the attic and the crawlspace that only had a few coax cables in it. I was able to reuse this for Ethernet cable. I loosely suspended the cable with velcro ties nailed to studs. I drilled holes up through the floor bottom plate or down through the ceiling top plate into the specific stud cavity where I wanted the Ethernet jack. I used Great Stuff fireblock foam to fill the holes after running the cable.

There Were So Many Little Decisions!

Making these decisions took time, research, and planning.

The Structured Media Enclosure Itself

The two big name brands are Leviton and Legrand. There are other brands but it’s harder to find info about them online. I went with Leviton and I don’t remember why. It’s fine. I suspect Legrand is fine, too. Even with Leviton it was hard for me to get a good idea in my head about how well it would work.

One worry I had was about installing the box when we already had drywall in place. The box comes with tabs that stick out on the sides and you’re supposed to screw them straight into studs before installing drywall (so the tabs go behind the drywall). But eventually I found one of their YouTube videos that demonstrates scoring the tabs with a knife and snapping them off, then screwing into the studs through the sides of the box. This allows the box to sit at the right depth in the wall. So that’s great. Though I wish this info was easier to find. Pet peeve: YouTube how-to videos that could have been a text article with images.

Another worry I had was how to attach things in the box. Both Leviton and Legrand sell mounting brackets and in both cases the mounting brackets are quite expensive for what they are. Like $20 or $30 each, for a little plastic or metal bracket. They’re pretty basic so their profit margin is likely high for these things. It’s kinda justified in that their sales volume is probably low and they have to recoup their development cost and overhead… but it’s still a hard pill to swallow. Here are Leviton’s mounting options.

I got kind of a gigantic box—42″ tall. It seemed bigger than I needed but also I had room for it and I thought the extra space might come in handy. This was a good choice! I found it hard to arrange things compactly. Partially because I tried hard to keep it tidy and tried to keep power cables separated from Ethernet. But also it was just hard to mount things side by side. The flexibility of Legrand’s universal mounting plate might be nice here. But I still have a decent amount of space and I could cram more stuff in there if I wanted.

Putting the SmartThings hub in the closet isn’t great for reception but it seems to mostly work fine. Maybe because I have a Z-Wave range extender/repeater plugged into an outlet outside the closet (Aeotec Range Extender 7, possibly discontinued). I did at least get the enclosure that’s made out of plastic instead of metal.

Ethernet Cable

There’s like a billion different kinds of Ethernet cables. I went with Cat 6A, which seems to offer the most bandwidth while still being a widespread standard. I went with plain old unshielded twisted pair (UTP) because foil shielding seemed unnecessary for my use case. I wanted to use pre-terminated cables because terminating is a pain and I was worried it would be less reliable if I did it myself. But I ended up buying unterminated cable on a spool because the longest terminated Cat 6A cable I could find was 100ft and I estimated that I needed a cable longer than that for the TV. Plus it was hard to estimate accurately and therefore hard to know what lengths to buy. The spool was solid core, which is what I wanted. I suspect most spools are solid core, since spools are probably mostly used for permanent installations. My worries were unnecessary—terminating wasn’t too bad and I think I was able to do a good job. And pulling the connectors+boots of pre-terminated cable through my conduit would have been harder.

I bought “riser-rated” (“CMR”) cable, but any cable rated for in-wall use is fine: CM, CL, CMR, or CMP. I think this page gives a good enough explanation while still being brief.

I chose a blue sheath because in my mind blue gives the biggest hint that “this is data” or “this is Ethernet.” But maybe that’s just me.

Connectors, Faceplates, and Boxes

And that lead to the decision to use a punch-down block and punch-down wall connectors rather than terminating with an RJ45 connector and plugging directly into a switch or into a pass-through wall connector. It seemed like the more professional route and I’m happy with these decisions. Here’s what the punch-down block looks like from the front:

To access the back, where the cables attach, you unhook the punch-down block from the structured media enclosure and turn it over.

For wall connections I went with keystone faceplates. The alternatives are Decora/decorator faceplates or faceplates with fixed Ethernet ports, but keystone seems like the most common, I like the way they look, and I like the ability to mix and match connections. It was hard to find keystone jacks marketed as Cat 6A. And actually I think my punch-down block is only marketed as Cat 6. I think the “A” in “6A” probably does make a difference for the cable in long cable runs, but in practice I suspect it matters much less for the jacks. Also even Cat 6 is overkill for my needs. But, you know, if you’re going through the effort to put cable in walls then you should use the best cable.

The second photo is behind the TV and the third photo is behind the stereo receiver below the TV. The HDMI connection runs between them. The coax behind the TV connects to an attic-mounted HDTV antenna. The coax behind the receiver connects to an attic-mounted FM radio antenna.

I used low voltage mounting brackets on interior walls. I used a normal electrical box on the one exterior wall to give some separation from the insulation.

Router

For networking gear I chose to use my own router rather than the one from my ISP because I’m wary of router firmware. I worry that router manufacturers aren’t careful enough and their firmware can be buggy and hackable. We have Google Fiber and I’d guess that Google’s router firmware is above average, but I still thought I could do better. Ubiquiti and Meraki (owned by Cisco) are companies that give me an impression of a high level of security. Maybe Aruba, too. I went with Ubiquiti because it was the personal and professional choice of some smart former coworkers.

Narrowing down which Ubiquiti devices took some time. I went with a UniFi Security Gateway. Configuration takes more work than with more mainstream consumer-focused routers. Those routers typically host the admin website directly on the router. With UniFi the management website is a separate thing. UniFi sells a separate hardware device called a Cloud Key that’s basically a mini computer that hosts the admin website, but that’s one more thing to cram into the structured media enclosure and also it’s $179. Another option is to use a hosted solution, but it seems ridiculous for me to pay $15 or $30 per month for my home network. And using a hosted solution is inherently less secure. Instead I opted to run the configuration service on my own hardware. At first I ran it natively on my Apple laptop but I’ve since switched to running it in a Docker container on my Linux desktop. I wrote up the steps on Super User if you want more info.

It’s been a few years since I did all this work and nowadays there might be better options. For example I think Ubiquiti sells some gateways that include the admin website. The Dream Router and Dream Machine both look like good options if you’re not trying to mount it in a structured media enclosure. And the Dream Machine Pro and Dream Machine Special Edition might be good if you’re mounting in a rack. More info here and here.

Network Configuration

Unfi allows configuration of multiple logical networks, and UniFi access points can act as multiple SSIDs simultaneously. I take advantage of this by having one network where devices are allowed to talk to each other (e.g. our computers and printer) and another, “untrusted” network where devices are not permitted to talk to each other. I love this. I relegate things like my thermostate and car to this network. They don’t need to talk to anything else on my network and having them isolated means they’re not an attack vector into my personal computers.

Access Points

Another decision was how many access points and where to put them. This depends entirely on the layout of the house and my solution isn’t great. Our house has a big open room in the middle with a hall/balcony/catwalk upstairs that’s open to the downstairs. I ended up putting one access point in the middle of this hall and it’s probably sufficient to cover the whole house. I also put an access point in the office with the intent of improving reception for the nearby rooms, which have some walls between them and the upstairs hall access point. But this second access point is probably excessive.

A note about access point placement: It’s better to put them in the middleish rather than at the extreme ends because signal degrades quickly over distance. See this Ars Technica article for more.

I wish Ubiquiti had a smaller product lineup. When I purchased my APs years ago there were thirteen different access points to choose from! That’s not counting mesh or APs that mount to a 1 gang wall box. It was hard to decide between them. It’s down to eight now, apparently, but I still have a hard time believing there are justifiable differences between all of them.

Mounting the AP to the ceiling was hard and I’m not completely satisfied with the solution. See “Mistakes/Learnings” below for more detail.

Switch

UniFi access points are powered with PoE (Power over Ethernet). That’s kind of nice and easy, but it meant I needed a switch that is capable of supplying power over ethernet. I bought a non-Ubiquiti, unmanaged PoE switch. It’s fine but I wish I had spent more money and gotten a single, bigger, managed PoE switch from Ubiquiti. See “Mistakes/Learnings” below for why.

Mistakes/Learnings

• I should have bought a single, bigger, managed, PoE switch for the structured media enclosure. Or maybe a smaller PoE switch but a bigger managed switch? Using a managed switch would allow putting hard-wired Ethernet devices on the untrusted network. This is nice for IoT (Internet of Things) devices that might be poorly written (e.g. a TV) and a potential attack vector for people to gain access to your home network. And a single switch would have made the enclosure less cluttered.
• I maybe should have used a rectangular wall box for the ceiling-mounted access point. I used a round old-work ceiling box. My impression is round boxes are the standard for electrical (lights) in ceilings. It seemed like a natural choice to me since access points are round. Putting a rectangular box in the ceiling felt wrong (though I’ve since realized that rectangular boxes might be more common than round boxes for smoke detectors). But for whatever reason it seems like Ubiquiti doesn’t expect round boxes to be used. They sell an access point mounting bracket but it doesn’t support attaching to a round ceiling box. Another problem is that the nanoHD AP is so small that you can see the blue edges of the ceiling box. I don’t remember exactly how I solved this problem, but I think it involved attaching the AP’s included mounting bracket to a blank cover for the round box and cutting a hole in both to be able to feed the Ethernet cable through. The cleanest fix for this problem is probably to replace the round box with a small rectangular box. That’s a significant amount of effort since it requires drywall repair.
• I should have bought surge receptacles with USB outlets for the structured media enclosure. I could have avoided a separate power adapter for the Google fiber⇔Ethernet converter.
• I accidentally cut into the drywall a little bit where a stud was when trying to place a box in the office for Ethernet jacks.
• I overestimated how much Ethernet I would need and also made my lengths too long. Also maybe the fiber cable.
• I used pestblock Great Stuff Foam to seal one or two of the holes I drilled for running cables. I should have used fireblock for all of them. I don’t know if Fireblock is required by code, but it’s something I worried about later. I mean, it basically doesn’t matter, but if you’re picking one I’d go with Fireblock.
• When cutting holes for old work boxes, make the hole on the small side. It’s easy to make it bigger but hard to make it smaller.

Full Product List

• Leviton 49605-42P – 42″ Wireless Structured Media Enclosure with Vented Hinged Door, Plastic, White
• Leviton 49605-42T – Trim Ring Accessory for 42″ Structured Media Center, Plastic, White. This is a fascia that covers the gap between the outside of the enclosure and the drywall.
• Leviton 49605-GRM – Grommet Accessory Pack for Structured Media Centers, includes (3) 1″ and (2) 2″ rubber grommets. Works with all enclosure knockouts. I think the enclosure doesn’t come with these&mbdash;they must be purchased separately.
• Leviton 49605-AFR – Cable Routing Ring with (2) Push Pins. For coiling fiber. This thing is great.
• Leviton 47605-ACS – J-Box Surge Protective Kit (one duplex blue receptacle). Two of these mounted in the bottom of the enclosure. I had an electrician wire them into an existing circuit.
• Leviton 47612-DBK – Data Plastic Bracket. These are the main brackets I used for mounting devices. Mostly the mounting holes on the backs of things lined up with the holes in these brackets. I did have to drill holes in one of the brackets for one of the devices. And I had to find some screws and nuts and a local hardware store that were an appropriate size.
• Leviton 47612-UBK – Universal Shelf Bracket used with Structured Media Center (discontinued). The SmartThings hub is sitting on this. Leviton sells a plastic shelf that could serve the same purpose.
• Leviton 49605-AST – Saddle Tie Kit with VELCRO®, includes (5) Saddle Ties, 5′ of VELCRO® SoftCinch, Black. I think I used these to strap down power adapters. They’re convenient but look messy.
• Leviton 47615-NYL – Push-Lock Pins for Structured Media Centers (Bag of 20). Because I broke one of the ones that came with a mounting bracket.
• Monoprice Entegrade Series 1000FT Cat6A Plus 650MHz UTP Solid, Riser-Rated (CMR), 23AWG, Bulk Bare Copper Ethernet Network Cable, 10G, Blue – Ethernet cable. 1,000 ft was more than I needed, but 500 ft probably would not have been enough. But it did allow me to be generous with my cable lengths in case anyone ever wants to move them, and I still have some cable left over.
• Monoprice product #7013 – 1-Gang Low Voltage Mounting Bracket
• Monoprice product #6727 – Wall Plate for Keystone, 2 Hole – White
• Monoprice product #6729 – Wall Plate for Keystone, 3 Hole – White
• Monoprice ethernet patch cables – I bought a bunch of these, mostly for the enclosure. Also some white cables for the office because I didn’t have any and they look nice. I bought “Cat6A Ethernet Patch Cable – Snagless RJ45, 550Mhz, STP, Pure Bare Copper Wire, 10G, 26AWG” which appear to be discontinued. STP wasn’t important… I think maybe the only UTP cable they had was “slim” and I wanted to avoid that because it sounds worse.
• Ubiquiti Unifi Security Gateway (USG) – Discontinued. Maybe the Gateway Lite is the spiritual successor to the USG? I’m not sure how similar they are, or if the Gateway Lite has notches on the back for wall-mounting.
• Ubiquiti UAP-nanoHD – UniFi nanoHD access point
• Netgear GS108PP – 8-Port Gigabit Ethernet Unmanaged PoE Switch

I’ve started using Mastodon. It’s an open alternative to Twitter. “Open” meaning there’s no central controlling entity. Tech-savvy people can run their own server and servers can talk to each other (referred to as federation). If you’re interested in joining you can find a server to join, sign up, and follow me: @mark@kingant.net.

Why???

Part of me has always disliked posting on Facebook and Twitter. They’re walled gardens. I’d rather self host. I like keeping a record of my posts. Twitter allows downloading an archive of your posts and Facebook might, too, but I’d rather control the system of record myself. Also I don’t love being used by a company so they can make money from ads. Wise man once say, “when you’re not paying for the product you are the product.”

And then Elon Musk being a jerk¹ drove me to make a change.

The open/federated nature is appealing to me. It’s similar to how email works. And XMPP.

ActivityPub

ActivityPub is the important thing. There are other ActivityPub services that aren’t Mastodon. For example Pixelfed (an Instagram clone) and PeerTube (which is tailored for video sharing). It’s possible for them to be written such that they can interact with each other. For example on Mastodon I can follow a Pixelfed user. It’s great.

And actually I think it’s weird that these services are treated as separate things. Mastodon is just an ActivityPub service that looks like Twitter and Pixelfed is just an ActivityPub service that looks like Instagram. I’m not even sure the functionality is very different. It makes me wonder if they could be written as different UIs atop a common server. But whatever, I’m not super familiar with it. Maybe there are good reasons for them to be separate.

Running My Own Server

And because I’m a huge nerd I’m running my own server. I did it partially as a learning exercise. But also now my ID can be my email address (“@mark@kingant.net“) instead of something like “@markdoliner@someone-elses-server.example.com”

It took some work. The developers haven’t prioritized ease of installation (which is perfectly reasonable). It runs as two processes: The web/API service and a background job queue worker. It also requires PostgreSQL and Redis. As mentioned previously, I use Salt to manage my cloud servers. Initially I tried running everything directly on an EC2 instance, but Mastodon is written in Ruby and installing and managing Ruby and building Mastodon via Salt rules is a lot of work.

There are official Docker images so I looked into that instead. The docker-compose.yml file was immensely helpful. At first I tried running containers in Amazon Elastic Container Service (ECS). But configuring it is way more elaborate than you would imagine. And I’m not sure but it might have required paying for separate EC2 instances per container, though maybe it’s possible to avoid that if you go a step further and use Amazon Elastic Kubernetes Service (EKS). But of course that’s even more effort to configure.

What I did instead is run the containers myself on a single EC2 instance. Three containers, specifically: web/API, background job queue worker, and Redis. I’m running PostgreSQL directly on the host because it’s super easy. Obviously I could have used RDS for PostgreSQL and that’s certainly a nice managed option, but it’s also more expensive. I wanted to run Redis on the host but it’s hard to configure it to allow access from the Mastodon containers but disallow access from outside networks. Though even with PostgreSQL I ended up configuring it to accept connections from the world (disallowed via AWS security group of course, and PostgreSQL is configured such that users can only authenticate from localhost or the Docker network). So this feels like a decent compromise. The maintenance overhead is manageable and it’s fairly cheap. I’m paying around $3 to $4 per month ($83 up front for a t4g.micro 3 year reservation plus $1 to $2 per month for EBS storage).

I don’t want to make my Salt config repo public but here are the states for the Docker containers in case it helps anyone:

include:
  - mastodon/docker
  - mastodon/user

# A Docker network for containers to access the world.
mastodon_external:
  docker_network.present:
    - require:
      - sls: mastodon/docker

# A Docker network for intra-container communication.
mastodon_internal:
  docker_network.present:
    - internal: True
    - require:
      - sls: mastodon/docker

# Create directory for Mastodon. We leave ownership as the default
# (root) because the mastodon user shouldn't need to create files here
# and using root is a little more restrictive. It prevents the Mastodon
# processes (running in Docker as the mastodon user) from causing
# mischief (e.g. modifying the static web files, for example).
/srv/mastodon.kingant.net:
  file.directory: []

# Create private directory for Mastodon Redis data.
/srv/mastodon.kingant.net/redis:
  file.directory:
    - user: mastodon
    - group: mastodon
    - mode: 700
    - require:
      - sls: mastodon/user

# Redis Docker container.
# We're running it as a Docker container rather than on the host mostly
# because we would need to change the host Redis's config to bind to the
# Docker network IP (by default it only binds to localhost) and that
# requires modifying the config file from the package (there is no
# conf.d directory). That means we would stop getting automatic config
# file updates on new package versions, which is unfortunate.
# Of course if we ever want to change any other config setting then
# we'll have the same problem with the Docker contain. Though it's maybe
# still slightly cleaner having Redis accessible only over the
# mastodon_internal network, because Redis isn't big on data isolation.
# The options are:
# 1. Use "namespaces." Meaning "prefix your keys with a namespace string
#    of your choice, maybe with a trailing  colon."
# 2. Use a single server but have different apps use different DBs
#    within Redis. This is a thing... but seems problematic because
#    the DBs are numbered sequentially so what happens if you remove one
#    in the middle?
# 3. Use separate servers. This probably makes the most sense (and
#    provides the strongest isolation).
redis:
  docker_container.running:
    - image: redis:7-alpine
    - binds:
      - /srv/mastodon.kingant.net/redis:/data:rw
    # Having a healthcheck isn't important for Redis but it existed in
    # Mastodon's example docker-compose file so I included it here. The
    # times are in nanoseconds (currently 5 seconds).
    - healthcheck: {test: ["CMD", "redis-cli", "ping"], retries=10}
    - networks:
      - mastodon_internal
    - restart_policy: always
    # The UID and GID are hardcoded here and in user.present in
    # mastodon/user.sls because it's really hard to look them up. See
    # https://github.com/saltstack/salt/issues/63287#issuecomment-1377500491
    - user: 991:991
    - require:
      - sls: mastodon/docker
      - sls: mastodon/user
      - docker_network: mastodon_internal
      - file: /srv/mastodon.kingant.net/redis

# Create directory for Mastodon config file.
/srv/mastodon.kingant.net/config:
  file.directory: []

# Install the Mastodon config file. It's just a bunch of environment
# variables that get mounted in Docker containers and then sourced.
# Note: Secrets must be added to this file by hand. See the "solution
# for storing secrets" comment in TODO.md.
/srv/mastodon.kingant.net/config/env_vars:
  file.managed:
    - source: salt://mastodon/files/srv/mastodon.kingant.net/config/env_vars
    - user: mastodon
    - group: mastodon
    - mode: 600
    # Do not modify the file if it already exists. This allows Salt to
    # create the initial version of the file while being careful not to
    # overwrite it once the secrets have been added.
    - replace: False
    - require:
      - file: /srv/mastodon.kingant.net/config

# Docker container for Mastodon web.
mastodon-web:
  docker_container.running:
    - image: ghcr.io/mastodon/mastodon:v4.1
    - command: bash -c "set -o allexport && source /etc/opt/mastodon/env_vars && set +o allexport && rm -f /mastodon/tmp/pids/server.pid && bundle exec rails s -p 3000"
    - binds:
      - /srv/mastodon.kingant.net/config:/etc/opt/mastodon:ro
      - /srv/mastodon.kingant.net/www/system:/opt/mastodon/public/system:rw
    - extra_hosts:
      - host.docker.internal:host-gateway
    - healthcheck: {test: ["CMD-SHELL", "wget -q --spider --proxy=off http://localhost:3000/health || exit 1"], retries=10}
    - networks:
      - mastodon_external
      - mastodon_internal
    - port_bindings:
      - 3000:3000
    - restart_policy: always
    - skip_translate: extra_hosts # Because Salt was complaining that "host-gateway" wasn't a valid IP.
    - user: 991:991
    - require:
      - sls: mastodon/docker
      - sls: mastodon/user
      - docker_network: mastodon_external
      - docker_network: mastodon_internal
      - file: /srv/mastodon.kingant.net/config/env_vars
    - watch:
      - file: /srv/mastodon.kingant.net/config/env_vars

# Docker container for Mastodon streaming.
mastodon-streaming:
  docker_container.running:
    - image: ghcr.io/mastodon/mastodon:v4.1
    - command: bash -c "set -o allexport && source /etc/opt/mastodon/env_vars && set +o allexport && node ./streaming"
    - binds:
      - /srv/mastodon.kingant.net/config:/etc/opt/mastodon:ro
    - extra_hosts:
      - host.docker.internal:host-gateway
    - healthcheck: {test: ["CMD-SHELL", "wget -q --spider --proxy=off http://localhost:4000/api/v1/streaming/health || exit 1"], retries=10}
    - networks:
      - mastodon_external
      - mastodon_internal
    - port_bindings:
      - 4000:4000
    - restart_policy: always
    - skip_translate: extra_hosts # Because Salt was complaining that "host-gateway" wasn't a valid IP.
    - user: 991:991
    - require:
      - sls: mastodon/docker
      - sls: mastodon/user
      - docker_network: mastodon_external
      - docker_network: mastodon_internal
      - file: /srv/mastodon.kingant.net/config/env_vars
    - watch:
      - file: /srv/mastodon.kingant.net/config/env_vars

# Docker container for Mastodon sidekiq.
mastodon-sidekiq:
  docker_container.running:
    - image: ghcr.io/mastodon/mastodon:v4.1
    - command: bash -c "set -o allexport && source /etc/opt/mastodon/env_vars && set +o allexport && bundle exec sidekiq"
    - binds:
      - /srv/mastodon.kingant.net/config:/etc/opt/mastodon:ro
      - /srv/mastodon.kingant.net/www/system:/opt/mastodon/public/system:rw
    - extra_hosts:
      - host.docker.internal:host-gateway
    - healthcheck: {test: ["CMD-SHELL", "ps aux | grep '[s]idekiq\ 6' || false"], retries=10}
    - networks:
      - mastodon_external
      - mastodon_internal
    - restart_policy: always
    - skip_translate: extra_hosts # Because Salt was complaining that "host-gateway" wasn't a valid IP.
    - user: 991:991
    - require:
      - sls: mastodon/docker
      - sls: mastodon/user
      - docker_network: mastodon_external
      - docker_network: mastodon_internal
      - file: /srv/mastodon.kingant.net/config/env_vars
    - watch:
      - file: /srv/mastodon.kingant.net/config/env_vars

Future Thoughts

I’d love to see more providers offering ActivityPub-as-a-service. There are some already, but they’re a bit pricey. And it feels like an immature product space. I could see companies wanting to use their own domain for their support and marketing accounts. e.g. “@support@delta.com” instead of something like “@deltasupport@mastodon.social”

I’d love to see a lighter-weight alternative to Mastodon that is targeted toward small installations like me. Like removing Redis as a requirement. Maybe getting rid of on-disk storage of files and just using the DB. Doing a better job of automatically cleaning up old, cached meda. Maybe this is Pleroma. Or maybe one of the other options.

Apparently I haven’t posted this anywhere so I just want to go on record: Let’s Encrypt is amazing and fantastic. In five years the percentage of web pages loaded by Firefox using HTTPS went from 30% to 80%. That’s huge! A really impressive accomplishment¹. And ACME, the protocol for validating domain ownership, is also great. A massive improvement over the old process of getting certificates. And all those certificates are only valid for 90 days, instead of the old standard of a year or more! So good.

A Quibble

I don’t like how Certbot is configured. To keep things in perspective let me say that this is just a minor usability complaint. It doesn’t stop Let’s Encrypt from being fantastic.

Certbot is a tool for obtaining certificates from Let’s Encrypt for https and other services. The configuration file is written automatically when the certbot command is run. Users are discouraged² from modifying the configuration file directly. I can’t recall any other tool with this behavior. I don’t get it. Like, why? Sysadmins are used to writing config files, why is it important for this to be different? Maybe it’s supposed to be easier for users? But is it?

I guess usually this behavior is fine and not a problem. I find it inconvenient because I manage my two cloud servers using Salt (a configuration-as-code tool). It’s easy to place a config file on the server and apply changes to it. But since that’s discouraged I settled on running the certbot command but only if the config file does not exist. This is what I did, in case it helps anyone:

{% macro configure_certbot(primary_domain, additional_domains = none, require_file = none) %}
{#
  @param require_file We use Certbot's "webroot" authentication plugin.
         Certbot puts a file in our web server's root directory. This
         means we need a working web server. This parameter should be a
         Salt state that ensures Nginx is up and running for this
         domain.
#}
{# Don't attempt this in VirtualBox because it will always fail. #}
{% if grains['virtual'] != 'VirtualBox' %}
run-certbot-{{ primary_domain }}:
  cmd.run:
    - name: "certbot certonly
        --non-interactive
        --quiet
        --agree-tos
        --email mark@kingant.net
        --no-eff-email
        --webroot
        --webroot-path /srv/{{ primary_domain }}/www
        --domains {{ primary_domain }}{{ ',' if additional_domains else '' }}{{ additional_domains|join(',') if additional_domains else '' }}
        --deploy-hook 'install --owner=root     --group=root     --mode=444 --preserve-timestamps ${RENEWED_LINEAGE}/fullchain.pem /etc/nginx/{{ primary_domain }}_cert.pem &&
                       install --owner=www-data --group=www-data --mode=400 --preserve-timestamps ${RENEWED_LINEAGE}/privkey.pem   /etc/nginx/{{ primary_domain }}_cert.key &&
                       service nginx reload'"
    # Certbot saves the above arguments into a conf file and
    # automatically renews the certificate as needed so we only need to
    # run this command once. This would need to be done differently if
    # we ever want to change the renewal config via Salt. The Certbot
    # docs[1] describe using --force-renewal to force the renewal conf
    # file to be updated. So we could figure out a way to do that once
    # via Salt. Or we could manage the renewal conf file directly via
    # Salt.
    #
    # [1] https://eff-certbot.readthedocs.io/en/stable/using.html#modifying-the-renewal-configuration-of-existing-certificates
    - unless:
      - fun: file.file_exists
        path: /etc/letsencrypt/renewal/{{ primary_domain }}.conf
    - require:
      - pkg: certbot
      - file: {{ require_file }}
{% endif %}
{% endmacro %}

{{ configure_certbot('kingant.net', additional_domains=['www.kingant.net'], require_file='/etc/nginx/sites-enabled/kingant.net') }}

It’s a bit messy and I don’t know what I’ll do when I need to change the config. If you want certbot to update the config file you have to use --force-renewal, but I certainly wouldn’t want to do that every time I apply my configuration state to my servers. I think I’ll have to either run certbot --force-renewal by hand (fine, but loses the benefits of configuration-as-code), or have Salt manage the config file (discouraged by the official docs). Either option is fine, it just feels like a dumb problem to have.

I’m not the only one who has been inconvenienced by this. A quick search turned up this question thread and this feature request ticket.

Anyway, but Let’s Encrypt really is fantastic! This one usability complaint for my atypical usage pattern is super minor.