What is Mastodon?

The main selling point of Mastodon is that it is a decentralised social network. Think of it as combination of Twitter and Email. Just as Twitter, Mastodon gives you a timeline of posts by people you follow. However, it is not a centralised system, instead you chose your Mastodon instance. That way your username looks as an email address. Mine for example is @edbro@swecyber.com, and my posts can be seen by any other instance.

This is called a federated solution. You work towards your instance, that shares its data with other instances. In practice this minimises the dependency on a single centralised entity. If you wish to change instance due to a lack of trust, it not being maintained or closed down you can just export your data and import it on a new instance. That could be on a personal instance or one of the larger ones that is already existing.

For now it seems to be mostly tech people whom have migrated from Twitter, but there are others as well. However, since each instance usually have a focus, this might be somewhat due to the my choice of instance to join, and the people I follow.

This design of Mastodon puts a big responsibility on its users to follow accounts with diverse opinions to not end up in a bubble. There is a risk that if you only follow people with opinions like your own, they will be further deepened, regardless if they are right or wrong. It is up to the user to ensure that views are challenged in a good way and that everyone uses their critical thinking to not be fooled by malicious actors.

Main Differences from Twitter

The main things that confused me was the likeness of twitter, while Mastodon is different. Some things that seem similar works quite different.

• There is no algorithm. You see the posts authored (or boosted) by the pepole you follow. If you want to find new people to follow you can also see the timeline of your instance and instances configured by its admin. However this timeline is sorted chronologically, and all posts of those instances are shown.
• The difference between Boosts, Favourites, and Bookmarks.
  • Boosts are retweets. On Mastodon they are used to further spread a post. This allows your followers (regardless of instance) to see the original post. Note also that it is not possible to quote boost. If you want to add something to the discussion, you need to do so as a reply.
  • Favourites shares some features with likes. They can be seen on an original post, but does not push the post to your followers. Also note that there are no algorithm pushing posts with many likes. Therefore the effect of favouriteing is limited.
  • Bookmarks are a way to save a post so that you can find it again later. These are seen by neither the author of the post nor your followers.
• The search does not search the full text. Instead only displaynames, tags, and usernames are searched. In addition, searches can only find things the instance is aware of. For example that could be posts that are federated to the users of the instance or the authors of those posts. To find a user of another instance you need their full username, including the address to the instance.
• Each post is tagged with a language. This makes it possible to use 1 account to communicate in different languages. Your followers can easily filter your posts to the languages they speak, and does not see the posts in other languages.

Thoughts on Mastodon

After getting used to the behaviour of Mastodon I really like what it does. It is a nice social network, and allows for discussions and networking in a way that twitter today doesn’t. It is easier to perform personal moderation of what I wish to see.

I have found a small instance with individuals interested in cybersecurity. This however does not limit me, I still partake in the broader community, replying to posts or sharing my thoughts from the beginning.

Hope to see you on Mastodon!

Goals

When setting up our network we have a couple of goals. Namely we want a stable network where we can plug in wired devices, as well as connect via Wi-Fi. For now we are happy with creating a single wireless network that all devices connect to, and that is not separated from the wired network. However, it would be possible to create a secondary guest network, separated from our trusted devices.

In addition to the main goal the network should be as easy to maintain as possible. The less configuration that can break the better, and the more resilient it is to changes the better.

Equipment and Terminology

Due to the configurability of the RouterOS firmware (the firmware used by MikroTik devices) this guide will likely be applicable for other devices as well. However, it is only tested with my setup of a wireless access point, and a router/switch combo.

To make it easier to follow along while using other devices this guide will use the name (or Identity in RouterOS terms) cap for the access-point and capMan for the router/switch. The table below gives an overview of the name and role of each device.

To achieve our goal of maintainability we will use a function called CAPsMAN (Controlled Access Point system Manager). This will allow us to centrally manage the access point (and new access-points in the future) from a centralised point. The router will then send updates to all access-points, removing the need to manage them one by one.

Steps

So how to configure a wireless network with MikroTik devices? I’ve broken it down into two steps, first the preparations, and then configuring the Wi-Fi network.

Preparation

The first step to any network configuration is to ensure that each device is reachable and has a recognisable identity (name). I found that it was easiest to factory reset the access-point from the GUI, and choosing the cap preset. This puts the device into a bridge mode, disabling all router functionality and NAT. This gave a good starting point for the rest of the configuration.

With a reset access-point it is time to ensure that each device have a recognisable identity. As described in Equipment and Terminology I will use CAP for the access-point and CAPMAN for the router. It is also important to ensure that the devices has good passwords and are up to date, so I recommend doing so now.

To make it easier to troubleshoot the network I also recommend setting a static DHCP lease for the CAP device. In my case the following IP configuration is used:

Configuring a Wireless Network with MikroTik Devices

