Mit Windows 10 2004 wurde die Version 2 von Windows Subsystem for Linux (WSL 2) veröffentlicht.
Diese verbessert die Linux Variante unter Windows weiter, da nun ein echter Linux Kernel verwendet wird.

Installation WSL2

Die Installation von WSL2 ist relativ einfach zu bewerkstelligen, es reichen ein paar Befehle in der Powershell Konsole aus:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Danach erscheint die Meldung:

WSL 2 erfordert ein Update der Kernelkomponente. Weitere Informationen finden Sie unter https://aka.ms/wsl2kernel

Diese Installation müsst ihr manuell tätigen, um das Update abzuschließen. In Zukunft möchte Microsoft solche Updates direkt über das Windows Update ausrollen.

Zum Abschluss muss in der Konsole auf die neueste Version umgestellt werden.

wsl.exe --set-default-version 2

Ein Download von Ubuntu oder Kali Linux kann direkt über den Store erfolgen.

WSL2 Tipps

Es gibt ebenfalls die Möglichkeit Installationen unter verschiedenen WSL Versionen laufen zu lassen

wsl.exe --set-version Distributionsname 2

Infos über die installierten Distributionen lassen sich ebenfalls anzeigen

wsl.exe -l –v

  NAME            STATE           VERSION
  * kali-linux      Stopped         2
    Ubuntu-18.04    Running         2

Wer es bunter mag, der kann auch wslfetch ausführen, dieses funktioniert momentan allerdings nur bei Ubuntu Installationen.

wslfetch

Im Windows Explorer kann das Home Verzeichnis der installierten Systeme mit \\wsl$\ aufgerufen werden.

\\wsl$

Es lassen sich ebenfalls Installationen exportieren und auf anderen Windows Installationen wieder importieren.

wsl.exe --export Linux ./export.tar

wsl.exe --import Linux Importverzeichnis ./export.tar --version 2 

Eine bestehende Installation lässt sich wie folgt löschen.

wsl.exe --unregister Linuxinstallation

Ausblick

WSL soll in Zukunft weiter ausgebaut werden und beispielsweise NVIDIA CUDA unterstützen.

Auch die Installation soll stark vereinfacht werden, so wird wohl in Zukunft ein einfaches Kommando für Installation und ein Update genügen, wie Bleeping Computer berichtet.

wsl.exe –- install
wsl.exe -- update

LTS Distributionen sind für mich das Maß der Dinge. Lange Produktlaufzeiten, wenig Wartungsaufwand und hohe Funktions- und Laufzeitstabilität sind nicht nur im Servereinsatz wichtig. Trotz hunderter Distributionen gibt es nur wenige LTS-Varianten (siehe: Linux - Eine sichere Basis). Mit CentOS steht hier ein weiteres Projekt vor dem Ausfall.

Natürlich sind Arch, Manjaro, Tumbleweed und wie sie alle heißen tolle Projekte und für den individuellen Desktopeinsatz gut geeignet. Ich glaube auch gerne, dass viele nie oder nur extrem selten Probleme bei Updates haben. Sie taugen aber kaum für den wartungsarmen Masseneinsatz, wo der Anwender nicht selbst die Administration übernehmen kann oder will.

Es braucht diese ständigen Updates eigentlich auch nicht. Linux auf dem Desktop ist im Wartungsmodus (siehe auch: Kein Ubuntu 20.04 Test). Ob ich nun GNOME Shell 3.32 oder 3.28 verwende macht weder funktional, noch von der Stabilität einen Unterschied. Das gleiche gilt für Plasma, LibreOffice und viele weitere Projekte. Relevant sind über eine lange Laufzeit lediglich neue Treiber für neue Hardware (entweder über massive Kernel-Modifikation durch den Distributor oder neue Kernel-Versionen) und neue Browser-Versionen.

Ich habe deshalb - sofern der Anwender mit GNOME klar kam - CentOS auch für den Desktop immer gemocht. 10 Jahre Ruhe am System sind einfach eine Hausnummer. Im Serverbereich dürfte CentOS neben Ubuntu LTS und Debian ebenfalls für viele eine maßgebliche Rolle spielen.

Wie Michael Kofler in seinem Blog aber zu recht thematisiert fällt CentOS 8 inzwischen für den Produktiveinsatz eigentlich aus. 71 und 48 Tage ohne Updates sind indiskutabel. Das Projekt scheint hier leider auch nicht willens oder fähig etwas zu ändern.

Im LTS Bereich wird es jetzt eng. Die sehr lange Supportdauern von 10 Jahren bietet nun nur noch SLED gegen eine - preislich allerdings vollkommen akzeptable - Subscription. Wer mit circa 3-5 Jahren leben kann hat noch Debian, openSUSE Leap und Ubuntu LTS zur Auswahl. Viel ist das nicht mehr. Gegebenenfalls muss man sich wirklich mit Oracle Linux beschäftigen, auch wenn sich dabei alle Nackenhaare aufstellen.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay

Google und Apple sind spätestens seit dem Erscheinen von Android 2008 Konkurrenten. In einem Punkt hat sich Google aber scheinbar ein Beispiel an Apple genommen: Wie man ein freies System so mit proprietären Bestandteilen zersetzt, dass der Open Source Charakter ins Absurde verkehrt wird. Dadurch profitiert man von freien Projekte ohne zurückgeben zu müssen.

Apples macOS ist nämlich auch so ein Zwitter. Es basiert im Kern auf Darwin und dieses steht unter APSL. Eine von deer OSI und FSF anerkannten freien Lizenz. Obwohl Darwin Open Source ist, kann man damit nichts machen. Apple gibt den Quellcode frei, allerdings fehlen das interne Build System, es ist schlecht dokumentiert und versuche der Gemeinschaft mit OpenDarwin oder PureDarwin einen freien und funktionierenden Abkömmling zu bauen scheiterten. Dessen ungeachtet gibt es natürlich einige Projekte von Apple (oder durch Apple aufgekauft), die weiterhin Open Source sind und der Commmunity zur Verfügung stehen. CUPS wäre hier ein Beispiel, WebKit mit Abstrichen ebenfalls.

Man kann sich des Eindrucks nicht erwehren, dass Google mit Android etwas ähnliches vorhat. Android wird zunehmend unfreier (siehe: Android wird unfreier - Alternativen nicht in Sicht). Jetzt hat man seitens Google auch entschieden die Schnittstelle für die Corona App in die proprietären Play Services einzubauen, weshalb freie Android-Varianten außen vor bleiben - obwohl die RKI-App an sich Open Source ist. Die proprietären Bestandteile nehmen immer größere und grundlegendere Ausmaße an und AOSP wird immer mehr zum Kernsystem herabgedrückt. Der Weg zum Status von Darwin ist da nicht mehr weit.

Meist heißt es, die Probleme Updates an die Anwender zu verteilen wären die Ursache für die Verteilung aller möglichen Sachen via Play Store. Aber Google bemüht sich ja auch nicht sonderlich die katastrophale Update-Situation in den Griff zu bekommen. Stattdessen verlagert man immer mehr in die Play Services und den Play Store und unterminiert die Funktionsfähigkeit der freien Instanz. Man kann sich des Eindrucks nicht erwehren, dass Google sich hier bequem in der Update-Situation eingerichtet hat und nicht traurig über die Zwangsverlagerung in den Play Store ist.

Wie wenig Bedeutung Open Source für Google noch hat zeigt die Lizenzfrage um die Billing Library 3, die entgegen der ersten beiden Versionen Closed Source ist. Entwickler müssen dann Klimmzüge machen, wenn sie ihre Projekte sowohl via F-Droid, als auch kostenpflichtig via Play Store verteilen möchte. Eine bisher nicht unübliche Vorgehensweise.

Kritik wird aus der Open Source Gemeinschaft trotzdem nicht zu laut kommen. Schließlich hat Google mit Förderungen wie den GSoC, den Verträgen mit Mozilla und Sachen wie Project Zero viele Projekte in eine monetäre Abhängigkeit von Google gebracht.

Nutzer freier AOSP Systeme müssen deshalb auf die Corona App verzichten.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay 

Das Standalone-VPN des Firefox Private Networks wird in Kürze die Betaphase verlassen und damit offiziell Mozillas Produkt-Portfolio erweitern – dann unter neuem Namen: Mozilla VPN.

Mit dem Firefox Private Network hat Mozilla Ende des vergangenen Jahres die Beta-Phase seines eigenen VPN-Angebots gestartet. Wie Mozilla heute angekündigt hat, wird das Standalone-VPN in den nächsten Wochen die Betaphase verlassen und damit offiziell einen Platz in Mozillas Produkt-Portfolio einnehmen.

Standalone-VPN: Mozilla VPN

Mit dem Start der finalen Version wird das Standalone-VPN, für welches Mozilla mit dem schwedischen VPN-Anbieter Mullvad zusammenarbeitet, von der Firefox-Marke losgelöst und dann als Mozilla VPN vermarktet werden, um so eine größere Zielgruppe anzusprechen und sich klarer von der bisher gleichnamigen Firefox-Erweiterung zu unterscheiden.

Den aktuellen Preis von 4,99 Dollar pro Monat wird Mozilla für eine begrenzte Zeit beibehalten. Damit können bis zu fünf Geräte gesichert werden. Wie viel das VPN danach kosten wird, steht zu diesem Zeitpunkt noch nicht fest, genauso wie noch nicht bekannt ist, wann das VPN auch hierzulande zur Verfügung stehen wird. Mozilla möchte in diesem Jahr noch in mehreren ausgewählten Regionen starten, natürlich beginnend mit den USA, wo bereits der Beta-Test läuft.

Das Mozilla VPN steht für Windows, Google Android, Google Chromebooks sowie Apple iOS zur Verfügung, Versionen für Apple macOS sowie Linux sollen folgen.

Firefox-Erweiterung: Firefox Private Network

Auch bezüglich Mozillas Firefox Private Network Browser-Erweiterung, für welche Mozilla mit Cloudflare zusammenarbeitet, gibt es Neuigkeiten. Hier wird man in Kürze von der kostenlosen in die kostenpflichtige Betaphase übergehen, welche den Nutzer 2,99 Dollar pro Monat kosten wird. Statt wie bisher nur auf einem können Nutzer dann mit einem Account auf bis zu drei Geräten gleichzeitig mit dem VPN verbunden sein. Auch die Erweiterung ist zunächst nur in den USA verfügbar und soll bald auch in weiteren Märkten ausgerollt werden.

Ausbau des Produkt-Portfolios

Mit dem Mozilla VPN und dem Firefox Private Network erweitert Mozilla sein Produkt-Portfolio rund um das Thema Privatsphäre und Sicherheit und schafft damit gleichzeitig eine zusätzliche Einnahmequelle, um so unabhängiger von den Einnahmen durch Suchmaschinen-Partner zu werden. Neben dem Einzel-Abonnement für das Firefox Private Network erwägt Mozilla für die Zukunft auch das Anbieten eines Privatsphäre- und Sicherheits-Paketes für Firefox, welches die VPN-Erweiterung mit weiteren Angeboten bündelt.

