Ich spiele zur Zeit mit einem MariaDB-Cluster herum der mit Galera läuft. Bisher bin ich damit auch sehr zufrieden. Ein Malheur, was mir allerdings gerade zu Beginn passiert ist, ist dass man am besten nicht alle Server auf einmal herunterfährt. In diesem Fall kommt der Cluster nämlich nach einem Neustart von selbst nicht mehr hoch.
Dies liegt daran, dass die jeweilige Node im Cluster, die im wsrep_cluster_address aufgeführten weiteren Nodes versucht zu erreichen, da allerdings auf keiner MariaDB gestartet ist, schlägt dieser Versuch fehl. In diesem Moment hat man den Cluster quasi zerstört. Ein Neustart des Galera Clusters ist aber, wenn man erst mal weiß wie, recht trivial.
Lasst euch auf allen Nodes die grastate.dat ausgeben. Diese beinhaltet den aktuellen Stand der jeweiligen Node:
Dies sieht z.B. bei mir so aus. Die Node mit der höchsten seqno ist am weitesten und somit auf dem neuesten Stand. Dort wird nun ein einfaches galera_recovery ausgeführt. Dadurch sollte safe_to_bootstrap auf 1 springen.
Nun reicht ein einfaches galera_new_cluster. Anders als der Befehl vermuten lässt, erstellt der Befehl in diesem Sinn keinen neuen Cluster, sondern erkennt die Daten des vorhandenen Clusters und startet mit diesen einen neuen.
Anschließend lassen sich ganz normal per systemctl start mariadb die vorhanden Nodes wie gewohnt starten.
Früher konnte man mit Firefox einen halben Desktop nachbauen, heute ist das Addon-System recht beschnitten. Das empfinde ich nicht als Nachteil, weil ich das nie exzessiv genutzt habe. Die meisten meiner Addons dienen dem Schutz meiner Privatsphäre.
Grundlegend ist natürlich ein Mehrbrowser-Konzept bzw. die Einbeziehung anderer Programme. Ich mache gar nicht so viel im Browser. Banking erledigt Moneyplex, Mails, Kalender etc. alles dezidierte Programme. Was übrig bleibt, landet entweder im Tor-Browser oder in Firefox. Einen dritten Browser nutze ich nicht, da meine Identität bei meinen Aktivitäten entweder offen liegt (wie z.B. hier) oder eben nicht. Also Firefox oder Tor.
Die wichtigsten Addons dafür habe ich hier zusammen gestellt und halte diese Seite auch immer leidlich aktuell. Im Kern sind das folgende Addons:
Manche nutzen noch weitere Addons wie Skip Redirect oder Neat URL aber bei mir verursachen die im Alltag zu viele Probleme.
Soweit so unspektakulär – mit einer kleinen Ausnahme. Im letzten Sommer hatte ich bereits zur Diskussion gestellt, ob die dauerhafte Cookie-Löschung (nach Session-Ende oder sogar per Intervall während der Session) noch eine sinnvolle Maßnahme ist.
Der Hintergrund ist relativ einfach. Viele seriöse deutschsprachige Seiten setzen ihre DSGVO-Pflichten inzwischen leidlich gut um. Konfiguriert man also beim ersten Besuch die Cookie-Abfrage gründlich, dann kommen nur wenige Tracking-Mechanismen zum Einsatz. Diese Mühe macht man sich natürlich nicht, wenn am Ende jeder Session die Präferenzen wieder aus Firefox gelöscht werden. In dem Fall verfolgt man eher das Prinzip „I don’t care about Cookies„.
Aus diesem Grund habe ich mich von der permanente Cookie-Löschung verabschiedet.
Stattdessen setze ich auf die integrierten Mechanismen zur First-Party-Isolation (entweder in about:config oder via Addon) und kombiniere dies mit den Addons Firefox Multi Account Containers und Temporary Containers. Shopping oder soziale Netze sind in eigene Containergruppen ausgelagert (und dort via First-Party-Isolation natürlich auch voneinander getrennt) und neue Seiten öffne ich über den automatischen Modus immer in einem Temporary Container, dessen Spuren 15 Minuten nach Schließen gelöscht wird.
Ob ich damit Tracking besser entgehe als mit permanenter Cookie-Löschung, weiß ich nicht – es ist aber allemal angenehmer so zu surfen.
Mit Firefox 87 setzt Mozilla einen häufigen Nutzerwunsch um: Die Hervorhebung aller Suchtreffer dort, wo sich die Scroll-Leiste befindet.
Mozilla hat ein neues Feature in Firefox 87 implementiert, welches sich einige Nutzer gewünscht hatten: Die Hervorhebung aller Treffer der Suchfunktion in der Scroll-Leiste. Voraussetzung dafür ist, dass die Schaltfläche zur Hervorhebung aller Suchtreffer aktiv ist.
Die Farbe der Highlights ist dabei die gleiche Farbe wie bei der Hervorhebung der Suchbegriffe selbst. Diese kann angepasst werden, indem über about:config ein neuer String-Schalter mit dem Namen ui.textHighlightBackground angelegt wird und als Inhalt den gewünschten CSS-Farbcode erhält. Allerdings ist es bereits geplant, hierfür noch eine separate Einstellung zu implementieren, so dass beides unabhängig voneinander konfiguriert werden kann.
Android ist im Kern ein Linux, aber darüber liegen viele Schichten Google. Wenn man auf Google-Dienste weitestgehend verzichtet, ist die Integration von Android in ein Linux-Ökosystem auf den simplen Dateiaustausch beschränkt. Mit KDE Connect kann man dies ändern.
Ich hatte KDE Connect schon an vielen Stellen beiläufig erwähnt, aber nie eigens thematisiert. Dabei ist KDE Connect nicht nur wahnsinnig praktisch, sondern kann ein Gewinn für digitale Privatsphäre bedeuten.
Das mag jetzt nicht unbedingt naheliegend sein. Viele Google Dienste, aber auch viele andere Cloud-Angebote basieren auf der Bequemlichkeit der Anwender. Natürlich gibt es auch sinnvolle Einsatzszenarien, ich nutze ja selbst eine Cloud, aber oft wandern Daten in Cloud, die dort eigentlich nicht hin müssen. Bevor man Smartphone und Laptop per Kabel verbindet, lädt man doch lieber ein paar Bilder und Dateien zum Cloud-Dienstleister hoch und dann auf dem Notebook wieder herunter. Das Gleiche mit Chromecast und anderen Diensten.
KDE Connect schließt diese Lücke und vereinfacht die Interaktion zwischen Linux-Desktop und Android-Smartphone drastisch.
Installation & Einrichtung
Die Installation und Einrichtung ist denkbar einfach. KDE Connect befindet sich bei allen relevanten Distributionen in den Paketquellen. KDE-Anwender können direkt KDE Connect installieren, GNOME-Nutzer können zum vollwertigen Ersatz GSConnect greifen.
Beide Varianten arbeiten mit der gleichen Android-App zusammen, die sowohl via F-Droid als auch via Play Store installiert werden kann. Zusätzlich existieren Varianten für Sailfish OS und Plasma Mobile, die ich hier allerdings nicht getestet habe.
Sollte das Linux-System über eine Firewall verfügen (was nicht verkehrt ist) müssen zusätzlich Ports freigegeben werden.
Fedora und openSUSE haben für KDE Connect vorgefertigte Profile für firewalld, die sich über die jeweiligen Konfigurationslösungen aktivieren lassen.
Befinden sich beide im gleichen WLAN, zeigt KDE Connect beim ersten Start das Notebook als verfügbares Gerät an. Theoretisch lässt sich die Verbindung aber auch via Linux-Desktop initialisieren.
Klickt man auf das Gerät, kommt der Button für „Kopplung anfordern“ erscheint auf dem Desktop eine Benachrichtigung.
Über die View Key Schaltfläche kann man den kompletten Key anzeigen und mit der Anzeige auf dem Smartphone vergleichen.
Die Android App erfragt nach der Koppelung zahlreiche Freigaben. Das liegt an den vielen Funktionen und da KDE Connect freie Software ist, kann man genug Vertrauen in die App aufbringen. Sollte man jetzt bereits wissen, dass man einige Funktionen nicht benötigt, kann man hier die Freigabe auch unterlassen.
Funktionen
KDE Connect bietet zahlreiche Module an, die einzeln an- und abgeschaltet werden können. Auf eine vollständige Auflistung verzichte ich hier und möchte stattdessen die zentralen Punkte zeigen.
KDE Connect erhält ein Symbol im Systemabschnitt der Kontrollleiste. Klickt man darauf, zeigt es den Akkustand an und ermöglicht das Smartphone anzuklingeln, das Dateisystem in Dolphin zu öffnen und die SMS auf dem Smartphone aufzurufen.
Vor allem die Integration in Dolphin ist sehr praktisch. SMS-Nachrichten nutze ich kaum noch, weshalb die Funktion eher nebensächlich ist.
Sehr praktisch ist auch die Trennung von Benachrichtigungen und Anrufen. Ich möchte auf dem Desktop nicht für jede Benachrichtigung eine Meldung erhalten und habe das Modul deshalb deaktiviert. Über eingehende Anrufe möchte ich dennoch informiert werden. Das Smartphone liegt schließlich manchmal in einem anderen Raum oder ist lautlos geschaltet.
Sehr gut funktioniert die geteilte Zwischenablage. Ich kann Texte auf dem Desktop markieren und im Smartphone in z. B. eine Messenger-Nachricht einfügen und umgekehrt.
Nette Spielereien sind die entfernte Mediensteuerung in beide Richtungen. Das ist vor allem praktisch, da Podcasts unter Linux nicht synchronisiert werden können und ich hier immer über das Smartphone hören muss.
Fazit
Mit KDE Connect erreicht die Integration der beiden Systeme fast das gleiche Niveau wie iPhone und macOS. Nur ohne proprietären Hersteller und Cloud-Bindung. Es gehört zu den wenigen Bereichen, wo ich unter Linux keine Komfortfunktionen vermisse und funktioniert auch nahezu fehlerfrei. Es ist einer der Hauptgründe; weshalb man direkt KDE Plasma oder GNOME nutzen sollte und keine der kleineren Alternativen.
Für mich ist einer der großen Vorteile, die OPen-Source-Projekte mitscihbringen, dass man zumindest uneingeschränkt die Möglichkeit hat, sich zu beteiligen.
Auch wenn es nur ein (sehr geringer) Bruchteil der Personen, die die Möglichkeit dazu haben, wahrnimmt, finde ich allein die Möglichkeit, dass man ohne viel Bürokratie helfen kann toll.Zwie wichtige Möglichkeiten wie man sich an solchen Projekten beteiligen kann sind:
Bugs melden. Viele Fehler sehen die Programmierer selber nicht und müssen erst darauf hingewiesen werden. Das kann enorm hilfreich sein und ist deshalb - auch wenn es banal klingt - ein großer Beitrag. Bugtracker findet man oft direkt beim Code-Repository des Projektes.
Übersetzungen beitragen. Die meisten Programme werden standardmäßig mit englischer Oberfläche ausgeliefert (und ggf. der Sprache des Programmierers) und können oft lokalisiert, also in andere Sprachen übersetzt werden. Die fördert zum einen die Verbreitung der Software und zum Anderen übt man dadurch selber seine eigenen Fremdsprachenkenntnisse.
Wenn man nicht weiß, ob und wie man sich in einem Projekt einbringen kann, hilft es oft, den Maintainer zu kontaktieren.Ich wüßte keinen, der sich über die Anfrage nach Mitarbeit beklagen würde. Dasselbe gilt auch für geschlossen entwickelte Projekte (wie z.B. bei Inyoka - so habe ich das bei Inyoka auch gemach gehabt), auch hier hilft oft eine nette Nachricht an einen Entwickler ob man helfen darf.
Passwörter sind ein gescheitertes Konzept. Nur leider haben wir immer noch kein Besseres für den flächendeckenden Einsatz. Die sogenannte Zwei-Faktor-Authentifizierung via SMS oder TOTP soll hier mehr Sicherheit bringen. Eine weitere Möglichkeit ist ein Security Key wie der YubiKey. Damit lassen sich auch verschlüsselte Volumes sichern.
Das eigentlich gute Berechtigungskonzept von Linux hat in den letzten Jahren gelitten. Komfort fordert seinen Preis. Viele Distributionen verzichten auf einen dezidierten root-Zugang und andere wie z.B. openSUSE empfehlen dem Nutzer, das root-Kennwort identisch mit dem des primäres Benutzers zu setzen. Viele nehmen dann gleich noch aus Bequemlichkeit dieses Kennwort für die LUKS Systemverschlüsselung.
Wenn wir mal ganz ehrlich sind, dann nutzen wir zudem doch eher triviale Kennwörter. Ein wirklich sicheres Kennwort mit ~30 Zeichen inklusive Groß-/Kleinschreibung, Zahlen und Sonderzeichen ohne erkennbares System – wer möchte das schon bei jedem Systemstart und jeder Administratorrechte-Abfrage eingeben. Die meisten Anwender machen hier also ein paar Abstriche und nehmen das, was sie für gerade noch vertretbar halten. Aus diesem Dilemma kann einen YubiKey befreien.
YubiKey für LUKS Volumes
Die Änderung der Authentifizierung für das System kann im schlimmsten Fall zur Aussperrung aus dem System und zu Datenverlust führen. Bitte daher ein aktuelles Backup anlegen und ggf. einen Rettungsstick vorbereitet haben.
Vorbemerkungen
Aller Nivellierung zum trotz gibt es zwischen den Distributionen noch immer erhebliche Unterschiede in der Art, wie sie Verschlüsselung konkret beim Systemstart einbinden. Es gibt deshalb nicht die eine Softwarelösung, die mit Anpassungen auf allen Distributionen läuft. Vielleicht ändert sich das mit den neuen Funktionen für systemd, die Lennart Poettering vor Kurzem bekannt gab. Allerdings bleibt abzuwarten, welche Distributionen dies kurz- oder mittelfristig wirklich nutzen.
Zum aktuellen Zeitpunkt gibt es funktionierende Implementierungen für Debian (und damit auch für alle Derivate inklusive Ubuntu) und Arch Linux. Die Debian-Lösung ist dabei von der Arch-Lösung inspiriert. Für openSUSE, Fedora, Red Hat & Co konnte ich zum aktuellen Zeitpunkt keine Lösungen ermitteln.
Ich persönlich fand die Debian-Lösung schlecht dokumentiert und konnte sie nicht erfolgreich umsetzen. Deshalb möchte ich das hier am Beispiel von Arch Linux demonstrieren, weil das hier verhältnismäßig einfach einzurichten ist und die Dokumentation wirklich gut ist.
Voraussetzung für die Einrichtung ist eine existierende Vollverschlüsselung mittels LUKS.
Installation & Konfiguration
YubiKey vorbereiten
Zur Einrichtung benötigt man das YubiKey-Personalisierungstool und das Paket yubikey-full-disk-encryption (im folgenden abgekürzt als ykfde)
Anschließend bereitet man den YubiKey entsprechend vor. Normalerweise nutzt man Slot 2, weil Slot 1 für die OTP-Challenge genutzt wird. Sollte das bei euch anders sein, könnt ihr das auch anpassen.
Die Einrichtung ist dann eigentlich sehr einfach. Die zentrale Konfigurationsdatei ist /etc/ykfde.conf. Hier gibt es eine hervorragende Inline-Dokumentation.
ykfde unterstützt zwei Modi für die Authentifizierung (genaueres über das Verfahren beim Entwickler nachzulesen):
Automatische Anmeldung mit gespeicherter Challenge: Ihr hinterlegt in der Konfigurationsdatei ein Passwort. Die Entsperrung erfolgt über die Antwort des YubiKey auf diese gespeicherte Challenge und den Secret Key des Tokens.
Manueller Modus mit geheimer Challenge: Ihr müsst jedes Mal das Kenntwort eingeben (deshalb geheim) und zusätzlich wird der Secret Key des Tokens benötigt.
Die erste Lösung ist bequem, bedeutet aber, dass jeder im Besitz des YubiKeys befindliche Mensch das System entsperren kann. Die zweite Lösung ist dafür extrem sicher. Es entsteht ein extrem langer Key, der sich nicht mit einem Brute Force Angriff knacken lässt, weil er Wissen und Besitz kombiniert.
Grundsätzlich empfehle ich die zweite Methode, aber es kann durchaus Anwendungsfälle geben, in denen die erste Methode ausreicht oder sogar sinnvoll ist. Deshalb ist es schön, dass beide Möglichkeiten existieren.
In der ykfde.conf Datei müssen je nachdem welche Variante man nutzen will, eine der beiden entsprechenden Zeilen aktiviert werden, indem man die Auskommentierung mittels # entfernt und ggf. die notwendigen Informationen hinterlegt. Solltet ihr oben nicht Slot 2 gewählt haben, könnt ihr hier auch einen anderen Slot einstellen.
### *REQUIRED* ###
# Set to non-empty value to use 'Automatic mode with stored challenge (1FA)'.
#YKFDE_CHALLENGE=""
# Use 'Manual mode with secret challenge (2FA)'.
#YKFDE_CHALLENGE_PASSWORD_NEEDED="1"
# YubiKey slot configured for 'HMAC-SHA1 Challenge-Response' mode.
# Possible values are "1" or "2". Defaults to "2".
#YKFDE_CHALLENGE_SLOT="2"
Bei dieser Konfiguration gehe ich davon aus, dass ihr euer LUKS Device mittels cryptdevice=UUID Bootparameter einbindet. Leicht nachzuprüfen in der GRUB oder systemd-boot Konfiguration. Solltet ihr das nicht machen, müsst ihr ggf. weitere Anpassungen vornehmen. Das konnte ich aber nicht austesten.
Exkurs: LUKS Keyslots
Bevor wir weitermachen, ist ein kleiner Exkurs zu LUKS Keyslots notwendig. LUKS Volumes können bis zu 8 unterschiedliche Kennwörter zur Entsperrung vorhalten. Normalerweise sollte man mindestens das primäre Kennwort (meist Slot 0) und einen Wiederherstellungsschlüssel konfigurieren. Wie es dem jeweiligen Volume aussieht kann man mit folgendem Befehl prüfen:
# cryptsetup luksDump /dev/nvme0n1p3
Im vorliegenden Beispiel sieht das dann wie folgt aus:
LUKS header information for /dev/nvme0n1p3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 87 51 d5 12 69 a7 4e 5d 6a 56 b3 f6 5e 6b 5d ef 21 81 d6 ce
MK salt: b9 9f 9e bf 34 da ba 5f 33 10 f5 e3 c2 7b 1f 33
9e f4 6d 1c e6 cd bc 8b 48 ad 34 56 98 79 cd ce
MK iterations: 126517
UUID: 3c4624a7-2e5b-4aa3-a7b8-76e4d8dc0aa8
Key Slot 0: ENABLED
Iterations: 2024276
Salt: 22 5c b6 24 c5 47 e2 71 23 dd 57 3a d3 4a 58 9a
94 28 f9 be 41 b7 5d 28 b1 5c e2 bf 84 4a 39 a6
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED
Iterations: 2312184
Salt: da 50 7a a7 76 96 3b 50 35 be aa dd e8 29 a8 ff
f6 6f a5 c2 67 31 22 c7 ba a2 09 61 1f 3b 1a 23
Key material offset: 3536
AF stripes: 4000
Man sieht den primären Schlüssel in Slot 0, der bei der Installation des Systems angelegt wurde und den Wiederherstellungsschlüssel in Slot 7. Alle anderen Slots stehen noch zur Verfügung. Hier können wir nun einen mit der YubiKey-Lösung belegen.
YubiKey in LUKS hinterlegen
Nun rollt man den Schlüssel aus. Die entsprechende Partitionsnummer ist ebenso anzupassen wie der gewünschte Slot.
Dabei wird ein bereits existierendes Kennwort abgefragt. Dies kann entweder das bisherige Primärkennwort oder irgendein anderes wie z.B. der Wiederherstellungsschlüssel sein.
Danach kann man mit dem luksDump Befehl prüfen ob das erfolgreich geschehen ist.
ykfde in den Arch Bootprozess einbinden
ykfde ist eigentlich „nur“ ein angepasster encrypt hook. Dadurch ist die Integration in den Bootprozess denkbar simpel und auch überhaupt nicht fehleranfällig. Erst wenn Arch hier Grundlegendes was ändert, kommen wir damit in die Bredouille. In der Konfigurationsdatei /etc/mkinitcpio.confhinterlegt man den ykfde hook. Die Zeile sollte dann erst mal wie folgt aussehen (Abweichungen je nach System natürlich möglich):
Eigentlich braucht man nicht ykfde und encrypt. Aber wenn bei den bisherigen Schritten irgendwas schief gegangen ist, hat man mit dem normalen encrypt hook erst mal noch ein Sicherungsnetz.
Danach noch mkinitcpio aktualisieren:
# mkinitcpio -p linux
Danach kommt ein Neustart und der Moment der Wahrheit. Nach dem Start sollte nun eine veränderte Abfrage kommen. Ihr habt 30 Sekunden (lässt sich aber auch anpassen) Zeit. den YubiKey einzustecken und ggf. eure Passphrase einzugeben. Je nachdem für welche Variante ihr auch oben entschieden habt. Nach Ablauf der Zeit kann man das LUKS Volume auch mit einem der anderen hinterlegten Keys entsperren.
Hat alles geklappt könnt ihr den encrypt hook aus der mkinitcpio.conf entfernen.
Im Alltagsbetrieb
Genau die Möglichkeit, nach 30 Sekunden einen anderen Key einzugeben, ist Fluch und Segen zugleich. Einerseits ist das eine essenzielle Möglichkeit das System bei Verlust, kurzfristiger Nicht-Verfügbarkeit oder Beschädigung des Keys zu entsperren. Andererseits besteht diese Möglichkeit halt immer. Das System ist daher nur so sicher wie eure übrigen Passphrasen. Ich empfehle deshalb nur den sogenannten Wiederherstellungsschlüssel zusätzlich zu Hinterlegen und andere ggf. vorhandene einfachere Passwörter zu entfernen.
Der YubiKey muss im laufenden Betrieb nicht permanent eingesteckt sein. Nach einem normalen Standby ist er ebenfalls nicht notwendig. Für Suspend lässt sich der YubiKey laut Entwicklerseite konfigurieren, aber diesen Modus nutze ich nicht und habe es deshalb nicht getestet.
Dies bedeutet im Klartext: Der YubiKey schützt als Sicherungsmethode das System nur im ausgeschalteten Zustand. Exzessive Nutzer des Standby-Modus hängen von den Sicherungsmechanismen ihrer Desktopumgebung ab (und die sind teilweise schlecht). Also lieber ab und an das System mal komplett herunterfahren, wenn ihr es einen längeren Zeitraum nicht benötigt.
Ebenso sollte man den YubiKey natürlich nicht neben dem Gerät liegen lassen.
Passwörter sind ein gescheitertes Konzept. Nur leider haben wir immer noch kein Besseres für den flächendeckenden Einsatz. Die sogenannte Zwei-Faktor-Authentifizierung via SMS oder TOTP soll hier mehr Sicherheit bringen. Eine weitere Möglichkeit ist ein Security Key wie der YubiKey.
Authentifizierung basiert immer auf dem gleichen Prinzip: Du verfügst über einen Faktor, über den andere nicht verfügen. Bei herkömmlichen Passwörtern ist es das Wissen. Nur du kennst (idealerweise) dein Kennwort. Schon die Zwei-Faktor-Authentifizierung mittels SMS und TOTP setzt hier an, indem ein zusätzlicher Faktor hinzugefügt wird. Zum Wissen kommt noch der Besitz des Gerätes für den zweiten Faktor – meist das Smartphone.
Der Sicherheitsgewinn ist hier zweifellos gegenüber einem normalen Kennwort gegeben. Nur sind Smartphones selbst Geräte mit Schwachstellen und Problemen. Die SMS ist sowieso ein hochgradig unsicherer Übertragungsweg. Kurzum: 2FA via SMS oder TOTP ist auch nicht perfekt. Schon gar nicht, wenn man Passwörter und TOTP in der gleichen Passwortdatenbank speichert.
An diesem Punkt setzen Security Keys an. Vereinfacht gesagt ist es ein ähnliches Prinzip wie bei der SmartCard, die viele vielleicht von ihren Dienstgeräten kennen. Du benötigst zur Authentifizierung einen zweiten Faktor, der sich in deinem Besitz befinden muss und der selbst kein anfälliges Gerät ist (wie eben das Smartphone).
Daneben verfügen moderne Security Keys über vielfältige Möglichkeiten der Code-Generierung. Thomas Leister hat das in einem Blogbeitrag vor Jahren so umfangreich dargestellt, dass ich mir die Mühe hier sparen möchte.
Es gibt ein paar wenige Anbieter für solche Sicherheitsschlüssel. Neben YubiKey wäre hier noch NitroKey zu nennen. Für NitroKey spricht der Firmensitz in Deutschland und die vollkommen offen gelegte Hardware. Ich habe mich dennoch für einen YubiKey entschieden, weil dieser weiter verbreitet ist und sich damit ein paar Sachen (leichter) umsetzen lassen, die ich so vorhabe. YubiKey bietet zudem Sticks mit USB-C, während NitroKey nur herkömmliches USB-unterstützt. Das ist dann eine Frage der vorhandenen Hardware.
Konkret habe ich mich für den YubiKey 5C NFC entschieden. NFC ist dabei eher in die Zukunft gedacht, falls ich vorhabe, den Key mit dem Smartphone zu nutzen.
Smartwatches und Fitnesstracker sind wahrlich kein neues Phänomen. Ein großes Problem ist der schwierige Datenschutz. Es geht schließlich um besonders sensible Gesundheitsdaten.
Die Pandemie und die dadurch bedingten Veränderungen haben aber auch hier Folgen. Ich war jetzt nie sportlich total aktiv, aber der Fahrtweg mit dem Fahrrad und ein Arbeitsumfeld, in dem Face-to-Face Gespräche höher bewertet waren als Telefonanrufe, sorgten für ordentlich Bewegung und viele Stockwerke am Tag.
Jetzt sitzt man im Homeoffice und bewegt sich gefühlt an manchen Tagen keine 1000 Schritte. Hier wollte ich mal wissen, ob es wirklich so schlimm ist, wie es sich anfühlt.
Bei der Recherche bin ich auf Gadgetbridge gestoßen. Dabei handelt es sich um eine Open Source-App für Android, die sich über den freien F-Droid Store beziehen lässt. Gadgetbridge unterstützt zahlreiche Geräte. Manche mit der Einschränkung, dass für die initiale Einrichtung ein Herstelleraccount notwendig ist.
Das wollte ich auf keinen Fall und weil es ja eher ein Experiment ist und ich nicht vorhabe, das Teil bis zum Exzess auszureizen, habe ich mich für ein Mi Band 3 entschieden. Das gibt es bereits für unter 15 € im Shop eures Vertrauens.
Einrichtung in Gadgetbridge
Die Einrichtung ist denkbar simpel. Uhr auspacken und aufladen, danach über das Plus-Symbol die Gerätesuche starten. Hierfür muss zumindest kurzfristig der Standort aktiviert werden. Die Suche und Verbindung hat schnell und kompliziert geklappt. Gadgetbridge listet das Mi Band 3 dann übersichtlich auf der Startseite.
Weniger übersichtlich ist die Detailkonfiguration, da sich die Einstellungen auf drei Einstellungsmenüs verteilen und man alles bis ins kleinste Detail steuern kann. Wie so oft ist das Fluch und Segen zugleich. Es gibt zum Glück eine ausführliche Anleitung.
Ich persönlich habe in den allgemeinen Einstellungen keine Haken bei Automatisch starten und Verbinde, wenn Bluetooth eingeschaltet ist gesetzt, weil ich das Mi Band ja nicht permanent im Einsatz haben möchte.
Weiter unten in den allgemeinen Einstellungen kann man die gerätespezifischen Einstellungen aufrufen. Hier lassen sich viele Feineinstellungen wie das tägliche Schrittziel und der Gerätename festlegen, aber auch Funktionen an- und abschalten.
Mit einem Klick auf das Zahnrad in der Mi Band Kachel auf der Startseite kommt man in die Einstellungen für das spezifische Gadget. Da geht es um so Details, ob man das Band links oder rechts trägt und weitere Spezifikationen.
Nicht immer ist für den Anwender ganz klar, welche Option sich warum und wo verbirgt. Zum Glück muss man hier nicht permanent nachjustieren, sondern kann nach der initialen Einrichtung die Optionen meist links liegen lassen.
Gadgetbridge im Alltag
Das Mi Band 3 ist ein preiswertes Einsteigergerät und hat dementsprechend kein eigenes GPS Modul. Wenn man also wert auf ein genaues Streckentracking legt, braucht man ein gekoppeltes Smartphone mit aktivierter Standorterkennung. Das muss jeder für sich entscheiden.
Als Schrittzähler funktioniert das Mi Band erstaunlich präzise und auch ohne aktive Koppelung. Aktivitätsdaten können per Tippen auf das Synchronisieren-Symbol manuell vom Band an Gadgetbridge übertragen werden.
Benachrichtigungen werden problemlos auf das Mi Band übertragen. Lediglich die Übertragung von Emojis klappt nicht. Die Bedienung ist anfangs ein wenig fummelig, aber man gewöhnt sich schnell ein.
Die Uhrzeit kann das Mi Band natürlich auch anzeigen, man kann also auf eine zusätzliche Armbanduhr verzichten. Wobei das Mi Band kaum als Modeaccessoire taugt.
Fazit
Als Experiment war es für mich ganz interessant und ich werde das Mi Band sicherlich selektiv mal nutzen, wenn mich die Tagesbilanz besonders interessiert. Die permanenten Benachrichtigungen bei aktiver Koppelung fand ich aber nervig. Hier müsste man vermutlich deutlich selektiver filtern, was durch gestellt werden soll. Außerdem habe ich persönlich keine Lust, bei noch einem Gerät darauf zu achten, dass es genug Akku hat. Meine analoge Armbanduhr ist da deutlich pflegeleichter.
Erst wurde der BER fertig und dann liefert Purism doch noch die ersten Librem Smartphones aus. Das Jahr 2020 war also doch nicht nur schlecht. Das Librem 5 erlebt dennoch eine Bruchlandung. Die Versprechen können nicht gehalten werden und agilere Projekte sind längst weiter.
Ich hatte die Entwicklung des Librem 5 hier im Blog immer interessiert, aber auch sehr skeptisch betrachtet:
Ich bekomme viel Kritik und kann damit sehr gut leben, aber abgesehen von meinen Artikelnzu Jolla hat mich nie so ein geballter Hass erreicht. Tenor: Wie könne ich nur den Heiligen Gral der Linux-Smartphone-Fanatiker so in den Dreck ziehen. Die Kommentare sind wegen des Softwarewechsels nicht mehr erhalten und das schlimmste kam sowieso per Mail, aber das waren die Momente, an denen ich wirklich überlegte, mit dem bloggen aufzuhören. Eines haben die Fanatiker allerdings erreicht: Meine Skepsis über das Projekt wuchs.
Nun liefert Purism endlich aus und Golem hat sich das Ganze mal genau angeschaut. Golem ist fair und würdigt ausgewogen die Leistung, so ein Gerät von null an zu entwerfen. Es hilft aber alles nichts, das Gerät ist vollkommen unbrauchbar. Nicht nur, dass es nicht funktioniert und Bugs an allen Ecken und Enden hat. Bei all der Privatsphäre hat man gleich laut Golem noch die Sicherheit vergessen. Keine Verschlüsselung, nur ein nummerischer PIN, abgeschottete Apps, Berechtigungskonzept – alles nicht vorhanden.
Purism hatte zum Erreichen seiner Crowdfunding-Kampagne hohe Erwartungen geweckt. Daran muss es sich messen lassen. Nicht für jedes Problem konnten die Entwickler etwas, aber es gab auch immer wieder politische Entscheidungen, wie beispielsweise einen Gutteil der Entwicklung in GNOME zu stecken, die bis dahin noch überhaupt nichts in Richtung mobile unternommen hatten.
Da ist mir ein Projekt wie das Pinephone, die nicht mit Weltenretter-Manier daher kommen, sondern ihr Projekt als Experiment klassifizieren, deutlich lieber. Aber das zieht vermutlich weniger Fanatiker an.
Purism hat ja schon wieder einen Haufen neuer Projekte in der Pipeline. Das Spiel geht weiter. Ob es aber noch mal ein Smartphone geben wird?
Mozilla hat Firefox 85.0.2 veröffentlicht und behebt damit Startschwierigkeiten, welche nach dem Update auf Firefox 85 bei manchen Nutzern aufgetreten waren.
Nach dem Update auf Firefox 85 berichteten einige Nutzer, dass Firefox nicht mehr gestartet werden konnte und stattdessen eingefroren war („Keine Rückmeldung“). Mozilla hat in Form von Firefox 85.0.2 reagiert und behebt das Problem mit dieser Version.
$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 10800
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout
10800
Die 10800 sind 3 Stunden (60*60*3)
Nun tauchen auch die 3 Stunden in der Auswahl auf und bleiben auch dort, wenn man mal einen anderen Wert auswählt.
Wenn man den richtigen Suchbegriff hat, kann man übrigens mit dem dconf-editor (apt install dconf-editor) auch ein grafisches Tool bemühen, welches einem das Auffinden der richtigen Stelle erleichtert.
Den dconf-editor hatte ich früher schon mal verwendet, es aber wieder vergessen. Vielleicht hilft mir mein Artikel später mal weiter, bei ähnlichen Problemen.
Die MZLA Technologies Corporation hat mit Thunderbird 78.7.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 78.7.1
Mit Thunderbird 78.7.1 unterstützen CardDAV-Adressbücher jetzt auch OAuth 2 und Google Contacts. Darüber hinaus gab es wieder ein paar kleinere Fehlerbehebungen. Eine vollständige Liste der Änderungen gibt es in den Release Notes (engl.).
Linux ist zwar schon lange kein Nischenprodukt mehr, aber das wollen augenscheinlich viele nicht wahr haben.
Linux ist für viele nicht existent, man kennt es halt nicht und die paar Menschen, denen ich begegne, die von Linux schon gehört haben, für die ist es oft keine Alternative. Es ist halt dieses “Geek-System” - wer soll damit schon vernünftig arbeiten? Die Erwartung ist, dass einfach viel zu viel sich unterscheidet von dem bisher genutzten System.
Ich war als ich das erste mal vor einem Linxu-System saß, begeistert.
Die Gründe, die Linux für mich zu einem perfekten System machen:
1. Für jeden Einsazzweck gibt es ein System
Linux per se ist enorm flexibel. Einzelne Distributionen bieten für alle die Möglichkeit das System zu haben, das man für sich selber braucht. Und selbst wenn es das System für einen aktuell nicht gibt, kann man es selber erstellen.
2. Flexibilität
Eigentlich schon mit dem ersten Punkt angesprochen. Es ist recht egal ob ich einen dick auftragenden Blink-Blink-Desktop haben möchte, einen simplen Fenstermanager oder gar keine grafische Oberfläche. Mit Linux ist alles möglich.
3. Es gibt immer eine Wahl
Wenn eine Anwendung nicht zustimmt, kann man sich eigentlich immer sicher sein, dass es eine Alternative gibt. Das selbe gilt auch bei Distributionen - hier gibt es auch immer eine Alternative.
4. Linux ist cool!
Ich kann meinen Desktop so anpassen, wie ich es will. Das bietet in diesem Umfang keines der beiden großen amerikanischen Betriebssysteme. Man kann damit angeben, was man aus einem simplen System gemacht hat und wie toll das jetzt aussieht. Auch die Arbeit in der Konsole hat finde ich etwas. ;)
5. Kostenlos
Auch wenn Geiz nicht gut ist, hapert es doch oft am Geld. Wieso sollte man also mehr als 100€ für ein Betriebssystem ausgeben, wenn man Linux-Distributionen kostenlos bekommen kann.
6. Quelloffen
Die wenigsten Anwender werden jemals den gesamten Quellcode studieren und dann entscheiden, inwiefern man ein Programm benutzt. Aber die Möglichkeit allein gibt einem ein gutes Gefühl. Gleichzeitig erleichtert dies oftmals auch die Mitarbeit an Softwareprojekten.
7. Hilfe!
Für mich ist die doch riesige Community rund um einzelne Linux-Distributionen einfach faszinierend. Man findet zu fast keinem Problem nicht schon irgendwo eine Lösung. Wenn es diese wider Erwarten doch noch nicht gibt, findet man in einem der vielen Foren sicher eine Lösung. Alternativ sind oft auch die Entwickler nicht weit.
Wenn man dann etwas mehr Erfahrung gesammelt hat, kann man wie ich auch anderen Nutzern bei ihren Problemen helfen.
Wenn du wert auf Datenschutz und digitale Privatsphäre legst, nimmst du am besten freie Betriebssysteme. Diesen Rat liest man so an zig Stellen im Internet. Doch stimmt das wirklich so vorbehaltlos? Die Antwort lautet: Kommt darauf an.
Worauf kommt es an? Auf deine Schutzziele! Die meisten Ratgeber suggerieren, dass du alle Fliegen mit einer Klappe schlagen kannst. Schnüffelnde US-Konzerne, übergriffige staatliche Organe, bösartige Hacker und neugierige Chefs oder Familienmitglieder. Das ist natürlich Unsinn!
Datenabfluss verhindern
Wann sind freie Systeme und transparente Open Source Software besonders gut geeignet? Dann, wenn es um die Schattenseiten des modernen Datenkapitalismus geht. Die Systeme aller großen IT-Konzerne von Windows über macOS bis zu den Mobilsystemen iOS oder Android in seiner Google-Variante. Sie alle sind inzwischen technisch eng an Konten der Hersteller angebunden. Windows oder macOS ohne Herstellerkonten und ohne Datenübertragung auf Server der Hersteller zu betreiben ist heute quasi unmöglich. Man kann es mehr oder minder umgehen und den Datenabfluss teilweise beschränken, aber man entkommt dem Problem nie vollständig.
Möchte man also vor allem den Datenabfluss an große IT-Konzerne stoppen, dann sind freie Systeme wie eine Linux-Distribution oder ein Custom ROM Android unumgänglich. Nur diese Systeme bieten dir die Freiheit, große Bestandteile der Software auszutauschen und solche Konten gar nicht zu nutzen. Wobei dies natürlich kein Automatismus ist. Auch Linux lässt sich mit Google-Diensten oder Microsoft-Diensten dicht pflastern und auch Linux hat in seiner Standardkonfiguration problematische Bestandteile. NTP-Zeitserver, Telemetrie-Daten, automatische Softwareaktualisierungen. Ein bisschen Hand anlegen muss man auch hier.
Daten vor unberechtigtem Zugriff schützen
Wenn es aber um Sicherheit im Sinne eines rigorosen Schutzes der gespeicherten Daten geht, dann sind freie Systeme gar nicht unbedingt die beste Wahl. Das Problem besteht hier einfach in dem unauflösbaren Widerspruch von Freiheit und Schutz. Nehmen wir als Gegenbeispiel das absolute Gegenteil von Freiheit: Vollkommen unzugängliche Apple-Systeme wie iOS und zunehmend macOS. Ein iPhone, das ich auf der Straße finde und das mit einem halbwegs sicheren PIN geschützt ist, bleibt mir (und auch den meisten staatlichen Stellen) ein Buch mit sieben Siegeln. Ich kann es nicht auslesen und wenn ich Pech habe, löscht es sich nach 10 Fehlversuchen selbst oder der Besitzer löscht es aus der Ferne. Ähnlich sicher sind moderne macOS Systeme mit T2 Sicherheitschip.
Ein mit LUKS verschlüsseltes Linux ist hier noch halbwegs sicher (wann gab es da eigentlich mal ein Audit?) aber auch hier bleibt die Community hinter ihren Möglichkeiten. Weil man vielen Firmware-Lösungen misstraut, sind Sachen wie TPM unter Linux kaum verbreitet und werden von vielen Distributionen nicht oder nur schlecht unterstützt. Das gilt ebenso für Secure Boot, das mittels Shim ad absurum geführt wurde.
Aber erst Android mit Custom ROM ist der eigentliche Albtraum. Solche Geräte sind das beste Beispiel für den Widerspruch Sicherheit ungleich Sicherheit. Zur Zeit gibt es keine bessere Möglichkeit, digitale Privatsphäre mit digitaler Teilhabe zu verbinden, als ein Android Smartphone mit Custom ROM ohne jegliche Google-Dienste zu nutzen. Aber wenn du das Telefon verlierst oder es beschlagnahmt wird, stehst du blöd da. Die Geräte haben naturgemäß einen entsperrten Bootloader, weshalb der neue Gerätebesitzer jederzeit ein anderes System flashen kann. SD-Karten verschlüsselt Android gar nicht und viele Custom ROMs deaktivieren auch die interne Verschlüsselung, um mehr Modding-Möglichkeiten zu erhalten und weil viele Custom Recovery-Systeme mit Verschlüsselung ein Problem haben. Ein Android mit Custom ROM ist also je nach Blickwinkel das sicherste oder unsicherste Gerät, das man besitzen kann.
Zusammengefasst
Es ist nahezu unmöglich, alle Schutzziele zu erreichen. Sowohl die Nutzer von freien Linux & Android Systemen können von sich behaupten, auf Sicherheit wert zu legen, wie die Besitzer von Apple-Hardware (nur Microsoft-Kunden sind doppelt gelackmeiert). Es kommt halt darauf an, welche Bedrohung man im Blick hat
Die Entwickler von GnuPG haben sich einen schweren Schnitzer erlaubt und fast vergessene Erinnerungen an OpenSSL und Heartbleed geweckt. Wieder mal zeigt sich, dass Open Source kein Garant für Sicherheit ist und die Entwicklung oftmals Offenheit vermissen lässt.
Die Auswirkungen des Fehlers waren nicht sonderlich groß. Durch das Distributionsmodell von Linux hatte die Version 1.9.0 nicht viele Anwender erreicht. Lediglich Anwender mit Arch Linux dürften in größerem Umfang betroffen gewesen sein.
Das Problem besteht eher in dem, was durch den Fehler wieder mal zu Tage gefördert wurde. Die Entwickler scheinen moderne Security-Praktiken komplett zu missachten und der Code insgesamt in einem nicht besonders guten Zustand zu sein. Die älteren Linux-Nutzer dürften sich an OpenSSL und den Heartbleed-Bug erinnert fühlen.
Der schlechte Zustand von GnuPG ist nun auch kein wirklich Geheimnis und es gibt sogar Alternativen. Thunderbird hat in seiner neuen Version, die eine integrierte GPG-Implementierung enthält, bewusst auf GnuPG verzichtet. Problematisch ist hier – wie so oft – die konservative Grundeinstellung vieler Linux-Projekte, die fast schon sklavisch an allem festhält, was GNU im Namen trägt.
Nun kann man sicherlich darüber streiten, ob die Fehlerdiskussion über den richtigen Kanal erfolgte, aber auch hier zeigt sich wieder ein grundlegendes Problem vieler Open Source Projekte. Man führt Offenheit im Namen, meint damit aber meist nur die freie Lesbarkeit des Codes. Viele Projekte werden nach Gutsherrenmanier geführt, nach dem Motto „meine Arbeit, meine Regeln“. Beteiligung wird erschwert oder ist oft sogar gänzlich unerwünscht. Die ständige Forkerei ist hier mehr Symptom eines Problems, denn eine segensreiche Eigenschaft von Open Source und wird nur von eingefleischten Fans verklärt. Es ist oft leichter, ein Projekt zu spalten, als sich mit den derzeitigen oder ehemaligen Hauptentwicklern ins Benehmen zu setzen. Die Liste der Beispiele ist hier endlos lang.
Ohne jemandem zu nahe treten zu wollen, liegt das sicher auch daran, dass Sozialkompetenz und IT-Affinität nicht unbedingt Hand in Hand gehen. Die Kommunikationskultur im Internet ist allgemein verroht, aber die Art und Weise, wie in freien Projekten diskutiert wird, setzt dem oft die Krone auf. Der Fisch stinkt auch hier vom Kopf.
Die Gesellschaft diskutiert momentan viel über „openness“. Open Source als Idee ist da sicherlich ein relevanter Bestandteil, die Entwicklercommunity eher nicht.
Mozilla hat Firefox 85.0.1 veröffentlicht und behebt damit mehrere Fehler und Sicherheitsprobleme der Vorgängerversion.
Mit dem Update auf Firefox 85.0.1 behebt Mozilla eine als kritisch eingestufte Sicherheitslücke in Googles Angle-Graphikbibliothek. Von der Sicherheitslücke betroffen sind ausschließlich Nutzer des Betriebssystems Windows. Außerdem wurde der Zugriff auf NTFS-Spezialpfade unterbunden.
Beim Drucken von Dokumenten konnte es unter bestimmten Umständen zu einer zusätzlichen leeren Seite am Ende kommen. Dieses Problem wurde behoben.
Behoben wurden auch mögliche Absturzursachen. Zum einen konnte es auf Geräten mit Apple Silicon SoC beim Authentifizieren auf Websites mittels SPNEGO zum Absturz kommen. Außerdem wurde ein möglicher Absturz bei einem unerwartetem Cache-API-Status behoben.
Bei Flatpak-Builds für Linux hatten externe URL-Handler nicht mehr funktioniert.
Auf der Seite about:config findet man in Firefox eine erweiterte Konfigurationsoberfläche, über welche zahlreiche Einstellungen vorgenommen werden können. Auch viele, für die es keine sichtbare Einstellung gibt. Ab Firefox 87 können auf Wunsch auch nur die Einstellungen angezeigt werden, welche von ihrem Vorgabewert abweichen.
Über about:config kann in Firefox eine Konfigurationsoberfläche erreicht werden, welche zahlreiche Einstellungen erlaubt – weit mehr Einstellungen, als es sichtbare Einstellungen gibt.
Achtung: Bei about:config handelt es sich um eine Experten-Oberfläche. Wer nicht weiß, was er tut, sollte besser die Finger davon lassen. Im Zweifel besser im Firefox-Forum nachfragen, bevor etwas verstellt wird, über dessen Auswirkungen man sich nicht sicher ist.
Seit Firefox 71 besitzt Mozillas Browser eine komplett neue Oberfläche für about:config. Was im Vergleich mit der alten Oberfläche fehlt, ist die Möglichkeit, nach dem Status der Zeilen zu sortieren. Die Sortierung selbst war dabei eher selten das eigentliche Ziel. Viel mehr wurde diese Möglichkeit gerne genutzt, um all jene Einstellungen zu finden, welche von ihrer Standard-Einstellung abweichen.
Mit Firefox 87 kommt Mozilla nun diesem häufiger genannten Wunsch nach. Eine neue Option erlaubt es, ausschließlich die Einstellungen anzuzeigen, welche von ihrem Vorgabewert abweichen.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
Seit WordPress 5.5 lassen sich Themes und Plugins automatisch aktualisieren. Ich selbst nutze die Funktion bei Themes und Plugins, wo ich mir sicher bin, dass ein unbeaufsichtigtes Update im Fehlerfall keinen größeren Schaden anrichten kann bzw. die sich auch in der Vergangenheit als sehr sicher und stabil erwiesen haben.
Was allerdings gerade, wenn man mehrere WordPress-Installationen verwaltet tierisch nervig ist, dass man bei Updates von Plugins oder Themes jedes Mal mit einer E-Mail benachrichtigt wird. Hier hätte ich mir ein zentrales Benachrichtigungs-System im Wordpress-Admin oder zumindest eine Option zum Deaktivieren der Mails im Admin-Bereich gewünscht.
Glücklicherweise gibt es zwei Filter für Theme- und Plugin-Updates, die die Benachrichtigungen deaktivieren:
Diese beiden Zeilen kommen am besten in die functions.php eines Child-Themes, so bleiben sie auch bei Updates eures aktiven Themes bestehen. Alternativ können diese aber auch per Plugin eingebunden werden. Ich persönlich versuche allerdings die Anzahl eingesetzter Plugins niedrig zu halten.