With our network in a state were we have a connection between CAPMAN and CAP we can begin to configure the network. The first step is to configure CAP to ask CAPMAN for configurations. This is done by using [admin@CAP] > /interface wireless cap set caps-man-addresses 192.168.88.1. This command sets the address of the manager and ensures that it is the one responsible for the configuration.

Next up we need to configure the wireless network. This is done in multiple steps, as shown below.

[admin@CAPMAN] > /caps-man security add name="wpa2psk" authentication-types=wpa2-psk encryption=aes-ccm
[admin@CAPMAN] > /caps-man security set 0 passphrase=[REDACTED]
[admin@CAPMAN] > /caps-man configuration add name=master-cfg ssid=[My-Wifi-Network] security=wpa2psk country=sweden
[admin@CAPMAN] > /caps-man provisioning add action=create-dynamic-enabled master-configuration=master-cfg
[admin@CAPMAN] > /caps-man configuration set 0 datapath.bridge=bridge
[admin@CAPMAN] > /caps-man manager set enabled yes

The first command will create a new security configuration, specifying that the Wi-Fi shall use wpa2-psk for authentication and AES encryption. After that we set the password. This is the password used to connect to the wireless network when it gets activated. The third step is to set the name of the Wi-Fi (the SSID). Note that we do not want to configure a band here. This will allow the CAP to create a network on 2.4ghz as well as on 5ghz. Otherwise, it would only create the network on the configured band. If we wish to configure the a second Wi-Fi, we would create a second configuration here and add it as a slave configuration in the next step. On line 5 we provision the network to be created. This tells CAPMAN what configuration to push to what device. This means that if you have multiple devices you can set what devices to push it to. For more information use the built-in help or the online documentation for provisioning. The last row is the thing that got me confused. It tells the CAPMAN what bridge (interfaces) the network should be attached to. In my case this is the default bridge, and this allows devices to connected to the Wi-Fi to access the network. The last step is to enable the CAPsMAN configuration on CAPMAN. This turns the configuration on and you should now be able to see your wireless network and connect to it.

Note that if you wish to change something in an existing configuration you need to remove the configured interfaces and then trigger a re provision. This is done by:

[admin@CAPMAN] > /caps-man interface print
# This shows all interfaces, remove all interfaces
[admin@CAPMAN] > /caps-man interface remove 0
[admin@CAPMAN] > /caps-man remote-cap print
[admin@CAPMAN] > /caps-man remote-cap provision 0
# Reprovision all CAPs

There are lots more that can be done with CAPsMAN, but this should be a good starting point. However, I recommend the MikroTik wiki to read up more on the options. There might be other things relevant for your needs.

Summary

Setting up a wireless network with MikroTik infrastructure is quite easy, when you know what steps to take. The steps to take are on the managing device (CAPMAN):

1. Set CAP to use CAPMAN for configuration.
2. Configure the security to use for the Wi-Fi.
3. Configure the password for the network.
4. Create a network configuration to use.
5. Provision the configuration to be pushed to access-points.
6. Configure datapath for the wireless network.
7. Enable the network

And on the CAP:

1. Configure the CAPsMAN manager to use.

This should allow your CAPMAN to dynamically configure any access-points connected to provide network access.

Buidling the Site

The first thing to do when migrating is to find a new theme and adapt/move things into it. I ended up choosing PaperMod, due to its simplicity in combination with a modern look and feel. With that out of the way it was time to move my logotype and descriptive texts. In both cases this kind of information is stored in the configuration files.

The next step is to move the actual contents of the blog. In Jekyll this is stored in two folders (at least in my case):

1. The posts: /_posts -> /content/posts
2. The images /assets -> /static/images

With this out of the way it is time to go through every single post to update the syntax. The first thing is the metadata of the posts, the top of my markdown files. In my case there was no difference. The following is the configuration is what was used in Jekyll.

1
2
3
4
5
6
7
8

---
layout: post
title:  "Building a Webpage"
date:   2020-08-19
categories: "Projects"
tags: ["Jekyll", "Projects"] 
author: "Oskar Edbro"
---

The layout is just discarded, and the rest have the same functionality in both Jekyll and Hugo. With this knowledge it is time to look at how each post looks. And sadly there is a difference between how images are included. The good thing is that Hugo better handles the default image syntax from markdown. This means that images can be included as shown below:

![A phone with apps seen as privacy violations](/images/2022/The-Modern-Con/The-Modern-Con-Privacy-Violation.jpg 'Photo by Jeremy Bezanger on Unsplash')

With that all the modifications required for the application is finished. The next step is to polish the site with information and ensure that all information is available.

Hosting

Setting up the hosting i Decided to use GitHub Actions instead of just using the Cloudflare auto build (as I did previously in Migrating to Cloudflare). This means that I am required to learn some thing about how to create a CICD Pipeline.

