Mastodon Configuration<!-- --> | <!-- -->Ben Pettis
Ben Pettis

Mastodon Configuration

December 15, 2022

A screenshot of green text on a black background in a terminal session. It is displaying current status of the 'mastodon-web.service' systdemd service

Back to Self-Hosted Mastodon Project Description

Now that I (finally) have my web server set up and running, it's time to try and configure it so I can use it as my main Mastodon instance. Right now there is only one account,, and everything is set up with the defaults. I'll want to make some adjustments, and maybe install some extras to get things up and running.

Creating my actual account

First, I get logged in as the admin user and check that everything works as expected. I have all the normal account options, but then all sorts of other Admin options as well - such as controlling Server name, rules, description, etc.

I want to create the account to be my main account here. But I disabled signups by setting SINGLE_USER_MODE=true in the config. I edit .env.production to set that to false and restart the service. Before this, I made sure to require approval for signups through the admin user account. I'll probably disable them entirely (but through the Web interface) unless I'm actively adding an account for myself.

And then I end up in this weird situation where I'm writing an application to be reviewed... by myself.

A screenshot of the Mastodon signup form. In the field for "Why do you want to join?" I have written the response "Of course I know him, he's me"

And now that I have this account created and set up as the owner role, I go ahead and disable signups

For now, I've just done some super simple account setup. Once I know that things are working, I'll set up the alias between the accounts. And possibly even fully redirect from my old one -- but likely only after a lot of testing.

Testing Access from Other Servers

The first thing I did after this was to follow my previous account in hopes that this will start to get my server federating with others. But also I'm not 100% about how that process works.

But it looks like I might not be out of the woods quite yet with my setup woes. When I try to follow from I can't even search for the account, getting the error '503 Remote Data Could Not Be Fetched' and when trying in the Metatext app for iOS, I get the error "Remote SSL certificate could not be verified" - so damn! I wonder if this is because I disabled SSL verification between Apache and Nginx. Maybe I'll need to go back and re-attempt that....

I did an SSL report and things look okay:

Based on some initial googling, and finding this GitHub discussion ( I'm wondering if this has to do with the redirect from to and the /.well-known/ directory needing to be accessible

I test this by trying curl -v and I get back a response, but possibly some problems with the config:

< HTTP/1.1 302 Found
< Date: Thu, 15 Dec 2022 02:44:42 GMT
< Server: Apache/2.4.54 (Debian)
< Location:
< Content-Length: 308
< Content-Type: text/html; charset=iso-8859-1
<title>302 Found</title>
<p>The document has moved <a href="">here</a>.</p>
<address>Apache/2.4.54 (Debian) Server at Port 443</address>
* Connection #0 to host left intact

We're redirecting - so that's good - but to this location:, which obviously isn't a real URL

Checking my Apache config, it looks like I have my RedirectMatch directive after my general redirect. I wonder if this order is screwing things up

Current config:

<VirtualHost *:80>
        # Send requests to (without a subdomain) back to the .com domain
        Redirect /
        RedirectMatch 301 ^/.well-known/webfinger(.*)$1
        RewriteEngine on
        RewriteCond %{SERVER_NAME} [OR]
        RewriteCond %{SERVER_NAME}
        RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

So I tried moving the RedirectMatch line above the Redirect line and then restart Apache.

And now when I search for from I no longer get a 503 error. But I do get zero results. I am still getting a "Remote SSL certificate could not be verified" error in the Metatext app

But when I try curl -v I am still getting that bad URL as the new location:

So I just disabled my other redirect (to to see what happens. Still nothing.

But then I also see that I have my redirect set to match on /.well-known/webfinger but there may be other requests to /.well-known/* that need to get redirected. So I changed my rule: RedirectMatch 301 ^/.well-known/(.*)$1

And now when I try curl -v I get what looks like a more proper redirect:

> GET /.well-known/host-meta HTTP/1.1
> Host:
> User-Agent: curl/7.79.1
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 15 Dec 2022 03:05:37 GMT
< Server: Apache/2.4.54 (Debian)
< Location:
< Content-Length: 332
< Content-Type: text/html; charset=iso-8859-1
<title>301 Moved Permanently</title>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="">here</a>.</p>
<address>Apache/2.4.54 (Debian) Server at Port 443</address>
* Connection #0 to host left intact

Still not able to find my server from but I suspect that may be a bit of a waiting game.

Let's Federate??

I suspect that we're just not federating right now. So I need to do some more research on how to get that set up in an optimal way. Interestingly, in the 'Federation' page of my 'Moderation' tools, I see this info for

If delivering to the domain fails on 7 different days without succeeding, no further delivery attempts will be made unless a delivery from the domain is received. Failed attempt on 1 day. Clear delivery errors Stop delivery

Fediverse relays

Per (, I can use a 'Federation Relay' to help out my smaller server have more exposure to other instances.

From that list, I added to my list of relays. We'll wait and see a while to see if that does anything for us.

I also see that my home feed has been stuck on 'Loading... Your home feed is being prepared!' for a little while now. So it's also possible that things are just a bit slow to get up and running - especially after I only just fixed the /.well-known/ issue

And hey, what do you know? Looks like things are now working again! I think it was the fixes I just did for the /.well-known/ redirect plus a bit of waiting.

Just as a little anecdote - looks like it took 30-45 minutes for activity to federate across servers. It was quite a while after following from my other site before I got the notification for it. This is good information to know.

ElasticSearch - Full Text Search

I followed the instructions as writen at

Wake On Lan

I'm still a bit concerned that the servers may shut down unexpectedly - especially with the power fluctuations I had before. My apartment is wired in a shitty way where basically all the bedrooms are on a single circuit - so that potentially means a lot of power draw... especially when charging my car at the same time.

What I'd like to do is schedule Wake-on-LAN packets to power up my web servers every morning, in case they were shut off. From what I've read, it seems that the Apple Xserve's stock network card supports it. So let's give it a try.

I shut down the server, but not before grabbing the MAC address

On my local machine, I install wakeonlan using homebrew: brew install wakeonlan

And then try wakeonlan <MAC ADDRESS>

And holy shit, it comes to life immediately! That's amazing! So now I just have to install a wakeonlan program on another computer (like a raspberry pi) that is actually behind battery backup, and schedule a cron task to send this magic packet once a day - just to ensure that the server is on.

These are set up on the pi user's crontab on my pihole:

0 1 * * * /usr/bin/wakeonlan <MAC ADDRESS>
15 1 * * * /usr/bin/wakeonlan <MAC ADDRESS>

And I think that should be it! I'm keeping my previous account for a few days before fully migrating. This will give me a chance to verify the overall stability of my setup and to test whether I've overlooked anything crucial

Back to Self-Hosted Mastodon Project Description