Crude solution to ban bots by their user-agent

Okay, this is a very crude way to block bots, spiders and crawlers by their user-agent, but so far, this has been very, very efficient.

Even when one chooses ” yes “, the question will be repeated. This is not a problem, because no one in their right mind is going to add “bot”, “spider” or “crawler” as their user-agent.

So here’s the PHP script that I rammed into a certain website to prevent it from being DDOSsed by (malicious) bots.


// Emergency bypass
// goto end;

// (c) FoxSAIn 2023, Free to use.

// Function to check if the user agent appears to be a bot or spider.
// Enter the bots you would like to block in a list as shown below.
function isBot()
    $user_agent = $_SERVER["HTTP_USER_AGENT"];
    $bot_keywords = [

    foreach ($bot_keywords as $keyword) {
        if (stripos($user_agent, $keyword) !== false) {
            return true;

    return false;

// Check if the visitor is a bot or spider
if (isBot()) {
    // This visitor appears to be a bot or spider, so display a choice.
    // Check if the choice form is submitted
    if (isset($_POST["submit"])) {
        // Check the choice made by the visitor
        $choice = isset($_POST["choice"]) ? $_POST["choice"] : "";

        if ($choice === "yes") {
            // User selected "Yes," block access
            echo "Access denied. If you believe this is an error, please contact us by writing the word support before the at sign, followed by";
        } elseif ($choice === "no") {
            // User selected "No," proceed to end
            goto end;
    } else {
        // Output the message to the user and make the choice mandatory
        echo "Your user agent suggests you might be a bot, spider, or crawler. Are you one of these three?";

        // Output the radio button choices within a form
        echo '</p>
<form method="post" action="">';
        echo ' <label><input type="radio" name="choice" value="yes" required>Yes</label>';
        echo ' <label><input type="radio" name="choice" value="no">No</label>';
        echo ' <button type="submit" name="submit">Proceed</button>';
        echo "</form>

    // Exit to prevent further processing
// Original website code starts from here.


CloudPanel website causing “Too many redirects”

I have installed CloudPanel and the new website caused a “Too many redirects” bug. This is because my SSL certificates are controlled by a proxy and this can cause some confusion between the systems. Also, because CloudPanel installs its own certificates.

This application can also install a Let’s Encrypt certificate, but this works only in more conventional systems. Mine is going through a DNS to a Proxy that listens to a certain IP address and that proxy redirects the request to a Virtual Machine on one of my servers.

So, here is my, probably unconventional method of disabling the SSL certificates on my CloudPanel installation:

  1. Open the CloudPanel controlpanel.
  2. Select the website you want to edit
  3. Choose the Vhost tab
  4. Change the following code into the new code:
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;


if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;
server {
listen 80;
listen [::]:80;
# listen 443 ssl http2;
# listen [::]:443 ssl http2;
# {{ssl_certificate_key}}
# {{ssl_certificate}}


# if ($scheme != "https") {
# rewrite ^ https://$host$uri permanent;
# }

Done! Your website should now say “Hello world :-)”

You can see that I have disabled the listen to port 443, the certificate keys, the forced https and the path to the keys. I chose to switch off the forced HTTP, because my proxy is already taking care of that.

This post is subject to change, but this helps you along your way!


How to update Mastodon to a new version

Updating Mastodon and creating backups are important steps to ensure the security and stability of your instance. Here’s a comprehensive tutorial on how to update Mastodon, including making backups of the database and assets:

Note: Always perform updates on a test/staging instance before applying them to your live instance. This tutorial assumes you have some basic knowledge of the command line and server administration.

Click here for the backup steps. It basically comes down to a Database dump, a settings file backup and a Redis dump. If you wish to backup your assets like images and stuff (User-uploaded files), backup the folder named “public/system”. Keep in mind that this folder can be rather large. Actually, it can become rather massive.

After a good 90 minutes, I gave up on trying to show you how large the asset folder is. So beware if you are going to make a backup of it. Perhaps you can just skip the cache folder?

You can always check the folder size by using NCDU, for which you can find the manual here. Also, installations may vary, but this is an example of my instance.

Upgrade procedure.

  1. su - mastodon
  2. cd /home/mastodon/live
  3. git fetch --tags
  4. git checkout [type the most recent version here, starting with the letter v. For example; v4.0.1
    Command example: git checkout v4.0.1
  5. bundle install
  6. yarn install
  7. RAILS_ENV=production bundle exec rails db:migrate
  8. RAILS_ENV=production bundle exec rails assets:precompile
  9. reboot now

And that should be it!

If you don’t want to restart your server, use the following commands instead of “reboot now”:

  1. exit
  2. systemctl restart mastodon-sidekiq
  3. systemctl reload mastodon-web

    The reload operation is a zero-downtime restart, also called a “phased restart”. As such, Mastodon upgrades usually do not require any advance notice to users about planned downtime. In rare cases, you can use the restart operation instead, but there will be a (short) felt interruption of service for your users.

  4. The streaming API server is also updated and requires a restart; doing so will result in all connected clients being disconnected, which can increase the load on your server:
systemctl restart mastodon-streaming



Measurements of a double parking garage for your home.

I got a question about whether it was better to have a 5x6m parking garage or a 6×6 one. Well, it depends on your budget, of course. It also comes down to how comfortable you want your parking to be and if you want additional storage space.

One (5,7m) door is expensive, and when it breaks down, you won’t be able to get in (easily) any more. One 3,5m door requires careful parking but is the cheapest option. Personally, I’d go for two 2.6m wide doors, so both cars can be parked comfortably. It also allows for a 20x20cm centre support beam, which can make your construction lighter and more economical.

If you want more storage space, you can make it 6m deep instead of 5m, but this comes at an extra cost. It doesn’t look like much, but it is an additional 2m of wall and 6m² of floor and (flat) roof.


A working Apache2 server with PHP7.4

I was in need of a server solution that could be quickly deployed as a VM.

      1. Install Debian 11 as a VM with web- and SSH server
      2. Create a USER next to your root account during the installation
      3. Find the IP address of the new installation. The easiest is if you have NoVNC running. Log in as USER and type
        ip a
      4. Time to so the sudo thing

        log in as root

        apt-get update && apt-get install -y sudo
        usermod -aG sudo USER

        log back in as USER

      5. Okay, let’s install some more stuff but first we do an update
        sudo apt-get update && sudo apt-get upgrade -y

        Now we want some essentials

        sudo apt-get install -y dirmngr gnupg2 nano wget gpg curl fail2ban ufw software-properties-common

        Preparing the PHP install

        wget -q -O- | sudo apt-key add -
        echo "deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
        sudo apt-get update
        sudo apt-get install -y php7.4 libapache2-mod-php7.4 php7.4-mysql php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-xmlrpc php7.4-zip

        And restart the Apache2 Webserver

        sudo systemctl restart apache2
      6. Alright, that’s done. Next step is to test things.
        sudo nano /var/www/html/test.php

        Enter this into the php file and press Control X and type Y to save and exit.

        // Show all PHP information
      7. Go to the IP address of the server you just created and type
        HTTP://IP ADDRESS/test.php

        If you see a PHP page with all sorts of data, you’re good. If not, go fix. Don’t ask me, I’m not there yet!


Mastodon: Manual backups

Prepare the folder

  1. Log in as root
  2. cd /home/mastodon
  3. mkdir backups
  4. cd backups

Making the backup

  1. Database (two steps)
    su - mastodon
    pg_dump -U mastodon mastodon_production -F t > DATE_FILENAME.tar
  2. Settings file (two steps)
    cp /home/mastodon/live/.env.production /home/mastodon/backups/DATE_.env.production
  3. Redis
    cp /var/lib/redis/dump.rdb /home/live/backups/DATE_dump.rdb

If you wish to backup your assets like images and stuff (User-uploaded files), backup the folder named “public/system”. Keep in mind that this folder can be rather large. Actually, it can become rather massive.


Garden sheds and stuff

Some stuff I get inspiration from:

Do Not Buy Ted’s 16,000 Woodworking Plans without Reading This

Spoiler: It’s a very terrible scam. More:


Mastodon: “There are pending database migrations. Please run them to ensure the application behaves as expected”

“There are pending database migrations. Please run them to ensure the application behaves as expected” or “Niet alle databasemigraties zijn voltooid. Je moet deze uitvoeren om er voor te zorgen dat de applicatie blijft werken zoals het hoort” can be solved with the following command, executed as user mastodon:

su - mastodon
cd live
RAILS_ENV=production bundle exec rails db:migrate

results in: