Feuerfest

Dall-E

Das Problem

Bekannte erhalten an ihre GMX-Mailadresse eine Mail. Diese enthält klickbare Links. Bei einem Klick landet man jedoch nicht auf der GMX-Weiterleitungsseite und anschließend auf der Seite auf die man eigentlich aufrufen möchte.
Stattdessen bekommt man die Fehlermeldung:

Ups, hier hat sich ein Fehler eingeschlichen...
Fehler-Code: 403

Bei einer web.de Adresse ist es genau so. Gut, das ist zu erwarten, da sowohl GMX als auch web.de zur gleichen Firma gehören und die Webmailer die gleichen sind. Lediglich etwas im Aussehen angepasst.

Stellt sich raus: Man verwendet nun endlich einen Adblocker. In diesem Fall uMatrix. Und uMatrix hat u.a. das Feature sog. HTTP-Referer für andere Seiten zu verbergen.
Normalerweise enthält der Referrer die Adresse der Webseite über die ich auf eine andere Webseite gekommen bin.

Suche ich z.B. auf Google nach einem Problem und klicke auf eine der Webseiten in den Ergebnissen, dann wird der Referrer an die aufrufende Webseite übermittelt. Somit kann man auswerten von wo ein Besucher auf die Webseite kam und wonach er gesucht hat. Durchaus relevante Informationen für viele Webseitenbetreiber. Aber natürlich unter Umständen ein Verlust an Privatsphäre für den Benutzer.

Daher ersetzt uMatrix den Referrer durch einen anderen Wert. Dies ist hier beschrieben: https://github.com/gorhill/uMatrix/wiki/Per-scope-switches#spoof-referer-header

Allerdings basiert die web.de/GMX Weiterleitung der Links auf dem HTTP-Referer. Da uMatrix diese Daten aber ersetzt, weiß die Weiterleitung nicht wohin sie weiterleiten soll und man erhält den Fehler 403 (welcher vermutlich für HTTP-403 Forbidden steht).

Die Lösung des Problems

Die Option das der Referer ersetzt wird nennt sich "Referrer verschleiern" und findet sich im Menü von uMatrix. Dies ist über die 3 Punkte zu erreichen.

Konkret müssen wir bei web.de dies für die Domains navigator.web.de & deref-web.de deaktivieren.
Bei GMX analog für die Domain der Weboberfläche und von deref-gmx.de.

Zuerst öffnen wir die Übersicht von uMatrix indem wir auf das Symbol von uMatrix klicken (üblicherweise rechts neben der Adresszeile).

Schritt 1: Wir ändern den Bereich auf navigator.web.de so das die Änderungen exakt nur für diese Domain gilt. Als Standard ist hier web.de ausgewählt, das wollen wir aber nicht. Also sicherstellen dass das komplette Feld blau hervorgehoben ist.

Schritt 2: Wir klicken auf das 3 Punkte Menü

Schritt 3: Wir deaktivieren die "Referrer verschleiern" Option, so das diese, wie im Bild, ausgegraut ist.

Schritt 4: Anschließend auf das nun blau hervorgehobene Schloß-Symbol klicken um die Änderungen zu speichern.

Nun müssen wir dies noch einmal exakt genau so für die Domain deref-web.de bzw. deref-gmx.de durchführen. Hierzu genügt es einfach auf einen Link in einer Mail zu klicken, so das sich die Seite mit der Fehlermeldung öffnet.

Schritt 1: Wir belassen den Bereich auf deref-web.de bzw. deref-gmx.de. Da wir hier keine Subdomain haben, ist dies bereits korrekt ausgewählt.

Schritt 2: Wir klicken auf das 3 Punkte Menü

Schritt 3: Wir deaktivieren die "Referrer verschleiern" Option, so das diese, wie im Bild, ausgegraut ist.

Schritt 4: Anschließend auf das nun blau hervorgehobene Schloß-Symbol klicken um die Änderungen zu speichern.

Nun am besten zur Sicherheit einmal den Browser komplett beenden, mindestens aber den Tab mit der web.de/GMX Weboberfläche neu laden.

Klickt man dann auf einen Link sollte der gewohnte Weiterleitungshinweis erscheinen und man nach wenigen Sekunden auf der eigentlichen Seite sein.

Dall-E https://admin.brennt.net/bl-content/uploads/pages/dad5b98ab9f04a2cdca5de3afe2f6b0e/dall-e_sudo.jpg

Claudio Künzler, whom I know briefly from working with him on enhancing is check_equallogic back in 2010, wrote an article over at Geeker's Digest on How to use sudo inside SSH command. Of course he mentions the ssh -t parameter, as without it, we would get the following error message when calling sudo: (Example shamelessly stolen from his article. 😇)

