It looks like Slackware 14.2 is starting to show its age when it comes to supporting Chromium. The packages that I uploaded earlier this week for Chromium (also -ungoogled) version 109.0.5414.74 failed to run on Slackware 14.2 despite the fact that they were successfully compiled on Slackware 14.2. The packages ran without complaint on Slackware 15.0 and -current however.
The cause was a run-time dependency on libdrm for which the minimum version requirement was increased in Chromium 109 and Slackware 14.2 contains a libdrm library that is now too old.
After finding that root cause, I have rebuilt the chromium (also -ungoogled) packages, this time using an internal copy of libdrm instead of relying on the system libraries. The BUILD=2 version of these packages is now available for download from my repository and its mirrors, they are working correctly on Slackware 14.2 again.
For some time now, the slakfinder.org website has been offline. The domain still exists, but the web site just does not respond. Matteo Rossini (zerouno) needed a break from computers, so it is likely that the site won’t return on short notice.
The effect of the site’s unavailability becomes quite obvious if you use the slackpkg+ extension for slackpkg to manage the packages you installed from 3rd-party community repositories. The “/etc/slackpkg/slackpkgplus.conf” configuration file contains these lines:
?# use this to keep the slackpkg+ package updated to the latest stable release
… and that causes a problem every time you run “slackpkg update“. There will be a timeout querying slakfinder.org and a subsequent error. After that, slackpkg will function as usual, you just won’t be able to check on updates for slackpkg+. But the error is annoying.
Luckily I am mirroring the repository for a long while now, so this is easy to fix. Replace the MIRRORPLUS URL above with the following line and run a “slackpkg update“, which will solve the timeout issue:
Now, slakfinder.org fulfilled another role!
It hosted a web-based Slackware package search tool. That may actually have been used a lot more than the slackpkg+ repository.
Unfortunately there has never been another instance of that package searcher available online, and the only thing I could dig up is a 10-year old Git repository archive for its code at https://github.com/mrossini/slakfinder . The code does not work with PHP 7, it has no documentation and the sparse comments in the code are mostly in Italian. It’s greek to me 😉
I thought, “a nice weekend project” and I spent the last few days understanding and then fixing the code. I looked at the repositories that it searched (the Internet Archive luckily created a snapshot early December 2022, right before the site disappeared) and decided to prune that repository collection to just the ones that support Slackware 14.2 and newer, and are known to me. That still leaves 62 repositories.
Today I am opening a custom instance of slakfinder on slackware.nl which will hopefully prevent new downtime. Get a look at it here: https://slackware.nl/slakfinder/ .
I haven’t tested the Guest Book, feel free to leave your comments there as well as in the comments section below. Commenting here on the blog will give you a much higher probability of me answering.
If there’s repositories (Slackware-compatible and for Slackware 14.2 or newer) that you want me to add, let me know.
Someone recently contacted me with the request to base Slackware Live DAW edition on a stable Slackware release like 15.0 instead of using Slackware -current. The rationale being that it would bring relative peace of mind not having to worry about daily updates and potential sudden breakage of your audio applications.
Instead you would only have to worry about applying security updates and as a result have a solid DAW experience.
I think that is a fair question and I have nothing against that switch. The DAW variant is a specialist variant unlike the others.
So, anyone against such a move for the Live DAW ISO, from -current to stable Slackware?
I have a fresh DAW Live ISO ready, it is based on Slackware64-15.0 and will upload that in a short while unless there is some serious ground not to do this.
Naturally, all other Slackware Live variants for which I provide downloadable ISO images, will remain based on Slackware -current.
It has been a while since I wrote an episode for my series about using Slackware as your private/personal ‘cloud server’. Time for something new!
Since a lot of people these days are looking for alternatives to Twitter and Mastodon is a popular choice, I thought it would be worthwhile to document the process of setting up your own Mastodon server. It can be a platform just for you, or you can invite friends and family, or open it up to the world. Your choice. The server you’ll learn to setup by reading this article uses the same Identity Provider (Keycloak) which is also used by all the other services I wrote about in the scope of this series. I.e. a private server using single sign-on for your own family/friends/community.
Check out the list below which shows past, present and future episodes in the series, if the article has already been written you’ll be able to click on the subject.
The first episode also contains an introduction with some more detail about what you can expect.
Episode 7 (this article): Decentralized Social Media Setting up Mastodon as an open source alternative to the Twitter social media platform.
What is decentralized social media
Mastodon server setup
Prepare the Docker side
Define your unique setup
Configure your host for email delivery
Download required Docker images
Create a mastodon role in Postgres
Mastodon initial setup
Tuning and tweaking your new server
Command-line server management
Connect your Mastodon instance to the Fediverse
Mastodon Single Sign On using Keycloak
Adding Mastodon client to Keycloak
Adding OIDC configuration to Mastodon’s Docker definition
Food for thought
Start Mastodon with SSO
Apache reverse proxy configuration
Episode X: Docker Registry
Twitter alternatives seem to be in high demand these days. It’s time to provide the users of your Slackware Cloud services with an fully Open Source social media platform that allows for better local control and integrates with other servers around the globe. It’s time for Mastodon.
This article is not meant to educate you on how to migrate away from Twitter as a user. I wrote a separate blog about that. Here we are going to look at setting up a Mastodon server instance, connecting this server to the rest of the Mastodon federated network, and then invite the users of your server to hop on and start following and interacting with the people they may already know from Twitter.
Setting up Mastodon is not trivial. The server consists of several services that work together, sharing data safely using secrets. This is an ideal case for Docker Compose and in fact, Mastodon’s github already contains a “docker-compose.yml” file which is pretty usable as a starting point.
Our Mastodon server will run as a set of microservices: a Postgres database, a Redis cache, and three separate instances of Tootsuite (the Mastodon code) acting as the web front-end for serving the user interface, a streaming server to deliver updates to users in real-time, and a background processing service to which the web service offloads a lot of its requests in order to deliver a snappy user interface.
These services can be scaled up in case the number of users grows, but for the sake of this article, we are going to assume that your audience is several tens or hundreds of users max.
Mastodon documentation is high-quality and includes instructions on how to setup your own server. Those pages discuss the security measures you would have to take, such as disabling password login, activating a firewall, using fail2ban to monitor for break-ins and act timely on those attempts.
The hardware requirements for setting up your own Mastodon server from scratch are well-documented. Assume that your Mastodon instance will consume 2 to 4 GB of RAM and several 10’s of GB disk space to cache the media that is shown in your users’ news feed. You can configure the expiry time of cached data to keep the local storage need manageable. You can opt for S3 cloud storage if you have the money and don’t want to run the risk of running out of disk space.
What is decentralized social media
Let’s first have a look at its opposite: Twitter. The Twitter microblogging platform presents itself as a easy-to-use website where you can write short texts and with the press of a key, share your thoughts with all the other users of Twitter. Your posts (tweets) will be seen by people who follow you, and if those persons reply to you or like your post, their followers will see your post in their timeline.
I highlighted several bits of social media terminology in italics. It’s the glue that connects all users of the platform. But there is more. Twitter runs algorithms that analyze your tweeting and liking behavior. Based on on the behavioral profile they compile of you these algorithms will slowly start feeding other people’s posts into your timeline that have relevance to the subjects you showed your interest in. Historically this has been the cause of “social media bubbles” where you are unwittingly sucked into a downward spiral with increasingly narrow focus. People become less willing to accept other people’s views and eventually radicalize. Facebook is another social media platform with similar traps.
All this is not describing a place where I feel comfortable. So what are the alternatives?
You could of course just decide to quit social media completely, but you would miss out on a good amount of serious conversation. There’s a variety of open source implementations of distributed or federated networks. For instance Diaspora is a distributed social media platform that exists since 2010 and GNU Social since 2008 even. Pleroma is similar to Mastodon in that both use the ActivityPub W3C protocol and therefore are easily connected. But I’ll focus on Mastodon. The Mastodon network is federated, meaning that it consists of many independently hosted server instances that are all interconnected and share data with each other in real-time. Compare this to a distributed network which does not have any identifiable center (Bittorrent for instance).
The Mastodon project was created back in 2016 by a German developer because he was fed up with Twitter and thought he could do better. Mastodon started gaining real traction in April 2022 when Musk announced he wanted to buy Twitter. Since completing this deal, here has been a steady exodus of frustrated Twitter users. This resulted in a tremendous increase of new Mastodon users, its user base increasing with 50,000 per day on average.
As a Twitter migrant, the first thing you need to decide on is: on which Mastodon server should I create my account? See, that is perhaps the biggest conceptual difference with Twitter where you just have an account, period. On Mastodon, you have an account on a server. On Twitter I am @erichameleers. But on Mastodon I am @firstname.lastname@example.org but I can just as well be @email@example.com ! Same person, different accounts. Now this is not efficient of course, but it shows that you can move from one server to another server, and your ‘handle’ will change accordingly since the servername is part of it.
As a Mastodon server administrator, you will have to think about the environment you want to provide to its future users. Will you define a set of house rules? Will you allow anyone to sign up or do you want to control who ‘lives’ in your server? Ideally you want people to pick your server, create an account, feel fine, and never move on to another server instance. But the strength of open source is also a weakness: when you become the server administrator, you assume responsibility for an unhampered user experience. You need to monitor your server health and monitor/moderate the content that is shared by its users. You need to keep it connected to the network of federated servers. You might have to pay for hosting, data traffic and storage. Are you prepared to do this for a long time? If so, will you be asking your users for monetary support (donations or otherwise)?
Think before you do.
And this is how you do it.
This section describes the technical details of our setup, as well as the things which you should have prepared before trying to implement the instructions in this article.
For the sake of this instruction, I will use the hostname “https://mastodon.darkstar.lan” as the URL where users will connect to the Mastodon server.
Furthermore, “https://sso.darkstar.lan/auth” is the Keycloak base URL (see Episode 2 for how we did the Keycloak setup).
The Mastodon container stack (it uses multiple containers) uses a specific internal IP subnet and we will assign static IP addresses to one or more containers. That internal subnet will be “172.22.0.0/16“.
Note that Docker by default will use a single IP range for all its containers if you do not specify a range to be used. The default range is “172.17.0.0/16”
Setting up your domain (which will hopefully be something else than “darkstar.lan”…) with new hostnames and then setting up web servers for the hostnames in that domain is an exercise left to the reader. Before continuing, please ensure that your equivalent for the following host has a web server running. It doesn’t have to serve any content yet but we will add some blocks of configuration to the VirtualHost definition during the steps outlined in the remainder of this article:
I expect that your Keycloak application is already running at your own real-life equivalent of https://sso.darkstar.lan/auth .
Note that I am talking about webserver “hosts” but in fact, all of these are just virtual webservers running on the same machine, at the same IP address, served by the same Apache httpd program, but with different DNS entries. There is no need at all for multiple computers when setting up your Slackware Cloud server.
Mastodon server setup
Prepare the Docker side
Let’s start with creating the directories where our Mastodon server will save its user data and media caches:
This provides a good base for our container stack setup. Mastodon’s own ‘docker-compose.yml‘ implementation expects a file in the same directory called ‘.env.production‘ which contains all the variable/value pairs required to run the server. We will download a sample version of that .env file from the same Mastodon git repository in a moment.
We need a bit of prep-work on both these files before running our first “docker-compose” command. First the YAML file:
Remove all the ‘build: .’ lines from the ‘docker-compose.yml‘ file. We will not build local images from scratch; we will use the official Docker images found on Docker Hub.
Pin the downloaded Docker images to specific versions; look them up on Docker Hub. Using ‘latest’ is not recommended for production.
For instance: change all “tootsuite/mastodon” to “tootsuite/mastodon:v4.0.2” where “v4.0.2” is the most recent stable version. If you omit the version in this statement,
by default “latest” will be assumed and then you won’t be certain of the actual version of Mastodon you are running.
Give all containers a name using “container_name” statement, so that they are more easily recognizeable in “docker ps” output instead of just a container ID:
Modify the ‘volumes’ directives in ‘docker-compose.yml‘ and define storage locations outside of the local directory.
By default, Docker Compose will create data directories in the current directory.
‘./postgres14:/var/lib/postgresql/data‘ should become:
‘./redis:/data‘ should become:
‘./elasticsearch:/data‘ should become:
‘./public/system:/mastodon/public/system‘ should become:
Change the default TCP ports (3000 for the ‘web’ service and 4000 for ‘streaming’ service) to respectively 3333 and 4444 (ports 3000 and 4000 may already be in use); note that there are multiple occurrences of these port numbers in the YML file, but only the ‘ports‘ value needs to be changed:
'127.0.0.1:3000:3000' needs to become: '127.0.0.1:3333:3000'
'127.0.0.1:4000:4000' needs to become: '127.0.0.1:4444:4000'
The Redis exposed port needs to be changed from the default “6379” to e.g. “6380” to prevent a clash with another already running Redis server on your host. Again, this only needs a modification in the ‘redis:’ section of ‘docker-compose.yml‘ because internally, the container services can talk freely to the default port.
We add two lines in the ‘redis:’ section of ‘docker-compose.yml‘: ports:
Give Mastodon its own internal IP range, because we need to assign the ‘web’ container its own fixed IP address. Then we can tell Sendmail that it is OK to relay emails from the web server (if you use Postfix instead of Sendmail, you can tell me what you needed to do instead and I will update this article… I only use Sendmail).
Make sure to pick a yet un-used subnet range. Check the output of “route -n” or “ip route show” to find which IP subnets are currently in use.
At the bottom of your ‘docker-compose.yml‘ file change the entire ‘networks:’ section so that it looks like this:
Download the sample environment file from Mastodon’s git repository and use it to create a bootstrap ‘.env.production‘ file. It will contain variables with empty values, but without the existence of this file the initial setup of Mastodon’s docker stack will fail:
This file is full of empty variables and some explanation about their purpose. The Mastodon setup process will eventually dump the full content for ‘.env.production‘ to standard output. You will copy this output into ‘.env.production‘ replacing the whatever was in there at first.
Define your unique setup
Your Mastodon server uses a Postgres database, Postgres will also need an admin password, you’ll need a database user/password combo, et cetera. All these parameters correspond with a variable value in ‘.env.production‘.
Here is the bare minimum configuration you should prepare in advance of starting the Mastodon setup process. With ‘prepare’ I mean, write down the values that you want to use for your server setup. Values in green are going to be unique for your own setup, this article uses example values of course.
# Our server hostname:
LOCAL_DOMAIN=mastodon.darkstar.lan # Postgress bootstrap:
# Optionally the server can send notification emails:
You will additionally need a password for the Postgres admin user when you initialize the database in one of the next sections. Just like for the ‘DB_PASS‘ variable above (which is the password for the database user account), you can generate a random password using this command:
When you have written down everything, we can continue.
Configure your host for email delivery
Part of the Mastodon server setup is to allow it to send notification emails. Note that this is an optional choice. You can skip that part of the setup if you want.
If you want your server to be able to send email notifications, your host needs to relay those emails, and particularly Sendmail requires some information to allow this. The IP address of the Mastodon webserver needs to be trusted by Sendmail as an email origin.
First the DNS part: if you use dnsmasq to provide DNS to your host machine, add the following line to “/etc/hosts”:
172.22.0.3 mstdn_web mstdn_web.external_network
followed by a “killall -HUP dnsmasq” to let your DNS server pick up the update in the hosts file. If you use bind, you’ll know how to add an IP to hostname mapping.
Sendmail needs to be able to resolve the IP when Mastodon requests an email to be sent.
For the Sendmail part of the configuration, add the following to “/etc/mail/access” if it is not already there:
It tells Sendmail to recognize our Docker IP ranges as trustworthy.
Run “makemap hash /etc/mail/access.db < /etc/mail/access” to compile the “access” file into a Sendmail database and reload Sendmail:
# /etc/rc.d/rc.sendmail restart
Download required Docker images
To download (pull) the required images from Docker Hub, you run:
# cd /usr/local/docker-mastodon
# docker-compose build
This does not yet start the containers.
Create a mastodon role in Postgres
We need to create the Postgres role “mastodon” prior to starting the Mastodon server setup, because the setup will fail otherwise with “Database connection could not be established with this configuration, try again. FATAL: role “mastodon” does not exist“.
To accomplish this, we spin up a temporary Postgres container using the same Docker image and configuration as we will use for the Mastodon container stack, i.e. we copy most of the parameters out of our ‘docker-compose.yml‘ file:
The following SQL commands will initialize the database and create the “mastodon” role for us, and all of that will be stored in “/opt/dockerfiles/mastodon/postgresdata” which is the location we will also be using for our Mastodon container stack. The removal of the container afterwards will not affect our new database since that will be created outside of the container.
postgres-# CREATE USER mastodon WITH PASSWORD 'XBrhvXcm840p8w60L9xe2dnjzbiutmP6' CREATEDB; exit
We can then stop the Postgres container, and continue with the Mastodon setup:
# docker stop postgres-bootstrap
Mastodon server initial setup
Note below the use of “bundle exec rake” instead of just “rake” as used in the official documentation; this avoids the error: “Gem::LoadError: You have already activated rake 13.0.3, but your Gemfile requires rake 13.0.6. Prepending `bundle exec` to your command may solve this.“
Everything is in place to start the setup. We spin up a temporary web server using docker-compose. Using docker-compose ensures that the web server’s dependent containers are started in advance:
# docker-compose run --rm web bundle exec rake mastodon:setup
The configurator will output a full server configuration to standard output at the end. You need to copy and paste that configuration into the ‘.env.production‘ file.
Use the information you compiled in the previous section “determine your unique setup” when answering these questions. After successful completion, this is what you should see:
Below is your configuration, save it to an .env.production file outside Docker:
# Generated with mastodon:setup on 2022-12-12 12:12:12 UTC
# Some variables in this file will be interpreted differently whether you are
# using docker-compose or not.
It is also saved within this container so you can proceed with this wizard.
The next step in the configuration initializes the Mastodon database. It is followed by a prompt to create the server’s admin user. The setup program will output an initial password for this admin user, which you can use to logon to the Mastodon Web interface. Be sure to change that password after logging in!
Now launch the Mastodon server using:
# docker-compose up -d
Note that if you run “docker-compose up” without the “-d” so that the process remains in the foreground, you’ll see the following warnings coming from the Redis server:
mstdn_redis | 1:M 12 Dec 2022 13:55:16.140 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
mstdn_redis | 1:M 12 Dec 2022 13:55:16.140 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.
mstdn_redis | 1:M 12 Dec 2022 13:55:16.140 # Current maximum open files is 4096. maxclients has been reduced to 4064 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
I leave it up to you to look into increasing the max-open-files default of 4096.
Tuning and tweaking your new server
Now that your server is up and running, it is time to use the admin account for which you received an initial password during setup, to personalize it.
Mastodon has a documentation page on this process. The server admin has access to a set of menu items under “Settings > Administration“.
One menu item is “Relays“. This is where you would add one or more relays to speed up the process of Federation between your small instance and the rest of the Fediverse. See the section further down called “Connect your Mastodon instance to the Fediverse” for the details.
Spend some time in the “Server Settings” and “Server Rules” submenus and their tabs (such as “Branding“) to add information about your server that identifies it to visitors and users, and shows the “house rules” that clarify what you expect of people that want an account on your server.
Here is an example of how branding is used to present my site to visitors:
Command-line server management
The admin user has access to the “Admin CLI” which is the fancy name for the “tootctl” command in the mstdn_web container. You can find its man-page at https://docs.joinmastodon.org/admin/tootctl/ .
If you need to run the “tootctl” command, use “docker exec” to execute your command inside of the already running Web container which we gave the name ‘mstdn_web‘ in ‘docker-compose.yml‘:
The tab “Content Retention” under “Server Settings” will be of importance to you, depending on the limitations of your storage capacity. It allows you to specify a max age of downloaded media after which those files get purged from the local cache. The amount of GB in use can increase rapidly as the number of local users grows. Alternatively you can run the following Docker commands on the host’s commandline to delete parts of the cache immediately instead of waiting for the container’s own scheduled maintenance. In my case, you’ll see that the server is quite inactive (single-user instance) and there’s nothing to be removed:
If you want to support full-text search of posts on your Mastodon server, you should un-comment the container definition for elasticsearch (the ‘es‘ service) in your ‘docker-compose.yml‘ file and run “docker-compose down ; docker-compose build ; docker-compose up -d” to pull the elasticsearch container from Docker Hub. Note that this will tax your host with additional RAM, CPU and storage demand.
In case of future re-configuration you may want to skip the full configuration if you only want to setup or migrate the database, in which case you can invoke the database setup directly:
# docker compose run --rm -v $(pwd)/.env.production:/opt/mastodon/.env.production web bundle exec rake db:setup
Adding more concurrency is relatively easy. But when it comes to caching the data and media pulled in by your users’ activities, you may eventually run into the limits of your local server storage. If your server is that successful, consider setting up a support model using Patreon, PayPal or other means that will provide you with the funds to connect your Mastodon instance to Cloud-based storage. That way, storage needs won’t be limited by the dimensions of your local hardware but rather by the funds you collect from your users.
Remember, Mastodon is a federated network with a lot of server instances, but the Mastodon users will expect that their account is going to be available at all times. You will have to work out a model where you can give your users that kind of reassurance. Grow a team of server moderators and admins, promote your server, secure a means of funding which allows to operate your server for at least the next 3 to 6 months even when the flow of money stops. Create room for contingencies.
Mastodon does not show ads, and instead relies a lot on its users to keep the network afloat.
Connect your Mastodon instance to the Fediverse
A Mastodon server depends on its users to determine what information to pull from other servers in the Fediverse. If your users start following people on remote instances or subscribe to hashtags, your server instance will start federating, i.e. it will start retrieving this information, at the same time introducing your instance to remote instances.
If you are going to be running a small Mastodon instance with only a few users, getting connected to the wider Fediverse may be challenging. The start of your server’s federation may not be guaranteed. To accommodate this, the Mastodon network contains relay servers.
Adding one or more of these relays to your server configuration makes the relay push federated data to your server. A list of relay servers is available for instance here: https://techbriefly.com/2022/11/11/active-mastodon-relays/ and I am sure you can find more relays mentioned in other locations. Some relays require that their admin acknowledges and approves your request before the data push is activated.
Mastodon Single Sign On using Keycloak
Like with the other cloud services we have been deploying, our Mastodon server will be using our Keycloak-based Single Sign On solution using OpenID Connect. Only the admin user will have their own local account. Any Slackware Cloud Server user will have their account already setup in your Keycloak database. The first time they login to your Mastodon server, the account will be activated automatically.
It means that your server should disable the account registration page. You can configure that in “Server Settings > Registrations“.
Adding Mastodon Client ID in Keycloak
Point your browser to the Keycloak Admin console https://sso.darkstar.lan/auth/admin/ to start the configuration process.
Add a ‘confidential’ openid-connect client in the ‘foundation‘ Keycloak realm (the realm where you created your users in the previous Episodes of this article series):
Select ‘foundation‘ realm; click on ‘Clients‘ and then click ‘Create‘ button.
‘Client ID‘ = “mastodon“
‘Client Protocol‘ = “openid-connect” (the default)
‘Access type‘ = “confidential”
Also in ‘Settings‘, allow this app from Keycloak.
Our Mastodon container is running on https://mastodon.darkstar.lan . We add
This secret is an example string of course, yours will be different. I will be re-using this value below. You will use your own generated value.
Add OIDC configuration to Mastodon’s Docker definition
Bring the mastodon container stack down if it is currently running: # cd /usr/share/docker/data/mastodon
# docker-compose down
Add the following set of definitions to the ‘.env.production‘ file:
# Enable OIDC:
# Text to appear on the login button:
# Where to find your Keycloak OIDC server:
# Use discovery to determine all OIDC endpoints:
# Scope you want to obtain from OIDC server:
# Field to be used for populating user's @alias:
# Client ID you configured for Mastodon in Keycloak:
# Secret of the Client ID you configured for Mastodon in Keycloak:
# Where OIDC server should come back after authentication:
# Assume emails are verified by the OIDC server:
Food for thought
Let’s dive into the meaning of this line which you just added:
> OIDC_UID_FIELD=preferred_username This “preferred_username” field translates to the Username property of a Keycloak account. The translation is made in the OpenID ‘Client Scope‘.
The Docker Compose definition which we added to ‘.env.production‘ contains the line below, allowing any attribute in the scopes ‘openid‘, ‘profile‘ and ‘email‘ to be added to the ‘token claim‘ – which is the packet of data which is exchanged between Keycloak and its client, the Mastodon server.
To learn more about the available attributes, login to Keycloak as the admin user and select our “foundation” realm.
Via ‘Configure‘ > ‘Client Scopes‘ click on ‘profile‘ > ‘Mappers‘ > ‘username’ where you will see that the ‘username‘ property has a token claim name of ‘preferred_username‘. We use ‘preferred_username’ in the OIDC_UID_ID variable which means that the actual user will see his familiar account name being used in Mastodon just like in all the other Cloud services.
However, what if you don’t want to use regular user account names for your Mastodon? After all, Twitter usernames are your own choice, as a Mastodon server admin you may want to offer the same freedom to your users.
In that case, consider using one of the other available attributes. There is for instance ‘nickname‘ which is also a User Attribute and therefore acceptable. It will not be a trivial exercise however: in Keycloak you must create a customized user page which allows the user to change not just their email or password, but also their nickname. For this, you will have to add ‘nickname’ as a mapped attribute to your realm’s user accounts first. And you have to ensure somehow that the nickname values are going to be unique. I have not researched how this should (or even could) be achieved. If any of you readers actually succeeds in doing this, I would be interested to know, leave a comment below please!
Start Mastodon with SSO
Start the mastodon container stack in the directory where we have our tailored ‘docker-compose.yml‘ file:
# cd /usr/share/docker/data/mastodon
# docker-compose up -d
And voila! We have an additional button in our login page, allowing you to login with “Keycloak SSO“.
Apache reverse proxy configuration
To make Mastodon available at https://mastodon.darkstar.lan/ we are using a reverse-proxy setup. This step can be done after the container stack is already up and running, but I prefer to configure Apache in advance of the Mastodon server start. You choose.
Add the following reverse proxy lines to your VirtualHost definition of the “mastodon.darkstar.lan” web site configuration and restart httpd:
# Set some headers:
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000"
RequestHeader set X-Forwarded-Proto "https"
# Reverse proxy to Mastodon Docker container stack:
Options FollowSymLinks MultiViews
allow from all
ProxyPass http://127.0.0.1:3333/ retry=0 timeout=30
ProxyPass ws://127.0.0.1:4444/ retry=0 timeout=30
When setting up my own server, I was helped by reading these pages:
I assume many of you are watching the Twitter soap, waiting for the moment that the social media platform burns down completely. Its fresh owner Elon Musk is abusing his newfound powers to vent his far-right extremist ideas, firing most of Twitter’s employees, shutting down the content moderation team, and so on.
You should definitively be looking for an alternative if you are interested in socially interacting with other people through online platforms. And especially if you represent a business or an organization and use Twitter as a communication medium, you must absolutely reconsider whether you are using the right platform.
A lot of people have been looking for alternatives to satisfy their Twitter habits. That process already started in February 2022 when Musk announced his intention to buy Twitter. But after completing that deal and essentially taking over daily operations, there has been a massive exodus. The platform which is absorbing most of this exodus as new users seems to be Mastodon. But Mastodon is a different platform than Twitter and a lot of new users struggle with the concepts. There’s a lot of documentation but not everyone reads documentation prior to jumping into the action.
I will share some pointers that may help you make the decision to move to Mastodon and getting all setup there.
Choose a Mastodon server
Mastodon is a federated network as opposed to Twitter which is a centralized network. To use Twitter, you login to a single URL, and have access the tweets of every other user of the platform.
Federated on the other hand means, the Mastodon network is run by any amount of independently and non-commercially hosted server instances, that are all interconnected and share updates in real-time. You login to your account on a specific server and have access to the full federated network’s content from there.
Unlike Twitter, where you have a unique handle (mine would be @erichameleers), your identity on the Mastodon network will also show the server you are operating from. My identity is a combination of the nick ‘alien’ on server ‘fosstodon.org’ which would make my Mastodon handle @firstname.lastname@example.org.
If you have difficulties grasping the concept of a server or an instance… compare it to a local community center in your town. You go there to hang out with like-minded people but the television screens on the walls will show you what’s going on in the outside world. But you won’t enter just the first community center you encounter… you’d want to know a bit about the kind of people that frequent the place. But if you just want to mingle in a large crowd, I guess you would rather go to the football stadium.
I hope the comparison was not too cheesy, but I have been told that “you techies built this stuff but normal people do not know what words like server or instance mean at all”. Fair enough.
So, your first step will be to pick and choose the server where you are going to create an account. Server instances are sometimes topic based (with a focus on for instance open source, food, journalism, art and so on) which will influence the nature of the posts you will see scrolling by in your Local and Federated timelines (see below).
There is a searchable list of available servers at https://instances.social/list which can help in your decision making. Do you want an account on a server with lots of user accounts already present, which usually means the admins know what they are doing and they have long-term commitment? Or do you want a smaller instance but with a focus on a specific topic so you’ll have a bigger chance to hang out with like-minded people?
Also there’s https://joinmastodon.org/servers which is a page you can set a bunch of conditions (location, language, topic, legal entity, speed of account enablement, community-size) and which will then show a shortlist of Mastodon instances that match your preferences.
I chose fosstodon.org as my logon server because of its focus on people who like to work with Free and Open Source Software.
Configure your profile
Once you have selected a server, open its URL in a web browser, click the “Create Account” button and start building your user profile. Be sure to tell a bit about yourself.
Mastodon allows a form of identity verification, not unlike the idea behind Twitter’s “blue badge” but then done right, and without cost! Your profile can list up to 4 personal web sites, and if you own or control these, you can add a bit of text on its web page which will be used by Mastodon to validate that it is actually your website. And it will color that website green on your profile page. Check out how that looks on my profile page:
Any Mastodon server is accessible by a web browser, and for many users that is sufficient. Don’t forget to enable the “enhanced web interface” in your profile settings!
On a smartphone however, the web user interface experience is not optimal. There are apps that you can use instead.
On Android, there’s the official Mastodon app, or else you could try Tusky. Both are free but there’s also paid-for apps available in the Store, like Fedilab.
Apple also has the official Mastodon app in their Store, but Tootle could be an alternative option.
The way in which other people’s posts are presented chronologically on your home page (the so-called timeline) is fundamentally different in Mastodon compared to Twitter. There you have a single timeline, populated by posts from the people you follow, combined with other people’s posts that have been favored (liked) by people you follow. Twitter will additionally show posts from people unknown to you, if its algorithms decide that these posts may be relevant for you based on the behavioral profile it created from your interactions with the platform. Therein lies the danger that you get pulled into an information bubble.
Plus you will see lots of targeted advertising by Twitter’s affiliates, again based on your interests and the posts you liked or replied to in the past.
Mastodon on the other hand does not analyze your posting behavior, it does not run algorithms to influence your experience of the platform. You decide what you will see on your home timeline.
Regarding timelines, Mastodon has three of them!
The Home timeline is displayed on your home screen by default, and contains the posts of people you follow, as well as posts from other people that were favored (boosted) by the people you follow, plus posts that contain hashtags that you have subscribed to (see below) and posts that directly mention your @nick.
The Local timeline is a separate view, showing posts of all the other users of the Mastodon server instance where you are logged-in.
The Federated timeline finally is a chronological feed of all the posts that are originating from outside your local server, of which the local server has been made aware. Meaning, you will see an arbitrary subset of all communication in the Fediverse, their relevance boosted by the interests of all users of your local server instance.
The nature of the content displayed in Local and Federated timelines is why I mentioned earlier that you might want to create an account on a Mastodon server centering around a specific topic that interests you. You will see more posts on such a server that are relevant to you.
Find people and hashtags to follow
Curating your timeline is a matter of following people you are interested in, apply proper filtering to hide unwanted content, and subscribe to hashtags to drag in the news from far away.
How to find people to follow?
Let’s start with people you are already following on Twitter. To find out who is already on Mastodon you can enter “mastodon” in the Twitter search bar and then limit the search results to “people you follow”.
Also, there are Twitter-to-Mastodon gateways which expose Twitter accounts to the Mastodon network; when you search for someone on Mastodon and the server part of their account contains a word like “birdsite” then this is a person whose Twitter posts are automatically being replicated on Mastodon.
And there’s a lot of folks who already migrated of course, and you will easily find them by entering their name or any nick/handle you know into the search box.
If you want to know who I am following, that’s not a secret: https://fosstodon.org/@alien/following
How to subscribe to hashtags?
If your server runs Mastodon version 4 or newer (most of them will do by now, the current version at the time of writing this is 4.0.2), and if you are using a Web browser to access Mastodon, you perform the following steps: enter a word in the Mastodon search box; in the results pane click on “hashtags” to display only the hashtags that match your search phrase; click on the hashtag that interests you; and finally click the “follow” icon which will be shown to the right of that hashtag.
Now, posts containing this hashtag will start showing on your Home timeline.
How to filter out the unwanted content?
In “Settings > Filters” you can use the “Add new filter” button to create filters that trigger on text strings that optionally match whole words. Posts containing the trigger text can be hidden from your Home, Local and/or Federated timelines, and/or conversations/mentions. You can set an expiry date to a filter if you are only temporarily fed up with someone you follow.
Next to filtering, you can also mute people you follow. The easiest way to do so is when you go that user’s profile page, click on the 3-dot menu to the right of the username and select “mute”. By the way, that menu contains a whole lot of ways to change your level of interaction with this person, go have a look!
Inform your Twitter friends
What I did to inform my Twitter friends and followers that I migrated to Mastodon, was adding my Mastodon handle to my Twitter display name. I am now known as “Eric Hameleers (@email@example.com)“. If you want to be a bit less conspicuous about it, you could also just update your profile description to tell people where they can find you on Mastodon. After all, everyone remembers the ban hammers on Freenode IRC network where every account was auto-banned and channel auto-disowned when you mentioned you had moved to Libera.Chat. Musk is maniacal and so emotionally unstable that he could just do something similar to Twitter.
Detailed explanations on how to use Mastodon and interact with other people on the network can be found in https://docs.joinmastodon.org/ . I encourage you to read that page, it will prove quite useful.
Move to a different server (optional)
If you decide that you actually like another community better, it is possible to move your Mastodon account from one server to another. There’s multiple ways to achieve this. It all starts with the creation of your new account of course, and adding aliases for both the old and the new account that link them together.
Then you set a redirect from your old to your new account. People visiting your old profile will be informed where you moved to. Next to a redirect, you can also initiate a formal move of your account, and in this case Mastodon will automatically move all your followers from your old to your new account. Your old account will become a redirect to your new account but at least to your followers the process is relatively transparent.
Redirected accounts will be excluded from search results so that people searching for you will only find the new account.
What is not moved, are your historical posts and the people your old account is following. Both your accounts will also go into a cooldown period, where it is not possible to initiate another account move.
Interested? Curious? I hope to see some of you on Mastodon!
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!