staging.inyokaproject.org

Nachdem, wie vorige Woche angekündigt, die Umstellung der Blogsoftware eigentlich gestern schon geplant war, aber wieder viele andere Sachen dazwischen gekommen sind, ist es nun endlich soweit: Der neue Blog ist online.

Gut, dem ein oder anderen mag es aufgefallen sein: Hier wird (noch) das Standardtheme von Ghost verwendet, und keiner der alten Artikel ist hier auffindbar. Ersteres dauert noch einige Zeit, aber letzteres ist zwischenzeitlich gelöst: Unter archiv.kopfkrieg.org sind alle bisherigen Artikel einsehbar. Ich werde diese natürlich im Laufe der nächsten Tage migrieren, aber bis dahin muss einfach auf dieses Provisorium zurückgegriffen werden. Entschuldigt das bitte. Mittlerweile sind alle Artikel migriert.

Das Design folgt auch noch, im Moment bin ich überhaupt erst einmal froh, dass das heute noch etwas geworden ist. Der Tag bräuchte für mich einfach mehr Stunden.

Wer den RSS-Feed abonniert hatte wird möglicherweise auch etwas enttäuscht sein, denn auch die Feeds und Kategorien werden überarbeitet, und funktionieren deswegen nicht mehr so wie erwartet.

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.

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

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 

Vor relativ genau sieben Jahren ging meine erste Webseite online. Das Ganze lief mit einem selbst in Python geschriebenen, statischen Blogkompilierer, und nicht ganz zwei Jahre war ich damit auch recht glücklich. Allerdings hatte die Software nur wenige Features, vor allem das automatische generieren von RSS/Atom Feeds hat mir gefehlt.

Im Juli 2014 bin ich dann auf makeblog umgestiegen, und habe mir dazu auch gleich eine neue Domain geholt. Seitdem existiert dieser Blog.

Um jetzt endlich auf den Punkt zu kommen: Ich werde demnächst™ wieder einmal umsteigen. Aber diesmal nicht, weil die bisher verwendete Software Schwächen hätte (tatsächlich kann ich makeblog für statische Seiten nur empfehlen), sondern weil ich in Zukunft auch vermehrt unterwegs Artikel schreiben möchte, und das so einfach wie möglich. Nach langer Suche und vielen Tests werde ich auf Ghost setzen.

Ghost selbst ist, wie auch schon die zwei Programme zuvor, Open Source. Das ganze ist relativ leichtgewichtig (verglichen mit anderen Systemen wie Wordpress), und erlaubt zudem das Erstellen von Artikeln mittels Markdown, was ich als ganz angenehm empfinde. Ich selbst hoste bereits mehrere Instanzen und bin dabei auf noch keine Probleme gestoßen (bei mittlerweile fast einem Jahr). Wer sich vorab ansehen möchte, wie so ein Blog aussehen kann: Bitte hier klicken. (zur Zeit offline 😕 )

Jetzt ist es so, dass ich den Umzug schon länger geplant habe, aber bisher nicht wirklich dazu gekommen bin das Standard-Theme von Ghost anzupassen, geschweige denn die Artikel zu portieren. Heißt konkret: Die neue Seite wird nächsten Samstag (14.09.2019) online gehen, und komplett anders aussehen wie diese hier. Die jetzige Seite wird in ein Archiv verschoben. Das Design werde ich nach und nach portieren, ebenso wie die Artikel. Wer meinen RSS/Atom Feed abonniert hat wird manche Artikel möglicherweise kurzzeitig doppelt sehen - dafür möchte ich mich vorweg entschuldigen, leider geht es nicht anders.

Nächste Woche wird es dazu dann auch nochmal einen gesonderten Artikel geben. Bis dahin - stay tuned!

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

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

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.

In this guide I’ll show the necessary steps to set up a Codeberg Git repository in Drone CI and run a simple build pipeline to generate and upload your static Hugo website. Anoxinon e.V. from Germany is using a very similar setup to make its blog authors' life easier.

All the steps are shown in an LXD based environment on Debian 10 Buster. Of course it will work very similarly on other Linux systems.

Preparing your Host

As Drone CI heavily depends on a Docker Environment, install the Docker Daemon on your Server (in fact, using Drone CI’s Docker image is the only official way to install it for now):

https://docs.docker.com/install/linux/docker-ce/debian/#install-docker-ce

Preparing credentials

The first credential you’ll need for your Drone setup is a random shared secret that is generated e.g. via:

openssl rand -hex 16

Note down the random string - you will need it later. The secret is used to connect the Drone main instance with a “worker” / “runner” / “agent” instance. The agent accepts build jobs and runs them in its own Docker environment. There can be more than just one agent, but a single one is sufficient for now.