Der Beitrag Firefox Private Network wird zu Mozilla VPN erschien zuerst auf soeren-hentzschel.at.

Da eingebaute optische Laufwerke im Jahr 2020 immer seltener werden, musste ich heute einen externen CD/DVD-Brenner benutzen, um eine Audio-CD zu brennen. Leider brach Brasero immer noch vor dem Schreibversuch ab.

BraseroWodim stderr: wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
BraseroWodim called brasero_job_get_flags
BraseroWodim stdout: TOC Type: 0 = CD-DA
BraseroWodim stderr: wodim: Resource temporarily unavailable. Cannot get mmap for 16781312 Bytes on /dev/zero.
BraseroWodim called brasero_job_get_flags
BraseroWodim stderr: HUP
BraseroWodim stdout: HUP
BraseroWodim process finished with status 11
BraseroWodim called brasero_job_error
BraseroWodim finished with an error
BraseroWodim asked to stop because of an error
	error		= 0
	message	= "no message"

Die Fehlermeldung allein war leider nicht besonders hilfreich, ich stieß jedoch nach einigem Suchen auf jemanden, der das gleiche Problem wie ich zu haben schien und eine Lösung präsentieren konnte.

Scheinbar stimmen die wodim-Zugriffsrechte unterhalb von /usr/bin bei Ubuntu ab Werk nicht.

Nach dem Anpassen der Zugriffsrechte mittels

sudo chmod 4711 /usr/bin/wodim /usr/bin/cdrdao /usr/bin/growisofs

lief der Brennvorgang sauber durch.

Meine Rechner sind mittels cryptsetup und luks verschlüsselt. Bei meinem Notebook habe ich das schon vor Jahren gemacht, so dass hier immer noch luks in Version 1 verwendet wird. Bei luks in Version 2 wird allerdings Argon2 verwendet, was einen Angriff mittels Brute Force erheblich erschwert.

Wie kann man nun auf Version 2 wechseln ohne die Partitionen neu verschlüsseln zu müssen?

Als erstes sollte man überprüfen ob man nicht schon Version 2 nutzt. Dies erreicht man mit folgendem Befehl:

cryptsetup luksDump /dev/sda2 | grep -A1 "^LUKS"

Anstelle von /dev/sda2 muss man seine verschlüsselte Partition angeben. Dies gilt auch für alle weiteren Befehle. Wird hiermit Version: 2 angezeigt kann man sich weitere Schritte sparen. Wenn Version: 1 angezeigt wird, geht es weiter und man sollte man als erstes den Header sichern. Denn geht etwas schief kommt man nicht wieder an seine Daten. Zum Sichern führt führt man folgenden Befehl aus:

cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file sicherung.dat

Die Datei sicherung.dat kopiert man anschließend auf einen USB-Stick oder auf einen anderen Rechner, da dies neben der Datensicherung (die natürlich jeder regelmäßig erstellt…) unsere Versicherung ist.

Nun geht es ans Eingemachte. Der folgende Befehl konvertiert luks 1 zu luks 2.

cryptsetup convert /dev/sda2 --type luks2

Nun nutzt die verschlüsselte Partition luks 2. Allerdings wird für das Passwort erst einmal nicht Argon2 verwendet sondern das was man ursprünglich angegeben hat. In meinem Fall pbkdf2. Also ist noch ein Befehl nötig um dies zu ändern.

cryptsetup luksChangeKey /dev/sda2 --pbkdf argon2id

Hierbei wird man aufgefordert sein bisheriges und ein neues Passwort einzugeben. Es ist aber auch möglich als neues Passwort erneut sein altes Passwort einzugeben.

Ein abschließender Test mittels cryptsetup luksDump /dev/sda2 sollte nun zum einen Version: 2 als auch die Verwendung von Argon2id anzeigen. Nutzt man mehrere Schlüssel, muss man den Befehl mit luksChangeKey für jeden Schlüssel wiederholen.

Funktioniert nach einem Neustart des Rechners alles wie gewohnt, sollte man vorsichtshalber noch die Header-Sicherung löschen.

Seit gestern ist CentOS 8.2 (genaugenommen »CentOS Linux 8 (2004)«) verfügbar. CentOS 8 ist eine von Red Hat Enterprise Linux (RHEL) abgeleitete Distribution, die in der Vergangenheit über einen Zeitraum von 10 Jahre Updates versprach. Mittlerweile sind auf https://centos.org keine klaren Aussagen zum Life Cycle mehr zu finden. Stattdessen weisen die FAQs darauf hin, dass man versucht, Minor Releases von RHEL innerhalb von vier bis acht Wochen nachzubilden.

Dessen ungeachtet hat die Update-Versorgung für CentOS 7 immer ziemlich gut funktioniert, auch wenn es zwischen den Minor Releases zu einer Lücke in der Update-Versorgung von üblicherweise 4 bis 5 Wochen kam.

Deutlich schlechter sieht die Aktualisierung von CentOS 8 aus. Seit CentOS 8.0 im Sep. 2019 erschienen ist (von heute aus gerechnet vor 266 Tagen), hat es über 147 Tage Updates gegeben, während zwei Zeiträumen von insgesamt 119 Tagen aber keine Updates.

Technische Hintergründe

Wo ist eigentlich das Problem? Dass CentOS 8.2 erst 48 Tage nach RHEL 8.2 fertig wurde, wäre den meisten CentOS-Anwendern vermutlich ziemlich egal. Allerdings kann CentOS im Zeitraum zwischen dem RHEL-Minor-Release und dem entsprechenden CentOS-Minor-Release auch keine Updates zur Verfügung stellen. Die Update-Versorgung setzt voraus, dass das gesamte Minor Release nachgebaut werden kann — und das ist (auch wegen der mit RHEL 8 eingeführten Modularisierung) aufwändig.

Anders formuliert: Jedes Mal, wenn RHEL ein neues Minor Release vorstellt, unterbricht CentOS (und übrigens auch Oracle Linux) die Update-Versorgung, bis die eigene Variante des Minor Release fertig ist. CentOS-Anwender mussten ihre Systeme deswegen von Nov. 2019 bis Jän. 2020 (71 Tage) und von April 2020 bis Juni 2020 (48 Tage) ohne Updates betreiben.

Dass es schneller geht, beweist Oracle. Das Minor-Release 8.1 wurde innerhalb von 10 Tagen veröffentlicht, jenes für 8.2 innerhalb von 8 Tagen.

Anmerkung: Eigentlich gibt es gar kein »CentOS 8.1« oder »CentOS 8.2«. Stattdessen heißen die Versionen »CentOS Linux 8 (1911)« bzw. »CentOS Linux 8 (2004)«, wobei sich die Nummer 1911 oder 2004 auf Jahr und Monat des entsprechenden RHEL-Release beziehen. Der Einfachheit halber bleibe ich in diesem Artikel aber bei den durch RHEL vorgegebenen Versionsbezeichnungen.

Firmenpolitik

Red Hat hat sich das CentOS-Entwicklerteam 2014 einverleibt. Das kann man positiv sehen (Red Hat zahlt die CentOS-Entwickler), oder kritisch.

Mein persönlicher Eindruck ist, dass Red Hat (inzwischen genaugenommen IBM) CentOS zu Tode spart. Gleichzeitig müssen die wenigen Kapazitäten auch noch für neue Aufgaben (CentOS Stream) ausreichen.

Die unausgesprochene Wahrheit lautet: Wer Red Hat produktiv einsetzen will, soll dafür zahlen und nicht in Versuchung geführt werden, CentOS zu verwenden. Möglicherweise wird das dem anderen noch verfügbaren RHEL-Klon, nämlich Oracle Linux, neuen Auftrieb schaffen.

Fazit: Für den Produktiveinsatz nicht mehr geeignet

Der wochenlange Betrieb eines Servers ohne Update ist aus Sicherheitsgründen nicht zu empfehlen. Nun muss natürlich jeder Administrator für sich entscheiden, was zu lange ist: Zwei Tage ohne Updates? Zwei Wochen? Zwei Monate?

Wer Server für milliardenschwere Unternehmen oder für kritische Infrastruktur betreibt, ist diesbezüglich schon bisher keine Kompromisse eingegangen und hat eben eine Lizenz für RHEL erworben. Aber für eine kleinere Firmenwebsite war CentOS 7 in der Vergangenheit aus meiner Sicht ein tragbarer Kompromiss (und ist es bis heute). Für CentOS 8 ist das nicht mehr der Fall.

Damit wurde CentOS 8 zur Test- und Unterrichts-Plattform degradiert.

Quellen

• https://en.wikipedia.org/wiki/CentOS
• https://en.wikipedia.org/wiki/Oracle_Linux
• https://wiki.centos.org/FAQ/General#How_long_after_Red_Hat_publishes_a_fix_does_it_take_for_CentOS_to_publish_a_fix.3F

Update 19.6.2020

Nachdem Nicolas Kovacs eine Zusammenfassung und einen Link zu diesem Artikel in die CentOS-Mailingliste gesendet hat, wurde das Thema auch dort diskutiert — allerdings ohne nennenswerte Resultate. Die langen Update-Lücken werden zwar bedauert, aber es hätte auch in der Vergangenheit keine Garantie für schnelle Updates gegeben.

Bei CentOS 8 sei alles noch komplizierter, und das CentOS-Team arbeite hart daran, das bestmögliche CentOS zu liefern. Mehr geht nicht. Johnny Hughes vom CentOS-Team: I am working my butt off everyday to make CentOS Linux the best it can be.

Johnny Hughes sieht die Zukunft in CentOS Stream, einer Art Rolling-Release-Development-Version von RHEL. Tatsächlich könnte das die Update-Lücken beheben. Allerdings ist CentOS Stream keine stabile Langzeit-Distribution, sondern ein Angebot für Entwickler. Vielleicht nicht so experimentell wie Fedora, aber eben auch nichts für den den Produktivbetrieb.

Andere Diskutanten sagen sinngemäß: Wer CentOS produktiv verwendet, ist eben selbst schuld.

https://lists.centos.org/pipermail/centos/2020-June/thread.html

Wenn man sich die Kommentare in Newsmedien, Foren und auf anderen Diskussionsplattformen zu den neuen Software-Paketen Snaps und Flatpaks (und AppImages) anschaut ist es ein wirkliches Trauerspiel. Die öffentlich sichtbare Community verweigert sich so offenkundig, dass schon bloßes zusehen schmerzt. Dabei wollen die Formate ein real existierendes Problem lösen.

Mit Snaps und Flatpaks habe ich mich hier schon ein paar Mal befasst. Grundsätzlich sehe ich den Ansatz durchaus positiv. Um mich nicht selbst zu wiederholen hier die Links:

• Kommentar: Flatpaks und Snaps - Ein Schritt in die richtige Richtung
• Kommentar: Paketverwaltung vs. moderne Lösungen
• Neue Paketformate - Der Weg ist noch weit
• Snaps oder Flatpaks - Es gibt kein zurück