Getting everything to play nicely was a bit of a hazel, especially since I to insisted on separating the build and deploy actions into different jobs. In the end, the issue was in regards to saving and then retrieving the artefacts. When that issue was solved all went smooth. So how was it done? To build the page I used the following job:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: recursive
      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: 'latest'
          # extended: true
      - name: Build with Hugo
        env:
          # For maximum backward compatibility with Hugo modules
          HUGO_ENVIRONMENT: production
          HUGO_ENV: production
        run: |
          hugo \
            --minify 
      - name: Upload artifact
        uses: actions/upload-artifact@v3
        with:
          name: site
          path: ${{ github.workspace }}/public
          retention-days: 7

Noteworthy things are the use of an existing Hugo build action, and saving the artefacts to my GitHub workspace. We also make sure to minify the generated HTML, just to save a bit of data. It does not make much difference, but every little bit counts. For the deployment, there are just two steps. Downloading the artefacts we saved, and then uploading them to Cloudflare. The project name has however been masked.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    needs: build
    steps:
      - name: Download a single artifact
        uses: actions/download-artifact@v3
        with:
          name: site
          path: ${{ github.workspace }}/public
      - name: Publish
        uses: cloudflare/pages-action@1
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          accountId: ${{ secrets.CF_API_ID }}
          projectName: XXXXXX
          directory: ./public
          gitHubToken: ${{ secrets.GH_PAT }}

Summary

So in the end, it took more time than expected to migrate to Hugo. However, most of the time spent was in learning things. How to use GitHub Actions, how Hugo works, etc. With that out of the way, it was quite easy. Now, the next step is to start modifying the small things to get the theme even better.

The experience of publishing new posts is about the same as when hosting on Github, you just push an update to the specified branch and then a build is triggered that will be published upon completion. The main difference is that the build process is somewhat slower in Cloudflare than on Github. This means that a build can take about 5 minutes, instead of the previous 1. This is most likely due to the fact that Cloudflare pulls everything and builds locally, instead of using Jekyll remote themes.

When the post is published, there are no major difference for the user, however the statistics for the creator is much deeper. The pure web analytics (provided by JavaScript) could be implemented wherever the site was hosted, but there is more. The web analytics is the most detailed analytics, since it provides what posts were visited, referrers, user agents and more. The Cloudflare proxy analytics on the other hand does not require JavaScript, and can therefore not be blocked. The amount of information provided is not as detailed, but it gives a broader picture of the visitors. This data contains unique visitors and their origin country, but not much more. This could be seen in the web statistics as well, but that tracking is easily blocked.

Even though I have a quite negative stance on tracking, I think that information that is collected in the server anyway can be shown to the content creator without infringing the readers privacy. By being able to track number of readers it’s possible to gain insight in the trends depending on the type of content published. For this blog for example I can from the statistics note that the most interesting content is in the divide between technical security and policies. For example Spotify GDPR Analysis is one of the most read articles on the blog, and it was written before I added analysis, and posts are often read the most directly at launch.

Getting back to the topic at hand, the experience of using Cloudflare, it gives the possibility to handle everything at a single location. This includes managing the domain as an registrar, hosting the application, managing TLS certificates and much more. The only thing I’ve found that is a bit tricky is that I’ve not found a way to register a new domain, only to transfer an existing one. With that said, I’ve been very happy with my switch to Cloudflare, it gives me the tools I need for my blog, and just works.

Migrating from GitHub pages to Cloudflare pages was as easy as configuring what GitHub repo to use in Cloudflare, picking Jekyll and then it just worked. Right after the page was built you see some basic statistics, such as the amount of request grouped by country. Below the first hours of traffic is shown in a map, as presented by Cloudflare.

In addition to providing basic statistics, using Cloudflare gives a lot of additional benefits. This includes the use of their Content Delivery Network, protection from Denial of Service, and easy HTTPS. I have not dug deep into which is best in these regards, but i find it difficult to believe that I have made a significant downgrade.

So in conclusion to gain some basic statistics of the usage of my blog, I’ve migrated it to Cloudflare. The solution will not track any personal data, only basic statistics to gain some insight in how many readers are using/enjoying my blog.

Getting things to work have been quite a fiddle, so lets walk through how I got things up and running.

The first step was to get ruby and jekyll installed on my local machine for testing. After trying with wsl I lost my patience and to my surprise it was easier to install directly in windows. Jekyll has a great guide on how to install ruby, jekyll and all dependencies at https://jekyllrb.com/docs/installation/windows/.

The next step was to create my github repository. To be able to host github pages you have to name the repository <username>.github.io where you replace <username> with your github username. After that I cloned my repository to my local machine and initiated jekyll by running jekyll new . in my repository.

At this point I got a basic blog. By using bundle exec jekyll serve the webpage is built and hosted locally for testing. It works, but now it’s time to pretty the page up a bit. After looking around on different themes for a while I ended up choosing Hamilton, it fits my needs nicely, and i really enjoy the look. Installing it was as easy as following the guide in the documentation, you just have to remember to change the theme in _config.yml, to ensure that you use the new theme. That took far to long to realise, but finally I made it.