Next, log in to your Codeberg.org account and enter the settings page. Create a new OAuth2 application in the “Applications” tab. You can give any title to your new Application, such as “Drone”. The “Redirect URI” must point to the Login page of your future Drone web interface. In case you’re planning to make the web interface available at https://drone.myserver.tld, the settings look like this:

Hit “Create Application”. You will receive

• A client ID
• A client secret

You will need both to connect Drone to your Codeberg repositories. Note them down carefully. As soon as you click on “Save”, the secret will never be displayed again.

Setting up startup files for Drone CI and Drone agent

Now let’s get Drone configured!

Drone is configured mainly via environment variables. There’s a lot of them, and we need to define them in the docker run command. That is why you should create two different startup Bash scripts. The first one is for the Drone main instance - the second one is for the build agent.

For the Drone main instance: create_drone_main.sh

#!/bin/bash
export DRONE_GITEA_SERVER="https://codeberg.org"
export DRONE_GITEA_CLIENT_ID=""
export DRONE_GITEA_CLIENT_SECRET=""
export DRONE_RPC_SECRET=""
export DRONE_SERVER_HOST="drone.myserver.tld"
export DRONE_SERVER_PROTO="https"
export DRONE_ALLOWED_USERS="myuser@codeberg.org, mygroup"
docker run \
--volume=/var/lib/drone:/data \
--env=DRONE_AGENTS_ENABLED=true \
--env=DRONE_GITEA_SERVER=${DRONE_GITEA_SERVER} \
--env=DRONE_GITEA_CLIENT_ID=${DRONE_GITEA_CLIENT_ID} \
--env=DRONE_GITEA_CLIENT_SECRET=${DRONE_GITEA_CLIENT_SECRET} \
--env=DRONE_RPC_SECRET=${DRONE_RPC_SECRET} \
--env=DRONE_SERVER_HOST=${DRONE_SERVER_HOST} \
--env=DRONE_SERVER_PROTO=${DRONE_SERVER_PROTO} \
--env=DRONE_TLS_AUTOCERT=true \
--env=DRONE_USER_FILTER="${DRONE_ALLOWED_USERS}" \
--publish=80:80 \
--publish=443:443 \
--restart=always \
--detach=true \
--name=drone \
drone/drone:latest

You need to adapt all the exported variables to your environment and your own credentials. RPC_SECRET is the “shared secret” that you created earlier with the openssl command.

DRONE_ALLOWED_USERS="myuser@codeberg.org, mygroup" defines all (Codeberg) users and groups that are allowed to register / use your Drone.ci instance.

For the Drone Docker runner: create_drone_agent.sh

#/bin/bash
export DRONE_RUNNER_NAME="local-docker"
export DRONE_RPC_PROTO="https"
export DRONE_RPC_HOST="drone.myserver.tld"
export DRONE_RPC_SECRET=""
docker run -d \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DRONE_RPC_PROTO=${DRONE_RPC_PROTO} \
-e DRONE_RPC_HOST=${DRONE_RPC_HOST} \
-e DRONE_RPC_SECRET=${DRONE_RPC_SECRET} \
-e DRONE_RUNNER_CAPACITY=2 \
-e DRONE_RUNNER_NAME=${DRONE_RUNNER_NAME} \
-p 3000:3000 \
--restart always \
--name ${DRONE_RUNNER_NAME} \
drone/drone-runner-docker:latest

• RUNNER_NAME: Can be any name. You can choose your own :-)
• RPC_SECRET: The “shared secret” again.

Make both files executable:

chmod u+x create_drone_main.sh
chmod u+x create_drone_agent.sh

And now let the magic happen: Start your main instance, first. Then, start your agent:

./create_drone_main
./create_drone_agent

It might take a minute until both containers are initialized and ready. You should then be able to open https://drone.myserver.tld in your web browser.

Authenticating on Codeberg and activating Drone for your repos

Drone will ask you to log in to your Codeberg account or accept an access request. Allow the OAuth2 request, so Drone can access your repositories.

Back on the Drone CI main page, you should be able to see a “Sync” button at the top of the page. Click it. Your Git repositories should now appear as a list below.

Hit “Activate” on every repo which Drone should be enabled for. After confirming your request on the next page, you will will be shown the CICD settings for that repository.

Creating a Drone “build and publish” pipeline for Hugo

You can leave most of the settings at their default values. We only need to add a “Secret”.

A secret in Drone terms can be any string. It can be a password, a PIN, or even an SSH key… and that’s what we are going to use it for: We will create a “secret” to securely store the SSH key that we are going to use for the website upload.