Natürlich haben die neuen Formate Probleme. Sicherheitslücken in enthaltenen Bibliotheken, Ressourcenverbrauch, Updateverwaltung, zentrale proprietäre Bestandteile etc. pp. Dabei handelt es sich teilweise um Kinderkrankheiten, aber teilweise auch um strukturelle Beschränkungen durch das Konzept. Es gibt deshalb Einsatzszenarien, wo sie einfach keinen Sinn machen. Der gesamte Bereich "Server" gehört dazu. Andere Probleme müssen durch sinnvolle Weiterentwicklung gelöst werden.

Die Gegner der neuen Formate ignorieren aber vollständig, dass Snaps und Flatpaks zwei real existierende Probleme lösen wollen:

1. Verschränkung des Systems

Die klassische Linux-Paketverwaltung hat ein prinzipielles Problem in der Anwendungsverwaltung. Das Paketmanagement verschränkt Kernel, grundlegendes Betriebssystem, grundlegende Werkzeuge, Desktop und grafische Endanwender-Anwedungen. Man kann letzteres nicht sinnvoll aktualisieren ohne die anderen Bestandteile anzufassen.

Die meisten BSD-Varianten haben das Problem schon vor Jahrzehnten mittels der Trennung von Basissystem und Anwendungen (Ports) gelöst. Die Linux-Community hat stattdessen die Paketverwaltung auf einen Sockel gestellt und genau das gemacht, was sie eigentlich ablehnt: Hässliche Workarounds für strukturelle Probleme geschaffen. Nichts anderes ist z. B. der Trend zur Rolling Release Distribution oder die PPA/OBS/Backports der verschiedenen Distributionen. Anwender wollen aktuelle Anwendungen und bekommen stattdessen ein Betriebssystem, das vom Kernel bis zur letzten Bibliothek ständig auf den letzten Stand gebracht wird oder müssen unsichere Drittquellen einbinden.

2. Software-Distribution

Linux Software kommt nicht direkt vom Entwickler zum Anwender (wie meist bei Windows) und auch nicht über einen zentralen Store (wie bei macOS, iOS, Android), sondern über die Distribution. Ein und dieselbe Software muss daher für jede Distribution und jede unterstützte Version einer Distribution gebaut werden. Das war schon immer arbeitsintensiv aber angesichts einer hohen zweistelligen Zahl an verbreiteten Distributionen, plus jeweils mehrere unterstützte Versionen ist das völlig ausgeufert. Distributions-Entwickler haben deshalb wahre Raketentechnik entworfen, wenn es darum geht diese Prozesse zu automatisieren. Trotzdem ist das noch viel Handarbeit und steht inzwischen einem eklatanten Missverhältnis zum Nutzen. Distributionen fungieren zudem immer häufiger als Flaschenhals bei der Softwareverteilung.

Wer also Snaps oder Flatpaks rundweg ablehnt sollte alternative Vorschläge machen, die diese beiden Probleme adressieren. Es sei denn natürlich man ist der Meinung Linux sei perfekt und ausentwickelt.

Bilder:
Einleitungs- und Beitragsbild von harshahars via pixabay

Die Synology DiskStation lässt sich mittels zusätzlicher Pakete in einen vollwertigen E-Mail Server verwandeln. Angesichts der Bedrohungen und Herausforderungen beim selbstständigen Betrieb eines Mailservers ist das eigentlich kein ratsames Unterfangen. Wohl lassen sich damit aber sehr einfach E-Mails archivieren.

Ich bin ein bekennender E-Mail Messie. Ich lösche grundsätzlich keine E-Mails. Abgesehen lediglich von solchen, die meine Mailprogramme in Spam absortieren oder automatisierte Benachrichtigungen, die nach dem lesen sofort in den Mülleimer wandeln. Alles andere behalte ich bis zum Sankt-Nimmerleins-Tag. Der Hintergrund ist nicht, dass ich ein unordentlicher Mensch wäre, sondern schlicht und einfach Effizienz. Ich habe irgendwann gemerkt wie viel Zeit die Entscheidung ob man eine Mail behalten soll, das rekursive Aufräumen der E-Mail die man irgendwann mal behalten hat etc. pp. kostet. Da ist es viel effektiver einfach alles zu behalten. Aufgaben markiere ich mit farbigen Fähnchen und ggf. Erinnerungen. Wenn ich irgendwas suche, bietet jedes moderne Mailprogramm eine integrierte Suchfunktion. Das hat mich schon das ein oder andere Mal gerettet, wenn andere beteiligte Kommunikationspartner sich partout nicht an einen E-Mail Vorgang erinnern wollten konnten. Zum Jahreswechsel lege ich in einem Archivordner Jahresarchive für Postein- und -ausgang an.

Leider ist nach vielen Jahren und zig tausenden E-Mails die Datenmenge gewaltig und externe Hoster bieten oft nicht unendlich viele GB. Daneben kommt noch der Datenschutz zum tragen. Will man wirklich die Kommunikation von vielen Jahren einem externen Dienstleister anvertrauen?

Man könnte nun natürlich einfach ein lokales Postfach mit dem Mailprogramm der eigenen Präferenz anlegen und die E-Mail dort rein verschieben. Dann macht man sich allerdings sehr von diesem Mailprogramm abhängig und externer Zugriff ist nicht möglich. Wenn man sehr viel unterwegs ist, keine so gute Idee.

Eine andere Möglichkeit bietet da ein Synology NAS. Mittels weniger Handgriffe kann man hier einen lokalen Mailserver in den eigenen vier Wänden aufsetzen, der per IMAP (oder wahlweise auch POP3 für die Dinosaurier unter uns) von jedem Gerät angesteuert werden kann.

Synology Mail Server einrichten

Sucht man im Paket-Zentrum nach "mail" finden sich mehrere Pakete. Relevant ist hier der Synology Mail Server. Die Mail Station bietet lediglich einen Webmail-Client (Roundcube) um auf die E-Mails zuzugreifen. Für den hier thematisierten Anwendungsfall spieltg das keine Rolle. Die Installation geht wie immer schnell und unkompliziert. Zusätzlich wird als Abhängigkeit noch Perl nach installiert, sofern man das nicht eh schon nutzt.

Synology Mail Server basiert - wie so oft bei Synology - auf bewährter Open Source Software wie Dovecot, Postfix, SpamAssassin & Co. Hier kommen also keine unausgereiften Eigenentwicklungen zum Einsatz.

Anschließend kann über den Launcher die Einstellungsoberfläche für den Mail Server gestartet werden. Hier erscheint zuerst eine Warnung über die TLS-Sicherheitsstufe. Diese ist standardmäßig hoch eingestellt, was wohl mit einigen veralteten Clients Probleme machen kann. Im Test mit Apple Mail hatte ich keine Probleme. Wer Schwierigkeiten hat muss in den Systemeinstellungen unter Sicherheit die TSL-/ SSL-Profilebene anpassen.

In den Einstellungen aktiviert man nun den lokalen Nutzer in SMTP.

Hierdurch kann der normale Synology Account genutzt werden. Der Rest ist irrelevant, da für die Funktion als Archiv kein SMTP benötigt wird.

Relevanter sind die Einstellungen für POP3/IMAP.

Wie bereits gesagt, halte ich POP3 für ein vollkommen überholtes Protokoll, das in der Gegenwart angesichts zahlloser Endgeräte keinerlei Daseinsberechtigung für normale Anwender mehr hat. Lediglich für Spezialfälle, wenn man Postfächer wirklich abholen und leeren möchte macht das noch Sinn.

Für die Funktion als Mailarchiv brauchen wir nur IMAP. Dadurch liegen die Mails auf dem NAS gespeichert und die Endgeräte greifen per IMAP auf dieses zu. Offline-Zugriff bietet inzwischen jeder ernst zu nehmende Mailclient und ist bei einem Archiv auch tendenziell nachrangig.

Sofern man lediglich innerhalb des eigenen Netzes (oder per VPN) auf das Mailarchiv zugreifen möchte kann man nur IMAP aktivieren. Bei Zugriff von außerhalb sollte man unbedingt IMAP SSL/TLS aktivieren um eine verschlüsselte Verbindung zu nutzen. Man kann ggf. dann auch nur IMAP SSL/TLS aktivieren.

Der Mailserver ist nun grundsätzlich einsatzbereit. Sofern ein externer Zugriff ohne VPN angestrebt wird, muss zusätzlich noch Port 993 (TCP) über eine Portfreigabe an das Synology NAS weiter geleitet werden.

Konfiguration im Mail Programm

Jedes IMAP-fähige E-Mail Programm kann nun mit dem NAS verbunden werden. Folgende Informationen sind hier relevant:

• Name: Beliebig
• E-Mail Adresse: Beliebig (z. B. archiv@NAS-NAME)
• Account: Name des Synology Benutzers
• Passwort: PW des Synology Benutzers
• IMAP / SMTP Server: Interne IP oder DynDNS-Name

Letzteres hängt davon ab, ob ein interner oder externer Zugriff angestebt wird.

Das Postfach ist beim ersten Start komplett leer. Der einzige Ordner bei mir in Apple Mail war der Posteingang. Via Rechtsklick auf diesen und "Neues Postfach" habe ich anschließend den Ordner "Archiv" angelegt. Mittels Apple Mail habe ich dann das komplett bisherige E-Mail Archiv auf das NAS transferiert. Je nach Netzgeschwindigkeit und Postfachgröße sollte man dafür ordentlich Zeit einplanen.

Tipps & Tricks

Speicherort / Backup

Die E-Mails liegen anschließend im Home-Ordner des Synology Benutzers unter .Maildir. Diesen sollte man also unbedingt in das Backup mit aufnehmen. Backup? Ja richtig gelesen! Nur weil ein NAS mehrere Festplatten hat und die Daten je nach Setup spiegelt ersetzt das kein Backup!

Standby

Der Mail Server verhindert den Standby-Vorgang des NAS. Der Umstand ist bekannt und eigentlich auch logisch, weil ein Mailserver immer erreichbar sein sollte. Wenn man das NAS normalerweise in den Standby laufen lässt und - wie hier im Artikel - den Mailserver lediglich als E-Mail Archiv nutzt, kann man mit Mail Relaxer das Problem umgehen. Dabei handelt es sich um eine Paar Skripte, die blockierende Prozesse beenden, wenn der letzte Client die Verbindung beendet hat. Das macht vor allem Sinn wenn man das E-Mail Archiv nicht auch vom Smartphone ansteuert. Das ist schließlich nahezu immer angeschaltet.

Der Mail Relaxer kann über das Paket-Zentrum und die Schaltfläche Manuelle Installation installiert werden.

Bilder:

Einleitungs- und Beitragsbild von Muhammad Ribkhan via pixaybay

Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.

In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.

Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.

Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:

• heise online: Neue CPU-Sicherheitslücken in Intel-Prozessoren umgehen Kern-Grenzen — CVE-2020-0543
• heise online: Massives Sicherheitsproblem in GnuTLS erlaubt Mitlesen von Kommunikation — CVE-2020-13777

Nutzung der Red Hat CVE-Datenbank

