Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.
Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund. Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht. Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss. Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:
Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain. Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.
Mozillas neuester Dienst hört auf den Namen Firefox Relay und schützt die persönliche E-Mail-Adresse vor Spam und unerwünschter Offenlegung.
Firefox Relay ist ein neuer Dienst von Mozilla, der sich derzeit in einer geschlossenen Beta-Phase befindet und noch eine Einladung benötigt, um getestet werden zu können. Eine öffentliche Beta-Phase soll folgen.
E-Mail-Adressen sind gleichzusetzen mit einer persönlichen Adresse. Sie sind einmalig und viele Nutzer besitzen nur eine einzige E-Mail-Adresse, die sie teilweise auf dutzenden, wenn nicht gar auf hunderten Websites verwenden. Findet auf einer Website, auf der man mit seiner E-Mail-Adresse registriert ist, ein Datendiebstahl statt, wird damit in vielen Fällen auch die persönliche E-Mail-Adresse offengelegt. Und haben Spammer erstmal eine E-Mail-Adresse in ihrem System, darf man sich auf viele unerwünschte E-Mails ohne realistische Hoffnung einstellen, dass der Spam abnehmen wird.
Mit Firefox Relay können Alias-Adressen angelegt werden, die der Nutzer für Newsletter-Anmeldungen und Website-Registrierungen angeben kann. Firefox Relay leitet diese E-Mails dann an die persönliche E-Mail-Adresse weiter. Wird ein Alias nicht mehr benötigt, kann dieser ganz einfach temporär deaktiviert oder komplett gelöscht werden.
Mittels Firefox-Erweiterung können in Online-Formularen ganz einfach bei Bedarf neue Alias-Adressen angelegt werden, ohne dass hierfür zunächst die Weboberfläche von Firefox Relay aufgesucht werden muss.
Interessierte können sich auf relay.firefox.com mit ihrem Firefox Account anmelden und sich auf die Warteliste setzen lassen.
Die Verwendung von target=“_blank“ in Webseiten-Links ist nicht nur praktisch, um Seiten standardmäßig in einem neuen Tab öffnen zu lassen, es handelt sich dabei gleichzeitig auch um eine unterschätzte Sicherheitslücke. Eine Lösung dagegen ist die Verwendung von rel=“noopener“, was die meisten Webseitenbetreiber allerdings versäumen. In Zukunft soll Firefox diesen Zusatz automatisch annehmen, wenn target=“_blank“ verwendet wird.
Jeder Webentwickler kennt das target-Attribut mit seinem Wert _blank, um vom Benutzer geklickte Links auf Webseiten standardmäßig in einem neuen Tab statt im gleichen Tab aufrufen zu lassen. Was aber nur die Wenigsten wissen: es handelt sich dabei um eine Sicherheitslücke, welche Phishing ermöglicht. Die Lösung für Webseitenbetreiber ist einfach: wird target=“_blank“ verwendet, ist gleichzeitig auch noch rel=“noopener“ zu verwenden. Bonuspunkt: Die Verwendung von rel=“noopener“ liefert gleichzeitig auch noch einen Performance-Vorteil gegenüber dem Weglassen.
Das offensichtliche Problem an der Geschichte ist, dass zwar jeder Webentwickler das target-Attribut kennt, aber nur die wenigsten um die Notwendigkeit von rel=“noopener“ wissen, was in der Konsequenz bedeutet, dass die meisten Seiten im Web das zusätzliche Attribut für Links in neuen Tabs nicht verwenden.
Wenn der Entwickler einer Webseite target=“_blank“ verwendet und das entsprechende rel-Attribut nicht setzt, wird Firefox ab Version 79 automatisch annehmen, dass rel=“noopener“ gesetzt sein soll, womit die Sicherheitslücke auch ohne Aktion des Webentwicklers nicht mehr existiert. Soll das alte Verhalten in Kraft treten, muss der Webentwickler dieses in Zukunft explizit über rel=“opener“ aktivieren.
Das neue Verhalten ist bereits seit Version 65 in Nightly-Versionen von Firefox standardmäßig aktiviert. Da weitere Anpassungen seitens Firefox notwendig waren, schafft es diese Änderung aber erst mit Firefox 79 standardmäßig in die finale Version. Firefox 79 wird nach aktueller Planung am 28. Juli erscheinen.
Apple hat dieses Verhalten bereits in Safari 12.1 im März 2019 implementiert. Google plant, in diesem Punkt nachzuziehen.
Ich hatte das Problem, dass nach einer Rücksicherung meiner Daten, das Startmenü von KDE keine Favoriten mehr angezeigt hat. Weder die alten Favoriten wurden angezeigt, noch konnte ich neue Favoriten anlegen. Die Lösung des Problems war das Löschen von
allen Dateien im Verzeichnis ~/.local/share/kactivitymanagerd/resources/
und die Datei ~/.config/kactivitymanagerd-statsrc
Danach ein Neustart - vermutlich hätte auch ein Aus- und wieder eInloggen gereicht und schon konnte ich wieder ganz normal Favoriten in diesem Bereich hinzufügen.
Mozilla arbeitet an einer neuen Einstellungs-Seite für Firefox, über welche Nutzer experimentelle Funktionen aktivieren können.
In den Firefox-Einstellungen lassen sich einige Aspekte von Firefox konfigurieren. Wem dies noch nicht weit genug geht, findet mit about:config eine Oberfläche, auf welcher zahlreiche weitere Einstellungen vorgenommen werden können. Auch neue Funktionen, die noch nicht fertig sind, können hierüber häufig vorab aktiviert werden. Allerdings ist von der Verwendung von about:config abzuraten, wenn man nicht genau weiß, was man tut, da sich hierüber tiefgreifende Veränderungen durchführen lassen, welche gerade bei Unwissenheit unerwünschte Nebeneffekte haben können, zumal about:config keinerlei Raum für Beschreibungen oder Links zu weiteren Informationen bietet.
Mozilla arbeitet derzeit an einer neuen Oberfläche, welche einen Mittelweg für Funktionen bietet, die sich noch in Entwicklung befinden. Über einen neuen Reiter in den Einstellungen lassen sich darüber ausgewählte Funktionen vorab aktivieren.
Derzeit, da sich die Oberfläche selbst noch in Entwicklung befindet, muss in der Nightly-Version von Firefox über about:config der Schalter browser.preferences.experimental auf true gesetzt werden. Anschließend steht der neue Reiter in den Firefox-Einstellungen zur Verfügung.
Derzeit werden hierüber drei experimentelle Funktionen angeboten, welche sich alle im Bereich Webstandards einordnen lassen:
AVIF: AVIF steht für AV1 Image File Format und ist ein Bildformat, welches auf dem neuen Video-Codec AV1 basiert und ebenfalls von AOMedia, denen auch Mozilla angehört, spezifiziert worden ist. Ähnlich wie AV1 bei Videos verspricht auch AVIF bei Bildern bei gleichbleibender Qualität deutlich geringere Dateigrößen als konkurrierende Formate wie JPG oder WebP.
CSS Masonry Layout: Bei einem sogenannten Masonry Grid handelt es sich um eine bestimmte Anordnung von Elementen, wie man es beispielsweise von Pinterest kennt. Durch Aktivierung dieser Option werden CSS Grids um eine experimentelle Unterstützung für derartige Layouts erweitert.
WebGPU:WebGPU ist eine experimentelle Grafikschnittstelle für das Web, welche langfristig WebGL ablösen soll und anders als WebGL nicht auf OpenGL basiert und durch dessen Einschränkungen limitiert ist, sondern auf den modernen Grafikschnitttstellen Vulkan, Direct3D12 und Metal aufbaut.
Wenn die Frage nach einer längerfristig unterstützten Linuxdistribution auftaucht, wird oft auch Opensuse als Möglichkeit genannt. Doch das scheint kein guter Rat zu sein.
Softwareverwaltung von Opensuse Leap
Fluch und Segen an Linux auf dem Desktop ist die Qual der Wahl, sowohl bei Desktopoberflächen als auch bei den Distributionen selbst. Die Auswahl macht manchmal Kopfschmerzen, aber es ist auch reizvoll, aus unterschiedlichen Konzepten wählen zu können, die allein schon deshalb viel passgenauer auf die eigenen Anforderungen zugeschnitten werden können.
Wie schnell man trotzdem in eine Sackgasse laufen kann, obwohl man sich im Vorfeld ausgiebig informiert, zeigt die Erfahrung mit Opensuse. Als Opensuse Leap 15.0 herauskam, dachte ich: Gibst du der Sache mal eine Chance. Und installierte auf einem Rechner einmal nicht Ubuntu LTS, Debian Stable oder ein Mageia, sondern eben das neue Leap. Denn bei Opensuse fährt man seit einiger Zeit zweigleisig: „Opensuse Leap“ ist die klassisch herausgegebene Variante der Distribution mit berechenbaren Supportzeiträumen, während „Opensuse Tumbleweed“ ständig neue Funktionen erhält.
Eigentlich zwei Geschwindigkeiten zur Wahl
Das klang alles richtig gut: Während Tumbleweed die Rolling-Release-Fraktion bedient, wird mit Leap die konservative Nutzerschaft angesprochen. Für Leap 15 waren mindestens 36 Monate Unterstützung in den Raum gestellt. Drei Jahre Sicherheitsaktualisierungen, das ist nicht ganz so lange wie bei Ubuntu LTS, aber ausreichend viel, vor allem im Vergleich zu Fedora. Also fast schon Langzeitsupport.
Schließlich kommt es selten vor, dass beim Aufsetzen eines Rechners zufällig auch die gewünschte Distribution gerade taufrisch erschienen ist. Ein paar Monate Spielraum sollte es daher im klassischen Installationsmuster schon geben. Wer will schon eine „noch aktuelle“ Version installieren, die nach 6 Monaten schon wieder eingestellt wird? Das kann einem natürlich auch bei einer 3-Jahres-Distribution passieren, wenn man zum Ende der Produktlebensdauer installiert, doch ein bisschen zeitlicher Puffer ist nie verkehrt.
3 Jahre Ruhe haben, das war der Plan
Vor allem aber war es von Anfang an verheißene längere Unterstützung durch das Projekt selbst – zuvor hatte es mehrmals mit dem zusätzlichen „Evergreen“-Projekt Versuche gegeben, Langzeit-Support quasi „nachzurüsten“. Also Leap 15 installieren, und dann 3 Jahre Ruhe haben. So war der Plan. Pustekuchen. Als bei der grünen Distribution Ende vergangenen Jahres plötzlich die Updates ausblieben, dachte ich schon, dass irgendetwas kaputt gegangen wäre oder dass ich versehentlich etwas verkonfiguriert hätte. „Kaputt“ war aber tatsächlich nur das Release.
Denn sang- und klanglos war das Produktende bereits erreicht worden. Nach knapp 18 Monaten. Die angekündigte Produktlebensdauer hatte man also mal eben halbiert, statt 3 Jahre gab es letztlich nur anderthalb Jahre Aktualisierungen. Mit anderen Worten: Damit wäre auch Fedora keine schlechtere Wahl gewesen.
3 Jahre Versorgung mit Sicherheitsupates waren angekündigt
Noch schlimmer: Die Nachfolgeversion 15.1, auf die Anfang Dezember 2019 aktualisiert werden musste, erreicht nicht mal mehr die Lebensdauer von einem Jahr: Schon im kommenden November müsste auch hier wieder auf 15.2 gewechselt werden. Damit wird sogar das als zu flott geltende Fedora unterboten, bei dem man maximal ca. 13 Monate Freude haben kann, bevor die Folgeversion installiert sein muss. Gerade da es doch neben Leap auch noch Tumbleweed gibt, das stets aktuell ist, ist das rasche Ende der Leap-Versionen Leap-Hauptversionen nur schwer verständlich.
Fatales Signal
Für die langzeitinteressierte Nutzerschaft hätte man bei Opensuse kein fataleres Signal senden können. Selbst wenn Opensuse nun noch einmal Quasi-Langzeitsupport bei Version 16 ankündigen würde – darauf zählen würde ich nicht mehr. Das Vertrauen ist dahin, was verlässliche Zeiträume betrifft. Da wird dann eher tatsächlich Ubuntu wieder interessant.
Denn dieses hat inzwischen in diesem Punkt ein Alleinstellungsmerkmal. Ubuntu ist eine der wenigen desktopzentrierten Distributionen, die echte Langzeitunterstützung bieten und bei denen man nicht alle paar Monate zum Upgrade gezwungen ist. Abseits von Debian und Abkömmlingen bleibt es somit schwierig, wenn man nicht gleich zu Unternehmenslösungen greifen möchte, aber ein wartungsarmes System bevorzugt.
Bei Red Hat Insights handelt es sich um eine SaaS-Anwendung, welche Nutzern von RHEL-Subskriptionen kostenlos zur Verfügung steht.
Dieser Artikel bietet eine kurze Einführung in Red Hat Insights, zeigt, wie RHEL-Systeme in den Cloud-Dienst eingebunden werden und führt wichtige Dokumente und Quellen zum Dienst auf.
Hinweis: Ich teste den Dienst im Rahmen meiner beruflichen Tätigkeit im Bielefelder IT-Service Zentrum (BITS) der Universität Bielefeld.Dieser Artikel spiegelt meine persönliche Ansicht zu Red Hat Insights wider. Des Weiteren weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community bin (siehe „Zu meiner Person“).
Was ist Red Hat Insights?
Red Hat Insights, im folgenden Text auch kurz Insights genannt, ist ein von der Firma Red Hat angebotener Cloud-Service, welcher der proaktiven Analyse von Umgebungen mit Red Hat Enterprise Linux (RHEL) dient. Als Ergebnis dieser proaktiven Analyse erhält der Systemadministrator Hinweise auf vorhandene Konfigurationsprobleme, Sicherheitslücken und Schwachstellen sowie Handlungsempfehlungen, wie diese behoben werden können.
An Insights angebundene Systeme werden vom lokal installierten Insights-Client gescannt und gegen ein Regelwerk abgeglichen, um potenzielle Risiken in Bezug auf die System-Leistung, Skalierbarkeit, Verfügbarkeit und Sicherheit zu identifizieren und zu melden. Red Hat ist dabei bestrebt, die Sammlung persönlicher Daten zu vermeiden.
Neben dem Reporting können über diesen Service auch Ansible-Playbooks zur Mitigation erkannter Probleme generiert und von einer on-premise vorhandenen Ansible Engine ausgeführt werden. Das Regelwerk wird von der Firma Red Hat gepflegt und stetig erweitert.
Seit 2019 ist Insights in allen aktiven RHEL-Subskriptionen enthalten. Somit entstehen keine zusätzlichen Kosten durch die Nutzung des Dienstes. Insights kann in RHEL-Installation verwendet werden, unabhängig davon, ob diese on-premise, in privaten oder öffentlichen Clouds betrieben werden.
Die Produktdokumentation und eine FAQ-Sektion finden sich unter den folgenden URLs:
Wer noch keine Zugangsdaten für die vorstehend verlinkten Seiten besitzt, kann sich für eine kostenlose Red Hat Developer Subscription registrieren. Mit dieser erhält man auch Zugriff zur Red Hat Wissensdatenbank.
Ob Red Hat Insights den Mehrwert bietet, den es verspricht, versuche ich gerade in einem zeitlich und vom Umfang her begrenzten Test herauszufinden. Mit den folgenden Schritten könnt ihr euch auch selbst ein Bild davon machen.
Datenschutz und Datensicherheit
Für uns ist die Nutzung eines SaaS-Dienstes wie Insights nicht ganz unproblematisch. Wer die vorstehend verlinkte Dokumentation liest, wird schnell feststellen, dass zur Erbringung des Dienstes jeder angebundene Host eine Menge Daten sammelt und an den Cloud-Dienst überträgt. Dies ist einerseits erforderlich, damit der Service funktioniert. Denn ohne zu analysierende Daten kann es keine Hinweise und Empfehlungen geben. Anderseits kann man anhand der übertragenen Daten eine ziemlich genaue Karte der Netzwerkinfrastruktur zeichnen.
Insights selbst wird auf OpenShift Dedicated in AWS (US East) gehostet. Aktuell gibt es keinerlei Pläne, den Dienst in weiteren Regionen zu hosten.
Der insights-client bietet mit den Optionen --no-upload bzw. --offline die Möglichkeit, Daten lokal zu sammeln, ohne diese an den Cloud-Dienst zu übertragen. Als Sysadmin hat man so die Möglichkeit, im Vorfeld zu inspizieren, welche Daten gesammelt wurden. Dazu gibt es die Möglichkeit, eine Blacklist zu pflegen und zu spezifizieren, welche Daten von der Sammlung und Übertragung auszuschließen sind.
Die folgende Datei beinhaltet eine Baumansicht der Dateien und Informationen, die ein insights-client auf einem System mit installiertem MediaWiki gesammelt hat. Darunter befinden sich z.B. diverse Konfigurationsdateien und mit Hilfe verschiedener Kommandos gesammelte Informationen.
Stellt man sich den Betrieb von 100 RHEL-Servern vor, welche verschiedenste Dienste erbringen, wird jedoch deutlich, dass eine manuelle Kontrolle und Pflege individueller Blacklists für alle Systeme nicht leistbar ist. Zumal sich das Regelwerk, welches die zu sammelnden Daten bestimmt, dynamisch ändert und eine Prüfung vor jedem Upload erfolgen müsste.
Leider existiert Stand heute keine on-premise Appliance, welche die Nutzung des Dienstes innerhalb des eigenen Perimeters ermöglichen würde. Auch eine Whitelist für den insights-client existiert (noch) nicht. Letzteres würde dem Nutzer noch mehr Kontrolle über die Daten-Sammlung/-Übertragung geben. So könnte er einmal definieren, was übertragen werden darf und müsste nicht fürchten, dass bereits einige Tage später weitere Daten ohne sein Wissen gesammelt und übertragen werden.
Sowohl den Wunsch nach einer on-premise Appliance, als auch den Vorschlag zur Einführung einer Whitelist, habe ich dem Insights-Team gemeldet. Die Meldung wurde nach meinem Empfinden konstruktiv aufgenommen. Und auch wenn mein größter Wunsch nach der Appliance kurz- und mittelfristig nicht realisiert werden wird, fühle ich mich als Nutzer ernst genommen und habe das Gefühl, dass mein Feedback willkommen ist.
Red Hat beschreibt in oben verlinkter Dokumentation, dass der Dienst keine persönlichen Daten sammelt. So sind /etc/{passwd,group,shadow} sowie /home nicht in den gesammelten Daten enthalten. Auch werden keine vollständigen Logdateien an den Dienst übertragen. Generell legt Red Hat sehr viele Informationen über den Dienst offen und handelt hier sehr transparent. Das Unternehmen verhält sich in dieser Hinsicht vorbildlich.
Wenn ein Client keine Daten mehr übermittelt, werden die zuletzt von ihm empfangenen Daten nach 14 Tagen automatisch gelöscht. Wird ein Client aus Insights entfernt, werden die für diesen Client gespeicherten Daten ebenfalls gelöscht.
Nichtsdestotrotz verliert man die Gewalt über einmal übertragene Daten. Man muss dem Anbieter wie bei jedem SaaS-Dienst vertrauen, dass er sich an die eigenen Zusicherungen und Versprechen hält.
Möchtet ihr Insights in eurer Dienststelle oder eurem Betrieb testen, rate ich euch deshalb, sprecht zuerst mit der/dem Informationssicherheitsbeauftragten und Datenschutzbeauftragten und eurer/eurem Vorgesetzten über das Thema.
Trotz aller Bedenken bietet Insights die Chance, Kenntnis über Probleme und Schwachstellen zu erlangen, die bisher unbekannt sind und ein größeres Sicherheitsrisiko darstellen als die regelmäßige Datenübertragung an Insights. Ob der Nutzen überwiegt, muss allerdings jede Organisation für sich selbst beurteilen.
Einrichtung von Red Hat Insights auf Red Hat Enterprise Linux
Die folgenden Schritte setzen voraus, dass die verwendeten RHEL-Systeme registriert sind und über eine gültige Subskription verfügen.
Manuelle Einrichtung
Um den vollen Funktionsumfang von Insights nutzen zu können, werden die folgenden Pakete installiert:
Die Installation des OpenSCAP-Scanners und des SCAP-Security-Guides sind optional. Diese Pakete sind erforderlich, um den Compliance Service nutzen zu können. Da der insights-client in RHEL 8 bereits integriert ist, muss dieser hier nicht gesondert installiert werden.
Um die Einrichtung des insights-client abzuschließen und gesammelte Daten an den SaaS-Dienst zu übertragen, genügt es, das folgende Kommando auszuführen:
$ sudo insights-client --register
Automatisierte Einrichtung mit Ansible
Um die notwendigen Schritte zur Einrichtung nicht auf jedem Host manuell ausführen zu müssen, kann folgendes Ansible-Playbook verwendet werden.
---
- hosts: rh-insights-poc # Gruppe aus dem Ansible-Inventory
tasks:
- name: Make sure required packages are present
yum:
name:
- openscap-scanner
- scap-security-guide
- insights-client
state: latest
- name: Register insights-client
command: insights-client --register
Für meine Zwecke reicht obiges Playbook. Alternativ gibt es auf Ansible Galaxy eine Rolle mit deutlich größerem Funktionsumfang: redhatinsights.insights-client
Sind die Systeme eingerichtet und registriert, ist es an der Zeit, sich unter der URL https://cloud.redhat.com einzuloggen und das Insights Dashboard zu erkunden.
Startseite unter https://cloud.redhat.com
An dieser Stelle lasse ich euch vorerst mit dem Dashboard allein. Im nächsten Artikel dieser kleinen Reihe werde ich mich mit dem Inisghts Advisor befassen.
LTS Distributionen sind für mich das Maß der Dinge. Lange Produktlaufzeiten, wenig Wartungsaufwand und hohe Funktions- und Laufzeitstabilität sind nicht nur im Servereinsatz wichtig. Trotz hunderter Distributionen gibt es nur wenige LTS-Varianten (siehe: Linux - Eine sichere Basis). Mit CentOS steht hier ein weiteres Projekt vor dem Ausfall.
Natürlich sind Arch, Manjaro, Tumbleweed und wie sie alle heißen tolle Projekte und für den individuellen Desktopeinsatz gut geeignet. Ich glaube auch gerne, dass viele nie oder nur extrem selten Probleme bei Updates haben. Sie taugen aber kaum für den wartungsarmen Masseneinsatz, wo der Anwender nicht selbst die Administration übernehmen kann oder will.
Es braucht diese ständigen Updates eigentlich auch nicht. Linux auf dem Desktop ist im Wartungsmodus (siehe auch: Kein Ubuntu 20.04 Test). Ob ich nun GNOME Shell 3.32 oder 3.28 verwende macht weder funktional, noch von der Stabilität einen Unterschied. Das gleiche gilt für Plasma, LibreOffice und viele weitere Projekte. Relevant sind über eine lange Laufzeit lediglich neue Treiber für neue Hardware (entweder über massive Kernel-Modifikation durch den Distributor oder neue Kernel-Versionen) und neue Browser-Versionen.
Ich habe deshalb - sofern der Anwender mit GNOME klar kam - CentOS auch für den Desktop immer gemocht. 10 Jahre Ruhe am System sind einfach eine Hausnummer. Im Serverbereich dürfte CentOS neben Ubuntu LTS und Debian ebenfalls für viele eine maßgebliche Rolle spielen.
Wie Michael Kofler in seinem Blog aber zu recht thematisiert fällt CentOS 8 inzwischen für den Produktiveinsatz eigentlich aus. 71 und 48 Tage ohne Updates sind indiskutabel. Das Projekt scheint hier leider auch nicht willens oder fähig etwas zu ändern.
Im LTS Bereich wird es jetzt eng. Die sehr lange Supportdauern von 10 Jahren bietet nun nur noch SLED gegen eine - preislich allerdings vollkommen akzeptable - Subscription. Wer mit circa 3-5 Jahren leben kann hat noch Debian, openSUSE Leap und Ubuntu LTS zur Auswahl. Viel ist das nicht mehr. Gegebenenfalls muss man sich wirklich mit Oracle Linux beschäftigen, auch wenn sich dabei alle Nackenhaare aufstellen.
Google und Apple sind spätestens seit dem Erscheinen von Android 2008 Konkurrenten. In einem Punkt hat sich Google aber scheinbar ein Beispiel an Apple genommen: Wie man ein freies System so mit proprietären Bestandteilen zersetzt, dass der Open Source Charakter ins Absurde verkehrt wird. Dadurch profitiert man von freien Projekte ohne zurückgeben zu müssen.
Apples macOS ist nämlich auch so ein Zwitter. Es basiert im Kern auf Darwin und dieses steht unter APSL. Eine von deer OSI und FSF anerkannten freien Lizenz. Obwohl Darwin Open Source ist, kann man damit nichts machen. Apple gibt den Quellcode frei, allerdings fehlen das interne Build System, es ist schlecht dokumentiert und versuche der Gemeinschaft mit OpenDarwin oder PureDarwin einen freien und funktionierenden Abkömmling zu bauen scheiterten. Dessen ungeachtet gibt es natürlich einige Projekte von Apple (oder durch Apple aufgekauft), die weiterhin Open Source sind und der Commmunity zur Verfügung stehen. CUPS wäre hier ein Beispiel, WebKit mit Abstrichen ebenfalls.
Man kann sich des Eindrucks nicht erwehren, dass Google mit Android etwas ähnliches vorhat. Android wird zunehmend unfreier (siehe: Android wird unfreier - Alternativen nicht in Sicht). Jetzt hat man seitens Google auch entschieden die Schnittstelle für die Corona App in die proprietären Play Services einzubauen, weshalb freie Android-Varianten außen vor bleiben - obwohl die RKI-App an sich Open Source ist. Die proprietären Bestandteile nehmen immer größere und grundlegendere Ausmaße an und AOSP wird immer mehr zum Kernsystem herabgedrückt. Der Weg zum Status von Darwin ist da nicht mehr weit.
Meist heißt es, die Probleme Updates an die Anwender zu verteilen wären die Ursache für die Verteilung aller möglichen Sachen via Play Store. Aber Google bemüht sich ja auch nicht sonderlich die katastrophale Update-Situation in den Griff zu bekommen. Stattdessen verlagert man immer mehr in die Play Services und den Play Store und unterminiert die Funktionsfähigkeit der freien Instanz. Man kann sich des Eindrucks nicht erwehren, dass Google sich hier bequem in der Update-Situation eingerichtet hat und nicht traurig über die Zwangsverlagerung in den Play Store ist.
Wie wenig Bedeutung Open Source für Google noch hat zeigt die Lizenzfrage um die Billing Library 3, die entgegen der ersten beiden Versionen Closed Source ist. Entwickler müssen dann Klimmzüge machen, wenn sie ihre Projekte sowohl via F-Droid, als auch kostenpflichtig via Play Store verteilen möchte. Eine bisher nicht unübliche Vorgehensweise.
Kritik wird aus der Open Source Gemeinschaft trotzdem nicht zu laut kommen. Schließlich hat Google mit Förderungen wie den GSoC, den Verträgen mit Mozilla und Sachen wie Project Zero viele Projekte in eine monetäre Abhängigkeit von Google gebracht.
Nutzer freier AOSP Systeme müssen deshalb auf die Corona App verzichten.
Das Standalone-VPN des Firefox Private Networks wird in Kürze die Betaphase verlassen und damit offiziell Mozillas Produkt-Portfolio erweitern – dann unter neuem Namen: Mozilla VPN.
Mit dem Firefox Private Network hat Mozilla Ende des vergangenen Jahres die Beta-Phase seines eigenen VPN-Angebots gestartet. Wie Mozilla heute angekündigt hat, wird das Standalone-VPN in den nächsten Wochen die Betaphase verlassen und damit offiziell einen Platz in Mozillas Produkt-Portfolio einnehmen.
Standalone-VPN: Mozilla VPN
Mit dem Start der finalen Version wird das Standalone-VPN, für welches Mozilla mit dem schwedischen VPN-Anbieter Mullvad zusammenarbeitet, von der Firefox-Marke losgelöst und dann als Mozilla VPN vermarktet werden, um so eine größere Zielgruppe anzusprechen und sich klarer von der bisher gleichnamigen Firefox-Erweiterung zu unterscheiden.
Den aktuellen Preis von 4,99 Dollar pro Monat wird Mozilla für eine begrenzte Zeit beibehalten. Damit können bis zu fünf Geräte gesichert werden. Wie viel das VPN danach kosten wird, steht zu diesem Zeitpunkt noch nicht fest, genauso wie noch nicht bekannt ist, wann das VPN auch hierzulande zur Verfügung stehen wird. Mozilla möchte in diesem Jahr noch in mehreren ausgewählten Regionen starten, natürlich beginnend mit den USA, wo bereits der Beta-Test läuft.
Das Mozilla VPN steht für Windows, Google Android, Google Chromebooks sowie Apple iOS zur Verfügung, Versionen für Apple macOS sowie Linux sollen folgen.
Firefox-Erweiterung: Firefox Private Network
Auch bezüglich Mozillas Firefox Private Network Browser-Erweiterung, für welche Mozilla mit Cloudflare zusammenarbeitet, gibt es Neuigkeiten. Hier wird man in Kürze von der kostenlosen in die kostenpflichtige Betaphase übergehen, welche den Nutzer 2,99 Dollar pro Monat kosten wird. Statt wie bisher nur auf einem können Nutzer dann mit einem Account auf bis zu drei Geräten gleichzeitig mit dem VPN verbunden sein. Auch die Erweiterung ist zunächst nur in den USA verfügbar und soll bald auch in weiteren Märkten ausgerollt werden.
Ausbau des Produkt-Portfolios
Mit dem Mozilla VPN und dem Firefox Private Network erweitert Mozilla sein Produkt-Portfolio rund um das Thema Privatsphäre und Sicherheit und schafft damit gleichzeitig eine zusätzliche Einnahmequelle, um so unabhängiger von den Einnahmen durch Suchmaschinen-Partner zu werden. Neben dem Einzel-Abonnement für das Firefox Private Network erwägt Mozilla für die Zukunft auch das Anbieten eines Privatsphäre- und Sicherheits-Paketes für Firefox, welches die VPN-Erweiterung mit weiteren Angeboten bündelt.
Da eingebaute optische Laufwerke im Jahr 2020 immer seltener werden, musste ich heute einen externen CD/DVD-Brenner benutzen, um eine Audio-CD zu brennen. Leider brach Brasero immer noch vor dem Schreibversuch ab.
BraseroWodim stderr: wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
BraseroWodim called brasero_job_get_flags
BraseroWodim stdout: TOC Type: 0 = CD-DA
BraseroWodim stderr: wodim: Resource temporarily unavailable. Cannot get mmap for 16781312 Bytes on /dev/zero.
BraseroWodim called brasero_job_get_flags
BraseroWodim stderr: HUP
BraseroWodim stdout: HUP
BraseroWodim process finished with status 11
BraseroWodim called brasero_job_error
BraseroWodim finished with an error
BraseroWodim asked to stop because of an error
error = 0
message = "no message"
Wenn man sich die Kommentare in Newsmedien, Foren und auf anderen Diskussionsplattformen zu den neuen Software-Paketen Snaps und Flatpaks (und AppImages) anschaut ist es ein wirkliches Trauerspiel. Die öffentlich sichtbare Community verweigert sich so offenkundig, dass schon bloßes zusehen schmerzt. Dabei wollen die Formate ein real existierendes Problem lösen.
Mit Snaps und Flatpaks habe ich mich hier schon ein paar Mal befasst. Grundsätzlich sehe ich den Ansatz durchaus positiv. Um mich nicht selbst zu wiederholen hier die Links:
Natürlich haben die neuen Formate Probleme. Sicherheitslücken in enthaltenen Bibliotheken, Ressourcenverbrauch, Updateverwaltung, zentrale proprietäre Bestandteile etc. pp. Dabei handelt es sich teilweise um Kinderkrankheiten, aber teilweise auch um strukturelle Beschränkungen durch das Konzept. Es gibt deshalb Einsatzszenarien, wo sie einfach keinen Sinn machen. Der gesamte Bereich "Server" gehört dazu. Andere Probleme müssen durch sinnvolle Weiterentwicklung gelöst werden.
Die Gegner der neuen Formate ignorieren aber vollständig, dass Snaps und Flatpaks zwei real existierende Probleme lösen wollen:
1. Verschränkung des Systems
Die klassische Linux-Paketverwaltung hat ein prinzipielles Problem in der Anwendungsverwaltung. Das Paketmanagement verschränkt Kernel, grundlegendes Betriebssystem, grundlegende Werkzeuge, Desktop und grafische Endanwender-Anwedungen. Man kann letzteres nicht sinnvoll aktualisieren ohne die anderen Bestandteile anzufassen.
Die meisten BSD-Varianten haben das Problem schon vor Jahrzehnten mittels der Trennung von Basissystem und Anwendungen (Ports) gelöst. Die Linux-Community hat stattdessen die Paketverwaltung auf einen Sockel gestellt und genau das gemacht, was sie eigentlich ablehnt: Hässliche Workarounds für strukturelle Probleme geschaffen. Nichts anderes ist z. B. der Trend zur Rolling Release Distribution oder die PPA/OBS/Backports der verschiedenen Distributionen. Anwender wollen aktuelle Anwendungen und bekommen stattdessen ein Betriebssystem, das vom Kernel bis zur letzten Bibliothek ständig auf den letzten Stand gebracht wird oder müssen unsichere Drittquellen einbinden.
2. Software-Distribution
Linux Software kommt nicht direkt vom Entwickler zum Anwender (wie meist bei Windows) und auch nicht über einen zentralen Store (wie bei macOS, iOS, Android), sondern über die Distribution. Ein und dieselbe Software muss daher für jede Distribution und jede unterstützte Version einer Distribution gebaut werden. Das war schon immer arbeitsintensiv aber angesichts einer hohen zweistelligen Zahl an verbreiteten Distributionen, plus jeweils mehrere unterstützte Versionen ist das völlig ausgeufert. Distributions-Entwickler haben deshalb wahre Raketentechnik entworfen, wenn es darum geht diese Prozesse zu automatisieren. Trotzdem ist das noch viel Handarbeit und steht inzwischen einem eklatanten Missverhältnis zum Nutzen. Distributionen fungieren zudem immer häufiger als Flaschenhals bei der Softwareverteilung.
Wer also Snaps oder Flatpaks rundweg ablehnt sollte alternative Vorschläge machen, die diese beiden Probleme adressieren. Es sei denn natürlich man ist der Meinung Linux sei perfekt und ausentwickelt.
Die Synology DiskStation lässt sich mittels zusätzlicher Pakete in einen vollwertigen E-Mail Server verwandeln. Angesichts der Bedrohungen und Herausforderungen beim selbstständigen Betrieb eines Mailservers ist das eigentlich kein ratsames Unterfangen. Wohl lassen sich damit aber sehr einfach E-Mails archivieren.
Ich bin ein bekennender E-Mail Messie. Ich lösche grundsätzlich keine E-Mails. Abgesehen lediglich von solchen, die meine Mailprogramme in Spam absortieren oder automatisierte Benachrichtigungen, die nach dem lesen sofort in den Mülleimer wandeln. Alles andere behalte ich bis zum Sankt-Nimmerleins-Tag. Der Hintergrund ist nicht, dass ich ein unordentlicher Mensch wäre, sondern schlicht und einfach Effizienz. Ich habe irgendwann gemerkt wie viel Zeit die Entscheidung ob man eine Mail behalten soll, das rekursive Aufräumen der E-Mail die man irgendwann mal behalten hat etc. pp. kostet. Da ist es viel effektiver einfach alles zu behalten. Aufgaben markiere ich mit farbigen Fähnchen und ggf. Erinnerungen. Wenn ich irgendwas suche, bietet jedes moderne Mailprogramm eine integrierte Suchfunktion. Das hat mich schon das ein oder andere Mal gerettet, wenn andere beteiligte Kommunikationspartner sich partout nicht an einen E-Mail Vorgang erinnern wollten konnten. Zum Jahreswechsel lege ich in einem Archivordner Jahresarchive für Postein- und -ausgang an.
Leider ist nach vielen Jahren und zig tausenden E-Mails die Datenmenge gewaltig und externe Hoster bieten oft nicht unendlich viele GB. Daneben kommt noch der Datenschutz zum tragen. Will man wirklich die Kommunikation von vielen Jahren einem externen Dienstleister anvertrauen?
Man könnte nun natürlich einfach ein lokales Postfach mit dem Mailprogramm der eigenen Präferenz anlegen und die E-Mail dort rein verschieben. Dann macht man sich allerdings sehr von diesem Mailprogramm abhängig und externer Zugriff ist nicht möglich. Wenn man sehr viel unterwegs ist, keine so gute Idee.
Eine andere Möglichkeit bietet da ein Synology NAS. Mittels weniger Handgriffe kann man hier einen lokalen Mailserver in den eigenen vier Wänden aufsetzen, der per IMAP (oder wahlweise auch POP3 für die Dinosaurier unter uns) von jedem Gerät angesteuert werden kann.
Synology Mail Server einrichten
Sucht man im Paket-Zentrum nach "mail" finden sich mehrere Pakete. Relevant ist hier der Synology Mail Server. Die Mail Station bietet lediglich einen Webmail-Client (Roundcube) um auf die E-Mails zuzugreifen. Für den hier thematisierten Anwendungsfall spieltg das keine Rolle. Die Installation geht wie immer schnell und unkompliziert. Zusätzlich wird als Abhängigkeit noch Perl nach installiert, sofern man das nicht eh schon nutzt.
Synology Mail Server basiert - wie so oft bei Synology - auf bewährter Open Source Software wie Dovecot, Postfix, SpamAssassin & Co. Hier kommen also keine unausgereiften Eigenentwicklungen zum Einsatz.
Anschließend kann über den Launcher die Einstellungsoberfläche für den Mail Server gestartet werden. Hier erscheint zuerst eine Warnung über die TLS-Sicherheitsstufe. Diese ist standardmäßig hoch eingestellt, was wohl mit einigen veralteten Clients Probleme machen kann. Im Test mit Apple Mail hatte ich keine Probleme. Wer Schwierigkeiten hat muss in den Systemeinstellungen unter Sicherheit die TSL-/ SSL-Profilebene anpassen.
In den Einstellungen aktiviert man nun den lokalen Nutzer in SMTP.
Hierdurch kann der normale Synology Account genutzt werden. Der Rest ist irrelevant, da für die Funktion als Archiv kein SMTP benötigt wird.
Relevanter sind die Einstellungen für POP3/IMAP.
Wie bereits gesagt, halte ich POP3 für ein vollkommen überholtes Protokoll, das in der Gegenwart angesichts zahlloser Endgeräte keinerlei Daseinsberechtigung für normale Anwender mehr hat. Lediglich für Spezialfälle, wenn man Postfächer wirklich abholen und leeren möchte macht das noch Sinn.
Für die Funktion als Mailarchiv brauchen wir nur IMAP. Dadurch liegen die Mails auf dem NAS gespeichert und die Endgeräte greifen per IMAP auf dieses zu. Offline-Zugriff bietet inzwischen jeder ernst zu nehmende Mailclient und ist bei einem Archiv auch tendenziell nachrangig.
Sofern man lediglich innerhalb des eigenen Netzes (oder per VPN) auf das Mailarchiv zugreifen möchte kann man nur IMAP aktivieren. Bei Zugriff von außerhalb sollte man unbedingt IMAP SSL/TLS aktivieren um eine verschlüsselte Verbindung zu nutzen. Man kann ggf. dann auch nur IMAP SSL/TLS aktivieren.
Der Mailserver ist nun grundsätzlich einsatzbereit. Sofern ein externer Zugriff ohne VPN angestrebt wird, muss zusätzlich noch Port 993 (TCP) über eine Portfreigabe an das Synology NAS weiter geleitet werden.
Konfiguration im Mail Programm
Jedes IMAP-fähige E-Mail Programm kann nun mit dem NAS verbunden werden. Folgende Informationen sind hier relevant:
Name: Beliebig
E-Mail Adresse: Beliebig (z. B. archiv@NAS-NAME)
Account: Name des Synology Benutzers
Passwort: PW des Synology Benutzers
IMAP / SMTP Server: Interne IP oder DynDNS-Name
Letzteres hängt davon ab, ob ein interner oder externer Zugriff angestebt wird.
Das Postfach ist beim ersten Start komplett leer. Der einzige Ordner bei mir in Apple Mail war der Posteingang. Via Rechtsklick auf diesen und "Neues Postfach" habe ich anschließend den Ordner "Archiv" angelegt. Mittels Apple Mail habe ich dann das komplett bisherige E-Mail Archiv auf das NAS transferiert. Je nach Netzgeschwindigkeit und Postfachgröße sollte man dafür ordentlich Zeit einplanen.
Tipps & Tricks
Speicherort / Backup
Die E-Mails liegen anschließend im Home-Ordner des Synology Benutzers unter .Maildir. Diesen sollte man also unbedingt in das Backup mit aufnehmen. Backup? Ja richtig gelesen! Nur weil ein NAS mehrere Festplatten hat und die Daten je nach Setup spiegelt ersetzt das kein Backup!
Standby
Der Mail Server verhindert den Standby-Vorgang des NAS. Der Umstand ist bekannt und eigentlich auch logisch, weil ein Mailserver immer erreichbar sein sollte. Wenn man das NAS normalerweise in den Standby laufen lässt und - wie hier im Artikel - den Mailserver lediglich als E-Mail Archiv nutzt, kann man mit Mail Relaxer das Problem umgehen. Dabei handelt es sich um eine Paar Skripte, die blockierende Prozesse beenden, wenn der letzte Client die Verbindung beendet hat. Das macht vor allem Sinn wenn man das E-Mail Archiv nicht auch vom Smartphone ansteuert. Das ist schließlich nahezu immer angeschaltet.
Der Mail Relaxer kann über das Paket-Zentrum und die Schaltfläche Manuelle Installation installiert werden.
Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.
In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.
Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.
Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:
Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.
Abb. 1: Screenshot der Red Hat CVE-Datenbank für CVE-2020-0543
Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).
Abb. 2: Red Hat CVE-Datenbank liefert nicht zu jeder CVE-Nummer einen Treffer
Nutzung des Paket-Managers auf der Kommandozeile
Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:
$ sudo yum updateinfo list --cve CVE-2020-0543
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$
Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.
Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:
$ sudo yum updateinfo info --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
===============================================================================
Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
Update ID : RHSA-2020:2432
Release : 0
Type : security
Status : final
Issued : 2020-06-09 18:20:28 UTC
Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
: 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
: 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
CVEs : CVE-2020-0543
: CVE-2020-0548
: CVE-2020-0549
Description : Security Fix(es):
:
: * hw: Special Register Buffer Data Sampling
: (SRBDS) (CVE-2020-0543)
:
: * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
:
: * hw: Vector Register Data Sampling
: (CVE-2020-0548)
:
: For more details about the security issue(s),
: including the impact, a CVSS score,
: acknowledgments, and other related information,
: refer to the CVE page(s) listed in the References
: section.
:
: Bug Fix(es):
:
: * Update Intel CPU microcode to microcode-20200602
: release, addresses:
: - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
: microcode from revision 0x61f up to 0x621;
[...]
CVE durch Update schließen
Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:
$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
--> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
--> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
--> mock-2.3-1.el7.noarch from epel removed (updateinfo)
--> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================================================
Updating:
microcode_ctl x86_64 2:2.1-61.6.el7_8 rhel-7-server-rpms 2.6 M
Transaction Summary
==============================================================================================================================================================
Upgrade 1 Package
Total size: 2.6 M
Is this ok [y/d/N]:
Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.