Create a user and SSH key for upload

To safely upload the generated HTML files, create a new Linux user on your webserver and generate a new SSH key for it:

adduser drone
su - drone
ssh-keygen -t ed25519
exit

Do not set a password for the key!

Then set the permissions on your webserver’s directory, so the drone user has full access:

chown -R drone:nginx /var/www/mysite.tld

Copy the SSH private key and paste it into the “Secret Value” field in your Drone repository settings:

cat /home/drone/.ssh/id_ed25519

The “Secret Name” field muss be set to drone_ssh_key. Then hit “Add a secret”.

Create pipeline in Hugo source repository

All build pipelines are controlled via a .drone.yml file (mind the dot prefix!) in their corresponding source repo. To enable the Hugo build pipeline, create a .drone.yml file in your source Repo and put the following contents inside:

---
kind: pipeline
type: docker
name: default
trigger:
branch:
- master
steps:
- name: Version check
image: jguyomard/hugo-builder
commands:
- echo "Checking Hugo version."
- hugo version
- name: Build
image: jguyomard/hugo-builder
commands:
- hugo --destination /drone/src/build
- minify -r -o /drone/src/build /drone/src/build
- name: Upload
image: jguyomard/hugo-builder
commands:
- eval `ssh-agent -s`
- echo "$SSH_KEY" | ssh-add -
- mkdir -p ~/.ssh
- echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
- rsync -rv -e "ssh -p 22" /drone/src/build/ drone@mywebserver.tld:/var/www/mysite.tld/ --checksum
environment:
SSH_KEY:
from_secret: drone_ssh_key

If you have a basic understanding of YAML and how build pipelines work in general, you might already have an idea what’s happening here.

The build process is separated in three steps. For each step a name, an image and a set of commands is defined. The image defines a Docker image as a build environment. All the commands will be run inside that Docker container. In this example, all the commands will be run in jguyomard’s “hugo-builder” container, which includes all the needed build dependencies, such as the hugo binary, a minify binary and some SSH tools for the upload. The environment setting at the end makes sure that the SSH key secret is available as an environment variable.

Push the new file to your Git repo, and watch Drone CI build and upload your site … :-)

The build and upload will be triggered on every push to the master branch. You change that behavior in the trigger section of the .drone.yml config file.

Happy droning!

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

In den IT-Medien konnte man in den vergangenen Tagen eine Meldung über den Telegram Messenger lesen. Nach dieser lässt sich eine zentrale Sicherheitsfunktion aushebeln. Insbesondere für staatliche Akteure dürfte es ein Leichtes sein das auszunutzen. Direkt betroffen sind vermutlich die Demonstranten in Hongkong, die zumindest mittelbar dem vielleicht effizientesten Überwachungsapparat der Welt gegenüberstehen.

Telegram bietet eine Funktion in Gruppenchats die eigene Telefonnummer zu verbergen. Der Haken ist - und Telegram gibt es in seinen FAQ auch zu - sobald jemand die Nummer bereits im Telefonbuch hat, kann er sie trotzdem sehen. Man muss nicht viel Fantasie haben um hier die Möglichkeiten für staatliche Akteure zu sehen. Es dürfte die chinesischen (aber auch andere!) Sicherheitsbehörden vor keine Herausforderung stellen zahlreiche potenzielle Nummern über die Anbieter herauszufinden und in ein System zu gießen. Telegram hat da wohl irgendwelche Sicherheitsfunktionen eingebaut, um solche Massenabfragen abzuwehren, aber wie wirksam diese sind weiß niemand.

Der Kern des Problems ist jedoch ein anderes: Telegram ist einfach kein sicherer Messenger. Ich hatte das auf der hiesigen Übersichtsseite (siehe: Sichere Messenger - Verschlüsselung und Metadaten) bereits zusammengefasst: Mir ist absolut kein Experte auf dem Gebiet bekannt, der das jemals behauptet hätte. Die technische Qualität von Telegram wird bereits seit längerem kritisch diskutiert. Insbesondere die technische Umsetzung der Verschlüsselung steht dabei im Zentrum der Aufmerksamkeit. Bereits Wikipedia widmet der Sicherheit von Telegram einen langen, sehr kritischen Abschnitt. Auch außerhalb der Tech-Filterblase sind kritische Artikel erschienen. Telegram setzt scheinbar bei der Verschlüsselung nicht auf eine bewährte Lösung, wie sie z.B. Open Whisper System anbietet, sondern auf eine unbekannte Eigenentwicklung. Nachrichten werden in der Cloud gespeichert und sind mindestens für den Betreiber einsehbar. Lediglich so genannte "Geheime Chats" bieten mehr Sicherheit, sind aber nur zwischen zwei Personen möglich und nicht für Gruppen. Genau wie WhatsApp gleicht Telegram das Adressbuch des Anwenders ab um Kontakte zu ermitteln. Das BKA scheint zudem in der Lage zu sein Telegram Nachrichten abzufangen. Ohne diese Aktion bewerten zu wollen, muss man festhalten: Was das BKA kann, können andere auch. Eine umfangreiche Sicherheitsanalyse liefert das Paper "Security Analysis of Telegram" aus dem Mai 2017.