ck@linux:~$ ssh targetserver "sudo whoami"
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

And ssh -t is the right call here. Well, to be fair: It's not the only solution and in my eyes even not the best solution.

No, I am not talking about piping the password into the command prompt which is so often recommend as a solution (it's not!) that it makes me sad.

I am talking about the usage of negating requiretty in the /etc/sudoers file or a file under /etc/sudoers.d/ respectively.

Lets take the /etc/sudoers.d/icinga2 file I use in my article How to monitor your APT-repositories with Icinga:

Here I must use NOPASSWD for all executed commands and monitoring plugins as well as the line Defaults:icinga2 !requiretty. This negates the need for a tty for the icinga2 user completely. Omitting either the NOPASSWD or the !requiretty will give us the error message we see above.

root@admin:~ # cat /etc/sudoers.d/icinga2
# This line disables the need for a tty for sudo
#  else we will get all kind of "sudo: a password is required" errors
Defaults:icinga2 !requiretty

# sudo rights for Icinga2
icinga2  ALL=(ALL) NOPASSWD: /usr/bin/unattended-upgrades
icinga2  ALL=(ALL) NOPASSWD: /usr/bin/unattended-upgrade
icinga2  ALL=(ALL) NOPASSWD: /usr/bin/apt-get
icinga2  ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_apt

It's also possible to just negate requiretty based on the path to the binary. As mentioned in this StackExchange question: How to disable requiretty for a single command in sudoers?

However keep in mind that the ordering of lines in a sudoers file is important! Quoting man sudoers from the SUDOERS FILE FORMAT section:

When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match).

Why not just use ssh -t?

Personally I prefer the configuration/setting of sudo-related parameters in an /etc/sudoers.d/ file. My reasons are:

When properly configured via a sudoers file it doesn't matter if a command is called via ssh, ssh -t or any other way. Hence enhancing operational stability and making it easier for users as they don't have to remember adding the -t parameter.

And it, at least, servers as some form of documentation that this user/binary is called from another script/host/etc. giving you a clue that these sudo rights are needed/used for.

Photo by cottonbro studio: https://www.pexels.com/photo/people-toasting-wine-glasses-3171837/

This is an update to my previous blogpost Puppet goes enshittyfication (Updated).

I the meantime the fork has happened. It's called OpenVox (https://github.com/openvoxproject) in reference to VoxPupuli - the name of community of module maintainer, authors and various other contributors around Puppet. But as we all now know, the community is dead. At least for Perforce. Well... As long as they can't get any real money out of it anyways..

The most non-surprising part? As of now there are no officially maintained container images for Puppet anymore.

Martin Alfke's betadots GmbH took over the maintenance of the puppetserver and puppetdb container images. As Puppet by Perforce did abandon them years ago. Now with the fork happening and Puppet effectively being a closed-source software product - and depending on how it develops - little to absolutely no support from Perforce, it simply makes no sense for the betadots GmbH anymore to do the free work for Puppet by Perforce. And they did so effective immediately. Understandably.

Hence they will be maintaining the openvoxserver & openvoxdb container images.

They announced this in a post on their betadots dev.to blog, in german but translation should work well. Read it here: https://dev.to/betadots/das-neue-puppet-open-source-projekt-heisst-openvox-2330

A questionable decision...

This means that in 2025 there are no container images for Puppet with official vendor support.

And as much as I like how this shows the power of a strong open source community...

I can't find a phrase strongly worded enough to describe this utter strategic mismanagement, so just look at this picture instead:

Photo by Photo By: Kaboompics.com: https://www.pexels.com/photo/a-short-haired-woman-holding-a-pair-of-eyeglasses-4491435/

Photo by Kyle Roxas: https://www.pexels.com/photo/crackers-cheese-and-fruits-2122278/

I use LineageOS on my OnePlus 8T. Sadly I still run it with Android 11 and LineageOS 18.1. Which is quite old in 2025. My plans to update the firmware and ROM got postponed again as non-surprisingly: I need my phone.

However one of the new year resolutions I choose is to finally update my mobile so I'm not lacking behind on Android security updates for several years. *ahem*

To de-google or to not de-google?

Along with this a long-standing idea surfaced again: I want to remove as many Google services as possible without having to give up needed tools/services.

Therefore, the first question regarding updating my mobile is: Do I still want to keep using the Google Apps? Or do I want to use another suite of alternative GApps that enhance privacy at the cost of some features? Or do I want to get rid of Google's apps altogether?

Depending on the choice, I can only use some (or all) Google Apps.

The rule of thumb is: The more functionality you need, the more you are paying with your data. The less privacy you have.

