Security Distributionen: BlackArch 2021.09 und Kali Linux 2021.3

Kali Linux 2021.3

Neues Quartal neues Kali Linux.

Kali_Linux

TLS 1.x

Mit Version 2021.3 wurden unter anderem alte Brötchen wieder aufgewärmt. So ist TLS 1.0 und TLS 1.1 unter OpenSSL wieder aktiv. Hintergrund sind mögliche Tests mit alten Systemen, welche noch mit den alten Standards laufen. Mit dem Befehl kali-tweaks lassen sich die Einstellungen allerdings jederzeit anpassen.

Virtuelle Maschinen

Virtuelle Maschinen haben eine bessere Unterstützung erhalten. So sollte nun ein Copy & Paste zwischen Host und virtuellem Zielsystem funktionieren. Unter Windows wurde mit dem Hyper-V Enhanced Session Mode die Möglichkeit für USB Sticks als lokale Ressource geschaffen.

Auch diese Funktion lässt sich über den Befehl kali-tweaks einrichten.

Smartwatches und Android 11 ohne TWRP

Neben der ersten Smartwatch TicHunter-Pro können Android 11 Smartphones nun via Magisk bespielt werden. Bisher war dies nur über das TWRP möglich. Das Projekt befindet sich allerdings noch am Anfang und ist mit Vorsicht zu genießen.

ARM

Kali für ARM hat neue Build Scripts erhalten, diese unterstützen nun auch RaspberryPi Zero.

Die aktualisierten Scripts erstellen ein neues Snakeoil Zertifikat. Als neue Standard Shell wird ZSH integriert. Dies lässt sich über das bereits bekannte kali-tweaks anpassen. Ebenfalls werden kalipi-config und kalipi-tft-config vorinstalliert.

Pinebook Freunde dürfen sich außerdem über einen neuen Kernel und einen hübscheren Bootscreen freuen.

kali-tools

Doku ist alles

Die neue Kali Tools Seite soll nicht unerwähnt bleiben. Sie bietet eine moderne und praktische Übersicht aller vorhandener Software.

BlackArch hat so eine Übersicht schon etwas länger und in der Vergangenheit ebenfalls ein neues Release veröffentlicht.

Download


BlackArch 2021.09

blackarch
Nachdem Kali Linux vorgelegt hatte, zieht BlackArch mit einer neuen Version nach.

Das auf Arch Linux basierende System bringt nach eigener Aussage nun 2700 Tools mit.

Welche Werkzeuge euch genau zur Verfügung stehen, könnt ihr dieser Tool-Liste entnehmen.

BlackArch 2021.09 läuft mit dem Kernel 5.13.10. Neben einem neuen Textinstaller gab es die üblichen Updates.

Download



Übersicht 09/2021

 

Name Version Tools Besonderes Basis GUI
Autopsy 4.18 ??? The Sleuth Kit Windows  
BackBox 7.0 100+ AWS Ubuntu Xfce
BlackArch 2021.09 1750+ ArchLinux ArchLinux Multi
CAINE 11 100+ WinUFO Ubuntu Mate
DracOS 3.0   veraltet LFS DWM
DEFT Zero 2018.2   offline Lubuntu 14.04 Lxde
Kali Linux 2021.03 300+ Plattformen Debian Testing Multi
Kali AppStore   40+   Android  
LionSec 5.0   veraltet Ubuntu  
Matriux v3 RC1   offline Debian Gnome
NST 34 ??? Server integriert Fedora  
NetSecL OS 6.0   veraltet OpenSuse Lxde
Paladin 7.0     Ubuntu  
Parrot OS 4.11.2 700+ Cloud fähig Debian Buster MATE/KDE
Pentoo 2018.0 RC7.1   veraltet Gentoo Xfce
Ronin     veraltet Lubuntu Lxde
Sans SIFT 3.0   veraltet Ubuntu  






Zwei Bash-Skripte zur Analyse der NGINX Access Logs

Beim Durchwühlen des Internets bin ich auf eine Perle gestoßen, die ich hier festhalten möchte. In „Bash Script to Parse and Analyze Nginx Access Logs“ stellt Ruan Bekker ein kurzes Bash-Skript vor, welches die NGINX Access Logs analysiert, um einen Bericht mit folgenden Sektionen auszugeben:

Ich selbst nutze aktuell den Fork von Marc Brunet, welchen ich meinen My-IT-Scripts hinzugefügt habe:

#!/bin/bash

# URL: https://github.com/Tronde/My-IT-Scripts/blob/master/bash/analyze_nginx_access_logs.sh

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

filters_404(){
grep -w "404"
}

request_ips(){
awk '{print $1}'
}

request_method(){
awk '{print $6}' \
| cut -d'"' -f2
}

request_pages(){
awk '{print $7}'
}

wordcount(){
sort \
| uniq -c
}

sort_desc(){
sort -rn
}

return_kv(){
awk '{print $1, $2}'
}

request_pages(){
awk '{print $7}'
}

return_top_ten(){
head -10
}

## actions
get_request_ips(){
echo ""
echo "Top 10 Request IP's:"
echo "===================="

cat $LOGFILE \
| filters \
| request_ips \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_methods(){
echo "Top Request Methods:"
echo "===================="
cat $LOGFILE \
| filters \
| request_method \
| wordcount \
| return_kv
echo ""
}

get_request_pages_404(){
echo "Top 10: 404 Page Responses:"
echo "==========================="
zgrep '-' $LOGFILE $LOGFILE_GZ\
| filters_404 \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}


get_request_pages(){
echo "Top 10 Request Pages:"
echo "====================="
cat $LOGFILE \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_pages_all(){
echo "Top 10 Request Pages from All Logs:"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

# executing
get_request_ips
get_request_methods
get_request_pages
get_request_pages_all
get_request_pages_404

Selbstverständlich erhalte ich damit keine genauen Statistiken, da meine Logs nach einem Monat automatisch gelöscht werden. Für einen kurzen Rückblick und der Erstellung eines monatlichen Berichts scheint das kleine Skript jedoch gut geeignet zu sein. Ich probiere es gerade aus, um zu sehen, wie gut es mir auf Dauer gefällt.

Auf Basis des ersten Skripts habe ich ein zweites geschrieben, mit dessen Hilfe ich die Requests für einen spezifischen Beitrag abfragen kann (Quelle):

#!/bin/bash

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"
ARG1=$1

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

request_ips(){
awk '{print $1}'
}

request_page(){
awk '{print $7}' \
| grep -w $ARG1
}

wordcount(){
sort \
| uniq -c
}

return_kv(){
awk '{print $1, $2}'
}

get_request_page(){
echo "Page requests in current log:"
echo "====================="
cat $LOGFILE \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

get_request_page_all(){
echo "Page requests in all logs (last month):"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

# execute
get_request_page
get_request_page_all

Der folgende Code-Block zeigt ein Beispiel, wie das Skript angewendet wird. Dabei wird der Permalink als Argument übergeben:

:~/bin$ sh get_page_requests_from_nginx_access_logs.sh kommentar-linux-container-spreu-und-weizen
Page requests in current log:
=====================
262 /wordpress/kommentar-linux-container-spreu-und-weizen/
6 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/

Page requests in all logs (last month):
===================================
5124 /wordpress/kommentar-linux-container-spreu-und-weizen/
49 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/
2 /wordpress/wp-json/oembed/1.0/embed?url=https://www.my-it-brain.de/wordpress/kommentar-linux-container-spreu-und-weizen/

Noch nicht schön, aber zweckmäßig.

Was haltet ihr davon? Falls ihr beim Drübergucken zufällig noch einen Fehler in den Skripten entdeckt, freue ich mich, wenn ihr mir einen Kommentar hinterlasst.






Lesetipp: Vision für Fedora Workstation

Christian Schaller hat in seinem Blog sich sehr ausführlich zur vergangenen und künftigen Entwicklung von Fedora Workstation (also der Desktop-Variante der Distribution) geäußert.

Den Artikel „Fedora Workstation: Our Vision for Linux Desktop“ möchte ich allen interessierten Linux-Nutzerns empfehlen. Neben einem Resümee der Ausgangssituation und getroffenen Entscheidungen kann man bereits einen Ausblick auf das werden, was konzeptionell angedacht wird. Besonders interessant ist die Schilderung, wie komplex die Entwicklung einer klassischen Distribution mit normaler Paketverwaltung ist und dass dieses Konzept eigentlich keine sinnvolle Variante für schnelle Entwicklungszyklen ist. Wenn es überhaupt eine langfristige Zukunft jenseits Status quo-orientierter Distributionen hat.

Die Zielrichtung von Fedora Workstation ist immer noch ein Szenario, das sich momentan in der Silverblue-Edition testen lässt. Das bedeutet eine gänzlich neue Art Linux-Distribution. Das Betriebssystem wird read-only eingebunden, Anwendungen primär über Flatpaks installiert und weiterführende Ansprüche werden mit Toolbox anvisiert. Dabei handelt es sich letztlich um Container mit Systemwerkzeugen.

Weitere Themen sind dann noch Wayland, Pipewire und LVFS. Ebenfalls sehr interessante Baustellen und für viele Community-Lieblinge wie MATE oder Xfce ein riesiges Problem, weil die Manpower für solche Entwicklungsleistungen eigentlich zu knapp ist.

An dem Artikel sieht man wieder sehr deutlich, wie wichtige Red Hat bzw. Fedora für Linux ist. Nahezu alle wichtigen Zukunftsthemen werden dort bearbeitet, viele wichtige Projekte gestartet und entwickelt. Diese sickern dann nach und nach in die anderen Distributionen.

Interessierte Anwender sollten sich außerdem Silverblue mal ansehen. Momentan halte ich Silverblue noch nicht für komplett alltagstauglich und die Fedora-Entwickler teilen diese Meinung scheinbar. Die Fortschritte sind aber immens und ich persönlich denke, dass diese Variante einer Linux-Distribution bereits in den nächsten Jahren das normale Desktop-Linux für Endanwender werden kann.

OpenSUSE experimentiert schließlich mit einem ähnlichen Konzept, das aber einen vollständig anderen technischen Ansatz hat und Ubuntu könnte Snaps weiter aufbohren und auf eine ähnliche Strategie schwenken. Sofern man an der Eigenentwicklung festhält und sich nicht letztlich doch wieder dem Linux-Mainstream beugt.

Der Artikel Lesetipp: Vision für Fedora Workstation erschien zuerst auf [Mer]Curius






Lennart Poettering hinterfragt Linux Verschlüsselung

Der systemd-Entwickler schreckt mal wieder die Linux-Gemeinde auf. Nicht ganz unerwartet befasst er sich mit der Ar,t wie die meisten Linux-Distributionen Daten verschlüsseln und Integrität gewährleisten. Ein notwendiger Weckruf für die oft bräsige Community.

Poettering befasst sich bereits seit längerem mit der Datensicherheit, LUKS und TPM. Der aktuelle Blogpost von ihm kommt daher nicht gänzlich unerwartet. Eine kurze Zusammenfassung und Bewertung kann man auch bei Golem lesen.

Einleitend befasst er sich mit dem aktuellen Status quo. Hier ist er sogar in vielen Fällen zu optimistisch, denn die Situation ist oft noch viel schlimmer.

Die meisten Distributionen verschlüsseln standardmäßig gar nicht und drängen diese Möglichkeit ihren Nutzern auch nur dezent auf. Linux ist hier schon länger deutlich unsicherer als die meisten anderen Betriebssysteme – abgesehen nur von der Windows-Home-Edition. Linux-Distributionen verschlüsseln Daten mittels einer LUKS/Cryptsetup-Lösung, die frühere verbreitete eCryptFS-Methode ist kaum noch verbreitet. Basale TPM-Unterstützung ist zwar vorhanden, wird aber kaum genutzt, obwohl (wegen entsprechender Microsoft-Vorgaben) alle halbwegs neuen Geräte einen TPM-Chip aufweisen.

Ein weiterer Baustein in der Validierungskette ist Secureboot. Hier ist Poettering wieder mal viel zu optimistisch, wenn er schreibt, dass die meisten Distributionen hierüber absichern. Insbesondere die vielen Kleinprojekte, aber auch so beliebte Distributionen wie Arch Linux oder Manjaro bieten kein Secureboot an bzw. zumindest nicht als Standard. Im besten Fall nutzt eine Distribution Secureboot und validiert via Shim Bootloader und Kernel. Eine lückenlose Valididerungskette inklusive Initrd und Betriebssystem erfolgt bei keiner Distribution. Dazu hatte ich mich hier auch schon mal geäußert. Das nicht verifizierte Initrd wird entpackt und fragt nach einem Passwort, um das LUKS-Volume zu entschlüsseln. Ab jetzt sind die Daten verfügbar. Der Benutzerlogin ist dann nur noch Kosmetik und wird von vielen LUKS-Nutzern bei Einzelnutzung auch per Autologin übersprungen.

Die aktuelle Vorgehensweise hat gleich mehrere offene Flanken. Vor allem schützt sie nicht, wenn die Festplatte physisch gestohlen oder komplett kopiert wird. Der Angreifer hat danach alle Zeit der Welt, um sich mit der Verschlüsselung und ihrer Umgehung zu beschäftigen. Ein weiteres Szenario ist die unbeobachtete Kompromittierung des Systems, genant Evil Maid Angriff.

Poettering kommt deshalb auch zu dem harten Schluss, dass alle anderen Betriebssysteme – ChromeOS, Android, Windows und macOS – die Daten der Anwender besser schützen.

Zur Abhilfe schlägt Poettering einige Punkte vor. Initrd müsste beim Start authentifiziert werden, ebenso das System unter /usr (was einen vollständigen usr-merge voraussetzt – Hallo Debian) und die Verschlüsselung des Benutzerverzeichnisses sollte an das Nutzerpasswort gebunden werden und nicht an das System. Besser wären noch Lösungen ohne Passwörter, wie beispielsweise FIDO2. Hier enteilt Microsoft Windows mit Hello Linux sowieso hoffnungslos.

Die Lösungsvorschläge basieren natürlich viel auf Entwicklungen in systemd (z. B. system-cryptenroll, systemd-home), aber auch auf Kryptofunktionen im Kernel wie dm-Verify und dm-Integrity. Ingesamt setzt Poettering auf eine viel stärkere Einbeziehung der sowieso verfügbaren TPM-Technik in die Sicherheitskonzepte der Distributionen. In diesem Zusammenhang wendet er sich auch massiv gegen nicht faktengestützte Vorurteile gegenüber TPM.

Diese Ideen sind natürlich weit entfernt davon, produktiv einsetzbar zu sein. Vermutlich werden sie am ehesten bei Fedora umgesetzt und dann sukzessive bei weiteren Distributionen.

Leider werden viele schon alleine deshalb dagegen arbeiten, weil die Ideen von Poettering kommen und systemd bei vielen nicht faktengestützte Vorurteile hervorrufen. Zudem haben viele Linux-Nutzer sich bequem in der Vergangenheit eingerichtet und leugnen die Herausforderungen der Gegenwart (von der Zukunft ganz zu schweigen).

Der Artikel Lennart Poettering hinterfragt Linux Verschlüsselung erschien zuerst auf [Mer]Curius






Mozilla veröffentlicht Firefox 92.0.1

Mozilla hat mit Firefox 92.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 92.0.1

Mit dem Update auf Firefox 92.0.1 behebt Mozilla ein Problem, welches unter bestimmten Umständen verursachen konnte, dass die Suchleiste keinen Schließen-Button anzeigte. Außerdem wurde ein Problem behoben, welches für manche Linux-Nutzer verursachte, dass bei der Wiedergabe von Medien kein Ton zu hören war. Darüber hinaus wurde das Suchmaschinen-Logo von DuckDuckGo aktualisiert und diverse Anpassungen in Vorbereitung auf ein bevorstehendes Experiment für Nutzer in den USA wurden integriert.

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






Kommentar: Viele Distributionen nutzen nur bei wirklicher Vielfalt etwas

Von Linux gibt es drölfzig Distributionen. Das wird gerne kritisiert, weil dadurch massiv Ressourcen gebunden werden. Befürworter verteidigen immer die Vielfalt als Stärke von Linux. Das gilt aber auch nur wenn man die Vielfalt auch wirklich zulässt und nutzt.

Aktuell gibt es nur Pseudo-Vielfalt unter den Distributionen, denn im Grunde genommen sind sie sich alle sehr ähnlich. Es gibt Distributionen mit rollenden Veröffentlichungsmodellen und stabile Distributionen mit festgelegten Releasezyklen und Supportzeiträumen. Bei Letzteren muss man noch die kleine Gruppe der Distributionen mit LTS/Enterprise-Support separieren.

Alle Distributionen funktionieren sehr ähnlich. Meistens bieten sie alle verfügbaren Desktopumgebungen an, die zunehmend lieblos integriert werden, weil die hohe Schlagzahl bei zurückgehenden Ressourcen keine liebevolle Integration mehr zulässt. Die allermeisten Distributionen verwenden systemd, udev, PolKit, eine X11/Wayland-Kombination, kompilieren mit GCC usw. usf.

Es gibt nur ein paar wenige exotische Distributionen mit Grundlagen, die sich deutlich von allen anderen unterscheiden. Spontan fallen mir da vielleicht Gentoo, Void, Slackware und vielleicht Devuan ein. Gemessen an der Gesamtzahl fallen diese kaum ins Gewicht.

Wo ist der Unterschied zwischen Linux Mint und Ubuntu oder zwischen Ubuntu und Debian? Wo ist der Unterschied zwischen Mageia und Fedora, zwischen openSUSE und Mageia? Wo trennt sich Manjaro von Arch Linux und was sind die Vorteile gegenüber openSUSE Tumbleweed? Man muss schon ganz weit heran zoomen, um hier noch die große Vielfalt zu erkennen, die angeblich der Vorteil von Linux ist.

Wenn also Distributionen wie Fedora mit Silverblue an der Distribution der Zukunft bauen, openSUSE mit MicroOS experimentiert, Ubuntu demnächst mehr Snaps ausrollen und elementary OS ein kuratiertes Flatpak-Ökosystem aufbauen, ist das eine Chance. Eine Chance auf wirkliche Vielfalt.

Es wird schließlich noch genug Distributionen geben, die andere Wege einschlagen. Die an konventionellen Veröffentlichungen festhalten, Flatpaks oder Snaps nicht standardmäßig verteilen oder sogar komplett aussperren.

Meiner Meinung nach könnte das noch viel weiter gehen. Anstatt 6 Desktops stiefmütterlich zu unterstützen, sollte man sich auch hier lieber auf einige wenige konzentrieren und hier auch guten Support bieten. So wie Fedora dies mit GNOME macht oder KDE neon mit Plasma. Andere Distributionen können hier ja andere Entscheidungen treffen.

Wenn nicht mehr alle Distributionen alles bieten, muss vielleicht der ein oder andere seine Distribution wechseln. Das Ökosystem gewinnt aber insgesamt hinzu. An wirklicher Vielfalt, an Wahlmöglichkeiten und an Qualität.

Momentan ist die vermeintliche Vielfalt nur ein Argument jener, die jede Kritik am Distributionsdschungel wegwischen wollen. Kaum entsteht wirkliche Vielfalt, wie bei Canonicals Entscheidung, künftig stärker auf Snaps zu setzen, kommt ein lautes Wehklagen, ob des vermeintlichen Verrats am Linux-Einheitsbrei und der Drohung, dass man dann selbst woanders hin abwandern möchte (gerne versteckt als „dann werden viele User gehen“).

Super, dann geht doch. Das ist überhaupt nicht negativ gemeint, denn genau dafür hat Linux doch die Vielfalt. Es muss nicht jede Distribution zu jedem Anwender oder Anwendungsfall passen. Gefällt einem eine Distribution nicht, sucht man sich eine andere. Vielfalt bedeutet nicht, hundert austauschbare Distributionen zu haben.

Der Artikel Kommentar: Viele Distributionen nutzen nur bei wirklicher Vielfalt etwas erschien zuerst auf [Mer]Curius






Etherpad unter Ubuntu installieren

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.






Flatpak / Snap vs. Paketverwaltung – Alles was dazu gesagt werden muss

Ubuntu stellt demnächst Firefox auf Snap um. In der Community kochen mal wieder die Gemüter hoch. Anstelle mich immer zu wiederholen, fasse ich hier mal alle relevanten Punkte zusammen. Das Ziel ist ein möglichst sachlicher Überblick

Es gibt unterschiedliche Arten wie Betriebssysteme Software organisieren. Windows und macOS haben lange auf separate Installationsroutinen für einzelne Programme gesetzt, die auf ein Betriebssystem mit eigener Updateroutine installiert werden. Heute drängen beide mehr oder minder erfolgreich auf die Adaption des App Store-Prinzips auch für den Desktop.

Die verschiedenen Linux-Distributionen haben stattdessen aus unterschiedlichen Gründen eine zentrale Paketverwaltung für die Installation und Aktualisierung des gesamten Systems, letztlich vom Kernel bis zum Taschenrechner, entwickelt. Dabei gab und gibt es unterschiedliche Spielarten, aber das System funktioniert bei fast allen Distributionen gleich.

Das hat nichts mit Open Source vs. proprietäre Software zu tun, was man schon daran sehen kann, dass die verschiedenen BSD-Varianten noch mal ganz andere Modelle aufgezogen haben.

Ganz zentral ist, dass es kein entweder/oder gibt. Die Entwickler von Flatpak respektive Snap haben nie die Absicht geäußert, klassische Paketverwaltungen gänzlich zu ersetzen und selbst wenn eine Distribution komplett bei klassischen Paketverwaltungen bleiben möchte, kommt man vermutlich zukünftig zumindest bei manchen proprietären Programmen nicht um die Nutzung von Flatpak bzw. Snap umhin.

Die Sinnhaftigkeit von zwei neuen Lösungen, also Flatpak und Snap, kann man infrage stellen. Es wird hier keine Analyse der Unterschiede der einzelnen beiden Lösungen geben und auch keine Prognose abgegeben, ob beide dauerhaft überleben, oder nur eines von beiden sich durchsetzt. Neben Flatpak und Snap gibt es mit AppImages und Container-Ansätzen weitere Lösungen, die hier nicht berücksichtigt werden.

Paketverwaltung

Kennzeichen der klassischen Paketverwaltung:

Vorteile der klassischen Paketverwaltung:

Nachteile der klassischen Paketverwaltung:

Neue Formate Flatpak / Snap

Kennzeichen der neuen Formate Flatpak / Snap:

Vorteile der neuen Formate Flatpak / Snap:

Nachteile der neuen Formate Flatpak / Snap:

Der Artikel Flatpak / Snap vs. Paketverwaltung – Alles was dazu gesagt werden muss erschien zuerst auf [Mer]Curius






Thunderbird 91.1.1 veröffentlicht

Die MZLA Technologies Corporation hat mit Thunderbird 91.1.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.1.1

Thunderbird 91.1.1 ist ein Fehlerbehebungs-Update außer der Reihe, welches noch einmal eine ganze Reihe von Fehlern der Versionsreihe 91 behebt, ehe ab dieser Woche die Updates von Thunderbird 78 auf Thunderbird 91 aktiviert werden – zunächst nur für Nutzer in den USA. Eine Übersicht über die in Thunderbird 91.1.1 behobenen Fehler gibt es in den Release Notes (engl.).

Der Beitrag Thunderbird 91.1.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.






Experiment: elementary OS 6 mit Flatpaks

In verwende seit einiger Zeit elementary OS im Consumer-Einsatz. Die Erfahrungen sind ziemlich positiv. Nun teste ich den weitestgehenden Umstieg auf Flatpaks.

In meinem Umfeld sind in den letzten Jahren einige Leute auf Linux umgestiegen. Ich empfehle das nicht aktiv, aber wenn der Wunsch von außen an mich herangetragen wird und eine Prüfung der Bedarfe Linux als mögliche Alternative ergibt, helfe ich gerne beim Umstieg. Ehrlicherweise allerdings auch langfristig als Ansprechpartner für Administration und Probleme. Das ist nur noch privat und semi-privat für ein KMU. Beruflich geht es für mich schon seit einiger Zeit in eine andere Richtung und weg von IT-„Management“.

Vor einiger Zeit habe ich damit begonnen, für diese Zwecke elementary OS auszutesten. Momentan betreue ich dadurch leider eine ziemlich krude Mischung aus Kubuntus und Systemen mit Pantheon Shell. Elementary OS 5 hatte leider einige nervige Bugs, weshalb ich längere Zeit auf Fedora setzte.

Die Pantheon Shell und die zugehörigen Programme plus Ergänzungen aus dem GNOME Ökosystem sind meiner Meinung nach ideal für Anwender, die keine Lust haben sich groß mit dem System zu befassen. Die Funktionsweise ist intuitiv und die Programme nicht überfrachtet mit Optionen. Die Anwender sind damit ziemlich zufrieden und ich bekomme sehr selten Probleme mit. Die Kubuntus machen mir da viel mehr Scherereien, nicht wegen Fehlern, sondern weil die Anwender es immer wieder hinbekommen, Plasma zu verunstalten und mit der Reorganisation der Elemente dann überfordert sind, weil die KDE-UX nicht intuitiv ist.

Die Integration von Pantheon in Fedora ist aber nur mittelmäßig und hat hier und da immer wieder für Probleme gesorgt. Trotz der Schwächen von elementary OS 6 habe ich daher angefangen, die Systeme sukzessive umzustellen.

Die elementary-Entwickler haben den Wechsel auf ein Flatpak-basiertes System eingeleitet. Das neue Appcenter kann zwar Aktualisierungen für APT durchführen, aber bietet Installationen von neuen Programmen nur über das Flatpak-Repo an. Ich stehe den neuen Formaten grundsätzlich offen gegenüber, obwohl ich persönlich bei meinem eigenen System noch eine klassische RR-Paketverwaltungssystem fahre.

Das Flatpak-Repo von elementary OS ist noch recht schmal bestückt, aber man kann Flathub unproblematisch systemweit einrichten und danach die dort enthaltenen Programme via Appcenter (oder Terminal) installieren.

Das habe ich auf einem „Testsystem“ jetzt mal konsequent verfolgt. Die klassische Paketverwaltung organisiert nun wirklich nur noch das Basissystem und die Desktopoberfläche. Alle Programme kommen konsequent aus dem elementary Flatpak-Repo oder von Flathub. Das ist der übliche Consumer-Mischmasch aus Firefox, Evolution, LibreOffice, Spotify, Anydesk usw. usf.

Der Vorteil ist ziemlich offensichtlich. Die Version von Kernel, X11, Mesa oder glibc ist hier völlig egal, die Hardware wird schon seit Kernel 5.4 perfekt unterstützt. Das Basissystem kommt nun direkt aus Ubuntu main plus die separat von elementary gepflegten Bestandteile. Das trägt notfalls bis ins Jahr 2025. Hier gibt es keine Überraschungen oder Updates, die Administration erforderlich machen. Durch den konsequenten Einsatz von Flatpaks entgeht man aber den ungepflegten Paketen in universe und bekommt hier immer die aktuelle stabile Version ausgeliefert.

Die Installation und die Updates laufen ziemlich problemlos und durch die Ähnlichkeit zu den mobilen Appstores ist das Verfahren auch sehr niedrigschwellig und bedurfte keiner weiteren Erklärung.

Ich bin gespannt wie sich das System so im Alltagsbetrieb schlägt, ob Probleme auftreten und wenn ja welche.

Der Artikel Experiment: elementary OS 6 mit Flatpaks erschien zuerst auf [Mer]Curius