Telegram ist ein wunderbares Beispiel für ein verbreitetes Phänomen. Es setzt sich nicht die beste Lösung durch, sondern eine Lösung von der viele Menschen glauben, sie wäre die beste Lösung. Schillernde Persönlichkeiten und Marketing sind hier die Ursachen. Signal ist hier die viel bessere Lösung, aber dahinter steht keine so schillerende Gründerfigur und die Auftritte sind eher trocken gehalten.

Bilder:
Einleitungs- und Beitragsbild von geralt via pixabay

Heute schreibe ich mal ein paar Zeilen zum Thema Datenträger die sich im laufe der Zeit doch sehr gewandelt haben.

Angefangen hatte alles mit der Diskette, die eine Kapazität von 1,44 bzw. 1,2 MB hatte. Zur damaligen Zeit schon eine recht ordentliche Menge. Für mich war es normal das ich für die Installation eines Programmes bis zu 10 Disketten benötige. Und auch ein Diskcopy für eine Sicherungskopie eines neuen Programmes war normal. Für mich waren Datenträger immer magnetisch.

Dann kam die CD-ROM und damit die optischen Datenträger. Die ersten Versionen wurden noch
abenteuerlich per Soundkarte angeschlossen, aber schnell setzte sich IDE/ATAPI durch und meine erste CD-ROM war dann auch so angeschlossen. Damals war es normal bei der Installation eines Betriebssystems noch wählen zu müssen was für ein CD-ROM Laufwerk man hatte. Es dauerte nicht lange bis IDE bzw. ATAPI der Standard wurde und der P-ATA Anschluss dominierte die Verbindungstechnik. Der Wechsel zu S-ATA brachte keine grosse Änderung für den Anwender und erst die Ansteuerung mit UEFI brachte Änderungen die auch für Linux interessant waren.

Weniger spektakulär war der Wechsel von optischen Datenträger zum USB-Stick der ohne viel aufsehen sich vollzog. Durch die Streamingdienste waren MusikCD’s nicht mehr so bedeutend wie früher und Software wurde gern per USB Stick installiert. So wurden optische Laufwerke zunächst in Notebooks und später Desktop PC’s auch nicht wirklich vermisst.

Ich muss zugeben das ich zunächst sehr an den magnetischen und dann später an den optischen Datenträgern “gehangen” habe und den Wechsel immer kritisch gesehen habe. Aber jeder USB Stick ist einer DVD, CD oder gar Diskette um längen überlegen.
Bei Ubuntu hat man ja auch schon Brasero als Brennprogramm aus der Standard-Installation heruasgenommen und es hat etwas gedauert bis ich es bemerkt habe. Es liegt daran das man dann doch immer weniger und weniger Rohlinge gebrannt hat- Während man um die Jahrtausendwende noch bergeweise Rohlinge gebrannt hat muss ich schon richtig überlegen wann ich die letzte CD gebrannt habe.

Die meisten Bilder, welche aus einer Digitalkamera kommen enthalten sogenannte EXIF-Informationen. Die Abkürzung EXIF steht dabei für Exchangeable Image File Format. In diesen Metadaten zum Bild können eine Reihe von Informationen enthalten sein, wie z.B. Datum und Uhrzeit, Koordinaten an welchen das Bild geschossen wurde, die Blendenzahl und viele weitere. Unter Umständen kann es gewünscht sein diese Informationen zu entfernen. Unter Linux, in diesem Fall Ubuntu, kann das mit dem ExifTool erledigt werden. Dazu muss dieses im ersten Schritt installiert werden:

apt install exiftool

Anschließend kann eine einzelne Datei mit dem Befehl:

exiftool -all= image.jpg

bearbeitet werden. Soll das Ganze rekursiv über mehrere Ordner passieren kann folgender Befehl genutzt werden:

cd folder/
find . -iname "*.jpg" -type f -exec exiftool -all= {} \;

Er durchsucht alle Verzeichnisse unterhalb des gewählten Verzeichnisses und entfernt, für jede Datei mit der Endung .jpg, die EXIF-Daten.