Red Hat betreibt eine CVE-Datenbank unter der URL: https://access.redhat.com/security/security-updates/#/cve

Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.

Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).

Nutzung des Paket-Managers auf der Kommandozeile

Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:

$ sudo yum updateinfo list --cve CVE-2020-0543                                
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$

Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.

Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:

$ sudo yum updateinfo info --cve CVE-2020-0543 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

===============================================================================
  Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
  Update ID : RHSA-2020:2432
    Release : 0
       Type : security
     Status : final
     Issued : 2020-06-09 18:20:28 UTC
       Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
	    : 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
	    : 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
       CVEs : CVE-2020-0543
	    : CVE-2020-0548
	    : CVE-2020-0549
Description : Security Fix(es):
            : 
            : * hw: Special Register Buffer Data Sampling
            :   (SRBDS) (CVE-2020-0543)
            : 
            : * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
            : 
            : * hw: Vector Register Data Sampling
            :   (CVE-2020-0548)
            : 
            : For more details about the security issue(s),
            : including the impact, a CVSS score,
            : acknowledgments, and other related information,
            : refer to the CVE page(s) listed in the References
            : section.
            : 
            : Bug Fix(es):
            : 
            : * Update Intel CPU microcode to microcode-20200602
            :   release, addresses:
            :   - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
            :     microcode from revision 0x61f up to 0x621;
[...]

CVE durch Update schließen

Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:

$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
 --> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
 --> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
 --> mock-2.3-1.el7.noarch from epel removed (updateinfo)
 --> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================
 Package                              Arch                          Version                                   Repository                                 Size
==============================================================================================================================================================
Updating:
 microcode_ctl                        x86_64                        2:2.1-61.6.el7_8                          rhel-7-server-rpms                        2.6 M

Transaction Summary
==============================================================================================================================================================
Upgrade  1 Package

Total size: 2.6 M
Is this ok [y/d/N]:

Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.

Weitere Informationsquellen zu diesem Thema

• Manpage yum(8)
• Is it possible to limit yum so that it lists or installs only security updates?
• Explaining Red Hat Errata (RHSA, RHBA, and RHEA)
• Determining your risk
• Is your software fixed?
• Changelog eines RPM-Pakets unter RHEL/CentOS anzeigen

Dieses Blog nutze ich leider viel zu selten, um mein eigenes Hardware- und Software-Setup zu dokumentieren. Manchmal tue ich das zum Glück schon, sodass ich im Nachhinein dann doch hin und wieder mal nachlesen kann, wie ich das ein oder andere früher mal gelöst habe.

Jetzt ist es jedenfalls wieder an der Zeit ein Update für mein Homeserver zu liefern. Wie auch in den letzten Jahren diente das Frickeln an meinem Homeserver zwei Zielen:

1. Ich will was lernen.
2. Es sollen ein paar Dienste betrieben werden.

Prinzipiell sollten zwar die Dienste funktionieren, aber im Vordergrund steht auch neue Technologien und Tools auszuprobieren, um was Neues zu lernen.

Früher™

Vor knapp sechs Jahren ersetzte ich meinen Raspberry Pi durch „richtige“ Hardware. Damals allerdings auch nur 4GB RAM mit einem Board mit einer Atom CPU. Damit geriet ich schnell an meine Grenzen, sodass das ganze wenig Spaß gemacht hat. Damals lief darauf ein ArchLinux und diente hauptsächlich als NAS.

2016 migrierte ich von ArchLinux auf Ubuntu 16.04. Dann lief schon mit ownCloud ein bisschen mehr als nur ein Fileserver und mit mehreren LXC/LXD Containern. Später im Jahr 2016 ersetzte ich die Hardware und schaffte mir ein Dell PowerEdge T20 mit einer Quad-Code Xeon CPU und 32GB RAM an. Die Hardware läuft auch noch heute und hat noch genügend Leistung.

In der Zwischenzeit experimentierte ich vor allem Software aus der „Cloud Native“ Welt herum.

Heute

Heute läuft der Server mit Ubuntu 20.04. Darauf laufen keine LXC/LXD Container mehr. Stattdessen läuft jetzt Kubernetes darauf. Zu Beginn nutzte ich für die Installation von Kubernetes Kubespray ein, das Standard-Kubernetes war allerdings deutlich zu fett. Größtes Manko war, dass das etcd verdammt viel auf die SSD geschrieben hat und ich regelmäßig bei jedem Upgrade das Setup kaputt gespielt habe. Für den Privatgebrauch ergab das so daher keinen Sinn.

Mittlerweile setze ich auf das vergleichsweise schlanke k3s.io. Das braucht im Heimbetrieb deutlich weniger Leistung und erledigt trotzdem das, was ich brauche. Statt etcd setzt es auf sqlite und statt Docker auf containerd.

Die Kubernetes Manifeste verwalte ich ausschließlich mit „dem GitOps Operator“ fluxcd. Wesentlicher Vorteil ist, dass der Zustand des Clusters in einem Git-Repository definiert ist und eine vollständige Neuinstallation innerhalb weniger Minuten durchgeführt werden kann. Im Gegensatz zu Ansible etwa, gebe ich hier explizit meinen Zielzustand an und eben keine Abfolge von Anweisungen. Die meisten Anwendungen sind über Helm-Charts installiert. Einige wenige sind ganz normal als Deployment YAML geschrieben. kubectl rufe ich daher nur zum Testen manuell auf. In der Regel mache ich daher einfach Commits in das Repository und pushe es auf mein GitLab-Repository. fluxcd kümmert sich dann darum, es auf dem Cluster auszurollen. Ziemlich angenehm.

Nicht zu vernachlässigen ist bei diesem Setup allerdings, dass die Lernkurve von Kubernetes verdammt steil ist. Wenn man Zeit und Lust hat, kann man das gut und gerne so umsetzen. Wirklich sinnvoll im Heimgebrauch ist es für meinen Anwendungsfall eigentlich nicht, da ich kaum die Skalierungsmechanismen von Kubernetes brauche und die Komplexität von Kubernetes nicht zu unterschätzen ist. Die Handhabung ist, sobald man sich mit Kubernetes angefreundet hat, für mich jedenfalls deutlich angenehmer, als vorher, wo ich Ansible Rollen und Playbooks geschrieben habe, die auch sehr viel Zeit in Anspruch genommen haben.

Anwendungen

Folgende Anwendungen laufen mittlerweile auf meinem Kubernetes-Cluster:

• Nextcloud für Kalender, Kontakte und Dateisynchronisation
• Bitwarden als Passwortmanager
• Prometheus für das Monitoring
• Grafana für die Visualisierung der Daten aus Prometheus, Influx und PostgreSQL
• GitLab für Git-Repositorys
• Unifi Controller für meine Unifi APs
• Syncthing für das Synchronisieren von Backups zu einer Offsite-Stelle
• rclone als Cronjob für das Hochladen von Backups „in die Cloud“
• Dataexporter der Photovoltaik-Anlage, der die Daten in eine Influx und PostgreSQL Datenbank schreibt
• Influxdb für die Daten der PV-Anlage, sowie Stromverbrauch und Temperatur-Sensoren
• PostgreSQL für Nextcloud, Kostal Datenhaltung und GitLab
• Plex für Multimedia-Daten
• minio als S3-kompatibles Object-Storage-Backend für GitLab
• traefik als Reverse Proxy
• Bald: Home-Assistant für Smart-Home

Fast alles installiere ich über fertige Helm-Charts. Einzig zwei Datensammler-Skripte für smarte Stromsteckdosen und für die PV-Anlage erfolgen über eigene, selbst gebaute, Container. Diese baue ich sehr einfach über die Auto DevOps Funktionalität von GitLab auf GitLab.com.

Außerhalb von Kubernetes läuft sonst nur noch borgbackup und sonst eigentlich nichts mehr. Den Rest habe ich sonst weiterhin mit Ansible durch automatisiert, allerdings durch den Einsatz von Kubernetes mit fluxcd in einem deutlich geringerem Umfang.

Spitfire Audio stellt qualitativ hochwertige Soundplugins her. Der aktuelle große Wurf ist eine tolle Samplelibrary “Discover"  https://www.spitfireaudio.com/shop/a-z/bbc-symphony-orchestra-discover/ mit Aufnahmen des BBC Orchesters, die nicht nur relativ wenig Platz verbraucht, sondern auch noch sehr gut klingt. Discover gibt es in mehreren Ausführungen. Die kleinste Ausführung kann entweder für 49 € gekauft werden, oder man bestellt die Samplelibrary und wartet dann einfach 14 Tage. Danach bekommt man einen Downloadlink zugeschickt bzw die Samplelibrary wird in der Spitfire Audio eigenen Software freigeschaltet. Dort kann man Discover schließlich runter laden.

Ausserdem hat Spitfire Audio in ihrer LABS Reihe https://www.spitfireaudio.com/info/faq/labs/ etliche Soundplugins, die ebenfalls komplett frei sind. Da lohnt sich ein tiefer Blick. Diese Samplelibraries werden ebenfalls in der Spitfire Audio eigenen Software verwaltet.

Damit die Spitfire Audio Software unter Linux läuft braucht man mindestens die Wine Version 5.10 . Das ist die aktuelle Entwicklerversion. Wie man diese Version unter Kubuntu bzw Ubuntu installiert, steht hier geschrieben https://wiki.winehq.org/Ubuntu und zusätzlich habe ich eine vollständige Installationsanleitung hier im Blog veröffentlicht, wie man Wine installiert und wie man zusätzlich die VSTs unter Linux, im Speziellen für Bitwig,  konfiguriert. Für andere DAWs ist der Vorgang fast identisch.

1. LinVST unter Wine für Bitwig compilieren https://hyperblog.de/hoergen/2020/06/01/linvst-unter-wine-fuer-bitwig
2. LinVST - Windows VSTs einrichten https://hyperblog.de/hoergen/2020/06/02/linvst-windows-vsts-einrichten

Ich gehöre zu den Leuten die sudo nur für bestimmte Befehle und nicht als Ersatz von root nutzen. In fast allen Fällen bin ich so konsequent und beende die Sitzung mit Root-Rechten im Terminal Emulator nachdem ich diese Rechte nicht mehr benötige. Aber eben nur fast immer.

An sich ist das kein Problem, da ich alleiniger Nutzer meiner Rechner bin. Aber sicher ist sicher. Als Lösung kann man die Variable TMOUT nutzen. Mit dieser kann man definieren nach wie vielen Sekunden Inaktivität die jeweilige Session beendet wird. Inaktivität bedeutet hierbei, dass keine Eingabe über die Tastatur erfolgt.

Hierzu legt man die Datei /etc/profile.d/bash_autologout.sh an und trägt in diese folgendes ein.

TMOUT=600
readonly TMOUT
export TMOUT

