Schon früh war ich von Imaging Software begeistert und habe die
ersten OS/2 Installationen (damals noch HPFS) damit gesichert. Später
habe ich damit auch NTFS und diverse Windows Versionen in Abbilder verwandelt.

Bei Linux war ich die ersten Jahre begeistert von Partimage, welches perfekt
ext3 aber auch ReiserFS oder jfs gesichert hat. Doch mit ext4 hörte die Unterstützung auf.
Als alternative habe ich partclone gefunden welches rein auf cli Basis das gleiche tut.
Der Unterschied ist nur das es auch mit ext4 zurecht kommt.
Sowohl Partimage wie auch partclone arbeitet auf Sektorbasis und erstellt so
ein 1:1 Kopie des Systems.

Bis zur Version 4.5.2 war partclone mit auf der RettungsCD und sicherte mir
alle Dateisysteme. Doch danach verschwand es. Erst als die RettungsCD nicht mehr
Gentoo sondern Arch als Basis nutze kam das Programm wieder dazu. Aktuell habe ich
immer die Version 6.0.3 auf nem Stick mit dabei.

Neben dem sehr nützlichen Programm partclone finden sich auch diverse Rettungsprogramme
darauf, z.b. um ein Windows Kennwort neu zu setzten, oder Daten von defekten Datenträgern
zu retten.

Seit meinem ersten Kontakt mit der CD kann ich mir ein Computer-Leben ohne das
Rettungssystem nicht mehr vorstellen. Selbstverständlich unterstützt die Version 6
auch Computer mit UEFI.

Mit Firefox 71 ersetzt Mozilla den bisherigen Zertifikats-Betrachter von Firefox durch eine neue mit Webtechnologie umgesetzte Oberfläche.

Infos zum TLS-Zertifikat einer Website hat Firefox bislang in einem separaten Fenter angezeigt.

Mit Firefox 71 verschwindet das Fenster. Dann verwendet Firefox einen neuen Zertifikats-Betrachter, welcher in einem Tab statt in einem separaten Fenster angezeigt wird und mit moderner Webtechnologie umgesetzt ist. Auch andere Teile von Firefox wurden in den letzten Monaten mit Webtechnologie neu entwickelt, darunter die Adressleiste, der Add-on Manager (beides Firefox 68) und die Konfigurations-Oberfläche about:config, welche in ihrer neuen Form bald ausgeliefert werden wird.

Die Neu-Implementierung des Zertifikat-Betrachters basiert auf der Firefox-Erweiterung Certainly Something von Mozilla-Entwicklerin April King und wurde im Rahmen eines Outreachy-Praktikums in Firefox integriert.

Firefox 71 erscheint nach aktueller Planung am 10. Dezember 2019.

Der Beitrag Firefox 71 bekommt neuen Zertifikats-Betrachter erschien zuerst auf soeren-hentzschel.at.

Mozilla bietet als neuen Service ab sofort kostenpflichtigen Premium-Support für Firefox im Unternehmen an.

Unternehmen können ab sofort von einem Premium-Support für Firefox Gebrauch machen. Während Firefox weiterhin für alle kostenfrei bleibt und allgemeiner Support wie gehabt über eine freie Wissensdatenbank und Community-Support stattfindet, bietet der Premium-Support spezielle Vorteile für Unternehmen.

So erhalten Kunden Zugriff auf das sogenannte Mozilla Enterprise Client Service Desk, wo sie Hilfe zur Anpassung und Verteilung von Firefox im Unternehmen erhalten. Es gibt Service-Level-Agreement (SLA) für kritische Sicherheits-Fixes und Fehler können privat gemeldet werden. Auch zur Produkt-Roadmap kann beigetragen werden, indem Ideen für neue Funktionen dem Produkt-Management mitgeteilt werden, wobei dies natürlich keine Implementierung in Firefox garantiert.

Preislich startet der Premium-Support bei 10 Dollar pro Installation, wobei das Sales-Team für weitere Details zu kontaktieren ist. Eine eigene Seite beantwortet wichtige Fragen zum Service-Level-Agreement (SLA).

Der Beitrag Firefox: Mozilla startet Premium-Support für Unternehmen erschien zuerst auf soeren-hentzschel.at.

Nach Firefox Monitor und Firefox Lockwise hat Mozilla seinen nächsten Dienst mit Privatsphäre-Fokus unter der Firefox-Dachmarke gestartet: Firefox Private Network. Die öffentliche Beta des VPNs ist derzeit allerdings nur für Nutzer in den USA verfügbar.

Mozilla baut sein Produkt-Portfolio rund um das Thema Privatsphäre unter der Firefox-Marke weiter aus. Nicht nur der Firefox-Browser hat in den letzten Monaten verstärkt Privatsphäre-Verbesserungen erhalten, auch wurde mit Firefox Lockwise ein Passwort-Manager für Android und iOS entwickelt und mit Firefox Monitor gibt es einen Dienst, welcher überprüft, ob die eigene E-Mail-Adresse schon einmal Teil eines bekannten Datenlecks geworden ist. Mit Firefox Private Network kommt nun in Zusammenarbeit mit Cloudflare ein VPN dazu.

Firefox Private Network verfolgt primär zwei Ziele. Zum einen soll sämtlicher Verkehr, welcher über den Browser abgewickelt wird, verschlüsselt werden, um so sensible Daten wie Passwörter, E-Mails oder Kreditkarteninformationen vor Angreifern zu schützen. Zum anderen wird aber auch gezielte Werbung erschwert, da der tatsächliche Standort vor Websites und Werbe-Netzwerken versteckt wird.

Der Nutzer muss nicht mehr tun als eine Firefox-Erweiterung zu installieren und sich in seinen Firefox Account einzuloggen. Über ein Symbol in der Navigationssymbolleiste kann Firefox Private Network jederzeit ein- und ausgeschaltet werden.

Firefox Private Network ist während der Betaphase kostenlos. Die spätere Preisstruktur steht zu diesem Zeitpunkt noch nicht fest. Der Dienst ist derzeit nur in den USA verfügbar.

Der Beitrag VPN: Mozilla startet Public Beta von Firefox Private Network erschien zuerst auf soeren-hentzschel.at.

EPEL steht für Extra Packages for Enterprise Linux und ist die wichtigste externe Paketquelle für RHEL- und CentOS-Anwender. EPEL hat deswegen eine so große Bedeutung, weil Red Hat traditionell viel weniger Pakete ausliefert/pflegt als beispielsweise Debian oder Ubuntu. RHEL/CentOS-Anwender, die darüberhinaus weitere Software-Pakete benötigen, richten deswegen zumeist die EPEL-Paketquelle ein.

Wer nach der Freigabe von Red Hat Enterprise Linux 8 (RHEL 8) sofort den Umstieg wagte, musste allerdings ohne EPEL auskommen. Weil Red Hat die Organisation seiner eigenen Pakete grundlegend verändert hat (Modularisierung durch das AppStream-Verfahren), muss auch das EPEL-Repository vollkommen neu organisiert werden — und das kostet Zeit.

Für early adopters bestand zwar grundsätzlich die Möglichkeit, einfach das alte EPEL-7-Repository einzurichten; wirklich praktikabel war das aber nicht, weil sich viele Pakete aufgrund unerfüllbarer Paketabhängigkeiten nicht installieren ließen. (Besonders betroffen waren Python-Pakete.)

EPEL-8-Rollout in mehreren Phasen

Mitte August wurde nun EPEL 8 offiziell freigegeben. Übertriebene Freude ist aber noch nicht angebracht. Wegen der bereits skizzierten Umstrukturierung ist das Paketangebot in EPEL 8 noch viel kleiner als in EPEL 7. Warum das so ist, hat der EPEL-Entwickler Stephen Smoogen bereits im Juli 2019 in seinem Blog skizziert. Demnach wird das EPEL-8-Rollout in mehreren Schritten erfolgen:

• EPEL 8.0: Das aktuelle Release ist nur der erste Schritt, den Stephen Smoogen »EPEL 8.0« nennt. Es nutzt die Modularisierungsfunktionen von RHEL 8 noch nicht.
• EPEL 8.1 wird ca. im November 2019 erwartet und wird möglicherweise parallel zu RHEL 8.1 freigegeben. Es soll RHEL-Module teilweise unterstützen.
• Erst EPEL 8.2 (Zeitraum der Fertigstellung noch unklar) soll vollständig mit dem neuen Modulkonzept von RHEL 8 kompatibel sein.

EPEL 8.0 in der Praxis

Das Einrichten der EPEL-Paketquelle ist unverändert einfach:

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Hinter den Kulissen werden damit die Repository-Dateien /etc/yum.repos.d/epel*.repo eingerichtet. Anschließend können Sie sich mit yum einen Überblick über die aktuell verfügbaren Pakete verschaffen:

yum repository-packages epel list

Verfügbare Pakete
BackupPC.x86_64             4.3.1-2.el8     epel
BackupPC-XS.x86_64          0.59-3.el8      epel
CGSI-gSOAP.x86_64           1.3.11-7.el8    epel
CGSI-gSOAP-devel.x86_64     1.3.11-7.el8    epel
Field3D.x86_64              1.7.2-16.el8    epel
Field3D-devel.x86_64        1.7.2-16.el8    epel
Lmod.x86_64                 8.1.10-2.el8    epel
...

yum repository-packages epel list | wc -l

971

(Nur zum Vergleich: Unter CentOS 7 mit der EPEL-7-Paketquelle kommt yum repository-packages epel list | wc -l auf über 13.000 Pakete!)

Ob Sie mit EPEL 8 im aktuellen Zustand glücklich werden, hängt naturgemäß stark davon ab, welche Pakete Sie brauchen. Ich installiere üblicherweise als Erstes das Paket joe. Es enthält neben anderen Editoren den winzigen Emacs-Klon jmacs, mit dem ich bevorzugt Konfigurationsdateien verändere. (jmacs ist in seinen Grundkommandos zum Emacs kompatibel. Seine größten Vorteile sind ein blitzartiger Start und ein sparsamer Umgang mit Ressourcen.) Um es kurz zu machen: joe steht aktuell nicht zur Verfügung, eben sowenig wie jove (noch ein Emacs-Klon).

Auf meiner EPEL-Hitliste ganz oben steht des Weiteren fail2ban. Dieses Programm blockiert IP-Adressen, wenn von dort wiederholt fehlerhafte Login-Versuche erfolgen. fail2ban ist damit ein wichtiger Schutz vor Angreifern, die (SSH-)Passwörter durch systematisches Probieren erraten möchten. fail2ban ist erfreulicherweise bereits in EPEL 8.0 enthalten.

