Probleme beim Deployen zu Maven Central

Im Rahmen einiger Wartungsarbeiten wollte ich eine neue Version einer Java-Bibliothek zu Maven Central deployen. Stattdessen wurde ich von der Meldung:

Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy failed: An API incompatibility was encountered while executing org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy: java.lang.ExceptionInInitializerError: null

überrascht. Am dahinterliegenden Problem wird bereits gearbeitet. Um das Deployment trotzdem durchführen zu können, eignet sich folgender Workaround:

export MAVEN_OPTS="--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED"
mvn deploy

Anschließend wird das entsprechende Deployment durchgeführt, was je nach Auslastung einige Minuten dauern kann.

Konfiguration der DOSBox unter macOS

Ab und an nutze ich die DOSBox, um ein paar alte Klassiker unter macOS wieder zu spielen. In letzter Zeit ist dies öfter passiert, sodass mir zwei Dinge an der DOSBox störend aufgefallen sind. Das erste ist die englische Tastaturbelegung und das zweite ist das manuelle mounten des Ordners mit den entsprechenden Spielen. Glücklicherweise können diese beiden Probleme durch die DOSBox-Konfiguration gelöst werden. Diese befindet sich unter macOS im Library-Ordner. In einem Editor der Wahl geöffnet:

nano "~/Library/Preferences/DOSBox 0.74-3-3 Preferences"

können die entsprechenden Optionen aktiviert werden. Für ein deutsches Tastaturlayout ist dies der Parameter keyboardlayout=gr in der Sektion dos:

[dos]
xms=true
ems=true
umb=true
keyboardlayout=gr

Damit das gewünschte Verzeichnis automatisch gemountet wird, gibt die autoexec-Sektion:

[autoexec]
mount c: /Users/seeseekey/Games/

Dort kann ein entsprechender mount-Befehl definiert werden, welcher in diesem Fall das Verzeichnis an den Laufwerksbuchstaben C bindet und es damit innerhalb der DOSBox beim Start derselbigen sofort verfügbar macht.

Themes für Visual Studio Code an Systemvorgabe anpassen

Mittlerweile unterstützen viele Betriebssysteme einen Dark-Modus, in welchem das System ein dunkles Theme wählt, mit welchem der Nutzer in den dunklen Stunden nicht geblendet werden soll. Auch die automatische Umstellung, je nach Tageszeit, ist in den meisten Betriebssystemen, wie z.B. macOS einstellbar. Die entsprechenden Apps können dann auf diese Systemvorgabe reagieren. Der freie Codeeditor Visual Studio Code, ist standardmäßig mit einem dunklen Theme konfiguriert.

Die entsprechende Einstellung im Editor

Allerdings unterstützt Visual Studio Code auch die automatische Auswahl des Themes auf Basis der Systemvorgabe. Dazu muss in den Einstellungen nach dem Wert:

window.autoDetectColorScheme

gesucht werden und dieser gesetzt werden. Anschließend wählt Visual Studio Code das passende helle oder dunkle Theme anhand der Systemvorgabe. Wem die Standardthemes nicht zusagen, der kann über die Parameter workbench.preferredLightColorTheme und workbench.preferredDarkColorTheme in den Einstellungen die entsprechenden Themes setzen.

Warum der SNEScast nicht auf Spotify zu finden ist

Für den SNEScast, unseren Podcast rund um das Super Nintendo Entertainment System, haben wir am Anfang überlegt, wo genau wir ihn anbieten wollen. Hauptsächlich ging es darum, ob wir ihn auch auf Spotify anbieten wollen. Nach einigen Überlegungen und etwas Recherche sind wir dann zu einem Schluss gekommen das wir dies nicht wollen. Doch was sind dafür die Gründe?

Der SNEScast Podcast ist nicht auf Spotify zu finden

Dafür vielleicht ein Blick darauf was einen Podcast in seinem Wesen ausmacht. Der Ersteller eines Podcasts stellt Audiodateien für die einzelnen Episoden und dazu einen RSS-Feed zusammen. Dieser Feed kann über einen Podcatcher abonniert werden. Er enthält alle notwendigen Informationen über den Podcast und die Links zu den Audiodateien. Damit hat der Ersteller des Podcasts die Kontrolle darüber welche Inhalte ausgeliefert werden. Podcast-Verzeichnisse wie iTunes bzw. mittlerweile Apple Podcasts respektieren diesen Gedanken. Die Inhalte werden auch dort durch die Server des Erstellers ausgeliefert; das Verzeichnis nutzt den Feed nur zur Anzeige des Podcasts im Verzeichnis. Damit erhält der Ersteller des Podcasts, anhand seiner Zugriffsstatistiken ein Bild darüber wie sein Podcast oder gar einzelne Episoden ankommen.

Wie funktioniert ein Podcast?

Spotify hingegen ist eine mehr oder weniger geschlossene Plattform, welche versucht Podcasts für sich zu vereinnahmen. Für diese Plattform darf der Ersteller des Podcasts seine Inhalte liefern und sich dafür den Beschränkungen der Plattform unterwerfen. Am Anfang konnten nur ausgewählte Individuen einen Podcast auf Spotify bringen, mittlerweile gibt es ein entsprechendes Portal um dies zu tun. Wenn der Podcasts nicht bei einem sogenannten zertifizierten Hostingpartner gehostet wird, erhält über den RSS-Feed und die Zugriffe auf die einzelnen Episoden keine Informationen darüber wie oft sie gehört wurden. Der Hintergrund ist das Spotify die Dateien selbst vorhält um eine entsprechende Servicequalität für sich in Anspruch nehmen zu können.

Daneben hat Spotify noch einige andere Probleme, es ist schlicht und ergreifend kein Podcast-Client. Die gesamte App ist darauf optimiert Musik zu streamen. Kaptitelmarken in Podcasts? Fehlanzeige. Das Offline-Hören von Podcasts bei Spotify ist zwar möglich, aber etwas umständlich und nur für Premium-Nutzer verfügbar. Und dann sind da noch die Nutzungsbedingungen für die Spotify for Podcaster-Plattform, die eine Lizenz vorgeben, die nicht jeder Podcast bereit ist einzugehen.

Aus der dezentralen Podcast-Welt wird mit Spotify eine Plattform zentraler Podcasts und das ist etwas, was wir mit dem SNEScast nicht unterstützen wollen. Natürlich kann es dadurch sein, dass der eine oder andere Hörer auf der Strecke bleibt, aber so hat er die Freiheit den SNEScast mit einem Podcatcher seiner Wahl zu hören und die Podcast-Welt bleibt etwas dezentraler. Es sollte nicht passieren das Spotify und Podcasts synonym werden, den das sind sie nicht. Natürlich, wenn ich Spotify habe, warum sollte ich mir zusätzlich noch einen Podcatcher installieren?

Und so begeben wir uns in einen Vendor-Lockin den wir für Podcasts nicht sehen wollen. Wenn Spotify beschließt, dass der eigene Podcast nicht mehr genehm ist und ihn von der Plattform entfernt, verliert der Podcasts so im schlimmsten Fall einen Großteil seiner Hörer. Auch dies ist ein Problem von zentralen Plattformen im Gegensatz zu einem dezentralen offenen System. Ansonsten ist der Podcast der Plattform völlig ausgeliefert. Daneben gehört Spotify mit dem Anchor bereits ein Dienst, der Podcasts-Hosting anbietet und bei denen knapp die Hälfte aller Podcastsfeeds hostet.

So bleibt nur der Appell: installiert euch einen Podcatcher und abonniert eure Lieblingspodcasts direkt beim Ersteller. Sie werden es euch danken.

Fail2ban für WordPress einrichten

Beim Betrieb eines Servers wird der Nutzer schnell feststellen, dass er nicht der einzige ist, der gerne Zugriff auf den Ser­ver hätte. Um zu häu­fige Log­in­ver­su­che abzu­blo­cken, gibt es Fail2ban. Die­ses Pro­gramm­pa­ket durch­sucht die ent­spre­chen­den Logs und blockiert bös­wil­lige Ver­su­che, in das Sys­tem ein­zu­bre­chen. Damit gehört Fail2ban zu den Intru­sion Preven­tion-Sys­te­men. Damit kann es auch zur Auswertung von Login-Versuchen auf die eigenen WordPress-Installationen genutzt werden. Wer in die Logs schaut, wird dort ähnliche Zeilen finden:

18.217.216.181 – – [23/Nov/2021:19:32:40 +0100] „POST /wp-login.php HTTP/1.1“ 200 8408 „https://seeseekey.net/wp-login.php“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0“

Um WordPress mit Fail2ban zu verheiraten muss ein einsprechender Jail und ein Filter angelegt werden. Was mich im Vorfeld in Bezug auf WordPress irritierte war der Statuscode 200, wenn ein Login in WordPress fehlschlägt. Hintergrund ist hier das WordPress bei einem erfolgreichen Login stattdessen den Statuscode 302 (Found) nutzt. Damit kann im ersten Schritt der Jail für Fail2ban erstellt werden:

nano /etc/fail2ban/jail.d/wordpress.conf

Diese Datei wird nun wie folgt befüllt:

[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 3

Anschließend muss der genutzte Filter ebenfalls angelegt werden:

nano /etc/fail2ban/filter.d/wordpress.conf

Der entsprechende Filter sieht wie folgt aus:

# Filter for WordPress login

[INCLUDES]

before = common.conf
 
[Definition]

failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 200

datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

Nach einem Neustart von Fail2ban mittels:

service fail2ban restart

ist der neue Jail aktiv. Über das Log kann die Arbeit desselben betrachtet werden:

tail -f /var/log/fail2ban.log

Damit sind die WordPress-Installationen gegen den Versuch unbefugter Logins besser abgesichert. Nach drei Fehlversuchen, wird die entsprechende IP-Adresse gesperrt, sodass weitere Verbindungsversuche von dieser IP-Adresse vom Server nicht mehr beantwortet werden.