Anyone need more fediverse?

2023-01-08T00:00:00Z

I've been running a single user Mastodon instance for a few months now. It's been running smoothly and has let me interact with the exodus of users from the bird site. But it can be lonely on a single user instance. Discovery can be hard, following #hashtags only shows you posts from people you already follow, and you can't easily just browse the public timeline of some of the larger instances. I had read about public relays but that seemed more like a firehose approach with too much content of questionable quality. I wanted something more curated.

Enter GetMoarFediverse

While looking for a solution I stumbled upon GetMoarFediverse by @g3rv4@mastodonte.tech. It utilizes another one of @g3rv4's projects FakeRelay to allow you to follow hashtags, separately from your Mastodon followed hashtags, and automatically import posts.

Running GetMoarFediverse

There are a few different steps, spread across a few containers, to be able to run a fully selfhosted version of GetMoarFediverse. There are several different options on how to run each step but in the spirit of self-hosting my own Mastodon instance, I wanted to run everything myself. The steps are as follows:

Configure and run FakeRelay
Add an authorized instance to FakeRelay
Add FakeRelay to your Mastodon instance
Configure and run GetMoarFediverse
Configure GetMoarFediverse to run on a schedule

Configuring and running FakeRelay

FakeRelay has pretty good documentation in it's README but you have to make sure to follow the guide for I want to run it myself!. I use Traefik as my reverse proxy as well, so my docker-compose.yaml looks like this:

fakerelay:
    image: 'ghcr.io/g3rv4/fakerelay:latest'
    command: web
    hostname: fakerelay
    container_name: fakerelay
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ASPNETCORE_URLS=http://+:5000
      - CONFIG_PATH=/data/config.json
    restart: unless-stopped
    volumes:
      - '/mnt/data/appdata/fakerelay:/data'
    ports:
      - 5000:5000
    labels:
      traefik.http.routers.fakerelay.rule: Host(`fakerelay.alexdobin.com`)
  cli:
    image: 'ghcr.io/g3rv4/fakerelay:latest'
    volumes:
      - '/mnt/data/appdata/fakerelay:/data'
    labels:
      - traefik.enable=false

‼️ Do not immediately run docker-compose up. You need to configure the config.json file first using the cli container! You will want to run the following command to generate a new config.json file:

docker-compose run --rm cli config your-relay-host.example.com

You should now be able to start the main fakerelay container with docker-compose up -d. You should now be able to access the FakeRelay web interface at http://fakerelay.alexdobin.com (or whatever you set your hostname to).

Adding an authorized instance to FakeRelay

You can use the cli container to interact with FakeRelay. FakeRelay can be used with multiple instances and requires authorization for each Mastodon instance you want to use it with. This is easy enough with our single instance, just run the following command:

docker-compose run --rm cli instance add social.alexdobin.com

You will now see an API key for your instance. Copy this to a safe place, you will need it later on to configure GetMoarFediverse.

Adding FakeRelay to your Mastodon instance

Now that we have our FakeRelay instance running and authorized, we need to add it to our Mastodon instance. This is done by navigating to the admin portal on your Mastodon instance (/admin/relays). You will be prompted to add a new relay and should use the configured domain for your fake relay followed by /inbox (e.g. http://fakerelay.alexdobin.com/inbox). After submitting and waiting a few seconds, you should see the status update to Enabled next to your relay.

Configuring and running GetMoarFediverse

There are several options for how to run GetMoarFediverse, including utilizing GitHub actions. Instead we will follow the docker-compose method outlined in the README to keep everything running on our own server. The docker-compose.yaml file looks like this:

  getmoarfediverse:
    container_name: getmoarfediverse
    image: 'ghcr.io/g3rv4/getmoarfediverse:latest'
    volumes:
      - '/mnt/data/appdata/getmoarfediverse:/data'

Before running, you will want to create the configuration file config.json needed for GetMoarFediverse. Below is an example configuration that I have used, placing it in /mnt/data/appdata/getmoarfediverse or wherever you have locate the volume for your container.

{
  "FakeRelayUrl": "https://fakerelay.alexdobin.com",
  "FakeRelayApiKey": "YOUR_API_KEY_HERE",
  "Tags": [
    "javascript",
    "typescript",
    "svelte",
    "sveltekit",
    "100DaysOfHomeLab"
  ],
  "Instances": [
    "hachyderm.io",
    "mastodon.social",
    "fosstodon.org"
  ]
}

You should replace YOUR_API_KEY_HERE with the API key that you received earlier when registering your instance with FakeRelay. There are several options for configuring GetMoarFediverse but for now this has done a good job at bringing in new content that I might want without overwhelming me or my server.

Configuring GetMoarFediverse to run on a schedule

GetMoarFediverse works great when it runs but it does not have any scheduling built in. I am using Chadburn which is a fork of Ofelia with several quality of life fixes. I will cover setting Chadburn up in a separate blog post but adding the below to my Chadburn configuration was all I needed to run it with relative frequency.

[job-run "getmoarfediverse"]
schedule = @every 10m
container = getmoarfediverse

Tailscale hostnames for Pi-hole stats

2022-08-01T00:00:00Z

Update 2025-03-31: This applies to Pi-hole v5.0 and earlier. Pi-hole v6 has changed how configurations are handled and I have not validated that this works with the new version.

Tailscale is a fantastic secure mesh VPN that lets you connect all of your devices to each other, no matter where they are or if you've exposed them publicly to the internet. I use it extensively to use all my homelab services and run it on virtually every server. They have a very generous free tier and hope that enthusiasts enjoy it so much that they bring it to their workplace.

Tailscale publishes a great article on how to use a Pi-hole as the DNS server on your tailnet, allowing you to fully control the DNS of your device no matter what network you are connected to while leveraging their Magic DNS to connect to the other devices on your tailnet. One thing it doesn't cover is how to reenable conditional forwarding for your Pi-hole so that your statistics are not full of your Tailscale assigned 100.x.x.x addresses but instead show the machines hostname.

Conditional forwarding

Pi-hole already supports conditional forwarding but the UI only lets you configure a single local network. If you are like me, you still want to get the statistics for your local network but also would like to get the statics for machines on your tailnet. Luckily, Pi-hole uses dnsmasq and it's easy enough to add our own configuration file to support this use case.

Configuration

Pi-hole will load all configuration files for dnsmasq from /etc/dnsmasq.d/. To support looking up the Tailscale hostnames, we need to add our own configuration file to this directory.

rev-server=100.64.0.0/10,100.100.100.100

The IP address range 100.64.0.0/10 comes from the Tailscale documentation. 100.100.100.100 is the IP address of the local Tailscale DNS server. You will see this address if you have MagicDNS enabled, it will be listed as the DNS server for your tailnet.

Creating a blog

2022-02-21T00:00:00Z

I have been building a homelab for the last few years, mostly to self-host services securely at home without relying on the major cloud providers. I've learned a lot going through the experience and wanted to start sharing some of the knowledge back to the community outside of a few tiny pull requests that I've made. Look for more coming soon!

Alex Dobin's Blog