Bei diesem Beispiel wird nach 600 Sekunden, also 10 Minuten, die jeweilige Session beendet. Dies betrifft sowohl Benutzerkonten als auch root. Diesen Wert kann man nach Belieben anpassen. Mit “readonly TMOUNT” verhindert man, das man die Veriable im laufenden Betrieb ändern kann (z. B. mit unset TMOUT). Wer diese Möglichkeit weiterhin haben will, trägt die Zeile einfach nicht ein. Führt man einen Befehl aus der länger als der angegebenen Zeitraum läuft (z. B. sleep 650 && echo “Hallo Welt”), beginnt der Countdown erst nachdem der Befehl fertig ist. Wer nicht will, das auch normale Benutzer im Terminal Emulator ausgeloggt werden, verzichtet einfach darauf die Zeile “export TMOUT” einzutragen.

System- und Prozess-Monitore gibt es wie Sand am Meer. Top, htop, atop und vermutlich noch viele mehr. Vor kurzem bin ich auf eine weitere Alternative mit dem Namen Bashtop gestoßen, die ich interessant finde. So wird zum Beispiel die Auslastung der Netzwerkverbindung und die der CPU grafisch dargestellt. Ansonsten ist die Anzeige etwas bunter als bei anderen Tools aber nicht aufdringlich.

Wer schicke Anzeigen mag, sollte sich das Tool einmal ansehen. Positiv finde ich auch, dass die Netzwerkverbindung erfasst wird. Diese vermisse ich ab und zu bei htop. Trotzdem werde ich htop erst einmal treu bleiben.

Open Snitch ist der Versuch Little Snitch (siehe: Little Snitch 4 - macOS-Traffic im Blick) als freie Software für Linux nachzubilden. Das Programm nimmt den ein- und ausgehenden Datenverkehr der Programme unter die Lupe und lässt den Benutzer steuernd eingreifen. Trotz des frühen Entwicklungsstadiums ist es einen Blick wert.

Sinn und Unsinn

Firewall-Software auf Produktivsystemen ziehen sehr viel Kritik auf sich. Ein recht umfassender Artikel kann hier für Little Snitch nachgelesen werden. Die Kernaussagen lassen sich natürlich auf Open Snitch übertragen. Die Kritik zielt auf wenige Hauptpunkte ab. Erstens benötigt solche Software naturgemäß umfassende Rechte auf dem System um den Netzverkehr überwachen zu können. Was ist wenn die Software also selbst fehlerhaft ist? Zweitens sollte eine Firewall niemals auf dem gleichen System laufen, das es schützen soll. Schadsoftware kann schließlich jede Software - inklusive Open Snitch - manipulieren und dadurch unsichtbar werden. Der Autor ist daher der Meinung, dass solche Software nur dazu taugt, gutmütige Software, die nichts verbergen will zu überwachen.

Dem ist eigentlich nichts hinzuzufügen, aber genau darum soll es hier gehen. Viele "gutmütige" Softwareprodukte integrieren heute zahllose Tracker um die Nutzer zu überwachen. Auch unter freier Software gibt es zahllose Verbindungsaufrufe und man weiß nicht was auf der Gegenseite gespeichert wird. Das geschieht nicht immer um Nutzer auszuspähen, sondern oft auch weil Entwickler kein Gefühl für Datenschutz haben. Man sammelt, weil man sammeln kann. Diese Trackingdienste lassen sich inzwischen auch häufig nicht mehr in den Einstellungen abstellen, sondern laufen weitestgehend unbemerkt im Hintergrund. Genau an diesem Punkt setzen Litte Snitch und seine freien Kopien an.

Open Snitch

Open Snitch befindet sich schon länger in Entwicklung. Der originale Zweig ist seit einiger Zeit eingeschlafen, aber ein Fork wird aktiv weiter entwickelt. Die folgende Beschreibung basiert daher auf dem Fork.

Installation

Unter Releases lassen sich fertige Pakete für DEB und RPM herunterladen. Die Installation gestaltet sich z. B. unter Ubuntu 20.04 sehr einfach:

sudo apt install /Pfad/zur/Datei/opensnitch_1.0.0rc9-1_amd64.deb

sudo apt install /Pfad/zur/Datei/python3-opensnitch-ui_1.0.0rc9-1_all.deb

Es werden einige Abhängigkeiten installiert, sowohl aus den Paketquellen, als auch per pip. Unter Ubuntu wird der entsprechende Service direkt gestartet. Bei anderen System muss ggf. der Service noch aktiviert und gestartet werden.

sudo systemctl enable opensnitchd

sudo systemctl start opensnitchd

Im Anschluss ist Open Snitch sofort aktiv und einsatzbereit.

Bedienung

Möchte ein Programm eine neue Verbindung aufbauen erscheint nun ein Popup-Fenster und fragt um Erlaubnis. Das Timeout ist in den Systemeinstellungen standardmäßig auf 15 Sekunden festgelegt. Anschließend wird die Verbindungsanfrage automatisch erlaubt. Ein längeres Timeout und/oder ein automatisches Ablehnen lassen sich in den Einstellungen konfigurieren.

Standardmäßig erlaubt man die Verbindung einmal aber es lassen sich auch andere Zeiträume definieren.

Die bisher getroffenen Entscheidungen werden in einem Übersichtsfenster dargestellt. Dieses lässt sich über ein Systemtray-Icon schnell aufrufen.

Gerade am Anfang kommen unzählige Anfragen und man muss sich hier erst einmal durchkämpfen. Da hilft nur Ruhe und ein bisschen Nerven bewahren. Hat man erst einmal ein ordentliches Regelkorsett erzeugt nehmen die Anfragen deutlich ab.

Die Oberfläche ist noch ziemlich roh und manches nicht ganz intuitiv gestaltet. UX ist halt oft bei Open Source zweitrangig. Alle wichtigen Funktionen sind jedoch vorhanden und nach ein paar irritierten Fehlklicks hat man auch raus wie Open Snitch funktioniert.

Zusammengefasst

Ich mag diese Art von Software weil sie die alltäglichen Verbindungen der Programme sichtbar macht. Es verlangt aber auch ein Menge Vorwissen über die verschiedenen Dienste oder die Bereitschaft sich dieses sukzessive anzueignen. Eines ist jedoch schnell klar: Auch ein Linux Desktop funkt ganz schön viel nach Hause. Open Snitch ist aber noch ziemlich stark in der Entwicklung und vieles nicht so intuitiv gelöst wie beim Vorbild Little Snitch. Ob man sich das im jetztigen Stadium auf einem Produktivsystem antun möchte muss jeder für sich entscheiden.

Ich freue mich auf die Weiterentwicklung und hoffe der aktuelle Entwickler bleibt am Ball.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay 

Das Pi-Hole erfreut sich zunehmender Beliebtheit und hat inzwischen auch über Nerd-Kreise hinaus Bekanntheit erlangt. Obwohl das Pi-Hole eigentlich Sicherheit und Datenschutz stärken soll ist es eine ziemlich mächtiges Spionage-Werkzeug. Das Query-Log bietet ein sehr bedenkliches Einsatzszenario.

Ein Pi-Hole ist - stark simplifiziert gesagt - ein Werbeblocker auf Netzwerk-Ebene. Der gesamte Traffic des Netzwerks wird über das Pi-Hole (meistens ein raspberry pi) geleitet und dort wird zentral Werbung und Tracking blockiert. Für den Desktop mag das nicht so relevant sein, weil man z. B. bei macOS mit Little Snitch einen ähnlichen Effekt erreichen kann (siehe: Little Snitch 4 - macOS-Traffic im Blick) aber immer mehr Geräte im Haushalt sind internetfähig. Smart-TVs, Lautsprecher, Kühlschränke, Waschmaschinen. Der Fantasie sind hier keine Grenzen gesetzt. Diese Geräte sind dabei keineswegs so datenschutzfreundlich wie man es gerne hätte. Ohne ein Pi-Hole kann man deren Netzverkehr nicht so einfach blockieren.

Das Pi-Hole hat aber eine sehr kritische Funktion: Das Query-Log. Die Software ist in der Lage alle aufgerufenen Domains im Netzwerk zu speichern.

Wenn ihr alleine wohnt und nie Gäste in eurem Netzwerk habt ist das natürlich kein Problem. Die meisten Menschen haben aber Familienangehörige, die auch im Netz unterwegs sind oder Gäste, die sich mit ihren Smartphones ins WLAN einwählen. Für diese Menschen kehrt sich der Effekt eines Pi-Hole in sein Gegenteil um. Abstrakte Datensammlung durch Tracking wird zwar unterbunden, aber ihr Surfverhalten vor Freunden und Angehörigen offen gelegt. Dabei haben diese definitiv auch ein Recht auf Privatsphäre.

Es sollte daher selbstverständlich sein (so ihr nicht alleine wohnt und nie Gäste im Netz habt) in den Datenschutz-Einstellungen Level 3 einzustellen. Nur kann man das leider von außen nicht kontrollieren. Eure Familienangehörige und Freunde wissen also nicht, ob das Pi-Hole datenschutzfreundlich konfiguriert wurde oder nicht.

So sehr ich deshalb auch die Idee eines Pi-Holes schätze und die Funktionen und Vorzüge durch das ausufernde IoT begrüße, so bedenklich finde ich diese Funktion. In vielen Menschen sitzt ein kleiner Stalker (oder warum gucken wir uns Social Media Profile anderer Menschen an?) und Pi-Hole gibt ihn ein zu mächtiges Überwachungswerkzeug in die Hand.

Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

Mozilla hat Firefox 77.0.1 veröffentlicht. Für Nutzer hierzulande ist das Update vernachlässigbar.

Mozilla hat Firefox 77.0.1 veröffentlicht. Das Update bringt genau eine Änderung und betrifft die Ausrollung von DNS-over-HTTPS in den USA. Für Nutzer hierzulande besteht damit keine dringende Notwendigkeit, das Update einzuspielen.

Download Mozilla Firefox 77.0.1

Der Beitrag Mozilla veröffentlicht Firefox 77.0.1 erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Firefox 77 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Intelligentere Adressleiste

Firefox verhält sich nun smarter, wenn in die Adressleiste ein Suchbegriff mit Punkt und ohne Leerzeichen eingegeben wird. Bisher versuchte Firefox immer, die Eingabe als Domain aufzulösen, was häufig zu unerwünschten Ergebnissen führte. Dies passiert in Zukunft nicht mehr, sofern die Eingabe keiner Eingabe mit einer gültigen Domain-Endung entspricht. Eine Eingabe von „user.js“ etwa führt nun eine Suche bei der eingestellten Standard-Suchmaschine durch statt eine Seite öffnen zu wollen, die es gar nicht gibt.

Bei der Eingabe eines Suchbegriffes im E-Mail-Format hat Firefox bislang nur die Auflösung als URL angeboten, was zum Versuch führte, sich auf einer Seite anzumelden. Hier bietet Firefox als zweite Option nun auch die Suche nach dem eingegeben Text in der Standard-Suchmaschine an.

Gibt es Chronik-Einträge mit und ohne abschließendem „#“, die ansonsten identisch sind, schlägt Firefox nicht mehr zwei dazugehörige Einträge in der Adressleiste vor.

Seiten, welche bei Klick in die Adressleiste deswegen vorgeschlagen werden, weil sie auf der Firefox-Startseite angepinnt sind, werden in der Adressleiste nun mit einem Stecknadel-Symbol gekennzeichnet.