Dritter Testkandidat war certbot, um Let’s-Encrypt-Zertifikate einzurichten. Leider Fehlanzeige in EPEL 8.0 :-(

Quellen

• https://fedoraproject.org/wiki/EPEL
• https://smoogespace.blogspot.com/2019/07/epel-8-production-layout.html
• https://smoogespace.blogspot.com/2019/08/announcing-epel-80-official-release.html
• https://lwn.net/Articles/796202/
• https://linuxconfig.org/redhat-8-epel-install-guide
• https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 (nicht aktuell)

OMV lässt sich mittels Extensions aus den OMV-Extras automatisch herunterfahren und per RTC-Wake wieder aufwecken. Durch umfangreiche Einstellungsmöglichkeiten kann man das NAS in Zeiten der Nicht-Nutzung schlafen schicken und Energie sparen.

Im Gegensatz zu vielen anderen NAS-Betriebssystemen bietet OMV einige Extensions zum Energiesparen. Bei den heutigen Energiekosten auf dem deutschen Markt und unter Berücksichtigung der aktuellen Klimadebatte sicherlich ein wichtiges Alleinstellungsmerkmal.

Methode 1: Autoshutdown

Vor einigen Jahren war das Autoshutdown-Plugin hier schon mal Thema (siehe: WOL und Autoshutdown - Energie sparen mit OMV). Damals war es das Ziel das NAS komplett herunterzufahren. Das ist mit meiner aktuellen Hardware nicht mehr notwendig, aber man kann das Plugin auch sehr gut so konfigurieren, dass das NAS lediglich in den Suspend-Modus geht.

Die Oberfläche hat sch seitdem kaum geändert. Die gewählten Einstellungen sehen nun wie folgt aus:

In einem definierten Zeitraum (10-20 Uhr) ist das NAS immer in Betrieb und fungiert als Sicherungsziel (siehe: openmediavault 5 mit Time Machine Unterstützung. Ab 20 Uhr kann das NAS sich schlafen legen, sofern mein Arbeits-Mac ebenfalls nicht mehr in Betrieb ist. Daher die Überprüfung ob die IP 55 noch aktiv ist.

Alle anderen Einstellungen können daher für das gewählte Szenario deaktiviert werden.

Methode: 2: Geplante Aufgaben

Sofern keine Überprüfung auf einen aktiven Rechner notwendig ist kann man das Problem auch einfach mit einer geplanten Aufgabe im Menüpunkt Energieverwaltung lösen.

Hier kann man das NAS zu einem definierten Zeitpunkt Herunterfahren, neu starten oder in den Bereitschaftsmodus versetzen.

Starten

Um das NAS morgens wieder zu starten benötigt es eine weitere Extension openmediavault-wol. Hier kann man via Rtcwake einen Startzeitpunkt festlegen. Dazu wählt man die Option "No - Don't suspend. Sets RTC wakeup time only" und legt eine Uhrzeit fest. Das ist nicht sonderlich selbsterklärend aber das reine Wakealarm-Plugin scheint (noch) nicht auf OMV 5 portiert zu sein.

Wenn das nicht funktioniert (das Plugin scheint ein wenig wackelig zu sein) kann man auch auf der Konsole rtcwake entsprechend konfigurieren. Das ist allerdings nicht ganz trivial.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Das kommende OMV 5 basiert auf Debian 10 und bringt daher eine für Time Machine geeignete Samba-Version mit. Darüber hinaus haben die Entwickler dies aber auch in der Oberfläche berücksichtigt. Es ist daher sehr einfach ein OMV-NAS zum Sicherungsziel für einen Mac zu machen.

Früher war dies nur mit einer AFP Freigabe möglich (siehe: Time Machine auf openmediavault NAS sichern), was Apple als veraltet deklariert hat und zunehmend abschaltet. Vermutlich ist mit dem kommenden macOS "Catalina" endgültig Schluss.

Dazu legt man unter Dateisysteme eine Partition für Time Machine an. Eine eigene Partition ist sinnvoll weil Time Machine erst löscht wenn das Sicherungsziel voll läuft. Dadurch kann man auf einem NAS schnell Platzprobleme bekommen.

Anschließend legt man noch einen SMB-Benutzer an. Im vorliegenden Beispiel einfach als smbshare bezeichnet.

Im weiteren aktiviert man im Menüpunkt SMB/CIFS Samba und legt eine Freigabe an. Die Standardwerte müssen nicht modifiziert werden, lediglich Time Machine support aktiviert werden. Dadurch werden die entsprechenden Optionen automatisch gesetzt.

In der smb.conf sieht das dann wie folgt aus:

[TimeMachine]
path = /srv/dev-disk-by-label-TMB/TimeMachine/
guest ok = no
guest only = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
fruit:encoding = private
fruit:locking = none
fruit:metadata = netatalk
fruit:resource = file
fruit:time machine = yes
vfs objects = catia fruit streams_xattr
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = yes
valid users =
invalid users =
read list =
write list =

Zu guter letzt muss im Menüpunkt Freigegebener Ordner noch die notwendigen ACL für den Zugriff gesetzt werden. Hierzu räumt man einfach dem smbshare genannten Benutzer Lese- und Schreibrechte auf den Freigabeordner ein.

Die nun erstellte und konfigurierte Freigabe findet macOS automatisch und kann in den Systemeinstellungen unter Time Machine als Sicherungsziel ausgewählt werden. Sofern macOS per FileVault verschlüsselt sein sollte (siehe: macOS mit FileVault verschlüsseln) sollte die Sicherung ebenfalls verschlüsselt werden. Das System warnt in diesem Fall allerdings auch explizit vor einer unverschlüsselten Sicherung. Technisch legt macOS in der SMB-Freigabe ein Sparsebundle ab, das sich in jedes macOS-System einbinden und auch manuell durchsuchen lässt.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Manchen Leuten ist scheinbar ab und zu sehr langweilig. Dieses Wochenende habe ich doch tatsächlich eine E-Mail mit Hinweisen auf den einen oder anderen Fehler in meinen Artikeln erhalten. Im Grunde waren es nur Rechtschreibfehler.

In der E-Mail wurde ich auf gefragt ob ich für solche Sachen nicht ein öffentlicht zugängliches Repository anbieten kann. Kann ich. Es ist unter https://github.com/Fryboyter/Hugo erreichbar.

Aber würde ich selbst einen Artikel lesen und dann das Repository aufrufen und die Datei suchen wen ich einen Fehler finden würde? Eher nicht. Daher habe ich nun einen Link unterhalb der jeweilige Artikelüberschrift eingebaut, der direkt auf die betreffende Datei bei Github verweist.

Als erstes habe ich hierfür in der Konfigurationsdatei von Hugo (config.toml) den Bereich [params] um einen Verweis auf das Repository eingetragen.

[params]
ghrepo = "https://github.com/Fryboyter/Hugo/"

Als nächstes habe ich das verwendete Theme (single.html und list.html) von fryboter.de wie folgt erweitert.

| <a href="{{.Site.Params.ghrepo}}edit/master/content/{{.File.Path}}" >Bei Github bearbeiten</a>

Hiermit wird das in der Datei conifg.toml hinterlegte Verweis auf das Respository genutzt. Dieser wird dann einfachum edit/master/content/ erweitert, da sich dieser Teil nicht ändert. Ganz am Schluss wird mit {{.File.Path}} auf die betreffende Datei verlinkt.

Im Grunde ist das mal wieder ziemlich simpel. Huge gefällt mir immer mehr.

DNS over HTTPS, kurz: DoH, soll die Sicherheit und Privatsphäre der Nutzer verbessern. Nach einer langen Testphase wird Mozilla ab Ende September damit beginnen, DoH für erste Nutzer von Firefox standardmäßig auszurollen.

Was ist DNS over HTTPS?

Wikipedia beschreibt DNS over HTTPS mit den folgenden Worten:

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird. Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.

Wikipedia

DNS over HTTPS in Firefox

Bereits 2017 begann Mozilla die Arbeiten an DNS over HTTPS, seit Juni 2018 führt Mozilla diverse DoH-Experimente mit Firefox-Nutzern durch. Nun steht Mozilla kurz vor der Ausrollung.

Ab Ende September soll DoH für Firefox-Nutzer in den USA ausgerollt werden. Zunächst aber nur für einen kleinen Teil der Firefox-Nutzer, ehe man DoH flächendeckend ausrollen wird. Wann mit einer Ausrollung in Europa zu rechnen ist, ist zu diesem Zeitpunkt noch nicht bekannt.

Mozilla wird standardmäßig zunächst auf 1.1.1.1 von Cloudflare als DNS-Resolver setzen. Der Nutzer kann in den Firefox-Einstellungen aber auch jeden anderen DNS-Anbieter eintragen oder das Feature komplett deaktivieren. Die entsprechende Oberfläche ist bereits in Firefox integriert.

Sobald DoH in Firefox standardmäßig aktiviert wird, wird der Nutzer darüber informiert und erhält eine Möglichkeit, DoH abzuschalten. Keine Aktivierung von DoH findet statt, wenn der Nutzer eine Opt-in-Kindersicherung nutzt oder eine Unternehmenskonfiguration von Firefox entdeckt wird. Letzteres wird dadurch erkannt, dass die Option security.enterprise_roots.enabled auf true gesetzt ist oder durch Vorhandensein einer Enterprise Policy. Bei DNS-Problemen fällt Firefox automatisch auf die DNS-Konfiguration des Betriebssystems zurück.

Der Beitrag DNS over HTTPS (DoH) ab Ende September für erste Firefox-Nutzer erschien zuerst auf soeren-hentzschel.at.

Purism informierte vor kurzem die Interessen für das Librem 5 über die weiteren Pläne. Den bereits mehrfach verschobenen Launch in diesem Jahr schafft man nicht mehr. Vorab gibt es nur eine Kleinserie, die weder bei Hardware, noch bei Software final sein soll.

Ich polarisiere in manchen meiner Blogartikel und bekomme dementsprechend auch gerne - nennen wir es mal - Post in meinen E-Mail Eingang. Doch meine Artikel zu SailfishOS / Jolla (siehe: Jolla / Sailfish OS - Zu enge Staatsverbindungen?) und Purism (siehe: Purism Librem 5 - Bestenfalls eine Experimentalstudie) scheinen bei der Zielgruppe die Knöpfe zum Abschalten von Anstand und Moral getroffen zu haben. Ich schreibe das sonst nicht in dieser Deutlichkeit, aber eigentlich ist so eine Community ein Grund nicht mehr über diese Projekte zu berichten. Wenn man sich derart in einer Filterblase bewegt, dass man Fakten zu Finanzierung (Jolla / Sailfish) oder zum Zustand des Projekts nicht mehr verkraftet ohne ausfallend zu werden, hat man echt ein Problem.

Den heutigen Blogartikel kann ich mir aber nicht verkneifen. Bei der Veröffentlichungen der geplanten Spezifikationen des Librem 5 schrieb ich ja bereits:

Es bleibt zu hoffen, dass Purism in der aktuellen Version lediglich eine Experimentalstudie sieht, wodurch man Feedback einer breiteren Öffentlichkeit erhalten möchte um schnell mit einer weiteren Version nachzulegen.

Das haben zwar einige Fans nicht verkraftet aber Purism sieht das scheinbar selbst so. Weder die Hardware, noch das Gehäuse oder gar die Software werden dieses Jahr auch nur annähernd final sein. Erst im 2. Quartal 2020 (Stand jetzt...) soll ein Gehäuse und eine Software erscheinen, die einen längeren Support bekommt.

Meiner Meinung nach hat sich Purism mit dem Projekt vollkommen verhoben. Ähnlich wie Jolla seinerzeit mit dem Tablet. Der Anspruch eine freie Hardware zu entwickeln und parallel dazu Linux bzw. GNOME tauglich für den Smartphone-Alltag zu bekommen war von Anfang an sehr ambitioniert. Eventuell hätte hier eine stärkere Kooperation mit bestehenden Community-Projekten wie UBports oder Plasma Touch geholfen - man weiß es nicht.

Fakt ist, dass die Hardware mit fortschreitendem zeitlichen Verlauf nicht gerade an Aktualität gewinnt.

Ich halte das Librem 5 in seiner jetzigen Form für gescheitert. Nichtsdestotrotz kann aus dem Projekt noch interessantes hervorgehen. Andere ambitionierte Projekte wie coreboot haben schließlich auch ewig gebraucht um überhaupt nur annähernd relevant für den Endanwender zu werden.

Bilder:
Einleitungs- und Beitragsbild von 3dman_eu via pixabay 

Im Podcast bei netzpolitik ging es um den Einsatz von freier Software in der Verwaltung (siehe: netzpolitik.org Podcast zu freier Software). Es wurde zu Recht auf Schwierigkeiten bei den Ausschreibungen und Anforderungen hingewiesen. Auf wichtige Stärken der gegenwärtigen - überwiegend, aber nicht ausschließlich proprietären - Lizenzmodelle wurde nicht eingegangen.

Ursprünglich wollte ich diesen Kommentar bereits direkt in den Artikel schreiben, aber das hätte den Podcast mit zu viel ungerechtfertigter Kritik überzogen und zu weit weg vom Thema geführt.

Bezüglich der Hemmnisse beim Einsatz von freier Software in der Verwaltung gibt es oft zwei Argumente. Erstens seien die Ausschreibungen nicht auf OSS zugeschnitten, zweitens müssten sich doch nur mal genug staatliche Stellen zusammen tun um gemeinsam etwas voran zu bringen. Bei letzterem wird immer gerne auf Russland mit seinen Ambitionen in Richtung freier Software verwiesen.

Dahinter steht meiner Meinung nach ein mangelndes Verständnis davon wie ein demokratischer Staat wie Deutschland funktioniert und eine wenig begrüßenswerte Sympathie für autokratische Systeme. Deutschland ist weder ein Zentralstaat, noch eine Kommandowirtschaft oder gar ein autokratisches System wo ein Präsidialamt einfach mal einen Systemwechsel anordnet und die Untergeben wenigstens so tun, als ob sie es umsetzen. Deutschland ist ein föderales System in dem viele Glieder eine sehr große Unabhängigkeit genießen. Dies gilt natürlich auch für die IT Strukturen.

Das bedeutet ganz konkret, dass nicht nur Bund und Länder als vergleichsweise große Verwaltungseinheiten ihre eigenen Strukturen haben, sondern viele nachgeordnete Behörden und Einrichtungen ebenfalls viele Freiheiten genießen. Innerhalb dieser Einrichtungen gibt es dann teilweise noch unabhängige Substrukturen mit eigenen Anforderungen und Beschaffungsprozessen. All das fällt unter die Oberkategorie Öffentlicher Dienst bzw. Verwaltung.

Das kann man jetzt als Grundübel bezeichnen oder auch nicht. Im Grunde genommen fährt Deutschland damit sehr gut, weil zentralistische Strukturen sehr oft an den Anforderungen vorbei entscheiden. In jedem Fall sind dies die Rahmenbedingungen mit denen man in Deutschland umgehen muss.

Das überwiegend proprietäre System harmoniert da nahezu perfekt. Nun kann man hier die Henne/Ei Frage stellen. Funktioniert das System perfekt weil sich der Staat darauf eingestellt hat oder haben die Entwicklungsfirmen einfach ein passendes Modell für staatliche Stellen geschaffen. Gleichwohl klappt es relativ zuverlässig. Lizenzen und Supportverträge kosten zwar viel Geld, lassen sich aber in die Jahresbudgets einbeziehen. Gleichzeitig trägt man nicht die wirtschaftliche Verantwortung für das Gesamtprojekt und die zukünftige Entwicklung, sondern diese liegt beim Lizenzgeber. Funktioniert etwas nicht wechselt man schlimmstenfalls den Anbieter und bezahlt ein Migrationsprojekt mit begrenztem Umfang. Genau aus diesem Grund sind auch solche Anbieter von freier Software so erfolgreich, die sich in dieses System eingefügt haben. SUSE oder Red Hat bieten beispielsweise ein feststehendes Produkt (z. B. Linux Server) mit festen Supportverträgen, die sich über mehrere Jahre erstrecken. Die Verwaltung greift hier bereits sehr gerne auf Open Source Software zurück. Es ist also nicht so, dass der Staat FOSS gänzlich meidet, das Modell funktioniert sehr gut bei bereits bestehenden Produkten.

Anders sieht das bei den Leerstellen aus. Bei der Entwicklung für diese weißen Flecken scheitert das von Enthusiasten vorgetragene Entwicklungsmodell für freie Software. Hier wird immer pauschal gesagt, man müsste es nur entwickeln, Geld wäre schließlich ohne Lizenzgebühren genug da. Erstens ist das eine schwer zu beziffernde Rechnung, denn Lizenzgebühren über viele Jahre gegen Entwicklungskosten lassen sich nur schwer kalkulieren. Wohl stehen mehr Kontrolle und ggf. auch mehr Sicherheit auf der Positiv-Liste. Dafür könnte man theoretisch die eventuellen Mehrkosten in Kauf nehmen.

Ganz konkret in der deutschen Wirklichkeit bedeutet das aber, als Entscheidungsträger in einer Institution oder Abteilung müsste man sich dann aber erstmal deutschlandweit (oder gar europaweit) umsehen ob andere Einrichtungen etwas ähnliches brauchen und mich mit diesen vernetzen. Dann müsste man von den lokalen Anforderungen abstrahieren, etwas allgemeingültiges entwickeln lassen und dann für den lokalen Gebrauch wieder anpassen. Das ganze unter Zeitdruck, da Anforderungen selten viele Jahre im Vorfeld klar werden.

Keine Verwaltung kann dies aus den bestehenden Strukturen her leisten. Der berühmte Wasserkopf betrifft ganz sicher nicht die IT-Mitarbeiterzahlen. Dazu müsste also externe Expertise eingekauft (höre ich Beraterskandal?) werden oder die Institutionen müssten zentrale Entwicklungszentren gründen. Hier wäre wieder die Frage wie dies aus den sehr starren Finanzierungsmodellen bezahlt werden soll, da das Investitionen mit langer Laufzeit sind. Diese aber immerhin theoretisch möglichen neuen Entwicklungszentren wären naturgemäß im ÖD angesiedelt und müssten auf dem angespannten Arbeitsmarkt um Fachkräfte konkurrieren (siehe HIS im Hochschulsektor). Es ist kein sonderlicher Pessimismus von Nöten um jedes dieser Projekte zu einem kleinen BER werden zu lassen.

Das kann und wird niemals funktionieren. Da wo bestehende Open Source Produkte konkurrenzfähig sind finden sie bereits Verwendung. Es ist ja nicht so, dass momentan generalstabsmäßig Open Source Software gemieden wird. Freie Software ist auf vielen Desktoparbeitsplätzen allgegenwärtig, im Server-Bereich sowieso. In der Cloud hat Nextcloud gerade einen richtigen Clou landen können. All diese Projekte bestanden aber schon bevor staatliche Stelle sich für eine Nutzung entschieden. Neuentwicklungen in einem größeren Maßstab aus den Institutionen heraus - mit dem Ziel neue Aufgaben zu lösen oder bestehende Plattformen zu ersetzen - werden nicht funktionieren.

Nichtsdestotrotz ist es immer wieder schön, wenn einzelne Institutionen oder ganze Bundesländer wie Schleswig-Holstein sich dem Thema annehmen und zumindest Absichtserklärungen formulieren. Vielleicht entsteht daraus etwas mit Perspektive.

Bilder:
Einleitungs- und Beitragsbild von qimono via pixabay

Go ist eine Open-Source Programmiersprache, welche von Google 2009 entwickelt wurde. Die Sprache ist bei vielen Anwendungen beliebt, darunter Docker oder Kubernetes. 

Nun ist eine neue Version 1.13 erschienen, welche neben Sicherheitsfeatures in den Standardeinstellungen auf TLS 1.3 setzt.
Module welche von den Go Servern geladen werden, sind nun durch eine Checksummenprüfung abgesichert.

Weitere Neuerungen verrät das Changelog

Doch wie kommt Go überhaupt auf das eigene System?

Installation von Golang auf Ubuntu

Als erstes möchte ich die manuelle Installation betrachten.

Auf der Downloadseite muss zunächst nach der offiziellen Version gesucht werden.

wget https://dl.google.com/go/go1.13.linux-amd64.tar.gz

Nach dem Download sollte der Hashwert überprüft werden.

sha256sum go1.13.linux-amd64.tar.gz

    68a2297eb099d1a76097905a2ce334e3155004ec08cdea85f24527be3c48e856  go1.13.linux-amd64.tar.gz

Danach folgt das Entpacken, wobei ihr beim Pfad natürlich auch einen anderen verwenden könnt.

sudo tar -C /usr/local -xzf go1.13.linux-amd64.tar.gz

Nun den PATH anpassen und folgende Zeile unten anfügen.

sudo nano $HOME/.profile

    export PATH=$PATH:/usr/local/go/bin

Die neue PATH Variablen laden.

source ~/.profile

Nun kann der finale Test erfolgen, wenn alles klappt solltet ihr folgendes Ergebnis sehen.

go

Go is a tool for managing Go source code.

Usage:

        go command [arguments]

The commands are:

        build       compile packages and dependencies
        clean       remove object files and cached files
        doc         show documentation for package or symbol
        env         print Go environment information
        bug         start a bug report
        fix         update packages to use new APIs
        fmt         gofmt (reformat) package sources
        generate    generate Go files by processing source
        get         download and install packages and dependencies
        install     compile and install packages and dependencies
        list        list packages
        run         compile and run Go program
        test        test packages
        tool        run specified go tool
        version     print Go version
        vet         report likely mistakes in packages

Use "go help [command]" for more information about a command.

Installation von Go via apt auf Ubuntu

Golang kann unter Ubuntu ebenfalls über den Paketmanager installiert werden. Dazu muss zunächst ein extra Repository hinzugefügt werden.

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt update
sudo apt install golang-go

Jetzt könnt ihr euch mit Go austoben.

Im Netz findet ihr jede Menge Beispiele was damit möglich ist.
Zum Beispiel hier oder hier.

Ein eigenes Programm ist schnell geschrieben, dazu einfach folgende Schritte ausführen.

Ein neues Verzeichnis anlegen und eine erste Datei anlegen.

mkdir -p /home/user/hello

nano /home/user/hello/helloworld.go


        package main

        import "fmt"

             func main() {
                  fmt.Printf("Hello Go World \n")
             }

Datei builden und ausführen.

cd /home/user/hello

go build

./hello

    Hello Go World

Praktischerweise gibt es eine Online Spielwiese, die zum Probieren einlädt.

Es muss somit zunächst nicht zwingend auf der Kommandozeile gearbeitet werden.

PS. Natürlich kann Golang auch über die vorhandenen Ubuntu Pakete mit sudo apt install golang installiert werden, allerdings erhaltet ihr hier nicht die aktuellste Version.

Im Podcast NPP 183 stellen Matthias Kirschner und Katharina Nocun die Initiative Public Money, Public Code vor. Daneben geht es sehr viel um freie Software allgemein. Es lohnt sich in den Podcasts rein zu hören.

Inhaltlich werden folgende Aspekte behandelt:

• Die Bedeutung der vier Freiheiten freier Software für die Gesellschaft
• Prinzip "Freie Software"
• Unsicherheit der gegenwärtigen proprietären (Staats-)Infrastruktur
• Vorstellung der Initiative PMPC und ihren neuen Ansatz
• Bedeutung der stetig wachsenden IT in der Staatsverwaltung und ihre Auswirkungen auf demokratische Strukturen ("Wer kontrolliert die Geräte?")
• Lizenzmodelle unfreier Software mit stark restriktiven Bestandteilen
• Abkehr von Leuchtturmmodellen (LiMux)
• Wirtschaftsmodelle bei freier Software
• Probleme bei der Berücksichtigung in staatlichen Ausschreibungen.
• Eigentum und Urheberrecht

Kirschner und Nocun vertreten die Anliegen sehr eloquent. Einige Beispiele zur Funktionsweise von freier Software sind sehr schön und verdeutlichten die Prinzipien. Schade ist, dass der Gastgeber wenig kritisch nachfragt. Sowohl Kirschner, als auch Nocun äußern ab und an Allgemeinplätze, bei denen kritische Nachfragen angebracht gewesen wären.

Sehr kritisch fand ich im späteren Verlauf des Podcasts die Inhalte zum Urheberrecht, sowie zu kapitalistischen Wirtschaftsmodellen. Es gibt eigentlich keinen direkten Zusammenhang zwischen freien Lizenzen und dem geistigen Urheberrecht. Sowohl die GPL, als auch die Creative Commons Lizenzen bauen letztlich auf das Urheberrecht auf. Mit der zumindest unterschwellig geäußerten Forderung nach einer Abschaffung des Urheberrechts begeben sich die drei Gesprächspartner auf dünnes Eis. Das ist bedauerlich, weil die FSFE ansonsten versucht weniger radikal aufzutreten und dadurch größere Zustimmung zu erreichen. Hier sieht man vermutlich auch die Auswirkungen der Urheberrechts-Kampagne und ihre Auswirkungen auf andere Bereiche.

Bilder:
Einleitungs- und Beitragsbild von Tumisu via pixabay

Mich fragen ja häufiger mal Leute, was sich so in den letzten Git-Versionen getan hat. Das frage ich mich natürlich auch immer mal wieder und lese jedes Mal die Release-Notes und finde in der Regel nichts spannendes was mich als Endnutzer interessiert. Ja, Verbesserungen der Performance und Fehlerkorrekturen sind gut und wichtig – als „normaler“ Nutzer merkt man davon allerdings recht wenig.

Interessant ist allerdings die Neuerung in Git Version 2.23, die Mitte August veröffentlicht wurde. Es gibt nun zwei experimentelle neue Kommandos: git switch und git restore. Beide koexistieren zu dem bisherigen Kommando git checkout was den gängigen Git Nutzer bekannt sein sollte. Wie zuvor erwähnt, handelt es sich um „experimentelle“ Kommandos, das heißt, die Funktion wird zwar bleiben, die Parameter können sich allerdings noch weiter verändern und sind möglicherweise noch fehlerbehaftet.

In diesem Blogpost begutachte ich die beiden neuen Befehle und zeige die Unterschiede zu dem bisherigen Kommando auf.

Status Quo

Bevor wir uns die neuen Befehle anschauen lohnt es sich noch einmal aufzufrischen, wie der Status Quo ist und warum die neuen Befehle praktisch und sinnvoll sind.

Der Subbefehl checkout wird vielfältig in Git eingesetzt. Der wohl gängigste Einsatz ist der Wechsel von einem auf den anderen Branch:

$ git checkout master

Dieser Befehl wechselt vom aktuellen Branch auf den Branch master. Es ist auch möglich einen neuen Branch zu erstellen und direkt darauf zu wechseln:

$ git checkout -b feature/1337

Dieser Befehl nimmt den aktuellen Branch, auf dem man sich gerade befindet, und legt den Branch namens feature/1337 an und wechselt direkt da hin. Möchte man einen anderen Branch als Basis nehmen, tippt man den Namen dahinter als weiteren Parameter ein. Alternativ lässt sich mit git branch feature/1337 ebenfalls ein Branch anlegen, auf dem man nicht automatisch hin wechselt.

Checkout als Befehl zum Wechseln und Erzeugen von Branches sollte für die meisten geübten Git-Nutzern bekannt und gängig sein. Genau so lege ich immer meine Branches auf der Kommandozeile bisher an.

Der andere Modus von Checkout ist das Auschecken von Dateien aus anderen Branches, Revisionen bzw. dem Verwerfen von Änderungen aus dem Staging-Bereich und der Arbeitskopie. Dies wird durch die Nutzung von doppelten Minuszeichen -- ermöglicht.

In der bereits versionierten Datei index.html sind Änderungen vorhanden, die nicht im Staging-Bereich enthalten sind. Um die Änderungen zu verwerfen, kann folgender Befehl verwendet werden:

$ git checkout -- index.html

Somit sind die Änderungen in der Arbeitskopie verworfen und können nicht wiederhergestellt werden. Der Inhalt der Datei index.html wurde auf den Stand von HEAD – also dem aktuell ausgecheckten Commit – zurückgesetzt. Der Befehl kann auch verwendet werden, um einzelne Dateien aus einem anderen Branch auszuchecken und im aktuellen Projekt abzulegen.

Dieser Befehl würde dann wie folgt lauten:

$ git checkout feature/1337 -- index.html

Die Datei index.html aus dem Branch feature/1337 wird dann von Git im aktuellen Projektverzeichnis abgelegt. Mit einem git status wird dann auch aufgelistet, dass sich die Datei verändert hat. Dies natürlich nur unter der Voraussetzung, dass sich die Datei in beiden Branches unterscheiden. Statt eines Branches können auch andere Revisionen angegeben werden. Denn nicht vergessen: ein Branch sind letztendlich auch nur Zeiger auf einen bestimmten Commit, der stetig aktualisiert wird.

Status Futurus

Mit den neuen Kommandos switch und restore wird alles besser! Na gut, zumindest wird deutlich einfacher zu verstehen, was diese tun. Mit beiden Befehlen werden alte Zöpfe nach und nach abgeschnitten und die Befehle klarer und besser zu nutzen.

Git-Nutzer wissen vermutlich, dass viele Befehle nicht so offensichtlich sind und es nicht unbedingt auf Anhieb nachvollziehbar ist, was welcher Befehl tut. Das gute Beispiel ist eben git checkout womit man sowohl Branches wechseln kann, als auch Dateien aus anderen Revisionen holen kann.

git switch

Für das Wechseln von Branches gibt es jetzt den Befehl git switch. Mit diesem lassen sich ebenfalls neue Branches anlegen. Das Wechseln von einem Branch funktioniert wie äquivalent:

$ git switch feature/1337

Für das Erstellen eines neuen Branches existiert der Parameter -c:

$ git switch -c feature/1337

Dies ist äquivalent zu git checkout -b feature/1337. Interessant ist auch der Parameter -C, der mit einem großem C geschrieben wird. Dies ist effektiv ein forciertes Anlegen eines neuen Branches, da der Zielbranch hart überschrieben wird. Hier gilt es also aufzupassen.

git restore

Der zweite Befehl ist git restore. Wie der Name schon verrät, lassen sich Dateien wiederherstellen.

Die erste Nutzungsmöglichkeit ist bereits, wenn man eine neue Datei anlegt und diese zum Staging-Bereich hinzufügt.

$ echo "Hallo" > hallo.txt
$ git add hallo.txt
$ git status
Auf Branch master
Zum Commit vorgemerkte Änderungen:
  (benutzen Sie "git restore --staged <Datei>..." zum Entfernen aus der Staging-Area)
        neue Datei:     hallo.txt

Git zeigt schon ab der neuen Version 2.23 an, dass man git restore verwenden soll und kann. In diesem Fall lässt sich mit dem Befehl die Datei aus dem Staging-Bereich wieder herausnehmen. Restore lässt sich natürlich auch dafür verwenden eine Datei aus einem anderen Commit zu holen. Als zusätzlicher Parameter wird --source benötigt:

$ git restore --source feature/1337 index.html

Dies holt die Datei in das Arbeitsverzeichnis rein. Mit dem zusätzlichen Parameter --staged wird die Änderung hingegen direkt in den Staging-Bereich geschoben.

Sowohl git restore als auch git switch besitzen ein paar mehr Parameter. Meiner Meinung nach sind beide sinnvolle Ergänzungen und machen die Nutzung von Git deutlich angenehmer. Schwierig ist für den geübten Git-Nutzer nur sich die neuen Befehle einzuprägen. Bei mir sind die bisherigen Befehle schon länger in Fleisch und Blut übergangen, sodass ich jetzt erstmal umlernen muss.

Mozilla hat Firefox 69 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

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 69 hat Mozilla wieder zahlreiche Sicherheitslücken geschlossen, worunter auch einige sind, welche von Mozilla als besonders schwerwiegend eingestuft werden. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 69 daher für alle Nutzer dringend empfohlen.

Adobe Flash Player kann nicht länger dauerhaft aktiviert werden

Der Adobe Flash Player ist das letzte verbliebene NPAPI-Plugin, welches von Firefox noch unterstützt wird, nachdem andere NPAPI-Plugins wie Oracle Java oder Microsoft Silverlight bereits seit Firefox 52 nicht mehr unterstützt werden. NPAPI-Plugins waren für viele Jahre ein wichtiger Teil der Webplattform. In den letzten Jahren hat deren Bedeutung aber immer stärker abgenommen. Praktisch alles, was früher ausschließlich mittels NPAPI-Plugin umsetzbar war, wird heute, dank entsprechender Weiterentwicklung von Webstandards, nativ durch die Browser unterstützt. Heute gelten NPAPI-Plugins vor allem aus einer Sicherheits-Perspektive als problematisch.

Bereits im Juli 2017 hatte Adobe angekündigt, den Adobe Flash Player mit Ende 2020 zu beerdigen. Zeitgleich hatte Mozilla angekündigt, die Unterstützung für den Adobe Flash Player in Firefox Anfang 2020 für Privatanwender sowie Ende 2020 für Enterprise-Nutzer einzustellen.

Entsprechend der Roadmap hat Mozilla die Option aus Firefox 69 entfernt, den Adobe Flash Player dauerhaft aktiviert zu haben. Damit bleiben nur noch die Optionen, auf jeder Website mit Flash-Inhalten nachzufragen, ob der Adobe Flash Player aktiviert werden soll, oder diesen komplett deaktiviert zu lassen.

Windows 10: HmacSecret für Windows Hello

Firefox unterstützt bereits seit Version 66 eine passwortlose Authentifizierung via Windows Hello. Das Mai 2019-Update für Windows 10 vorausgesetzt unterstützt Firefox ab Version 69 auch die HmacSecret-Erweiterung, welche beispielsweise für Azure Active Directory benötigt wird und auch von Microsoft Edge unterstützt wird. Gerade im Unternehmensumfeld kann dies eine wichtige Anforderung sein, darum hat Mozilla diese Neuerung auch in Firefox ESR 68.1 implementiert.

Verbesserungen der Privatsphäre

Tracking-Cookies standardmäßig blockiert

Mit Firefox 67.0.1 hat Mozilla die Standard-Konfiguration für neue Nutzer geändert, um Drittanbieter-Cookies von mehr als 1.000 Tracking-Domains standardmäßig zu blockieren. Mit Firefox 69 hat Mozilla das Blockieren der Tracking-Cookies auch für bestehende Nutzer standardmäßig aktiviert.

Cryptomining-Blocker standardmäßig aktiviert

In Firefox 67 hat Mozilla seinen integrierten Content-Blocker optional um die Möglichkeit erweitert, Cryptomining– sowie Fingerprinting-Scripts zu blockieren. Ab Firefox 68 sind beide neue Schutz-Optionen Teil der strengen Konfiguration und nicht mehr nur über die Option „Benutzerdefiniert“ auswählbar. Der Cryptomining-Schutz ist ab Firefox 69 sogar Teil der Standard-Konfiguration und damit für alle Nutzer aktiv – sofern der Schutz vom Nutzer nicht ausdrücklich abgeschaltet wird.

Architektur-Information aus User-Agent entfernt

Mit dem bevorstehenden Ende des Adobe Flash Players besteht nicht länger eine Notwendigkeit, speziell Nutzer einer 32-Bit-Version von Firefox auf einem 64-Bit-Betriebssystem zu erkennen. Ab sofort unterscheidet Firefox nur noch einfach zwischen 32-Bit und 64-Bit-Version und reduziert damit den digitalen Fingerabdruck.

Geschwindigkeits-Verbesserungen

Retained Display Lists für Firefox-Oberfläche

Das Display List Building bezeichnet den Prozess, in welchem die Elemente wie Ränder, Hintergründe usw. gesammelt werden, welche auf dem Bildschirm angezeigt werden sollen und dann gemäß der CSS Painting-Regeln sortiert werden. Bislang musste die sogenannte Display List jedes Mal neu berechnet werden, wenn eine Änderung der Anzeige erfolgte. Dieser Vorgang kann langsam sein, insbesondere mit den immer komplexer werdenden Webseiten sowie den immer größeren Bildschirmen, welche von den Nutzern eingesetzt werden. Retained Display Lists ermöglichen es, dass nur die Teile neu berechnet werden müssen, die sich auch tatsächlich geändert haben. In einem Test konnte die Häufigkeit langsamer Ausführungen um 30 Prozent reduziert werden.

Mit Firefox 61 hat Mozilla die Retained Display Lists für Web-Content aktiviert, ab Firefox 69 sind diese auch für die Firefox-Oberfläche selbst aktiv.

Sonstige Geschwindigkeits-Verbesserungen

Auf Windows gibt Firefox dem Betriebssystem nun Hinweise, um die Priorität der Content-Prozesse optimal zu setzen, so dass mehr Prozessorzeit für Aufgaben zur Verfügung steht, an denen der Nutzer aktiv arbeitet, und weniger Prozessorzeit für Dinge, die im Hintergrund passieren – natürlich mit Ausnahme von Video- und Audio-Wiedergabe im Hintergrund.

Bessere Akkuleistung für Nutzer von Apple macOS

Auf Geräten mit Apple macOS als Betriebssystem und zwei Grafikkarten (wie einem MacBook Pro) versucht Firefox für WebGL-Content nun verstärkt, zur Energie-effizienteren GPU zu greifen. Umgekehrt versucht Firefox verstärkt, den Wechsel zur leistungsstärkeren Grafikkarte für einzelne Nutzungen von WebGL zu vermeiden. Davon soll vor allem die Akkuleistung profitieren.

Gespannt dürfen Nutzer von Apple macOS aber auf Firefox 70 sein. Mit Firefox 70 erhält Mozillas Browser nämlich signifikante Verbesserugen der Architektur, welche zu einem extrem reduzierten Energie-Verbrauch führen werden.

Verbesserter Autoplay-Blocker

Das Feature, um die automatische Wiedergabe von Medien zu blockieren, wurde dahingehend erweitert, dass nicht länger nur Medien blockiert werden können, welche Töne von sich geben, sondern optional auch sämtliche Videos, einschließlich derer ohne Audio-Spur.

Anpassung von Apple MacBook Pro Touch Bar

Mit der Touch Bar besitzt das MacBook Pro von Apple eine berührungsempfindliche Leiste, über welche ein Schnellzugriff auf anwendungsspezifische Funktionen möglich ist. Firefox bietet seit Version 66 Unterstützung für die Apple Touch Bar.

Während bisher eine Anpassung via about:config möglich war, sofern man die entsprechenden Schlüsselwörter kannte, ist diese Möglichkeit mit Firefox 69 zugunsten einer visuellen Anpassungsoberfläche weggefallen, welche über die normale Anpassen-Oberfläche von Firefox erreicht werden kann.

Änderung für Nutzer von userContent.css und userChrome.css

Wird im Profilverzeichnis von Firefox ein Unterverzeichnis mit der Bezeichnung „chrome“ und darin eine Datei „userContent.css“ abgelegt, sind darüber alle denkbaren CSS-Anpassungen für jede beliebige Webseite umsetzbar – ganz ohne Erweiterung. Nach dem gleichen Prinzip können über die Datei „userChrome.css“ beliebige Design-Anpassungen an der Firefox-Oberfläche vorgenommen werden.

Um die Startgeschwindigkeit von Firefox weiter zu optimieren, muss ab Firefox 69 ein Schalter in about:config aktiv sein, damit diese beiden Dateien weiterhin eingelesen werden. Denn das Überprüfen auf die Existenz zweier Dateien dauert länger als das Überprüfen einer Firefox-Option und am Ende zahlen ausnahmslos alle Nutzer den Performance-Preis, obwohl von diesem mächtigen Feature kaum ein Nutzer Gebrauch macht.

Nutzer, welche die Datei userContent.css oder userChrome.css bereits in Firefox 68 im Einsatz hatten, müssen überhaupt nichts tun. In Firefox 68 wurde die Einstellung automatisch für alle Nutzer mit einer dieser beiden Dateien gesetzt. Nur Nutzer von Firefox 69 und neuer, welche diese Form der Anpassung bislang nicht nutzen, müssen über about:config den Schalter toolkit.legacyUserProfileCustomizations.stylesheets auf true setzen, damit die Anpassungen weiterhin funktionieren.

Verbesserungen für Firefox-Erweiterungen (WebExtensions)

Natürlich gab es auch in Firefox 69 wieder einige Neuerungen für Entwickler von Firefox-Erweiterungen, unter anderem Verbesserungen der topSites-API.

Eine Übersicht über diese und weitere Neuerungen für Erweiterungs-Entwickler gibt es hier.

Verbesserungen der Webplattform

Auch für Webentwickler hält Firefox 69 viele spannende Neuerungen parat. Die neue Resize Observer API erlaubt es beispielsweise, auf Größenänderungen von Elementen zu reagieren.

JavaScript-Klassen unterstützen nun öffentliche Instanz-Felder. Was CSS betrifft, so unterstützt die @supports-Regel jetzt auch Selektoren, außerdem werden neue Eigenschaften wie overflow-block, overflow-inline, user-select, line-break und contain unterstützt.

navigator.mediaDevices ist nur noch in einem sicheren Kontext verfügbar. Vereinfacht gesagt bedeutet dies: nur noch über HTTPS, nicht länger über HTTP.

Durch die Unterstützung für den Empfang mehrerer Video-Codecs werden WebRTC-Konferenzen erleichtert, bei denen die Nutzer unterschiedliche Clients nutzen.

Dies war nur eine kleine Auswahl an Änderungen der Webplattform. Weitere Informationen zu Verbesserungen der Webplattform in Firefox 68 finden sich in den MDN web docs.

Neuerungen bei den Entwickler-Werkzeugen

Neues about:debugging mit Remote-Debugging

Die Seite about:debugging wurde komplett erneuert und beinhaltet nun auch die Fähigkeit für sogenanntes Remote Debugging via USB oder Netzwerk, um beispielsweise Websites in Firefox oder Firefox Preview für Android über den Desktop-Computer untersuchen zu können.

Dies war zuvor bereits über das Werkzeug WebIDE möglich, welche mit einem der nächsten Updates entfernt werden wird, nachdem about:debugging diese Funktion nun hat.

Debugger: Event-Breakpoints und weitere Verbesserungen

Der Debugger wurde um die Möglichkeit erweitert, Event-Breakpoints zu setzen. Damit lässt sich die Script-Ausführung pausieren, sobald ein bestimmtes Ereignis ausgelöst wird.

Scripts können über das Kontextmenü der Quellen-Ansicht im Debugger jetzt auch heruntergeladen werden. Erweiterungen werden hier nun mit ihrem Namen statt der UUID angezeigt. Und der Debugger lädt nun wesentlich schneller.

Weitere Verbesserungen der Entwicklerwerkzeuge

Die Netzwerkanalyse kennzeichnet jetzt wegen Mixed Content oder durch CSP blockierte Ressourcen. Außerdem gibt es hier optional ab sofort auch eine Spalte für die vollständige Adresse einer Ressource.

Nachdem Firefox über das Werkzeug für Barrierefreiheit bereits die Möglichkeit besitzt, das Kontrastverhältnis aller Elemente einer Seite zu prüfen, gibt es hier nun eine weitere Prüfung, um die Textbeschriftungen zu überprüfen.

Die Webkonsole gruppiert ähnliche Meldungen ab sofort und wird dadurch übersichtlicher. Die Browserkonsole erlaubt jetzt auch das Ausblenden aller Content-Meldungen.

Außerdem wurde die Standard-Reihenfolge der Werkzeuge geändert, um der realen Nutzung gerechter zu werden. Natürlich kann weiterhin jeder die Reihenfolge selbst beliebig durch Verschieben der Reiter verändern.

Weitere Informationen zu Verbesserungen für Webentwickler in Firefox 69 finden sich in den MDN web docs.

Enterprise Features

PKG installer für Apple macOS

Ähnlich zu MSI-Installern für Windows stellt Mozilla ab sofort auch PKG-Installer für Apple macOS zur Verfügung, um die Verteilung von Firefox im Unternehmen zu erleichtern.

Optionale Features

Passwort-Generator

Wird über about:config der Schalter signon.generation.available auf true gesetzt, steht in den Firefox-Einstellungen eine neue Checkbox zur Verfügung, um einen simplen Passwort-Generator zu aktivieren.

Wird dieses Feature aktiviert, dann schlägt Firefox auf Webseiten, welche das Attribut autocomplete=“new-password“ für ein Passwort-Feld gesetzt haben, automatisch ein Passwort vor. Für alle anderen Passwort-Felder kann ein Passwort via Kontextmenü generiert werden.

Passwörter von anderen Subdomains

Wird signon.includeOtherSubdomainsInLookup auf true gesetzt, schlägt der Passwort-Manager von Firefox auch Passwörter anderer Subdomains der gleichen Domain vor. Wird außerdem noch signon.showAutoCompleteOrigins auf true gesetzt, zeigt Firefox bei vorgeschlagenen Passwörtern die jeweilige Domain unterhalb der jeweiligen Zeile an.

Sonstige Neuerungen in Firefox 69

Für Nutzer der US-Version von Firefox hat Mozilla die Standard-Startseite von Firefox überarbeitet, um die Inhalte von Mozillas Pocket-Dienst mehr in den Vordergrund zu stellen.

Lädt der Nutzer eine Datei herunter, zeigt Firefox auf Apple macOS im Finder jetzt auch bei der Datei, welche gerade heruntergeladen wird, den entsprechenden Download-Fortschritt an.

Seit Firefox 68 wird für neue Nutzer von Windows 10 bei Installation von Firefox eine Verknüpfung in der Taskleiste angelegt. Mit Firefox 69 geschieht dies auch für bestehende Nutzer.

Die JavaScript-Engine wurde für bessere Performance um JIT-Unterstützung für ARM64-Geräte erweitert.

Auf about:performance kann nun nach beliebigen Spalten sortiert werden. Die Seite about:support zeigt jetzt auch den Installationspfad von Firefox an.

Außerdem hat Mozilla einen Fehler in Zusammenhang mit Scroll Anchoring behoben, welcher dafür sorgte, dass auf manchen Webseiten die Scroll-Position etwas verschoben war, wenn die Seite neu geladen worden ist.

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

Black Arch Linux

Das Entwicklungsteam hinter BlackArch Linux hat eine neue Version 2019.09.01 veröffentlicht, die zahlreiche neue Tools, aktualisierte Komponenten und verschiedene Verbesserungen enthält.

Die Hacking- und Penetrationstestdistribution läuft nun mit Kernel 5.2.9 und hat mehr als 150 neue Tools erhalten.

Der Installer wurde auf Version 1.1.19 angehoben und das Look and Feel verbessert.

Kali Linux 2019.3

Beim Platzhirsch hat sich ebenfalls etwas getan. So betreibt Offensive Security seine Distribution nun ebenfalls mit Kernel 5.2.9.

Was 8chan verloren hat, hat Kali hinzugewonnen. Gemeint ist Cloudflare als Content Delivery Network. Sollte beim Aufruf von apt update die Domain kali.download angezeigt werden, werden die Dienste von Cloudflare in Anspruch genommen.

Die bereits in der Vergangenheit angekündigten Änderungen der Metapakete (mehr Infos hier ) wurden umgesetzt. 
Speziell dafür wurde ein Image erstellt, welches alle alten Pakete enthält. (kali-linux-large-2019.3-amd64.iso)

In Zukunft werden Tools in folgende Gruppen unterteilt:

• Kali-linux-default – Tools, die unserer Meinung nach für einen Penetrationstester unerlässlich sind
• Kali-linux-large – für Penetrationstester, mit einer größere Anzahl an Tools für nicht standardisierte Einsatzgebiete
• Kali-linux-everything – für alle, die alles wollen (ohne Internetzugang während des Tests)

Zusätzlich wurden die üblichen Aktualisierungen eingespielt (Burp Suite, HostAPd-WPE, Hyperion, Kismet, Nmap), wobei amass neu dabei ist.

Erst vor kurzem hatte ich den neuen Kali App Store vorgestellt. Mit dem aktuellen Release hat Kali Linux die Unterstützung für mobile Geräte weiter ausgebaut und unterstützt nun zusätzlich diese Modelle

• LG V20 International Edition
• Nexus 5X
• Nexus 10
• OnePlus 7

Letzteres zählt nun zu den offiziellen Standardgeräten für die mobile Kali Linux Variante.

Das Image Portfolio wurde zusätzlich auf Geräte von PINEBOOK ($99 Notebooks), sowie den Platinen von Gateworks (Ventana) erweitert.

Der neue Raspberry Pi 4 wird natürlich ebenfalls unterstützt.

Übersicht 09/2019

Die bekannteste Lösung für eine private Cloud ist sicherlich das aus ownCloud hervorgegangene Nextcloud. Während man hier andauernd neue Funktionen einfügt um Nextcloud zur eierlegenden Wollmilchsau weiter zu entwickeln, vernachlässigt man zunehmend die Kernfunktion rund um Dateien. Eine Lücke in die FileRun sehr gekannt springt.

FileRun kann ebenso wie Nextcloud auf einem Home Server oder Webspace betrieben werden. Die übliche Kombination aus Apache, MySQL/MariaDB und PHP reicht hier aus. Die Entwickler haben in ihrem Blog eine exemplarische Anleitung am Beispiel von CentOS 7 veröffentlicht. Freunde von Docker finden hier auch einen fertigen Container.

Die Basisversion ist keine freie Software aber kann kostenlos genutzt werden. Geld verdient die Entwicklerfirma mit einer erweiterten Enterprise-Version.

FileRun konzentriert sich vollständig auf den Kernbereich Dateien. Die sehr aufgeräumte Oberfläche bietet hier die Möglichkeit Kollektionen zu verwalten, Bilder und Musik separat zu erkennen etc. pp. Die Dateien lassen sich über die durchdachte und reaktionsfreudige Oberfläche verwalten und es gibt die obligatorischen Funktionen um Dateien zu teilen.

Die umfangreichen Einstellungen beinhalten die notwendigen Zusatzoptionen. So lassen sich Benutzer und Gruppen verwalten, Accounts per Zwei-Faktor-Authentifizierung absichern sowie ein Aktivitätslog abfragen. Bei Bedarf kann man die Oberfläche zudem mit einem individuellen Branding versehen.

Interessant sind die zahlreichen Plugins für unterschiedliche Dateien. So bindet FileRun unter anderem die Onlinedienste von Microsoft ein um schnell OOXML-Dateien zu bearbeiten.

Bei einer bestehenden OnlyOffice-Installation kann man allerdings auch diese für entsprechende Aufgaben konfigurieren und die Microsoft-Äquivalente ersetzen.

Ein zu verbessernder Bereich betrifft die Clients. FileRun rekurriert hier ausschließlich auf die bestehenden Nextcloud-Clients oder empfiehlt alternative WebDAV-Lösungen.

FileRun zeigt sehr schön was im Kern-Bereich der Cloud - also alles direkt um die Dateien und ihre Synchronisation herum - machbar ist und das auch ziemlich gut. Im direkten Vergleich sieht man dann subjektiv auch die Lieblosigkeit mit der bei Nextcloud dieser Bereich behandelt wird. Der Fokus scheint dort auf die zahllosen anderen mit Nextcloud verbundenen Apps gewandert zu sein. Großes Manko sind die fehlenden Clients und die unfreie Lizenz, die lediglich eine kostenlose Verwendung ermöglicht. Trotzdem kann FileRun für solche Anwender sein, die wirklich nur eine selbst gehostete Cloud für Dateien benötigen.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

eCryptFS war eine dateibasierte Verschlüsselungslösung. Neben der Verschlüsselung von Verzeichnissen konnte man damit auch sehr gute die kompletten Homeverzeichnisse der Benutzer verschlüsseln. Die Lösung beworb vor allem Ubuntu sehr prominent in der Installationsroutine aber auch andere Distributionen experimentierten mit eCryptFS. Das ist aber nun vorbei!

Ubuntu hat sich mit Version 18.04 von eCryptFS verabschiedet (siehe: Ubuntu verabschiedet sich von eCryptFS). Der Entwickler Dustin Kirkland hatte Canonical den Rücken gekehrt und arbeitet nun für Google. Daher sah sich Canonical scheinbar außerstande die Sicherheit von eCryptFS für dieses Einsatzszenario über einen Zeitraum von 5 Jahren zu gewährleisten. Die Entwicklung von eCryptFS im Kernel und der Userspace-Bestandteile sieht zudem leider alles andere als aktiv aus.

Debian hat nun seine jüngste stabile Version "Buster" ebenfalls ohne eCryptFS ausgeliefert. Dies hatte sich bereits im Testing-Stadium abgezeichnet (siehe: eCryptFS - Unsicher und nicht mehr gepflegt?). Gleiches gilt für RHEL und die freien Clone, bei denen bereits vor vergangenen Version 7 ohne eCryptFS auskam.

Zeit also sich zu verabschieden. In diesem Zusammenhang habe ich hier eine kleine Premiere erlebt und meinen ersten Artikel archivieren müssen.

Ganz so schlimm ist der Verlust freilich nicht. Dank CPU-seitiger Verschlüsselungsunterstützung ist Verschlüsselung heute für die Hardware keine Herausforderung mehr. Einer vollständigen Verschlüsselung des Betriebssystems mittels LUKS (siehe: LUKS - Betriebssystem verschlüsseln) steht daher kaum noch etwas im Weg. Unter bestimmten Bedingungen kann man sogar nur das Homeverzeichnis mit LUKS verschlüsseln (siehe: Home-Partition mit LUKS verschlüsseln und bei Login automatisch einbinden).

Für dateibasierte Verschlüsselung kann man auf Lösungen wie CryFS zurückgreifen. Hierfür bietet z. B. Plasma Vault eine grafische Oberfläche (siehe: Plasma Vault - Cloud-Verschlüsselung einfach gemacht). Für andere Desktopumgebungen bietet sich ggf. Sirikali an (siehe: Sirikali - Eine Oberfläche, viele Verschlüsselungen). Theoretisch wäre die von Google vorangetriebene Verschlüsselung von ext4 auch eine Möglichkeit, aber diese steht faktisch bisher für keine Linux-Distribution zur Verfügung.

Bilder:
Einleitungs- und Beitragsbild von KRiemer via pixaybay

Viele Datenschutz- und Datensicherheitsvorschriften in Unternehmen sehen die Verschlüsselung mobiler Datenträger wie USB-Sticks und externer Festplatten vor. Lösungen gibt es zahlreiche (siehe: Verschlüsselung - Eine Übersicht), aber Windows-Anwender sind durch die breite Verfügbarkeit von BitLocker absolut im Vorteil.

Linux-Anwender haben im Wesentlichen die Wahl zwischen einer LUKS (dm-crypt) Lösung oder VeraCrypt. Bei macOS-Nutzern kann man auf die Apple-eigene APFS-Verschlüsselung oder ebenfalls VeraCrypt zurückgreifen. Bei Windows steht ebenfalls VeraCrypt zur Wahl und Microsofts Lösung BitLocker. Hinzu kommen natürlich zahllose Nischen-Lösungen, die das im weiteren beschriebene Problem aber nur noch vergrößern.

Im ersten Moment denkt man sich dann, dass VeraCrypt eine tolle Wahl ist (siehe: VeraCrypt - Systemübergreifende Verschlüsselung). Plattformübergreifend verfügbar, kann man damit überall die externen Datenträger ent- und verschlüsseln. Die Sache hat aber einen Haken. VeraCrypt ist bei keinem System vorinstalliert. Im Firmenumfeld hat man in der Regel keine Administratorrechte um eigenmächtig Software nachzuinstallieren und selbst wenn der eigene Arbeitsplatz mit VeraCrypt ausgestattet wurde, liegt es in der Natur eines mobilen Datenträgers, dass er eben nicht nur am eigenen Gerät angeschlossen wird.

Die nativen Lösungen für macOS und Linux sind zwar vorinstalliert, beschränken die Einsetzbarkeit aber auf das jeweilige Betriebssystem.

Das gleiche gilt natürlich auch für BitLocker. Was viele aber nicht wissen: BitLocker als Vollverschlüsselungslösung ist den teuren Windows-Versionen vorbehalten. BitLocker für externe Medien ist allerdings in allen Windows-Versionen seit Windows 7 enthalten. Durch den großen Marktanteil von Microsoft im Firmenbereich ist die Wahrscheinlichkeit, dass ich am Einsatzort einen Windows-PC vorfinde enorm hoch. Es mag auch Linux oder macOS-Systeme geben aber irgendeinen Windows-PC wird man immer finden.

Hier zahlt sich die Marktmacht von Microsoft immer noch aus. Genau deshalb muss man leider pauschal für externe Speichermedien den Einsatz von BitLocker empfehlen. Es sei denn man hat es mit einem homogenen Linux- oder macOS-Ökosystem zu tun, was enorm unwahrscheinlich ist.

Bilder:

Einleitungs- und Beitragsbild von MasterTux via pixabay

Das Thunderbird-Projekt hat Thunderbird 68 veröffentlicht. Die neue Version des Open Source E-Mail-Clients bringt wieder viele Neuerungen.

Neue Version ab sofort verfügbar, Updates jedoch später

Thunderbird 68 steht ab sofort zum Download bereit und kann ganz einfach über die bestehende Version installiert werden. Ein automatisches Update von Thunderbird 60 oder älter steht zu diesem Zeitpunkt jedoch nicht zur Verfügung – ein Update wird das Thunderbird-Projekt nach aktueller Planung erst mit Thunderbird 68.1 bereitstellen.

Neues Anwendungs-Menü und Einstellungs-Oberfläche

Mit Thunderbird 60 hat das Thunderbird-Projekt in Anlehnung an das neue Photon-Design von Firefox Quantum auch das Design von Thunderbird überarbeitet, was mit Thunderbird 68 eine konsequente Weiterführung fand. So wurde nun auch das Menü komplett erneuert und ist ab sofort ähnlich wie das von Firefox aufgebaut.

Auch die Einstellungsoberfläche von Thunderbird wurde überarbeitet und wird ab sofort, wie bei Firefox, in einem Tab geöffnet und nicht länger als eigenständiges Fenster.

Verbessertes dunkles Theme

Auch das in Thunderbird 60 neu eingeführte optionale dunkle Theme hat diverse Verbesserungen erhalten. Unter anderem ist nun auch die linke Sidebar dunkel.

Vollständige Farb-Unterstützung

Konnten Hintergrund- und Textfarbe für E-Mails bislang aus einer vorgegebenen Farbpalette ausgewählt werden, können jetzt dank neuem Farbpicker beliebige Farben gewählt werden.

Verbesserter Umgang mit Dateianhängen

Wie schon in Thunderbird 60 gab es auch in Thunderbird 68 wieder Verbesserungen beim Umgang mit Dateianhängen. Dateianhänge können nun von einer Nachricht „getrennt“ werden, um diese an einem anderen Ort zu speichern, aber gleichzeitig einen Link von der E-Mail zum neuen Speicherort zu behalten. Außerdem gibt es jetzt eine Option, um den Ordner zu öffnen, in welchem sich der Dateianhang befindet.

Das Filelink-Feature erlaubt den Upload von Dateien in einer Cloud, was praktisch ist, um die Dateigrößen-Begrenzungen verschiedener Mail-Provider zu umgehen. Bereits hochgeladene Dateien können nun neu verlinkt werden und müssen nicht länger neu hochgeladen werden. Für den Filelink-Anbieter WeTransfer ist nicht länger eine Anmeldung notwendig.

Hinweis für Nutzer von Erweiterungen

Erweiterungen sind nur dann mit Thunderbird 68 kompatibel, wenn diese von ihrem jeweiligen Entwickler ausdrücklich als kompatibel markiert worden sind. Für Nutzer von Thunderbird mit Erweiterungen ist es daher möglich, dass einige Erweiterungen nach dem Update auf Thunderbird 68 deaktiviert sind.

Was Wörterbücher und Themes betrifft, sind nur noch WebExtensions erlaubt. Sowohl addons.mozilla.org als auch addons.thunderbird.net sind bereits auf WebExtension-Wörterbücher und -Themes umgestellt.

Sonstige Neuerungen

Es ist nun möglich, alle Ordner eines Accounts mit einem Mal als gelesen zu markieren. Filter können so konfiguriert werden, dass sie periodisch ausgeführt werden. Feed-Artikel zeigen jetzt externe Anhänge als Links an. Thunderbird unterstützt außerdem eine OAuth2-Authentifizierung für Yandex.

In den erweiterten Einstellungen können ab sofort wie in Firefox Sprachpakete ausgewählt werden, wenn in der Konfiguration zuvor intl.multilingual.enabled auf true und extensions.langpacks.signatures.required auf false gesetzt worden ist.

Ebenfalls wie Firefox unterstützt auch Thunderbird jetzt die Konfiguration im Unternehmensumfeld via GPO auf Windows oder plattformübergreifend via policies.json.

Ein Downgrade-Schutz verhindert standardmäßig die Verwendung einer älteren Version von Thunderbird mit dem gleichen Profil.

Im Chat kann für jede Konversation jetzt eine andere Sprache für die Rechtschreibkorrektur ausgewählt werden.

Verbessert wurden auch die Phishing-Erkennung und die Scam-Warnungen. Im Kalender Lightning gab es Verbesserungen des Event-Dialogs.

Darüber hinaus gab es noch zahlreiche weitere kleinere Verbesserungen sowie Fehlerbehebungen, welche sich in den Release Notes (engl.) nachlesen lassen. Und natürlich wurden auch, wie in fast jedem Update, wieder diverse Sicherheitslücken geschlossen.

Der Beitrag Thunderbird 68 mit vielen Neuerungen veröffentlicht erschien zuerst auf soeren-hentzschel.at.

RSS Feeds sind so old school, dass sie unmittelbar davor stehen von den Hipstern ironisch als Alternative zu Social Networks verwendet zu werden. Gut, ganz so weit sind wir noch nicht aber RSS Feeds sind von Haus aus nicht besonders komfortabel. Mittels moderner Webanwendungen, Synchronisation und guten Clientprogrammen kann man die Technik aber in die Gegenwart heben.

RSS ist eigentlich eine grauenvolle Technik. Mittels eines Programms lädt man einen Feed von einer Webseite und macht ihn durch ein lokales Programm lesbar. Viele dieser Programme verweisen auch durch ihre Optik auf ihr Alter. Nebenbei entzieht sich die Qualität des Feeds dem Anwender, da hierfür die Webseite verantwortlich ist. Hat man mehr als ein Endgerät kommt man zudem mit den Leseständen durcheinander.

Genau aus diesen Gründen weichen sogar im Nerd-Bereich viele auf Twitter und andere Alternativen aus um Informationskanäle zu abonnieren. Eine fatale Entwicklung, da man hierdurch die Hoheit über seinen Nachrichten- bzw. Informationskonsum aus der Hand gibt und sich Veränderungen im Algorithmus der jeweiligen Netzwerke ausliefert. Natürlich erzeugen auch RSS-Feeds Filterblasen, aber diese unterliegen der Kontrolle des Anwenders, der die Sammlung erstellt und pflegt. Jedem reflektiert handelnden RSS-Nutzer ist klar, dass er nicht die Gesamtheit der Informationen abonniert hat. Zudem folgt man dem gesamten Angebot eines Anbieters, der auch mal abweichende Artikel veröffentlichen kann. Ähnlich wie bei einem Zeitungsabonnement stößt man auch mal auf Artikel, die der eigenen Meinung zuwider laufen.

RSS ist daher nach wie vor unverzichtbar. In einem modernen Gewand ist es auch einigermaßen komfortabel nutzbar. Wichtig ist eine zentrale Instanz um die Feeds zu verwalten. Niemand möchte auf dem Desktop, dem Notebook und dem Smartphone die RSS-Bibliothek separat pflegen und sich merken welche Artikel gelesen wurden. Es gibt eine Reihe an kommerziellen Diensten, die so etwas anbieten: Feedly, FeedBin etc. pp. Das ist hinsichtlich des Datenschutzes hochproblematisch. Der Anbieter kennt zumindest theoretisch die Interessen und Lesegewohnheiten seiner Anwender. Je nach Umfang der RSS-Bibliothek gibt man hier sehr viele Informationen zur Profilbildung aus der Hand.

Daher sollte man den zentralen Dienst nach Möglichkeit selbst betreiben. Es gibt hier nur drei ernst zu nehmende Lösungen: Tiny Tiny RSS, FreshRSS und Nextcloud News. Persönlich empfehle ich gerne FreshRSS. Nextcloud News ist zwar - eine laufende Nextcloud vorausgesetzt - schnell eingerichtet, bietet aber keine verbreiteten Schnittstellen. Das Client-Ökosystem ist daher sehr überschaubar. FreshRSS bietet im Gegenzug zu TT RSS von Haus aus Unterstützung für die Fever-API, was für mich ausschlaggebend war.

FreshRSS installieren & konfigurieren

FreshRSS setzt einen normalen LAMP-Server voraus. Wer keinen Home-Server (z. B. für die Nextcloud) betreibt kann FreshRSS daher problemlos auf jeden Webspace installieren. Die Anleitung ist etwas eigenwillig, dürfte aber auch Hobby-Admins vor keine Herausforderung stellen. Für Container-Freunde steht ein Docker-Container zur Verfügung.

Die Web-Anwendung präsentiert sich sehr übersichtlich und lässt sich gut bedienen. Das ist aber für den vorliegenden Anwendungsfall nachrangig, da FreshRSS primär als Synchronisationszentrale zwischen den verschiedenen Clientprogrammen dient.

Mehr Arbeit muss man in die Einrichtung investieren. Die bestehende Feed-Sammlung lässt sich problemlos als OPML-Datei in der Abonnementverwaltung importieren. Standardmäßig muss der Anwender auf der Weboberfläche aber selbst die Aktualisierung der Feeds anstoßen. Sofern man vorhat FreshRSS als Zentrale für Client-Programme zu nutzen ist das natürlich problematisch.

Um das Problem zu lösen gibt es zwei unterschiedliche Möglichkeiten. Betreibt man FreshRSS auf einem eigenen Server oder hat zumindest Zugriff auf die Crontab kann man einfach einen Cronjob einrichten:

6,36 * * * * www-data php -f /usr/share/FreshRSS/app/actualize_script.php > /tmp/FreshRSS.log 2>&1

Diese Möglichkeit besteht bei vielen Webspace-Anbietern nicht. Die Dokumentation hält deshalb ein paar Alternativen bereit. Hierbei muss man aber enorm aufpassen, da einige der Möglichkeiten sicherheitskritisch sind, weil sie letztlich anonymen Zugriff durch einen Dritten zulassen.

Besser ist es einen Authentifizierungstoken einzurichten und diesen mit der URL zu übergeben. Dazu klickt man in den Einstellungen auf Profil.

https://freshrss.example.net/i/?c=feed&a=actualize&token=<token>

Der Einsatz von HTTPS ist hier natürlich selbstverständlich.

Bei der Gelegenheit kann man auch gleich noch ein API Kennwort festlegen. FreshRSS unterstützt für Dritt-Programme zwei verbreitete APIs: Die so genannte Google API (wegen des früheren Google RSS Readers) und die Fever API. Letztere stammt vom RSS Reader Fever, der inzwischen eingestellt wurde. Die API ist aber heute weit verbreitet und viele quelloffene und proprietäre Programme unterstützen diese. Der API Zugriff lässt sich in den Einstellungen unter Authentifizierung aktivieren.

Clients

Die Situation an Clientprogrammen ist unter Linux ziemlich bitter. Im Grunde kann man mit Feed Reader lediglich ein einziges Programm empfehlen. Bezeichnenderweise kommt aus dem dem Umfeld von elementary OS. Einem der wenigen Projekt, die den Desktop nicht reaktionär vor sich hin vegetieren lassen. Feed Reader unterstützt zahlreiche Onlinedienste (neben Fever / FreshRSS) und kann gekürzte Feeds vollständig darstellen. Zwei Funktionen, die jenseits von Linux inzwischen Standard sind. Nebenbei ist Feed Reader auch für Podcasts geeignet, was hier eine Leerstelle schließt (siehe auch: Cloud in Eigenregie IX: Baustelle Podcasts).

Für macOS sieht die Situation hier wesentlich besser aus. Auf dem Desktop bieten sich hier ReadKit und Reeder an. Letzteres ist jüngst in Version 4 erschienen. Beide kosten ca. 10€ als einmaliger Kauf. Ich persönlich präferiere ReadKit weil es sich optisch besser in den Desktop einfügt, während man Reeder die iOS-Adaption ansieht.

Die Auswahl für iOS und padOS ist deutlich größer. Viele bekannte Apps wie Fiery Feeds oder Unread sind allerdings auf ein Abonnement-Modell gewechselt oder beabsichtigen dies für die nähere Zukunft. Diese Form der Monetarisierung mag ich persönlich überhaupt nicht, weshalb die Empfehlung hier klar zu der iOS App von Reeder geht.

Android-Nutzer sollten prüfen, ob ihnen EasyRSS genügt. Dieses lässt sich über F-Droid beziehen. Ansonsten gibt es noch das famose Readably, das leider nur via Google Play bereit steht.

Mittels der Kombination von FreshRSS und entsprechenden Clients für die genutzten Endgeräte kann man seinen Nachrichten- und Informationkonsum strukturieren und bleibt für Neueigkeiten auf dem Laufenden. Ohne Abhängigkeit von fremden Diensten und Algorithmen, die entscheiden, was für einen interessant sein könnte.

Bilder:

Einleitungs- und Beitragsbild von stevepb via pixabay

QR-Codes sind eine praktische Sache um Informationen schnell mit dem Smartphone einzulesen. Dies können Visitenkarten oder andere Informationen wie URLs sein. Am Markt existieren unzählige Tools um QR-Codes zu erzeugen.

Ein mit qrencode erzeugter QR-Code

Unter Linux können QR-Codes unter anderem einfach mit dem Kommandozeilenwerkzeug qrencode erstellt werden. Nach der Installation mittels:

apt-get install qrencode

kann der erste QR-Code erzeugt werden:

qrencode -o qrcode.png https://seeseekey.net

Die Fehlerkorrekturinformationen in dem QR-Code sind im Normalfall auf niedrig gestellt. Soll der Error Correction Level erhöht werden, so wird hierfür die Option -l genutzt:

qrencode -o qrcode.png -l H https://seeseekey.net

Bei den gewählten Option ist die erzeugte PNG-Datei in etwa 111×111 Pixel groß. Mithilfe des Parameters -s kann die Größe des erzeugten QR-Codes eingestellt werden:

qrencode -o qrcode.png -l H -s 24 https://seeseekey.net

Bei der Option gilt, je größer die Zahl desto größer das resultierende Bild. Lizenziert ist qrencode unter der GPL in Version 2 und damit freie Software. Die offizielle Seite des Projektes ist unter fukuchi.org/works/qrencode/ zu finden.

Ein FreeNAS System ist seit Jahren ein Sicherungsziel für meinen Mac. Seit der Abkündigung von AFP durch Apple waren dafür immer einige Klimmzüge notwendig (siehe zuletzt: FreeNAS 11.2 - Time Machine auf SMB Freigabe sichern). In der jüngsten Version von 11.2 ist das nun deutlich vereinfacht.

Bei der Erstellung einer SMB-Freigabe lässt sich nun einstellen, dass diese als Time Machine Sicherungsziel gedacht ist. Dadurch ist die Eingabe von weiteren Parametern für die Freigabe nicht mehr notwendig.

Ebenso hat man die Probleme mit der MDNS Erkennung durch macOS behoben, weshalb die Freigabe automatisch in den Systemeinstellungen erkannt wird.

FreeNAS hat hier in Punkto Einfachheit diese Nase deutlich vorn.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay