Mastodon Configuration
December 15, 2022
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, @admin@benpettis.ninja, 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 @bpettis@benpettis.ninja
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.
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 @bpettis@mastsodon.social
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 @bpettis@benpettis.ninja
from @bpettis@mastodon.social
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: https://www.ssllabs.com/ssltest/analyze.html?d=mastodon.benpettis.ninja
Based on some initial googling, and finding this GitHub discussion (https://github.com/mastodon/mastodon/issues/8375) I'm wondering if this has to do with the redirect from benpettis.ninja
to mastodon.benpettis.ninja
and the /.well-known/
directory needing to be accessible
I test this by trying curl -v https://benpettis.ninja/.well-known/host-meta
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: https://benpettis.com.well-known/host-meta
< Content-Length: 308
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://benpettis.com.well-known/host-meta">here</a>.</p>
<hr>
<address>Apache/2.4.54 (Debian) Server at benpettis.ninja Port 443</address>
</body></html>
* Connection #0 to host benpettis.ninja left intact
We're redirecting - so that's good - but to this location: https://benpettis.com.well-known/host-meta
, 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 benpettis.ninja (without a subdomain) back to the .com domain
ServerName benpettis.ninja
ServerAlias www.benpettis.ninja
Redirect / https://benpettis.com
RedirectMatch 301 ^/.well-known/webfinger(.*) https://mastodon.benpettis.ninja/$1
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.benpettis.ninja [OR]
RewriteCond %{SERVER_NAME} =benpettis.ninja
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
So I tried moving the RedirectMatch
line above the Redirect
line and then restart Apache.
And now when I search for @bpettis@benpettis.ninja
from mastodon.social
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 https://benpettis.ninja/.well-known/host-meta
I am still getting that bad URL as the new location: https://benpettis.com.well-known/host-meta
So I just disabled my other redirect (to benpettis.com) 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/(.*) https://mastodon.benpettis.ninja/.well-known/$1
And now when I try curl -v https://benpettis.ninja/.well-known/host-meta
I get what looks like a more proper redirect:
> GET /.well-known/host-meta HTTP/1.1
> Host: benpettis.ninja
> 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: https://mastodon.benpettis.ninja/host-meta
< Content-Length: 332
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://mastodon.benpettis.ninja/host-meta">here</a>.</p>
<hr>
<address>Apache/2.4.54 (Debian) Server at benpettis.ninja Port 443</address>
</body></html>
* Connection #0 to host benpettis.ninja left intact
Still not able to find my server from mastodon.social
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 mastodon.social
:
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 (https://joinfediverse.wiki/index.php?title=Fediverse_relays&mobileaction=toggle_view_desktop), I can use a 'Federation Relay' to help out my smaller server have more exposure to other instances.
From that list, I added https://federation.stream/
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 @bpettis@mastodon.social
from my other benpettis.ninja
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 https://docs.joinmastodon.org/admin/optional/elasticsearch/
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 @bpettis@mastodon.social
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