Wurden die Ergebnisse in der Adressleiste zuvor bei 500 Pixeln und weniger Fensterbreite zweizeilig, geschieht dies nun schon ab 650 Pixeln Fensterbreite.

WebRender für weitere Nutzer

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

Auf Computern mit Windows 10 und Nvidia-GPU im Akku-Betrieb wird WebRender nun bei allen Bildschirmauflösungen unterstützt. Außerdem wurde WebRender für weitere Grafikchips aktiviert.

Neuer Zertifikats-Betrachter

Bereits in Firefox 71 hatte Mozilla den alten Dialog-basierten Zertifikats-Betrachter, welcher Informationen zum verwendeten TLS-Zertifikat einer Website bereitstellt, durch einen neuen Tab-basierten ersetzt. Ab Firefox 77 kann about:certificate auch direkt aufgerufen werden, um Zertifizierungsstellen und Server-Zertifikate zu betrachten und exportieren.

Verbesserungen der Webplattform

Experimentelle AVIF-Unterstützung

AVIF steht für AV1 Image File Format und ist ein Bildformat, welches auf dem neuen Video-Codec AV1 basiert und ebenfalls von AOMedia spezifiziert worden ist. Ähnlich wie AV1 bei Videos verspricht auch AVIF bei Bildern bei gleichbleibender Qualität deutlich geringere Dateigrößen als konkurrierende Formate wie JPG oder WebP. Firefox 77 besitzt eine erste experimentelle Unterstützung, welche über about:config aktiviert werden kann, indem der Schalter image.avif.enabled auf true gestellt wird.

Sonstige Verbesserungen der Webplattform

Firefox 77 unterstützt die JavaScript-Methode String.prototype.replaceAll().

Firefox unterstützt experimentell ein CSS Masonry Grid. Hierfür muss derzeit aber noch layout.css.grid-template-masonry-value.enabled in about:config auf true gesetzt werden.

Ausführliche Informationen zu Verbesserungen der Webplattform in Firefox 77 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Verbesserungen der Entwickler-Werkzeuge

Der JavaScript-Debugger hat signifikante Performance-Verbesserungen erhalten und benötigt nun auf Dauer weniger RAM. Auch Sourcemaps funktionieren jetzt zuverlässiger.

Seit Version 75 unterstützt Firefox natives Lazy Loading ohne dafür notwendige JavaScript-Bibliothek. Das Netzwerkanalyse-Werkzeug zeigt bei entsprechenden Bildern nun an, dass diese via Lazy Loading geladen worden sind.

Ausführliche Informationen zu Verbesserungen der Entwickler-Werkzeuge in Firefox 77 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Verbesserungen für Firefox-Erweiterungen

Mehr optionale Berechtigungen

Firefox-Erweiterungen benötigen Berechtigungen, um bestimmte Funktionen ausführen zu dürfen. Meistens werden diese Berechtigungen bereits bei der Installation der jeweiligen Erweiterung angefragt. Werden durch Erweiterungs-Updates zusätzliche Berechtigungen erforderlich, müssen diese beim Update-Vorgang erteilt werden, ansonsten kann die Erweiterung nicht aktualisiert werden.

Es gibt aber auch sogenannte optionale Berechtigungen. Diese müssen nicht mit der Installation erteilt werden und können durch die Erweiterung bei Bedarf zur Laufzeit angefragt werden. Allerdings kann durch Erweiterungen nicht jede Berechtigung als optionale Berechtigung implementiert werden. Mit Firefox 77 stehen zahlreiche Berechtigungen nun auch als optionale Berechtigungen zur Verfügung, bei denen dies zuvor nicht möglich war.

CSP-Header verschiedener Erweiterungen

Hatte der Nutzer mehr als eine Erweiterung installiert, welche die Content Security Policy-Header von Anfragen verändern, konnte dies bisher zu einem unerwarteten Verhalten führen. Ab Firefox 77 finden die CSP-Header mehrerer Erweiterungen korrekt Anwendung. Dies ist insbesondere für Content-Blocker relevant, welche diese Methode nutzen, um Ressourcen wie Scripts und Bilder zu blockieren.

Sonstige Verbesserungen für Firefox-Erweiterungen

Firefox 77 beinhaltet weitere Verbesserungen für Firefox-Erweiterungen, darunter ein verbesserter Umgang mit sameSite-Cookies, neue Tab-Funktionen und mehr. Mehr Informationen gibt es im Mozilla-Blog.

Neue und entfernte Einstellungen in about:config

Die Option browser.urlbar.oneOffSearches in about:config, um die Suchmaschinen-Icons in der Adressleiste zu deaktivieren, wurde entfernt. Stattdessen können einzelne oder auch alle Suchmaschinen über die Sucheinstellungen deaktiviert werden.

Über die Option browser.stopReloadAnimation.enabled war es bisher möglich, die Animation des Stop-/Reload-Buttons abzuschalten. Die Option existiert nicht länger, dafür berücksichtigt Firefox ab sofort automatisch die Einstellung des Betriebssystems zur Reduzierung von Animationen.

Auch ein Teil der Animationen, welche über toolkit.cosmeticAnimations.enabled gesteuert werden, wird ab sofort automatisch über die Einstellung des Betriebssystems berücksichtigt und nicht länger über diesen Schalter. In Firefox 78 werden die restlichen Animationen folgen, welche bisher durch diesem Schalter kontrolliert werden.

Mit middlemouse.openNewWindow wurde eine neue Option in about:config eingeführt, um zu verhindern, dass bei Druck mit der mittleren Maustaste auf einen Link dieser in einem neuen Fenster geöffnet wird.

Eine weitere neue Option in about:config ist pdfjs.enablePermissions, womit der PDF-Betrachter von Firefox Dokumenten-Berechtigungen unterstützt. So können PDF-Dateien beispielsweise das Kopieren von Text verbieten. Der PDF-Betrachter hat diese Berechtigung bislang ignoriert, so dass ein Kopieren des Textes über Firefox immer möglich war. Setzt der Nutzer den entsprechenden Schalter, berücksichtigt Firefox die Berechtigungen.

Ersatzlos entfernt wurde die Option security.identityblock.show_extended_validation, um bei Seiten mit Extended-Validation-Zertifikat neben dem Schloss-Symbol in der Adressleiste den Namen des Zertifikats-Inhabers direkt in der Adressleiste anzuzeigen. Diese Funktion wurde in Firefox 70 standardmäßig abgeschaltet.

Ebenfalls entfernt wurde browser.tabs.multiselect pref. Mit dieser Einstellung konnte die Möglichkeit deaktiviert werden, mehrere Tabs gleichzeitig zu markieren und damit zu arbeiten, um diese beispielsweise zu verschieben, klonen, schließen etc. Beim Multi-Tab-Management handelt es sich um eine in Firefox 63 eingeführte Funktion.

Entfernt wurden außerdem die in Firefox 75 mit der neuen Adressleiste temporär eingeführten Optionen browser.urlbar.update1 und browser.urlbar.update1.view.stripHttps sowie die bislang immer noch zugängliche alte Passwort-Verwaltung, welche standardmäßig in Firefox 70 durch about:logins ersetzt worden war.

Sonstige Neuerungen in Firefox 77

Auf der Firefox-Startseite werden jeden Monat an annähernd 40 Millionen Menschen in Deutschland, den USA sowie Kanada Pocket-Empfehlungen ausgespielt. Ab sofort erhalten auch Nutzer in Großbritannien kuratierte Lese-Tipps auf der Firefox-Startseite. Pocket ist ein Dienst, den Mozilla 2017 gekauft hat.

Der in Firefox 76 neu eingeführte optionale HTTPS-only-Modus hat eine Ausnahme für localhost und lokale IP-Adressen erhalten.

Nachdem in den letzten Monaten und Jahren große Teile der Oberfläche von Firefox mit Webtechnologie neu umgesetzt worden sind, wurde nun auch die Oberfläche des sogenannten Stub Installers, also dem Installations-Paket, welches Firefox bei Ausführung herunterlädt und direkt installiert, in HTML, CSS und JavaScript neu geschrieben.

Die Firefox-Startseite wird nun in einem eigenen speziellen Prozess ausgeführt. Auch die Barrierefreiheit von Firefox wurde an diversen Stellen verbessert.

Natürlich kam auch in Firefox 77 die Unterstützung weiterer Unternehmensrichtlinien dazu. Die Dokumentation der Unternehmensrichtlinien unter about:policies verlinkt außerdem jetzt direkt auf den entsprechenden Abschnitt in der Online-Dokumentation.

Geschlossene Sicherheitslücken

Auch in Firefox 77 hat Mozilla wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 77 daher für alle Nutzer dringend empfohlen.

Der Beitrag Mozilla veröffentlicht Firefox 77 erschien zuerst auf soeren-hentzschel.at.

Wie man LinVST runterläd und selbst compiliert habe ich in diesem Artikel “LinVST unter Wine für Bitwig compilieren” beschrieben. Nun soll es darum gehen eine Windows VST unter Linux zu benutzen.

Dazu muss das VST unter Wine installiert werden und/oder die entsprechende Datei in das Verzeichnis innerhalb Wine kopieren, wo alle VSTs liegen sollen. Je nachdem, ob eine Installationsdatei (.exe) oder eine Zip Datei vorliegt.

Die gesamte Wine Installation liegt im Verzeichnis .wine . Unter Linux sind Dateien und Verzeichnis, die mit einem Punkt anfangen, so wie “.wine” versteckte Dateien und Verzeichnisse. Diese müssen unter Umständen in deinem Dateinamager z.B. Dolphin meist erst sichtbar gemacht werden.

1. In meinem Fall lege ich das Verzeichnis /home/userName/.wine/drive_c/Program Files/Common Files/VST2/an. C:\Program Files\Common Files\VST2


2. Dann lade ich das Hall-Plugin VST Valhalla Supermassive runter https://valhalladsp.com/shop/reverb/valhalla-supermassive/
   
   
3. Mit Hilfe des Dateimanagers dolphin lasse ich die Zip Datei auspacken
   
   
4. Dann auf die Datei ValhallaSupermassiveWin_V1_0_0.exe mit einem Rechtsklick die Option “Mit Wine Windows Programmstarter öffnen” starten.
   Oder über die Kommandozeile in das Verzeichnis wechseln und mit wine ValhallaSupermassiveWin_V1_0_0.exe die Installation starten.
   
   
5. Jetzt nur das 64 Bit-VST2.4 64 Plugin auswählen und dieses dann installieren
   
   
6. Nun existiert in diesem Pfad die Datei ValhallaSupermassive_x64.dll
   Dann muss das Programm linvstconvert aufgerufen werden. Das befindet sich, in dem Unterverzeichnis convert des Vezeichnises, das wir im vorherigen Artikel erstellt und wo wir LinVST compiliert haben. (/home/userName/Programme/LinVST/convert/)
   
   
7. linvstconvert öffnet ein grafisches Fenster, in dem man 2 Pfade auswählen muss
   1. Den Pfad zur Datei linvst.so : /home/userName/Programme/LinVST/
   2. Den Pfad zu den installierten (oder kopierten ) Windows VST3 oder VST2 Dateien (.dll). In diesem Fall ist es das Verzeichnis /home/userName/.wine/drive_c/Program Files/Common Files/VST2/ 


8. Wenn beides ausgewählt ist, dann auf Start klicken und recht schnell steht dort dann “Done”
   
   
9. In Bitwig gibt man dann noch unter Settings->Location den Entsprechenden Pfad zu den Windows VSTs /home/userName/.wine/drive_c/Program Files/Common Files/VST2/ an und startet Bitwig am besten nochmal neu.
   
   
10. Jetzt sollte das VST in Bitwig zur Verfügung stehen.

Mit dem Valhalla Supermassive hat es geklappt. Aber zum Beispiel mit Izotope Ozone 8 hat es bei mir nicht geklappt. Was auch nicht weiter schlimm ist, da ich es sowieso nicht produktiv einsetze.

Für mich ist die Nutzung von Windows Effekt VSTs sowieso nur im Notfall wichtig. Und das passiert vermutlich eher nicht. Bitwig hat von Hause aus sehr gute Devices und wenn man mal gelernt hat, wie man welchen Effekt durch welche Devices, Schalter und Einstellungen erreicht hat, dann braucht man extrem wenig von allen diesen Effekt VSTs. Das Meiste davon ist sowieso nur BlingBling.

Interessanter wird es dann da schon bei VST Instrumenten.Dort findet man aber auch recht schnell heraus, was funktioniert und was nicht. Und die meisten bekannten Instrumente wie z.B. Kontakt funktionieren auch.

Es ist aber gut zu wissen, dass man so eine Möglichkeit hat. Mittlerweile setzen einige Firmen auch darauf für Linux VSTs zu erstellen, oder vielleicht in der Zukunft LV2s. Wer weiss. Es geschehen ja manchmal noch Zeichen und Wunder.

In meinem letzten Artikel habe ich erklärt, wie man unter Linux die Firewall mit einem IP Block ausstatten kann. In diesem Artikel möchte ich euch erklären, wie ihr auch IP's melden könnt, und somit der Community wieder was zurückgeben könnt.

Fail2Ban installieren

Fail2Ban ist schnell installiert:

apt install -y fail2ban

Fail2Ban und UFW

Wie im ersten Artikel bereits beschrieben, nutze ich als Firewall für meine Systeme UFW. Damit Fail2Ban mit UFW sprechen kann, müssen wir kleine Anpassung machen. Als Erstes müssen wir die Datei jail.local erstellen, dazu macht einfach folgendes:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

In der jail.local such jetzt bitte die folgende Zeile (ist bei mir die 167):

banaction = ....

Alles hinter dem Gleichzeichen entfernen und ufw angeben.

Fail2Ban und AbuseIPDB

Als Nächstes müssen wir in der jail.local noch eine Änderung vornehmen. Sucht in der Datei, im [DEFAULT] Block bitte die folgende Zeile (ist bei mir 228 kurz vor dem sshd Jail):

action = %(action_)s

Diese muss durch die folgende erstes werden, passt auch direkt deine API Key an.

action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18"]

Was haben wir gerade gemacht? Wir haben Fail2Ban gesagt, dass er bei einem Ban, die IP die gebannt wird, an die Aktion AbuseIPDB (bearbeiten wir gleich) übergeben werden soll, mit der Kategorie 18 (Brute-Force). Weiteres zu den Kategorien hier.

In diesem Teil habe ich jetzt beschrieben, wie wir allgemein eine Aktion für alle Bans aufrufen können. Natürlich kann man das für jeden Jail auch einzelnen machen, und so genauer melden, wenn man die entsprechenden Kategorien angibt. So könnte man die Zeile oben auf Default lassen und im Jail sshd zum Beispiel das folgende machen:

[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18,22"]

Jetzt sind die Kategorien die wir melden, 18 (Brute-Force) und 22 (SSH). So kann AbuseIPDB, das viel genauer filtern und anderen zur Verfügung stellen.

Als letztes müssen wir noch die Action abuseipdb anpassen. Leider, ist die action die mit Debian mitgeliefert wird nicht mehr aktuell, und führt dazu, das ihr nichts melden könnt, weil die API falsch angesprochen wird. Dazu geht in die Datei /etc/fail2ban/action.d/abuseipdb.conf.

Löscht die aktuelle Zeile, die mit actionban = begint komplett und setzt die folgenden rein:

actionban = curl --tlsv1.2 --fail 'https://api.abuseipdb.com/api/v2/report' -H 'Accept: application/json' -H 'Key: <abuseipdb_apikey>' --data-urlencode "comment=<matches>" --data-urlencode 'ip=<ip>' --data 'categories=<abuseipdversionb_category>'

WICHTIG: hier nichts einsetzen, so eintragen wie ich es hier geschrieben habe, der APIKey und die IP und die Kategorien werden von Fail2Ban bei einem Ban übergeben!

Jetzt alles speichern und einen neustart von fail2ban machen:

fail2ban-client restart

Hier sollte kein Fehler kommen, sicherheitshalber kann man auch nochmal die Log überprüfen:

cat /var/log/fail2ban.log

Ergebnis

Dementsprechend wie sehr eurer Server “angegriffen” wird, solltet ihr nach einigen Tagen bereits einige IP's gemeldet haben, bei mir sieht das aktuell so aus:

Im folgenden Artikel möchte ich erläutern, wie ihr eure Linux Firewall (UFW) mit einer Blackliste von IP-Adressen, die durch Meldungen bereits als schadhafte IP's (wurden zum Beispiel für Brute-Force) genutzt, erweitern könnt.

AbuseIPDB

Ich nutze für dieses Setup die Datenbank von AbuseIPDB. Damit auch ihr diese nutzen könnt, müsst ihr euch einfach einen kostenlosen Account erstellen. Danach könnt ihr in den Einstellungen einen API Key generieren, den ihr für das folgenden Setup benötigt.

Software installieren

Wir benötigen natürlich einige Softwarepakete. Grundsätzlich, gehe ich davon aus, das ihr UFW bereits installiert habt und entsprechend konfiguriert habt. Zusätzliche Pakete, die noch benötigt werden:

apt install -y screen curl 

Ordnerstruktur

Jetzt legen wir den Ordner an, den wir benötigen:

mkdir /opt/blacklist

Los geht es

Ok, jetzt fangen wir dann mal wirklich an. Die erste Datei, die wir anlegen heißt blacklist.shund liegt in dem eben von uns erstellten Ordner. Der Inhalt ist klein und fein und sieht so aus:

#!/bin/bash

while read line;
do
	ufw insert 1 deny from $line to any;
done < /opt/blacklist/blacklist

Das Script macht nichts anderes, als die Datei /opt/blacklist/blacklist Zeile für Zeile einzulesen und entsprechend an die UFW Firewall zu übergeben und zu blockieren. Richtig, jede Zeile enthält eine potenzielle “böse” IP-Adresse.

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

chmod 700 /opt/blacklist/blacklist.sh

Um diese Liste mit den IP-Adressen zu erstellen, benötigen wir noch ein zweites Script, diese legen wir direkt im Verzeichnis /etc/cron.daily/ an. (Achtung, bei schwachen Servern sollte eher in diesem Verzeichnis /etc/cron.weekly/ die Datei angelegt werden). Das Script hat den Namen getBlacklist. Der Inhalt der Datei, sieht wie folgt aus:

#!/bin/bash

#get latest blacklist from abuseIPDB

curl -G https://api.abuseipdb.com/api/v2/blacklist \
  -d confidenceMinimum=50 \
  -H "Key: EurerAPIKey" \
  -H "Accept: text/plain" | sort > /opt/blacklist/blacklist

#block every ip in list

/usr/bin/bash /opt/blacklist/blacklist.sh

Bitte ersetzt EurerAPIKey mit eurem Key, achtet auf das Leerzeichen nach dem Doppelpunkt!

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

chmod 755 /etc/cron.daily/getBlacklist

Diese Datei holt die IP-Adressen aus der AbuseIPDB Datenbank und schreibt diese in die blacklist Datei. Danach wird unser erstes Script aufgerufen. Der Wert confidenceMinimum gibt das folgenden an:

Wir empfehlen Ihnen, nach abuseConfidenceScore zu filtern, d.h. nach unserer berechneten Bewertung, wie missbräuchlich die IP ist, basierend auf den Nutzern, die sie gemeldet haben (mehr).

Quelle: AbuseIPDB Dokumentation

Testen

Wichtig: Diese Liste enthält aktuell über 10.000 IP-Adressen

Das Einfügen einer solchen Menge in die Firewall, dauert. Also werden wir den folgenden Befehl ausführen, nachdem wir screen gestartet haben.

screen
# Enter drücken
# dann folgendes ausführen
bash /etc/cron.daily/getBlacklist

Jetzt sollten die IP's geladen werden und dann alles in die Firewall eingetragen werden. Mit Strg + a und Strg + d verlasst ihr die aktuelle screen Session. Um das Ergebnis zu sehen, gebt einfach folgenden Befehl ein:

ufw status

Das Bild sollte dann diesem hier sehr ähnlich sein:

In meinem neuen Unternehmen arbeiten wir nur noch mit PostgreSQL Datenbanken. Für ein aktuelles Projekt haben wir jetzt in die Backup Strategie natürlich auch den Dump der jeweiligen Datenbank mit aufgenommen. Im folgenden will ich kurz erklären, wie es schnell unter Linux mit Cron zu lösen ist.

Dazu legen wir eine Datei an, mit dem Name db_backup.sh. Diese sollte dann die folgenden Rechte gesetzt bekommen:

chmod 700 db_backup.sh

Grund hierfür ist, dass wir in die Datei, das Passwort des jeweiligen DB Nutzers ablegen müssen.

Als nächstes kommen wir zum Inhalt:

#!/bin/bash

date=$(date +%Y-%m-%d-%H-%M)
export PGPASSWORD=PasswortVomNutzerTest
/usr/bin/pg_dump -C -f /opt/backup/dumps/${date}_postgres_dump_churchevents.dmp --encoding=UTF-8 -U Test

find /opt/backup/dumps -mtime +5 -exec rm {} \;

Okay, gehen wir Zeile für Zeile durch

date=$(date +%Y-%m-%d-%H-%M)

Wir legen einen Variabel mit dem Namen date fest, die einen String aus dem aktuellen Datum und Uhrzeit beinhaltet.

export PGPASSWORD=PasswortVomNutzerTest

In dieser Zeile legen wir das Passwort vom Nutzer Test fest, was als Umgebungsvariable übergeben wird. Jetzt kommen wir zum eigentlichen Sicherungsbefehl:

/usr/bin/pg_dump -c -C -f  p /opt/backup/dumps/${date}_postgres_dump.sql --encoding=UTF-8 -U Test

• -c enthält im Dump eine Passage, was beim importieren die bereits vorhandene DB löscht und alles neu anlegt
• -C enthält im Dump eine Passage, mit CREATE TABLE Statments
• -f Speicherort des Dumps (das p bedeutet Plaintext, also SQL)
• —encoding ist glaube ich klar :–)
• -U Angabe des Datenbankbenutzers, hier Test