On a normal Android phone, the Google apps (YouTube, Maps, Wallet, etc.) are almost always pre-installed. Contrary custom ROMs often can't pre-install these, as a) Google doesn't allow this, and b) nowadays ROM developers know that users choose an alternative ROM to gain more control over their digital life and therefore explicitly want to disable some (or all) features related to Google's services and apps.

Alternative Google apps packages: The agony of choice

For this, several Google Apps packages exist. All vary in features and what they try to accomplish.

The big three in this field are:

• MindTheGapps
• MicroG
• OpenGApps

MindTheGapps

Currently I am running LineageOS with MindTheGapps. Which is their current standard (LineageOS Wiki). MindTheGapps uses the proprietary Google services/packages. It just servers as an installer for the official Google packages. This means you can use the Google Play store, Google Maps, every method of authentication with Google Firebase (more relevant than you might think), and the SafetyNet (here is a good site with a presentation, whitepaper & lectures about SafetyNet - also known as DroidGuard) feature on which banking apps often rely. Among all other Google services.

The downside? Google happily leeching as much data from you as they do.
But helpful if you just want a custom ROM and no hassle with non-working apps.

MicroG

A viable alternative is MicroG. MicroG is, to quote the project itself, "A free-as-in-freedom re-implementation of Google’s proprietary Android user space apps and libraries." This means MicroG is a redevelopment to match the functionality while keeping privacy-harming features out. This also means that privacy-focused ROMs like CalyxOS include them and allow users to choose if they want to activate them.

There is an overview about the implementation status of each feature in the MicroG apps: https://github.com/microg/GmsCore/wiki/Implementation-Status. And it also serves as a good example: In MicroG, two Firebase authentication methods are currently not supported. This means if an app you use only uses these two methods, you won't be able to sign in. It's generally advisable to check your important apps if they work with MicroG or not.

The neat thing is that MicroG uses signature spoofing to present itself as the Google apps. Additionally, the long-standing issue with allowing signature spoofing in LineageOS has been fixed recently. This means that if MicroG is installed via F-Droid and the app package is signed with the signature from the MicroG development team, LineageOS allows MicroG to spoof the signatures. Which eliminates many long-standing issues.

The neat thing is: This allows us to simply install MicroG via F-Droid and be done with it. No more incorporating the MicroG image during the flash process.

Information about their F-Droid repository can be found here: https://microg.org/fdroid.html

Please, only install MicroG from their own repository. Don't install it from the PlayStore or other GitHub repositories. It's common to find Malware posing as the official MicroG package. One such example is documented in this Reddit-Thread: https://www.reddit.com/r/MicroG/comments/1icxc8h/malware/

And here is an interview with the MicroG developer about how it all came to be: https://community.e.foundation/t/microg-what-you-need-to-know-a-conversation-with-its-developer-marvin-wissfeld/22700

OpenGApps

Honestly, I still did know this project from when I first flashed my phone. And it was the first project I had a looked after. But sadly it seems that development is currently very slow.

The last news post is from August 23, 2019.
Android 11 is the last supported OS version, according to their homepage.
The last update in their SourceForge repository happened on May 3rd, 2022. Stating that support for Android 11 is, for most variants, still in the testing phase. According to their GitHub issues, some support for Android 12 should be there, but I didn't dig deeper into this.

In this GitHub issue, it's stated that they currently suffer from a lack of supporters/maintainers and have problems with their build server infrastructure, etc.

Therefore, I didn't look any deeper into this. If you want: Here is a link about what package contains which features: https://github.com/opengapps/opengapps/wiki/Advanced-Features-and-Options

Google Play store alternatives

Now that we have decided which package we want to use, we probably want to quit using the Google Play Store. After all, the more Google apps we replace, the less we are dependent on their services running on our phone.

Luckily, there are two app store alternatives that solve all our problems together.

F-Droid

F-Droid is the most commonly used alternative app store. It focuses on OpenSource software, rebuilding the .apk packages from the official repositories. Undesired features such as tracking, ads, or proprietary code are listed on the apps' site. However, due to hosting all files themselves and having a focus on privacy and OpenSource they have their own inclusion policy, which apps need to fulfill in order to be added to F-Droid. Hence, many commercial apps simply can't be added as they either directly use Google's Play services or other proprietary software to build their app. Or the company simply doesn't agree to being hosted on F-Droid.

This has the direct result that many popular apps will & can never be available on F-Droid. Which leads us to...

Aurora OSS

Aurora OSS is another Google Play store alternative. One that is even usable with and without Google services or even MicroG. As Aurora is directly accessing the Google Play store you can download all apps, even the ones you paid for - as long as you log in with your Google account.

For the rest. I recommend reading their project description: https://gitlab.com/AuroraOSS/AuroraStore. The "nicer" looking URL is https://auroraoss.com/; however, this is just to forward you to their GitLab project.

There is however a report that a freshly created Google account that solely used Aurora got deleted after just two hours: https://www.reddit.com/r/degoogle/comments/13td3iq/google_account_deleted_after_2_hours_of_aurora/ and https://news.ycombinator.com/item?id=36098970

But then again, this was the only big reporting on that matter. So I can't really tell what will happen to accounts which are also used for YouTube. Or that have paid apps in the Play store connected to their account.

This discussion on Reddit provides a little bit of insight as to why this could happen to an account.

Conclusion

Aurora combined with F-Droid means we have a solution to get any and all apps we need.

And even if you plan on flashing your Android device or not. Both app stores can be used on any phone. Allowing you to test them out prior to making any fundamental changes to your phone.

Side note: Vanishing developers

While doing my research for this article, I spent some time in the XDA developers forum, on GitHub, GitLab instances, and even SourceForge. And I noticed a constantly reoccurring pattern: many of the developers simply stopped being present in the last few years. No new posts in the XDA Developers forum. No activity on GitHub, etc.

Now it's not uncommon for OpenSource projects to lose contributors or even main project developers. After all, people do have a job, a family, a life. And somehow they need to earn money. Nothing surprising about that.

But I additionally noticed that many seem to be male and of Russian nationality. Given the fact that the Russian attack on Ukraine started in February 2022 and many developers went silent in the last 2-3 years, I have a bad feeling that many of them were conscripted into the Russian army.

Let's just hope that I am wrong...

Photo by Kevin Ku: https://www.pexels.com/photo/data-codes-through-eyeglasses-577585/

Just a short post if someone else stumbles about this.

I use GoAccess to view my Apache logfiles on the command line. Now I got an error which I never encountered before.

Token 'host.somedomain.tld' doesn't match specifier '%h'

Strange. I use the standard CustomLog format line from Apache. Also known as "NCSA Combined Log Format". Which is what I choose in GoAccess to open the logfile.

Long story short: If you run an older version there is a bug in GoAccess. If the first line in the logfile doesn't start with an IPv4 or IPv6 you will get the error above.

I got the error with version 1.4, updated to 1.7 and the error was gone. Most likely just a bad regular expression.

Photo by Erik Mclean: https://www.pexels.com/photo/a-room-with-black-and-white-seats-8266814/

Pixelfed's creator Daniel Supernault recently published an open letter addressed at Mark Zuckerberg. The reason being that posts containing links to Pixelfed are marked as Spam by Facebook/Meta and are deleted immediately (404 Media on the topic).

My opinion? The open letter is written exactly in the way it needs to written. Read it for yourself:

Dear Mark,

I hope this finds you well. I noticed something interesting today – it seems Instagram is blocking links to my little open-source project. You know, the one that lets people share photos without harvesting their personal data or forcing algorithmic feeds on them.

I have to admit, I’m flattered. Who would’ve thought a small team of volunteers could build something that would catch your attention? We’re just trying to give people a choice in how they share their memories online. No VCs, no surveillance capitalism, just code and community.

Remember when Facebook started? It was about connecting people, not maximizing engagement metrics. Our project might be tiny compared to Instagram, but we’re staying true to that original spirit of social media – giving people control over their online presence without turning them into products.

You could’ve ignored us. Instead, by blocking our links, you’ve given us the best endorsement we could ask for. You’ve confirmed what we’ve been saying all along – that big tech is more interested in protecting their walled gardens than fostering genuine innovation.

Every time you block a link to our platform, you remind people why we built it in the first place. Your action tells them there are alternatives worth exploring, ones that respect their privacy and agency. So thank you, Mark. You’ve turned our little project into a symbol of resistance against digital monopolies.

Perhaps one day you’ll remember what it felt like to be the underdog, building something because you believed in its potential to make the internet better. Our doors are always open if you want to remember what that feels like.

Best regards,

Daniel Supernault

P.S. Keep blocking those links. Every error message is just free advertising for the social web.

This again brought up a topic: How do I treat companies/social networks that literally block the competition?

Easy answer: I avoid them. Or migrate away from them. Then I delete all my data from their network and stay away from them. Sometimes even going so far as to add their domains to my DNS-Blocklist, so I never ever accidentally browse their site again.

Why?

I don't like being forced into a cage. The term "Internet" stands for interconnected networks. Attempting to create isolated "walled gardens" contradicts my core beliefs about how the Internet should function. If platforms like Facebook/Meta or Twitter/X try to oust the competition I'll gladly start using the competition - provided they uphold the principles of openness and connectivity.

There is a straightforward and logical rationale for this: The Internet is immense, and no single service can encompass everything - whether in terms of functionality or content. If a platform chooses to isolate itself in an effort to retain its users, it has every right to do so. However, it must also acknowledge the consequence of losing a few users along the process.