Und als letztes ein Befehl der alle Dumps älter als 5 Tage löscht:

find /opt/backup/dumps -mtime +5 -exec rm {} \;

Jetzt legen wir noch den jeweiligen Cronjob an und das wars.

Alle Datenbanken sichern

Um alle Datenbank zu sichern, gibt es den Befehl pg_dumpall:

pg_dumpall -U postgres > /opt/backup/all.sql

Hier wird der Benutzer postgres verwendet, was der Default Admin Nutzer ist. Entsprechend sein Passwort muss verwendet werden.

Dokumentation

Weitere Hilfe könnt ihr auch in der Dokumentation finden.

Im folgenden Artikel, möchte ich kurz erläutern, wie ihr eine Sicherung von Mailcow auf einer Hetzner Storagebox auslagern könnt. Ich gehe davon aus, dass ihr bereits eine Hetzner Storagebox habt und den SSH sowie den RSYNC Zugriff erlaubt habt.

Storagebox vorbereiten

Es werden einige kleine Schritte benötigt, damit ihr mit der Storagebox problemlos arbeiten könnt. Als erstes generieren wir einen neuen SSH Key:

ssh-keygen -t ed25519

Beantwortet die Fragen nach euren Bedürfnissen, jedoch darf der Key kein Passwort haben. Als nächstes installieren wir sshfs um unsere Storagebox zu mounten:

apt install sshfs -y

Im nächsten Schritt, werden wir die Storagebox mounten:

mkdir /mnt/storagebox
sshfs u123456@u123456.your-storagebox.de:/ /mnt/storagebox/

Jetzt noch entsprechend den Ordner und die Datei für den Schlüssel anlegen:

mkdir /mnt/storagebox/.ssh
touch /mnt/storagebox/.ssh/authorized_keys

Jetzt kopieren wir noch den Key auf die Storagebox:

cat ~/.ssh/id_ed25519.pub >> /mnt/storagebox/.ssh/authorized_keys

Als vorletzten Schritt legen wir noch das Sicherungsverzeichnis in der Storagebox an und umounten die Storagebox wieder vom System:

mkdir /mnt/storagebox/mailserver
fusermount -u /mnt/storagebox

Als letzten Schritt, müssen wir noch eine SSH Config Datei anlegen, da die Storagebox einen anderen Port benutzt:

Host u123456.your-storagebox.de
        User u123456
        Port 23

Bitte wieder den Nutzer entsprechend anpassen

Danke an Thomas Leister

Diese Schritte sind im groben von Thomas Leistner kopiert und angepasst worden. Danke

Backup einrichten

Als erstes legen wir mal die Ordner an die wir brauchen

mkdir /backup
mkdir /opt/backup

Als nächstes legen wir die Datei environment.sh mit folgendem Inhalt an:

#!/bin/bash
export RESTIC_REPOSITORY="sftp:u1234567.your-storagebox.de:mailserver"
export RESTIC_PASSWORD="MeinSicheresBackupPasswort"

Bitte passt entsprechend u1234567 und MeinSicheresBackupPasswort an!

Jetzt legen wie die Datei backup.files mit diesem Inhalt an:

/etc
/backup
/root
/opt

Wir ihr dem Namen vielleicht entnehmen könnt, wollen wir, das restic diese Verzeichnisse sichert. Diese könnt ihr natürlich erweitern. Als letztes legen wir die Datei backup.sh mit folgendem Inhalt an:

#!/bin/bash

MAILCOW_BACKUP_LOCATION=/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 30

source /opt/backup/environment.sh

### Backup new stuff
restic backup \
        --verbose \
        --files-from /opt/backup/backup.files \

### Remove old stuff
echo "Deleting old backups ..."
restic forget --prune \
        --keep-last 7 \
        --keep-daily 14 \
        --keep-weekly 4 \
        --keep-monthly 6 \


restic check

Hier müsst ihr den Pfad zum Mailcow Verzeichniss anpassen: /opt/mailcow-dockerized Zum Schluß machen wir das Script jetzt noch ausführbar:

chmod 700 /opt/backup/backup.sh

Repo initialisieren

Damit restic auch läuft, müsst ihr den folgenden Befehl einmal ausführen, dabei wird die Repo angelegt:

source /opt/backupt/environment.sh && restic init

Crontab

Jetzt legen wir noch einen Cronjob an, der alle 4 Stunden die Sicherung ausführt:

0 */4 * * * /bin/bash /opt/backup/backup.sh

Artikel wird gerade überarbeitet mit einer frischen Kubuntu 20.04 installation

Ich will für Bitwig Windows 32Bit und 64Bit VSTs benutzen. Um Windows VSTs unter Linux zu benutzen, braucht man eine sogenannte Bridge. Es gibt sogar mehrere dieser Bridges

• LinVST https://github.com/osxmidi/LinVst
• LinVST-X https://github.com/osxmidi/LinVst-X
• Airwave https://github.com/psycha0s/airwave
• YaBridge https://github.com/robbert-vdh/yabridge

Die ersten Beiden sind vom selben Programmierer. Der Unterschied zwischen den beiden ist, dass bei LinVST-X die VSTs untereinander kommunizieren können. Ich habe mich erstmal für das einfache LinVST entschieden, das ich unter Kubuntu 19.10 Kubuntu 20.04 mit einem aktivierten KXStudio Repository (https://kx.studio/)  aus dem git Repository installieren möchte.

Dazu sind aber einige Vorbereitungen mit Wine notwendig, damit auch die entsprechenden Dateien und Programme vorhanden sind, die LinVST zum kompilieren braucht. Ich bin teilweise nach der Anleitung von https://wiki.winehq.org/Ubuntu und einigen anderen Anleitungen vorgegangen, bis ich das Paket vollständig kompilieren konnte. Legen wir los.

Update 09.06.2020 : Wegen Spitfire Audio musste ich auf die Entwickler Version von Wine 5.10 wechseln.

Vorbereitungen für Wine

# Auf einem 64Bit System die 32Bit Unterstützung konfigurieren
sudo dpkg --add-architecture i386

# Den Schlüssel für das Repository von winhq hinzufügen
wget -O - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -

# Für Ubuntu 20.04 folgendes Repository hinzufügen
sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main'

# Die Softwarelisten der Repositories aktualisieren
sudo apt update

# ZUERST !! dieses Paket installieren
sudo apt-get install libwine-development-dev

# Jetzt wird die stabile Version von Wine, Wintricks und Git installiert
sudo apt install --install-recommends winehq-devel winetricks git


# Damit 64Bit und 32Bit Programme kompiliert werden können
sudo dpkg-reconfigure winehq-devel-amd64 winehq-devel winehq-devel-i386

# Nun werden die benötigten Entwicklerwerkzeuge zum Kompilieren installiert
sudo apt-get install gcc-multilib g++-multilib build-essential cmake libgtk-3-dev

Wine initialisieren

wineboot -u

Eventuell benötigte Fixe und Schriftarten installieren

winetricks -q corefonts vcrun2010 vcrun2013 vcrun2015 win7

Über das Tool winecfg sollte man noch die Anzeige bzw die Größe der Schriften anpassen. Im Reiter “Grafik” die DPI der Bildschirmauflösung ändern. Auf einem 1920x1080 Bildschirm ist ein Wert von 150 DPI ganz gut.

Ausserdem in winecfg die verwendete Windows Version auf Windows 10 einstellen.

LinVST kompilieren und installieren

Zuerst in ein Verzeichnis wechseln,(erstellen)  wohin man LinVST klonen (runterladen)  und bauen kann. Ich habe hier ein Verzeichnis das ich “Programme” genannt habe (/home/userName/Programme/).

In diesem Verzeichnis dann folgenden Befehl eingeben, um LinVST aus dem Git Repository zu laden

git clone https://github.com/osxmidi/LinVst.git

Im aktuellen Verzeichnis existiert jetzt ein weiteres Unterverzeichnis mit dem Namen LinVST. (/home/userName/Programme/LinVST)

1. In das Verzeichnis LinVST wechseln mit cd LinVST
2. Das aktuelle Makefile sichern mit mv Makefile Makefile.original
3. Für Bitwig das Makefile-64-32bit-Bitwig in Makefile umbenennen cp Makefile-64-32bit-Bitwig Makefile
4. Jetzt das Kompilieren starten mit make
5. LinVST systemweit installieren mit  sudo make install
6. Ins Unterverzeichnis convert wechseln cd convert
7. Und hier nochmal make ausfüheren. Damit wird das Tool linvstconvert erstellt

Damit ist alles installiert und vorbereitet, um Windows VSTs für Linux zu installieren.

Weiter geht es im nächsten Artikel “LinVST - Windows VSTs einrichten” wie man ein VST einrichtet und benutzt.

Ein paar nützliche Befehle im Bezug auf apt, die ich immer wieder brauche und von denen ich mir einige immer wieder neu zusammen suche. Das repetitive Suchen muss endlich ein Ende haben ;)

Installation und Deinstallation

• Installieren mit sudo apt install <Paketname>

• Deinstallation sudo apt remove <Paketname>
• Deinstallation mit Entfernung der Konfigurationen sudo apt purge <Paketname>
• Alle installierten Pakete ausgeben apt list --installed
• Eine bestimmte Version installieren sudo apt install <Paketname>=<Versionsnummer>
• Wenn eine Installation schief lief, hilft manchmal das hier  sudo dpkg --configure -a   und   sudo apt-get -f install

Update/Upgrade

• Software Update  sudo apt update
• Welche Pakete sollen aktualisiert werden apt list --upgradeable
• Software Upgrade der Pakete durch neuere Versionen sudo apt upgrade
• Software Upgrade mit Entfernen von nicht mehr benötigten Paketen sudo apt full-upgrade
• Software Upgrade mit Entfernen und Austausch durch neue Pakete sudo apt dist-upgrade
• Alle Pakete, die nicht mehr benötigt werden entfernen sudo apt autoremove

Aufräumen

• Nicht mehr benötigte Pakete deinstallieren sudo apt autoremove
• Löschen aller runtergeladenen und gecachten Pakete sudo apt clean
• Löschen aller lokalen Pakete, die nicht mehr in den Repositories verfügbar sind sudo apt autoclean

Suche

- Software suchen apt search |grep <Paketname>

Konfiguration

• Paket neu konfigurieren sudo dpkg-reconfigure <Paketname>

Repository

• Aus welchem Repository stammt das Paket apt policy <Paketname>
• Oder mit etwas mehr Info apt show <Paketname>
• So werden nur die installierten Pakete angezeigt apt list --installed

Sonstiges

• Die Repositories befinden sich in /etc/apt/sources.list bzw weitere Listen in /etc/apt/sources.list.d/
• Die runtergeladenen Pakete werden in /var/lib/apt/lists/ gespeichert
• Ein grafisches Tool unter Kubuntu ist muon