wünsche ich allen! Natürlich wünsche ich allen, dass sie das bekommen, was sie sich gewünscht haben. Aber vor allem hoffe ich, dass alle Zeit mit den Menschen verbringen und genießen können, die ihnen am Herzen liegen.
Also macht euch ein paar schöne Tage!
Seit ein paar Jahren lasse ich meine Server von Uptimerobot.com überwachen. Kürzlich habe ich entdeckt, dass der Monitoring-Service mittlerweile auch öffentliche schaltbare Statusseiten anbietet. Daher habe ich meine selbst gebastelte Statusseite abgeschaltet und wollte stattdessen das schönere Angebot von Uptimerobot nutzen. Die Statusseiten sind über Adressen nach dem Schema stats.uptimerobot.com/<ID> erreichbar, also z.B. https://stats.uptimerobot.com/rk3R0IDJq. Die Adressen sind schlecht zu merken. Viel lieber hätte ich etwas einfacheres, wie z.B. status.trashserver.net. Deshalb kann man die Statusseite auch mit einer eigenen Domain betreiben, indem man im DNS-Record für die jeweilige Domain auf den Uptimerobot-Server verweist. Allerdings schließt das HTTPS aus, denn Uptimerobot müsste dann die Zertifikate für meine Domain besitzen. Aber auch dafür habe ich eine Lösung gefunden:
Was die Einstellungen bei Uptimerobot angeht, belasse ich alles beim alten. Damit die Benutzer nicht die lange URL mit der ID eingeben müssen, habe ich mittels Nginx einen Proxy-Server aufgesetzt, der Anfragen an status.trashserver.net direkt an https://stats.uptimerobot.com/rk3R0IDJq weiterleitet und das Ergebnis zurückliefert. Mit der folgenden Konfiguration kann man dann auch auf die Angabe der ID in der URL verzichten:
server {
server_name status.trashserver.net;
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/myssl/...;
ssl_certificate_key /etc/myssl/...;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://stats.uptimerobot.com/rk3R0IDJq/;
proxy_redirect off;
}
location ~ ^/(.+) {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://stats.uptimerobot.com;
proxy_redirect off;
}
}
Rust ist eine neue Programmiersprache, in welcher die ebenfalls sich in Entwicklung befindliche neue Rendering-Engine von Mozilla geschrieben wird, die auf den Namen Servo hört. Ab sofort steht Rust 1.14 bereit.
Für die neue Programmiersprache Rust, in welcher auch Mozillas kommende Engine Servo entwickelt wird, ist ein Release-Zyklus vorgesehen, den man ähnlich auch von Firefox kennt: alle sechs Wochen erscheint eine neue Version und gleichzeitig eine erste Betaversion des Nachfolgers der neuen Version. Nachdem vor sechs Wochen Rust 1.13 erschienen ist, steht nun erwartungsgemäß Rust 1.14 bereit. 1.230 Patches sind im aktuellen Release gegenüber Rust 1.13 gelandet. Wer sich für alle Highlights der neuen Version interessiert, findet wie immer in der offiziellen Release-Ankündigung weitere Informationen.
Der Beitrag Programmiersprache: Rust 1.14 steht bereit erschien zuerst auf soeren-hentzschel.at.
Heute wurde eine neuer Snapshot des Browsers Vivaldi veröffentlicht, der meiner Meinung nach mal wieder erwähnenswert ist. Von nun an lassen sich Screenshots direkt mit dem Browser erstellen.
In der unteren Leiste findet man nun ein Kamerasymbol. Viele Tools / Plugins zum Erstellen von Screenshots sind allerdings nur in der Lage das aufzunehmen was auf dem Bildschirm angezeigt wird. Ist die Seite länger, so dass man scrollen muss, hat man hier oft ein Problem. Die Entwickler von Vivaldi haben diese Problematik berücksichtigt. Man kann entweder bestimmte Bereich aufnehmen die man mit der Maus markieren kann oder man kann Screenshots von kompletten Seiten anzeigen, egal wie lange diese sind. Als Dateiformat wird aktuell PNG oder JPEG angeboten.
Die erstellten Bilder landen bei mir (KDE Plasma) unter ~/Bilder/Vivaldi Caputures/. Was ich hier nicht so gut finde ist, dass die Dateien in Form wie dd4d8c5f-ac25-4ca6-ac83-b954fdb93cb2.png abgespeichert werden, ohne dass man hier einen Einfluss darauf hat. Ich vermute aber, dass sich hier zukünftig noch etwas ändern wird. Auch würde ich es begrüßen, wenn es einen einfacheren Editor wie bei Greenshot geben würde.
In den letzten Tagen gab es zwei große Relases für die Webanwendungen NextCloud und Piwik.
Die freie Anwendung für Dateiaustausch „NextCloud“, in diesem Jahr aus „OwnCloud“ entstanden, erreicht nun Version 11. Neben einer verbesserten Verwaltung für die „Apps“, welche die Funktionalität um z.B. Kalender- oder Kontaktfunktionen erweitern, wird in dieser Version viel Wert auf Sicherheit gelegt. Zwei-Faktor-Authentifizierung und erweiterte CSP-Richtlinien sind Beispiele dafür. Ebenso ist eine Volltextsuche dabei, die allerdings in Verbindung mit dem Backend „Nextant“ arbeitet, das auf Apache Solr/Lucene zurückgreift.
Für Besucherstatistiken von Webseiten eignet sich Piwik gut, welches in Version 3 angekommen ist. Optisch fällt direkt das neue Design auf, es wird verstärkt auf Material Design, bekannt seit Android 5, gesetzt. PHP 5.5 und MySQL 5.5 bilden ab sofort Mindestvoraussetzungen. Die Unterstützung für den Internet Explorer 8 und 9 entfällt.
Zum Updaten muss unbedingt erst ein Datenbankbackup und Datenbackup erstellt werden! Hiernach werden je nach Anleitung die neuen Dateien der jeweiligen Anwendungen in das Arbeitsverzeichnis kopiert. Es bietet sich zudem an, die Anwendungen in den Maintanace Mode (Piwik, NextCloud) zu versetzen. Abschließend müssen unbedingt die Datenbankschemata migriert werden. Das wird entweder beim ersten Aufrufen der Anwendung erzwungen oder kann bei größeren Installationen mithilfe einen Kommandozeilenbefehls ausgeführt werden. (SSH-Serverzugriff ist hierfür meist erforderlich) Abschließend Maintanace Mode deaktivieren und Anwendung testen.
Viel Spaß!
Die am 08. Dezember vorgestellte Chrome/Chromium-Version 56 Beta gibt einen konkreten Überblick, was uns in wenigen Wochen erwarten wird.
Wie schon im September 2016 angekündigt, wird zukünftig in der Adressleiste vor bestimmten Webseiten ohne HTTPS gewarnt. Darunter fallen allerdings vorerst nur Seiten, bei denen mittels Input-Boxen Passwörter oder Kreditkartendaten übermittelt werden. Der Hinweis wird anstelle des HTTPS-Schlosses grau mit einem „nicht sicher“-Schriftzug (original „not secure“) angezeigt.
Zwei weitere Änderungen beziehen sich auf CSS und JavaScript. Ab Chrome 56 Beta wird die CSS-Eigenschaft
position: sticky;unterstützt. Sie sorgt dafür, dass Elemente bis zu einem bestimmten Schwellwert mitscrollen und danach „kleben bleiben“. Ein Anwendungszweck hierfür ist z.B. ein Adressbuch, bei dem die Anfangsbuchstaben sticky sind. Beispiele und eine genauere Beschreibung findet sich im MDN. Firefox unterstützt seit Version 32 und Safari seit 6.1 diese Eigenschaft schon.
Mit Web Bluetooth lassen sich in Verbindung mit Bluetooth Low Energy solche Bluetooth-Geräte mithilfe weniger JavaScript-Zeilen in Webseiten einbinden. Ausprobieren lassen sich diese Funktionen hier.
Natürlich wurden auch weitere kleinere Verbesserungen eingearbeitet. Alles zur neuen Chrome Beta-Version lässt sich in den Changelogs in den Quellen nachlesen.
Oft fragt sich, welche Pakete, die man entweder installiert hat bzw. in den Paketquellen vorhanden sind, ein Sicherheitsproblem darstellen. Das Team hinter Arch Linux hat hier nun meiner Meinung nach einen Schritt in die richtige Richtung gemacht.
Unter https://security.archlinux.org/ wird eine Liste mit Paketen veröffentlicht, die aktuell ein Sicherheitsrisiko darstellen bzw. die kürzlich ein Update wegen eines Sicherheitsproblems erhalten haben. Einen Verweis auf die jeweiligen CVE, eventuelle Einträge in eigenen Bugtracker usw. findet man dort ebenfalls.
Mit Hilfe des Add-ons New Tab Override kann in Firefox die Seite festgelegt werden, welche erscheinen soll, wenn man einen neuen Tab öffnet. Nun wurde, nur zwei Tage nach Version 5.0, New Tab Override 6.0 veröffentlicht. Mit der neuen Version erhält eine weitere häufig gewünschte Funktion endlich Einzug in New Tab Override, ebenso wie zwei komplett neue Übersetzungen.
Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hat sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen (siehe Bug 1118285). Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen.
Es ist erst zwei Tage her, da wurde New Tab Override 5.0 veröffentlicht. Highlight dieser Version war, neben kleineren Optimierungen der Einstellungsseite sowie der Feed-Option, die Implementierung der mit Abstand meistgewünschten Funktion, seit es die Erweiterung gibt: die Möglichkeit, den Fokus beim Öffnen eines neuen Tabs auf die Webseite zu legen statt auf die Adressleiste.
Nun wurde New Tab Override 6.0 veröffentlicht und bringt erneut eine neue Funktion, welche sich häufiger von den Nutzern gewünscht worden ist. Ab sofort kann (optional) die Adressleiste beim Öffnen eines neuen Tabs geleert werden. Darüber hinaus gibt es mit Obersorbisch und Niedersorbisch nun zwei weitere Übersetzungen der Erweiterung, womit New Tab Override jetzt in fünf Sprachen zur Verfügung steht. Wer weitere Sprachen beitragen möchte, darf sich jederzeit melden.
Nach der Installation des Add-ons muss die gewünschte Option ausgewählt und ggfs. die gewünschte Webseite eingetragen werden. Dies kann entweder über die Einstellungs-Oberfläche geschehen, welche über die Schaltfläche in der Symbolleiste erreicht werden kann, über die Detail-Ansicht des Add-ons im Add-on Manager von Firefox oder aber per Direkt-Eingabe von about:newtaboverride in die Adressleiste.
Quelltext auf git.agenedia.com
Download auf addons.mozilla.org (deutsche Beschreibung)
Download auf addons.mozilla.org (englische Beschreibung)
Download auf addons.mozilla.org (niederländische Beschreibung)
Download auf addons.mozilla.org (obersorbische Beschreibung)
Download auf addons.mozilla.org (niedersorbische Beschreibung)
Der Beitrag Firefox: New Tab Override 6.0 veröffentlicht erschien zuerst auf soeren-hentzschel.at.
Foto: manseok auf pixabay / Lizenz: CC0
Network Attached Storage Systeme / Heimserver erfreuen sich seit Jahren wachsender Beliebtheit. Die vorhaltenen Datenmengen steigen stetig an, während mit dem Trend zu SSD-Speichermedien die verfügbare Kapazität im Notebook/Desktop-PC tendenziell rückläufig ist. Die ideale Lösung ist ein NAS. Der Markt wird dominiert durch einige wenige Hersteller wie Synology, die jeweils eigene Betriebssysteme für ihre Systeme entwickelt haben.
Ihnen gemein ist, dass sie die komplexe Funktionalität eines NAS hinter einer hübschen Web-GUI verbergen, über die der Anwender das System konfigurieren und warten kann. Die zugrunde liegenden Basisfunktionen wie SMB-Freigaben etc. pp. sind allerdings keine Zauberei, sondern lassen sich auch mit einem beliebigen Linux-System auf der Kommonadozeile einrichten. Wenn es in Bereich wie Wake-On-Lan, automatischer Bereitschaftsmodus und rsync-Backups geht, ist aber bereits etwas mehr Wissen erforderlich und viele greifen dann lieber zu den vorkonfigurierten Lösungen der großen Hersteller.
Doch auch für Anwender, die es gerne etwas komfortabler haben wollen und trotzdem ein selbst zusammen gestelltes NAS besitzen gibt es ein Angebot: openmediavault.
Openmediavault firmiert offiziell als eigene Distribution, ist aber eigentlich nur eine grafische Konfigurationsoberfläche für Debian. Die aktuelle stabile Version OMV 2 basiert noch auf Debian 7, das in der Betaphase befindliche OMV 3 auf Debian 8. Die Installation kann entweder über die OMV-Medien erfolgen oder durch das einbinden einer zusätzlichen Paketquelle in eine bestehende minimale Debian-Installation.
Da OMV 2/Debian 7 bereits veraltet und die Fertigstellung von OMV 3 nur noch eine Frage der Zeit ist, sollten Neuinstallationen (zumindest zu Testzwecken) mit Debian 8 / OMV 3 erfolgen. Eine bestehende minimale Debian-Installation muss dazu um folgende Paketquelle erweitert werden:
# echo "deb http://packages.openmediavault.org/public erasmus main" > /etc/apt/sources.list.d/openmediavault.list
Diese wird danach eingelesen:
# apt-get update
Anschließend muss noch der Signaturschlüssel installiert werden:
# apt-get install openmediavault-keyring
Woraufhin die Paketquellen nochmal neu eingelesen werden müssen:
# apt-get update
Im Anschluss kann man OMV über das entsprechende Meta-Paket installieren. Empfehlenswert ist die Installation ohne empfohlene Abhängigkeiten, um das System nicht unnötig aufzublasen.
# apt-get install --no-install-recommends openmediavault
Während der Installation fragt Debian die Konfiguration einiger Basispakete ab. Sofern man keine besonderen Wünsche hat, kann man die Voreinstellungen einfach absegnen.
Abschließend muss OMV noch initialisiert werden:
# omv-initsystem
Die WebGUI kann nun von jedem PC im Netzwerk aufgerufen werden. Entweder durch Eingabe der lokalen IP oder durch den vergebenen Hostname. Die Anmeldung erfolgt mit dem Administrationsaccount admin, dessen Standardpasswort openmediavault lautet. Dieses muss man natürlich nach der ersten Anmeldung sofort ändern.
Über die WebGUI lässt sich nun das NAS bequem steuern. Zur Konfiguration gibt es im Internet detaillierte Manuals, weshalb hier nicht auf jeden Punkt eingegangen wird. Standardmäßig sind die verbreiteten Schnittstellen NFS, SMB und FTP bereits verfügbar. Über die Rubrik Erweiterungen lassen sich Ergänzungen installieren. Wer das NAS in ein Apple-Ökosystem einbindet wird zu schätzen wissen, dass ein leidlich aktuelles Netatalk-Paket bereit steht, was standardmäßig sonst bei kaum einer aktuellen Distribution paketiert ist.
Praktisch ist auch, dass sich sowohl normale Partitionen, als auch LVM-Volume über die GUI verwalten lassen. Insbesondere auf einem Datenspeicher muss man hier schließlich manchmal nachjustieren.
Obwohl OMV als eigenständige Distribution firmiert, kommt ein Großteil der Pakete direkt aus den Debian-Paketquellen. In dem hier eingerichteten Testsystem kamen lediglich 9 Pakete aus den OMV-Quellen. Ohne Netatalk wären es noch einmal bedeutend weniger gewesen. Das System lässt sich deshalb auch ganz normal über SSH auf der Kommandozeile administrieren.
Es gibt daher auch immer wieder Kritik von Shell-Puristen, die (zu recht) sagen, dass die gebotene Funktionalität sich auch ohne den Umweg über OMV einrichten ließe. Nur ist es halt sehr bequem über die WebGUI z.B. eine SMB-Frreigabe einzurichten und die notwendigen Rechte zu erteilen. Auch ohne erst die Manpage von Samba gelesen zu haben.
Im Linux-Bereich ist die GUI von OMV ein echtes Alleinstellungsmerkmal. Keine andere Distribution hat etwas vergleichbares in den Paketquellen. Lediglich FreeNAS (aus dem OMV hervorging) kann im BSD-Bereich etwas ähnliches bieten.
Trotzdem ist OMV eher ein Debian mit WebGUI, als eine eigene Distribution. Wer Debian im Serverbetrieb nicht mag, wird mit OMV nicht warm werden.
So komfortabel die Konfiguration ist, man muss sich ein Stückweit auch in die Hand des grafischen Konfigurationswerkzeuges begeben. Per fstab eingehängte Partitionen lassen sich z.B. nicht als Speichermedien verwenden, sondern diese müssen zwingend durch das OMV-Werkzeug eingebunden werden. Was für Anfänger praktisch ist, stellte erfahrenere Benutzer manchmal vor Hürden, weil gewohnte Administrationsabläufe nicht mehr funktionen.
OMV hängt zudem in der Debian-Entwicklung deutlich hinterher. Die Freeze-Phase für das kommende Debian 9 beginnt bereits in Kürze und das auf Debian 8 basierende OMV 3 ist noch nicht mal veröffentlicht. Zwar lässt sich über die Backport-Kernel einiges kompensieren, aber Debian 8 fällt 12 Monate nach dem Release von Debian 9 aus dem offiziellen Support raus, d.h. vermutlich irgendwann Anfang 2018. Damit ist OMV für Anwender, die ihr Gerät einmal einrichten und dann vergessen wollen, wenig geeignet.
Foto: manseok auf pixabay / Lizenz: CC0
Network Attached Storage Systeme / Heimserver erfreuen sich seit Jahren wachsender Beliebtheit. Die vorhaltenen Datenmengen steigen stetig an, während mit dem Trend zu SSD-Speichermedien die verfügbare Kapazität im Notebook/Desktop-PC tendenziell rückläufig ist. Die ideale Lösung ist ein NAS. Der Markt wird dominiert durch einige wenige Hersteller wie Synology, die jeweils eigene Betriebssysteme für ihre Systeme entwickelt haben.
Ihnen gemein ist, dass sie die komplexe Funktionalität eines NAS hinter einer hübschen Web-GUI verbergen, über die der Anwender das System konfigurieren und warten kann. Die zugrunde liegenden Basisfunktionen wie SMB-Freigaben etc. pp. sind allerdings keine Zauberei, sondern lassen sich auch mit einem beliebigen Linux-System auf der Kommonadozeile einrichten. Wenn es in Bereich wie Wake-On-Lan, automatischer Bereitschaftsmodus und rsync-Backups geht, ist aber bereits etwas mehr Wissen erforderlich und viele greifen dann lieber zu den vorkonfigurierten Lösungen der großen Hersteller.
Doch auch für Anwender, die es gerne etwas komfortabler haben wollen und trotzdem ein selbst zusammen gestelltes NAS besitzen gibt es ein Angebot: openmediavault.
Openmediavault firmiert offiziell als eigene Distribution, ist aber eigentlich nur eine grafische Konfigurationsoberfläche für Debian. Die aktuelle stabile Version OMV 2 basiert noch auf Debian 7, das in der Betaphase befindliche OMV 3 auf Debian 8. Die Installation kann entweder über die OMV-Medien erfolgen oder durch das einbinden einer zusätzlichen Paketquelle in eine bestehende minimale Debian-Installation.
Da OMV 2/Debian 7 bereits veraltet und die Fertigstellung von OMV 3 nur noch eine Frage der Zeit ist, sollten Neuinstallationen (zumindest zu Testzwecken) mit Debian 8 / OMV 3 erfolgen. Eine bestehende minimale Debian-Installation muss dazu um folgende Paketquelle erweitert werden:
# echo "deb http://packages.openmediavault.org/public erasmus main" > /etc/apt/sources.list.d/openmediavault.list
Diese wird danach eingelesen:
# apt-get update
Anschließend muss noch der Signaturschlüssel installiert werden:
# apt-get install openmediavault-keyring
Woraufhin die Paketquellen nochmal neu eingelesen werden müssen:
# apt-get update
Im Anschluss kann man OMV über das entsprechende Meta-Paket installieren. Empfehlenswert ist die Installation ohne empfohlene Abhängigkeiten, um das System nicht unnötig aufzublasen.
# apt-get install --no-install-recommends openmediavault
Während der Installation fragt Debian die Konfiguration einiger Basispakete ab. Sofern man keine besonderen Wünsche hat, kann man die Voreinstellungen einfach absegnen.
Abschließend muss OMV noch initialisiert werden:
# omv-initsystem
Die WebGUI kann nun von jedem PC im Netzwerk aufgerufen werden. Entweder durch Eingabe der lokalen IP oder durch den vergebenen Hostname. Die Anmeldung erfolgt mit dem Administrationsaccount admin, dessen Standardpasswort openmediavault lautet. Dieses muss man natürlich nach der ersten Anmeldung sofort ändern.
Über die WebGUI lässt sich nun das NAS bequem steuern. Zur Konfiguration gibt es im Internet detaillierte Manuals, weshalb hier nicht auf jeden Punkt eingegangen wird. Standardmäßig sind die verbreiteten Schnittstellen NFS, SMB und FTP bereits verfügbar. Über die Rubrik Erweiterungen lassen sich Ergänzungen installieren. Wer das NAS in ein Apple-Ökosystem einbindet wird zu schätzen wissen, dass ein leidlich aktuelles Netatalk-Paket bereit steht, was standardmäßig sonst bei kaum einer aktuellen Distribution paketiert ist.
Praktisch ist auch, dass sich sowohl normale Partitionen, als auch LVM-Volume über die GUI verwalten lassen. Insbesondere auf einem Datenspeicher muss man hier schließlich manchmal nachjustieren.
Obwohl OMV als eigenständige Distribution firmiert, kommt ein Großteil der Pakete direkt aus den Debian-Paketquellen. In dem hier eingerichteten Testsystem kamen lediglich 9 Pakete aus den OMV-Quellen. Ohne Netatalk wären es noch einmal bedeutend weniger gewesen. Das System lässt sich deshalb auch ganz normal über SSH auf der Kommandozeile administrieren.
Es gibt daher auch immer wieder Kritik von Shell-Puristen, die (zu recht) sagen, dass die gebotene Funktionalität sich auch ohne den Umweg über OMV einrichten ließe. Nur ist es halt sehr bequem über die WebGUI z.B. eine SMB-Frreigabe einzurichten und die notwendigen Rechte zu erteilen. Auch ohne erst die Manpage von Samba gelesen zu haben.
Im Linux-Bereich ist die GUI von OMV ein echtes Alleinstellungsmerkmal. Keine andere Distribution hat etwas vergleichbares in den Paketquellen. Lediglich FreeNAS (aus dem OMV hervorging) kann im BSD-Bereich etwas ähnliches bieten.
Trotzdem ist OMV eher ein Debian mit WebGUI, als eine eigene Distribution. Wer Debian im Serverbetrieb nicht mag, wird mit OMV nicht warm werden.
So komfortabel die Konfiguration ist, man muss sich ein Stückweit auch in die Hand des grafischen Konfigurationswerkzeuges begeben. Per fstab eingehängte Partitionen lassen sich z.B. nicht als Speichermedien verwenden, sondern diese müssen zwingend durch das OMV-Werkzeug eingebunden werden. Was für Anfänger praktisch ist, stellte erfahrenere Benutzer manchmal vor Hürden, weil gewohnte Administrationsabläufe nicht mehr funktionen.
OMV hängt zudem in der Debian-Entwicklung deutlich hinterher. Die Freeze-Phase für das kommende Debian 9 beginnt bereits in Kürze und das auf Debian 8 basierende OMV 3 ist noch nicht mal veröffentlicht. Zwar lässt sich über die Backport-Kernel einiges kompensieren, aber Debian 8 fällt 12 Monate nach dem Release von Debian 9 aus dem offiziellen Support raus, d.h. vermutlich irgendwann Anfang 2018. Damit ist OMV für Anwender, die ihr Gerät einmal einrichten und dann vergessen wollen, wenig geeignet.
Ich habe letztens mit der Idee gespielt einen Bot für ein Spiel auf meinem Tablet zu entwickeln bzw auch zu bauen (Hardware). Für den Software-Teil möchte ich gerne C nutzen, wobei dass Programm am Ende auf einem Raspberry Pi laufen soll. Für die Steuerung werde ich wohl einen billigen Controller verwenden, den ich mit den GPIO’s des Pi’s verbinden werde.
Für dieses Projekt habe ich wie immer eine eigene Kategorie eingerichtet, sodass dort auch alle zukünftigen Artikel zu finden sind. Auch werde ich alle Daten in einem GitHub Repository unter der GPL-3 Lizenz bereitstellen.
Kinder sollten damit aufwachsen und wissen, wie die Technologie funktioniert, die sie umgibt. Mit dem teuren Smartphone oder dem Tablet lässt sich das leider nicht lernen – nur konsumieren. Der wunderbare Maxim hat sich deshalb etwas ausgedacht, mit dem schon Grundschüler experimentieren können: Der Calliope ist ein sternförmiger Minicomputer und nur so groß wie eine Spielkarte.
Der kleine Platinenrechner ist aber nicht nur eine weitere Konkurrenz für den Raspberry Pi oder den Arduino. Er ist viel einfacher in der Technologie, hat schon Mikrofon, Lautsprecher, ein LED-Display und verschiedene Schalter und Taster integriert. Zusammen mit einer einfachen Programmiersprache und einem didaktischen Konzept, ist das eine tolle Sache.
Jetzt braucht der wunderbare Maxim Geld, damit der Zauberstern auch gebaut wird und in die Schulen kommt. Dazu hat er eine Crowdfunding-Aktion gestartet. Wer also will, dass die Digitalisierung endlich auch in der Schule ankommt, kann hier seinen Beitrag leisten: https://www.startnext.com/calliope
Wenn möglich nutze ich unter Linux KDE Plasma. Der dort enthaltene Partition Manager zum Ändern der Partitionen hatte bisher immer Probleme mit LUKS in Verbindung mit LVM (oder umgekehrt).
Gestern wurde nun Version 3.0 des KDE Partition Managers veröffentlicht. Über das Changelog habe ich mich in dem Fall mal wirklich gefreut, da ich viel mit LVM / LUKS arbeite und bisher immer auf alternative grafische Oberflächen ausgewichen bin oder die die Befehle per Hand eingegeben habe.
Izulu war übers Wochenende kaputt, es wurden zwar noch die Hintergrundbilder gewechselt, aber das basierte nicht auf dem realen Wetter. Denn der Server, der als Wrapper für die Wetter-API dient, war kaputt. Im Grunde wurde er nur für Wartungsarbeiten neugestartet, aber ich hatte etwas falsch konfiguriert und kam dadurch nicht mehr rein. Leicht ärgerlich.
Den Digitalocean-Droplet habe ich abgeschaltet und lasse den Serverdienst jetzt stattdessen auf dem Server für diesen Blog laufen. Es funktioniert also wieder alles.
Schon länger plane ich, eine kleine Artikelserie über gute und freie, quelloffene (Android)Apps zu erstellen. Freie Apps haben nämlich nicht nur den Vorteil, dass ich den Quellcode inspizieren und verändern kann, sondern sie kommen meist ohne lästige Werbung aus, die andere Apps leider häufig auszeichnet und bringen zudem viele Möglichkeiten Android sinnvoll zu erweitern. Zu folgenden Apps habe ich vor, die nächsten Wochen kurze Vorstellungen zu schreiben (und diese dann hier zu verlinken):
Update vom 02.01.2017: Einige weitere Apps zur Liste hinzugefügt. Weitere werde ich eventuell aus den schon bestehenden Vorschlägen und aus noch kommenden aufnehmen.
Habt ihr weitere tolle, freie Apps, die hier nicht auftauchen und die ich noch aufnehmen sollte?
Eine Artikelserie über freie Apps für Android kommt ganz sicher nicht ohne einen Artikel zu F-Droid aus. F-Droid ist nämlich nicht nur selber freie Software, sondern ein alternativer App Store, aus dem freie Apps (und nur solche) heruntergeladen und installiert werden können.
Hier ein Screenshot von F-Droid
Was mir gefällt
F-Droid erweitert die Anzahl der auf Android verfügbaren freien Apps enorm. Damit sorgt die App indirekt für mehr potentielle Sicherheit beim User, da sie Software von allen eingesehen werden kann und so zumindest potentiell das Mehr-Augen-Prinzip greift. Hierzu kommt auch, dass die enthaltenen Apps den F-Droid-Regeln entsprechen müssen und somit z.B. keine proprietären Bestandteile enthalten dürfen. Dies schließt dann z.B. auch das Tracking durch Google Analytics u.a. aus. Außerdem ist über F-Droid ein anonymer Download von Apps möglich, da der App-Store im Gegensatz z.B. zum Google Play Store, keine Anmeldung erfordert. Auch finden sich hier Apps, die gar nicht im Google Play Store zu finden sind.
Wie andere App-Stores auch, stellt F-Droid ein zentrale Paketverwaltung dar, über die die installierten Apps auch aktualisiert werden. Also genauso komfortabel wie andere App-Stores auch.
Was ich mir wünschen würde
Ich würde mir wünschen, dass es in F-Droid eine prominentere Möglichkeit zum Bezahlen und/oder spenden geben würde. Für mich ist das Entscheidende nicht, dass die Apps kostenlos sind, sondern dass der Quellcode einzusehen ist und die Software von guter Qualität ist. Ich bin daher gerne bereit für Software zu zahlen. Ich denke, dass die pekuniären Anreize, wenn also sichergestellt wäre, dass die Entwickler trotz Offenlegung ihres Quellcodes ihren Lebensunterhalt angemessen sichern können, noch mehr Personen überzeugen könnten, sich mit der Erstellung freier Software zu beschäftigen. Anscheinend wird hieran aber auch schon gearbeitet.
Wie installiere ich F-Droid?
F-Droid ist nicht im Google Play Store vorhanden. Daher muss eine *.apk heruntergeladen und installiert werden. Damit dies jedoch funktioniert, muss dies erst erlaubt werden. Hierzu in den Einstellungen den Menüpunkt „Sicherheit“ öffnen. Hier muss die Installation von Apps aus unbekannten Quellen erlaubt werden:
Anschließend kann F-Droid heruntergeladen werden. Anschließend nur noch die heruntergeladene Datei öffnen (der Paket-Installer sollte sich öffnen) und F-Droid installieren. Update: Wie Jörg K. zurecht angemerkt hat, empfiehlt es sich die Installation von Apps aus unbekannten Quellen nach der Installation von F-Droid (und den Apps, die ich aus dem Katalog installieren oder aktualisieren möchte) wieder zu verbieten.
Android ist durch die Installation von F-Droid enorm bereichert, wie sich auch im Folgenden in der Artikelserie: Empfehlenswerte freie, quelloffene Apps für Android zeigen wird.
Nachtrag vom 02.01.2017
Quellcode
Der F-Droid-Client steht unter der GPL-3.0. Der Quellcode wird auf Gitlab gehostet, wo sich auch der Bugtracker befindet.
Wie kann man die weitere Entwicklung unterstützen?
Wem F-Droid gefällt, der kann auf verschiedene Arten zu der weiteren Entwicklung beitragen. Zuerst ist hier sicherlich, wie bei allen freien Projekten, das Anzeigen von Bugs (Fehlern) im Bugtracker zu nennen. Außerdem können Apps, die bisher noch nicht im F-Droid-Katalog sind, für die Aufnahme vorgeschlagen werden, wenn sie den Anforderungen entsprechen. Für Entwickler bietet sich außerdem natürlich die Mitarbeit am Code des Clients oder des Servers an. Nichtentwickler können des Weiteren bei der Übersetzung in weitere Sprachen helfen oder die weitere Entwicklung durch eine Spende unterstützen. Hierbei kann man wählen zwischen einer Spende über Paypal, Flattr, bitcoin (15u8aAPK4jJ5N8wpWJ5gutAyyeHtKX5i18) oder Überweisung (IBAN: GB92 BARC 2056 7893 4088 92; SWIFT: BARCGB22).
Mit Hilfe des Add-ons New Tab Override kann in Firefox die Seite festgelegt werden, welche erscheinen soll, wenn man einen neuen Tab öffnet. Nun wurde New Tab Override 5.0 veröffentlicht. Mit der neuen Version erhält die von den Nutzern meistgewünschte Funktion endlich Einzug in New Tab Override.
Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hat sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen (siehe Bug 1118285). Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen.
Seit dem Erscheinen der ersten Version von New Tab Override gab es viel Feedback. Vieles davon hat bereits den Weg in die Erweiterung gefunden. Ein Wunsch wurde dabei besonders häufig genannt. Nun, kurz vor Weihnachten, hat es dieser Wunsch endlich in die Erweiterung geschafft.
Ab sofort gibt es in den Einstellungen der Erweiterung eine neue Option, um den Fokus beim Öffnen eines neuen Tabs auf die Webseite zu legen statt auf die Adressleiste.
Standardmäßig verhält sich New Tab Override so, dass der Fokus beim Öffnen eines neuen Tabs stets auf der Adressleiste liegt. Das heißt, wer einen neuen Tab öffnet, kann direkt in der Adressleiste eine andere URL eingeben. Die neue Option erlaubt es, dass beispielsweise für Nutzer, welche Google als Seite für den neuen Tab eingestellt haben, automatisch das Suchfeld fokussiert wird.
Nach der Installation des Add-ons muss die gewünschte Option ausgewählt und ggfs. die gewünschte Webseite eingetragen werden. Dies kann entweder über die Einstellungs-Oberfläche geschehen, welche über die Schaltfläche in der Symbolleiste erreicht werden kann, über die Detail-Ansicht des Add-ons im Add-on Manager von Firefox oder aber per Direkt-Eingabe von about:newtaboverride in die Adressleiste.
Quelltext auf git.agenedia.com
Download auf addons.mozilla.org (deutsche Beschreibung)
Download auf addons.mozilla.org (englische Beschreibung)
Download auf addons.mozilla.org (niederländische Beschreibung)
Der Beitrag Firefox: New Tab Override 5.0 veröffentlicht erschien zuerst auf soeren-hentzschel.at.
Roundcube ist ein schöner und quelloffener Webmail-Client, der relativ große Verbreitung erlangt hat. Auch ich setze diesen unter anderem auf meinem privaten Server ein. Letzte Woche wurde eine kritische Sicherheitslücke in Roundcube aufgedeckt. Zwar können nur eigene User die Schwachstelle ausnutzen und einige weitere Vorbedingungen müssen erfüllt werden (Sendmail muss im Einsatz usw.), so dass die von mir betriebenen Systeme von der Lücke nicht betroffen waren. Trotzdem lohnt sich alleine aufgrund der zahlreichen Bugs, die in der neuen Version 1.2.3 zusätzlich zum Schließen der Lücke behoben wurden, ein Update.
Photo by aag_photos 
Backup
Bevor mit dem eigentlichen Update begonnen wird, sollte zunächst ein Backup durchgeführt werden, falls irgendetwas schief gehen sollte.
Einerseits sollte das Verzeichnis, in dem Roundcube liegt gesichert werden (bei mir /opt/www/roundcubemail/). Hierfür habe ich zunächst im Homeverzeichnis meines Users einen Ordner angelegt:
mkdir rc_backupdir
Anschließend habe ich das ganze Roundcube-Verzeichnis in dieses gesichert:
rsync -Aax /opt/www/roundcubemail /home/user/rc_backupdir/
Außerdem sollte noch ein Backup der Datenbank von Roundcube durchgeführt werden. (hier muss natürlich der Datenbankname (rot markiert) unter Umständen angepasst werden).
mysqldump --lock-tables -h localhost -u root -p roundcubemail > /home/user/rc_dbbackup_`date +"%Y%m%d"`.bak
Letzte Vorbereitungen
Vor dem Update sollte geprüft werden, ob die systemVariable in der php.ini disabled ist. Hierzu die php.ini öffnen
sudo nano /etc/php/7.0/cli/php.ini
Wenn die Datei geöffnet ist STRG+W drücken und nach disable_functions suchen und hier system, löschen und die Datei speichern.
Update
Ist das Backup abgeschlossen, kann mit dem Update begonnen werden. Hierzu zunächst die neue Version von Roundcube auf den Server laden:
wget https://github.com/roundcube/roundcubemail/releases/download/1.2.5/roundcubemail-1.2.5-complete.tar.gz
Und entpacken:
tar xf roundcubemail-1.2.5-complete.tar.gz
Anschließend in den neuen Ordner wechseln:
cd roundcubemail-1.2.5/
Und das Updateskript starten (hier auch unter Umständen wieder den Installationspfad von Roundcube anpassen):
bin/installto.sh /opt/www/roundcubemail/
Und schon ist Roundcube auf die schöne neue Version 1.2.5 geupdated. Abschließend sollte noch die system-Funktion wieder disabled werden, indem sie wieder in die php.ini eingefügt wird (s.o.).
OpenSUSE Leap ist die LTS-Variante von openSUSE. Im Gegensatz zu Debian, RHEL/CentOS oder Ubuntu galt openSUSE nie als gutes Serverbetriebssystem - die Supportzeiträume waren einfach zu kurz. Jede Leap-Hauptversion hat jedoch mindestens 42 Monate Support. Das ist weniger als Ubuntu oder CentOS, aber genug um für manchen Heimserver attraktiv zu werden.
Diese Attraktivität wird noch gesteigert durch den Releaseprozess von Leap. Dieses basiert nämlich auf SUSE Linux Enterprise und vor allem die Server-relevanten Pakete entstammen fast alle SLE. In diesem Einsatzszenario kommt openSUSE Leap somit auch seiner zugeschriebenen Rolle als freie SLE-Variante besonders Nahe.
Bei der Installation sind jedoch einige Fallstricke zu beachten. Zwar lässt sich in der Desktopauswahl der Server-Modus auswählen. Das entsprechende Metapaket reduziert die Installation auf ein Basisbetriebssystem ohne grafischen Überbau. Durch eine fehlerhafte Abhängigkeit zieht das Paket snapper-zypp-plugin jedoch Mesa nach sich und dann durch empfohlene RPM-Abhängigkeiten einen vollständigen GTK-Stack. Bei einem Server ist das natürlich vollkommen überflüssig. Das Paket snapper-zypp-plugin sollte daher bei der Installation manuell abgewählt werden. Dadurch funktioniert allerdings das SUSE-eigene snapper/btrfs-snapshot System nicht mehr vollständig, da dieses Plugin die Veränderungen bei jeder Installation/Deinstallation von Paketen dokumentierte. Gegebenenfalls muss man hier im Einzelfall abwägen, welche Prioritäten man setzt.
Weiterhin muss SSH in der Installationsübersicht manuell aktiviert werden, da man ansonsten nach der Installation nicht über das Netzwerk zugreifen kann. Die Firewall ist standardmäßig bereits abgeschaltet und sollte daher keine Problem verursachen. Sofern eine Firewall gewünscht ist, sollte man darauf achten, dass die entsprechenden Ausnahmen für SSH festgelegt sind.
Direkt nach der Installation sollte man zudem noch die wicked-Einstellungen anpassen. Dies kann man über die ncurses-Oberfläche von YAST erledigen. Wicked ist das SUSE-eigene Werkzeug zur Netzwerk-Konfiguration.
Bei einer Server-Installation ist standardmäßig eine feste IP eingestellt. Oft soll aber die IP über DHCP zugewiesen werden und die feste IP-Zuordnung im Router erfolgen. Hier muss man dann nachjustieren, bevor der Server von der Peripherie getrennt wird.
Hierzu muss die entsprechende Netzwerkschnittstelle (i.d.R. eth0) bearbeitet werden. Hier sollte das "x" bei Dynamische Adresse positioniert sein.
Zur Reduzierung des Wartungsaufwands kann man noch die automatische Onlineaktualisierung aktivieren. Hierzu muss das Konfigurationsmodul für das entsprechende YAST-Modul noch nachinstalliert werden:
zypper in yast2-online-update-configuration
Anschließend lässt sich in Konfiguration der Online Aktualisierung festlegen wie oft die Onlineaktualisierung durchgeführt und welche Pakete mit einbezogen werden sollen. Die automatische Installation sicherheitsrelevanter Patches ist empfehlenswert. Ob man auch lediglich empfohlene Pakete einbeziehen möchte oder dies lieber gelegentlich manuell macht, muss jeder für sich entscheiden. Dies hängt sicherlich auch davon ab, wie viel Kontrolle man über die Updates ausüben möchte bzw. wie sehr man den Testroutinen von openSUSE vertraut.
OpenSUSE Leap ist die LTS-Variante von openSUSE. Im Gegensatz zu Debian, RHEL/CentOS oder Ubuntu galt openSUSE nie als gutes Serverbetriebssystem - die Supportzeiträume waren einfach zu kurz. Jede Leap-Hauptversion hat jedoch mindestens 42 Monate Support. Das ist weniger als Ubuntu oder CentOS, aber genug um für manchen Heimserver attraktiv zu werden.
Diese Attraktivität wird noch gesteigert durch den Releaseprozess von Leap. Dieses basiert nämlich auf SUSE Linux Enterprise und vor allem die Server-relevanten Pakete entstammen fast alle SLE. In diesem Einsatzszenario kommt openSUSE Leap somit auch seiner zugeschriebenen Rolle als freie SLE-Variante besonders Nahe.
Bei der Installation sind jedoch einige Fallstricke zu beachten. Zwar lässt sich in der Desktopauswahl der Server-Modus auswählen. Das entsprechende Metapaket reduziert die Installation auf ein Basisbetriebssystem ohne grafischen Überbau. Durch eine fehlerhafte Abhängigkeit zieht das Paket snapper-zypp-plugin jedoch Mesa nach sich und dann durch empfohlene RPM-Abhängigkeiten einen vollständigen GTK-Stack. Bei einem Server ist das natürlich vollkommen überflüssig. Das Paket snapper-zypp-plugin sollte daher bei der Installation manuell abgewählt werden. Dadurch funktioniert allerdings das SUSE-eigene snapper/btrfs-snapshot System nicht mehr vollständig, da dieses Plugin die Veränderungen bei jeder Installation/Deinstallation von Paketen dokumentierte. Gegebenenfalls muss man hier im Einzelfall abwägen, welche Prioritäten man setzt.
Weiterhin muss SSH in der Installationsübersicht manuell aktiviert werden, da man ansonsten nach der Installation nicht über das Netzwerk zugreifen kann. Die Firewall ist standardmäßig bereits abgeschaltet und sollte daher keine Problem verursachen. Sofern eine Firewall gewünscht ist, sollte man darauf achten, dass die entsprechenden Ausnahmen für SSH festgelegt sind.
Direkt nach der Installation sollte man zudem noch die wicked-Einstellungen anpassen. Dies kann man über die ncurses-Oberfläche von YAST erledigen. Wicked ist das SUSE-eigene Werkzeug zur Netzwerk-Konfiguration.
Bei einer Server-Installation ist standardmäßig eine feste IP eingestellt. Oft soll aber die IP über DHCP zugewiesen werden und die feste IP-Zuordnung im Router erfolgen. Hier muss man dann nachjustieren, bevor der Server von der Peripherie getrennt wird.
Hierzu muss die entsprechende Netzwerkschnittstelle (i.d.R. eth0) bearbeitet werden. Hier sollte das "x" bei Dynamische Adresse positioniert sein.
Zur Reduzierung des Wartungsaufwands kann man noch die automatische Onlineaktualisierung aktivieren. Hierzu muss das Konfigurationsmodul für das entsprechende YAST-Modul noch nachinstalliert werden:
zypper in yast2-online-update-configuration
Anschließend lässt sich in Konfiguration der Online Aktualisierung festlegen wie oft die Onlineaktualisierung durchgeführt und welche Pakete mit einbezogen werden sollen. Die automatische Installation sicherheitsrelevanter Patches ist empfehlenswert. Ob man auch lediglich empfohlene Pakete einbeziehen möchte oder dies lieber gelegentlich manuell macht, muss jeder für sich entscheiden. Dies hängt sicherlich auch davon ab, wie viel Kontrolle man über die Updates ausüben möchte bzw. wie sehr man den Testroutinen von openSUSE vertraut.
Foto: © Vladislav Kochelaevs / Fotolia.com
Clouddienste basieren auf dem grundsätzlich erst einmal merkwürdigen Ansatz, dass Personen und Firmen bereit sind ihre Daten einem externen Dienstanbieter anzuvertrauen. Wenn einer dieser Dienstanbieter, dann das - eigentlich selbstverständliche - formuliert und zugibt, dass hierdurch thereotisch auch andere Personen Zugriff auf diese Daten haben ist das Geschrei groß.
Die Frage ist nur welche Optionen man hat, um seine Daten bestmöglich zu schützen.
Die erste Frage, die man sich stellen muss, lautet eigentlich "Brauche ich überhaupt einen Clouddienst?". Clouddienste sind angesagt, bei der Einrichtung eines neuen Smartphones werden einem meist zusätzliches Speichervolumen bei diesem oder jenem Clouddienst angeboten. Moderne Betriebssysteme wie macOS oder Windows 10 benötigen einen Apple- respektive Microsoftaccount und haben Cloudfunktionen vorinstalliert. Das verleitet dazu solche Dienste unüberlegt einzusetzen.
Jede Absicherungsmaßnahme kann man sich aber sparen, wenn man zu dem Ergebnis kommt, gar keinen Clouddienst zu benötigen. Das kann insbesondere dann der Fall sein, wenn man nur ein physisches Endgerät benötigt und faktisch nur von diesem einen Endgerät auf die Daten zugreift. Clouddienste hätten dann nur eine Bedeutung als ausfallsicheres Backupmedium, was man aber durch eine gute Backupsstrategie kompensieren kann.
Sollte man jedoch zu dem Ergebnis kommen, dass ein Clouddienst unbedingt vonnöten ist, muss man seine Daten jedoch nicht unbedingt einem externen Dienstanbieter anvertrauen. Dank großartiger Projekte wie Nextcloud/ownCloud kann eigentlich jeder einen heimischen Cloudserver aufsetzen.
Allerdings bedarf es dazu ein bisschen Wissen über die Administration eines Linux-Servers, sowie die Absicherung desselben. Nur weil der Server in den eigenen vier Wänden steht, sind die Daten nicht unbedingt besser vor unbefugten Zugriffen geschützt, als bei einem externen Anbieter.
Bei einem eigenen Server ist man zudem selbst für die Backupstrategie verantwortlich. Als ausfallsicheres Backupmedium - womit manche Clouddienstleister werben - ist so eine Konstruktion sicherlich ungeeignet.
Sofern also aus Gründen der Ausfallsicherheit oder mangels eigener Kenntnisse in der Serveradministration die Entscheidung fällt einen externen Clouddienstleister zu nutzen, steht man vor der Wahl einen der großen Platzhirsche zu wählen oder einen kleinen Dienst, der beispielsweise auf Open-Source Lösungen setzt (Liste von Providern mit Nextcloud).
Open Source wird dabei von vielen immer noch mit "sicher" und "vertrauenswürdig" gleichgesetzt. Das ist allerdings nicht unbedingt der Fall. Wie die Auseinandersetzungen um Seafile in diesem Jahr zeigten, agieren kleine Firmen manchmal wenig transparent und die Sicherheit der eigenen Daten ist nicht unbedingt gewährleistet. Zumal man den Zusicherungen des Anbieters genau wie bei proprietären Systemen vertrauen muss. In die Serverkonfiguration kann man schließlich nicht hineinschauen.
Aus diesem Grund sollte man immer auf clientseitige Verschlüsselung setzen - egal wie sehr man seinem Anbieter vertraut. Mit Cryptomator steht inzwischen eine freie, anbieterübergreifende Lösung zur Verfügung, die sicherer als das gebrochene EncFS ist und kein Abomodell voraussetzt wie z.B. Boxcryptor. Qualitativ hochwertige Verschlüsselung (also nicht EncFS) mit einem sehr guten Passwort ist der beste Schutz.
Grundsätzlich ist es immer die beste Entscheidung keinen Cloudanbieter zu verwenden. Daten die einmal die eigenen vier Wände verlassen haben, lassen sich prinzipiell nur eingeschränkt kontrollieren. Entsprechendes Fachwissen vorausgesetzt kann es einen Kompromiss darstellen einen eigenen Server zu betreiben und auch von außerhalb des Heimnetzwerkes verfügbar zu machen.
Sofern beides keine Option und ein externer Anbieter notwendig ist, kann ein großer Anbieter mit proprietärer Software die bessere Wahl als eine kleine "Klitsche" mit vielen Versprechungen sein. Einfach weil Sicherheit auch ein Kostenfaktor ist und kleine Startups oft nicht solide finanziert sind - egal wie professionell die Internetauftritte sich gestalten. Hier ist auch immer zu hinterfragen, wie sich die Dienste finanzieren. Sehr preiswerte oder kostenlose Angebote legen immer die Vermutung nahe, dass mit den Daten Geld verdient werden muss.
Egal welchen Anbieter man wählt, Verschlüsselung ist Pflicht. Das einzige wirklich valide Argument gegen einen Anbieter ist daher, wenn sich Daten bei diesem nicht verschlüsseln lassen.
Schon seit einiger Zeit hilft mir Ansible1 fast täglich dabei, meine Arbeit leichter zu gestalten. Heute möchte ich euch ganz kurz erzählen, was ich am Ad-hoc-Modus schätze.
Der Ad-hoc-Modus bietet die Möglichkeit, einfache Kommandos parallel auf einer Gruppe von Nodes ausführen zu lassen, ohne zuvor ein Playbook erstellen zu müssen. Ein Ad-hoc-Befehl besitzt z.B. den folgenden Aufbau:
ansible [-m module_name] [-a args] [options]
Ein einfaches Beispiel aus der Ansible-Dokumentation2 soll die Anwendung verdeutlichen:
# ansible all -m ping -i staging --limit=e-stage
host01.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
host02.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
host03.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
Das Schlüsselwort all gibt an, dass das Kommando auf allen Nodes ausgeführt werden soll, welche in der Inventar-Datei enthalten sind. Mit -m ping wird das zu verwendende Ansible-Modul spezifiziert. Da das verwendete Modul keine weiteren Argumente besitzt, findet -a in diesem Beispiel keine Anwendung. Mit der Option -i kann die zu verwendende Inventar-Datei angegeben werden. Lässt man diese Option weg, wird die Standard-Inventar-Datei /etc/ansible/hosts verwendet. Mit der Option --limit=e-stage wird die Ausführung noch weiter eingeschränkt. So wird in diesem Fall das Modul ping nur auf den Nodes der Gruppe e-stage ausgeführt. Das in diesem Beispiel verwendete Inventar besitzt den folgenden Aufbau:
[e-stage] host01.example.com host02.example.com host03.example.com host06.example.com host07.example.com [i-stage] host04.example.com [p-stage] host05.example.com
Selbstverständlich lassen sich Ansible-Ad-hoc-Kommandos auf der Kommandozeile auch weiter verknüpfen. Dies soll an zwei kleinen Beispielen verdeutlicht werden.
In diesem ersten Beispiel soll der Status des Dienstes chronyd überprüft werden, ohne den aktuellen Status zu ändern. Dabei soll das Kommando systemctl status chronyd.service via Ansible parallel auf den Nodes ausgeführt werden.
Zuvor habe ich mir auf einem Node angesehen, wie die Ansible-Ausgabe in Abhängigkeit vom Dienststatus aussieht (Ausgabe gekürzt):
# Der Dienst auf dem Node ist gestartet
root@ansible-control-machine>ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging -l host01.example.com
host01.example.com | SUCCESS | rc=0 >>
* chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2016-12-15 14:52:02 CET; 19h ago
# Der Dienst auf dem Node ist gestoppt
root@ansible-control-machine>ansible all -m command -a’/usr/bin/systemctl status chronyd.service‘ -i staging -l host01.example.com
host01.example.com | FAILED | rc=3 >>
* chronyd.service – NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2016-12-16 10:04:34 CET; 4s ago
# Das Paket, welches den Dienst enthaelt ist nicht installiert
root@ansible-control-machine>ansible all -m command -a’/usr/bin/systemctl status chronyd.service‘ -i staging -l host01.example.com
host01.example.com | FAILED | rc=4 >>
Unit chronyd.service could not be found.
Anhand der Ausgaben ist zu erkennen, dass Ansible den Task als „| SUCCESS |“ markiert, wenn der Dienst läuft und als „| FAILED |“, wenn der Dienst gestoppt bzw. gar nicht installiert ist. Durch Verknüpfung des Kommandos mit grep kann man sich nun schnell einen Überblick über den Dienststatus auf seinen Rechnern verschaffen:
root@ansible-control-machine> ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\|| FAILED |'
host01.example.com | SUCCESS | rc=0 >>
host02.example.com | SUCCESS | rc=0 >>
host03.example.com | FAILED | rc=3 >>
host06.example.com | SUCCESS | rc=0 >>
host07.example.com | SUCCESS | rc=0 >>
Anhand der Ausgabe ist leicht zu erkennen, dass der Dienst chronyd auf host03 nicht läuft. Anhand des Return-Codes rc=3 lässt sich weiterhin erkennen, dass das notwendige Paket offensichtlich installiert ist, der Dienst jedoch nicht gestartet wurde. Dies kann nun jedoch schnell durch folgenden Befehl korrigiert werden (Ausgabe gekürzt):
root@ansible-control-machine>ansible host03.example.com -m systemd -a'name=chronyd state=started' -i staging
host03.example.com | SUCCESS => {
"changed": true,
"name": "chronyd",
"state": "started",
"status": {...}
}
Eine erneute Ausführung des ersten Kommandos bestätigt, dass der Dienst nun auch auf dem Node host03 ausgeführt wird.
root@ansible-control-machine> ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\|| FAILED |'
host01.example.com | SUCCESS | rc=0 >>
host02.example.com | SUCCESS | rc=0 >>
host03.example.com | SUCCESS | rc=0 >>
host06.example.com | SUCCESS | rc=0 >>
host07.example.com | SUCCESS | rc=0 >>
In diesem Beispiel möchte ich die installierte Version des Pakets tzdata abfragen. Dies geschieht auf einem einzelnen Host mit dem Kommando rpm -qi :
# rpm -qi tzdata
Name : tzdata
Version : 2016i
Release : 1.el7
Architecture: noarch
Install Date: Wed Nov 9 08:47:03 2016
Group : System Environment/Base
Size : 1783642
License : Public Domain
Signature : RSA/SHA256, Fri Nov 4 17:21:59 2016, Key ID 199e2f91fd431d51
Source RPM : tzdata-2016i-1.el7.src.rpm
Build Date : Thu Nov 3 12:46:39 2016
Build Host : ppc-045.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor : Red Hat, Inc.
URL : https://www.iana.org/time-zones
Summary : Timezone data
Description :
This package contains data files with rules for various timezones around
the world.
Mich interessiert lediglich die zweite Zeile, welche die Version des Pakets enthält. Die frage ich nun wie folgt ab:
root@ansible-control-machine> ansible all -m command -a'/usr/bin/rpm -qi tzdata' -i staging --limit=e-stage | grep 'SUCCESS\|Version'
host01.example.com | SUCCESS | rc=0 >>
Version : 2016f
host02.example.com | SUCCESS | rc=0 >>
Version : 2016g
host03.example.com | SUCCESS | rc=0 >>
Version : 2016i
host06.example.com | SUCCESS | rc=0 >>
Version : 2016i
host07.example.com | SUCCESS | rc=0 >>
Version : 2016i
Ohne Ansible hätte ich diese Aufgaben entweder mit Iteration in einem kurzen Shell-Skript lösen müssen, oder zuerst ein Kochbuch, Manifest, etc. schreiben, welches dann anschließend ausgeführt werden kann. So wurde mir hingegen einiges an Zeit gespart, die ich für andere Dinge verwenden konnte.
Quellen und weiterführende Links
Schon seit einiger Zeit hilft mir Ansible1 fast täglich dabei, meine Arbeit leichter zu gestalten. Heute möchte ich euch ganz kurz erzählen, was ich am Ad-hoc-Modus schätze.
Der Ad-hoc-Modus bietet die Möglichkeit, einfache Kommandos parallel auf einer Gruppe von Nodes ausführen zu lassen, ohne zuvor ein Playbook erstellen zu müssen. Ein Ad-hoc-Befehl besitzt z.B. den folgenden Aufbau:
ansible [-m module_name] [-a args] [options]
Ein einfaches Beispiel aus der Ansible-Dokumentation2 soll die Anwendung verdeutlichen:
# ansible all -m ping -i staging --limit=e-stage
host01.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
host02.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
host03.example.com | SUCCESS => {
"changed": false,
"ping": "pong"
}
Das Schlüsselwort all gibt an, dass das Kommando auf allen Nodes ausgeführt werden soll, welche in der Inventar-Datei enthalten sind. Mit -m ping wird das zu verwendende Ansible-Modul spezifiziert. Da das verwendete Modul keine weiteren Argumente besitzt, findet -a in diesem Beispiel keine Anwendung. Mit der Option -i kann die zu verwendende Inventar-Datei angegeben werden. Lässt man diese Option weg, wird die Standard-Inventar-Datei /etc/ansible/hosts verwendet. Mit der Option --limit=e-stage wird die Ausführung noch weiter eingeschränkt. So wird in diesem Fall das Modul ping nur auf den Nodes der Gruppe e-stage ausgeführt. Das in diesem Beispiel verwendete Inventar besitzt den folgenden Aufbau:
[e-stage] host01.example.com host02.example.com host03.example.com host06.example.com host07.example.com [i-stage] host04.example.com [p-stage] host05.example.com
Selbstverständlich lassen sich Ansible-Ad-hoc-Kommandos auf der Kommandozeile auch weiter verknüpfen. Dies soll an zwei kleinen Beispielen verdeutlicht werden.
In diesem ersten Beispiel soll der Status des Dienstes chronyd überprüft werden, ohne den aktuellen Status zu ändern. Dabei soll das Kommando systemctl status chronyd.service via Ansible parallel auf den Nodes ausgeführt werden.
Zuvor habe ich mir auf einem Node angesehen, wie die Ansible-Ausgabe in Abhängigkeit vom Dienststatus aussieht (Ausgabe gekürzt):
# Der Dienst auf dem Node ist gestartet
root@ansible-control-machine>ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging -l host01.example.com
host01.example.com | SUCCESS | rc=0 >>
* chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2016-12-15 14:52:02 CET; 19h ago
# Der Dienst auf dem Node ist gestoppt
root@ansible-control-machine>ansible all -m command -a’/usr/bin/systemctl status chronyd.service‘ -i staging -l host01.example.com
host01.example.com | FAILED | rc=3 >>
* chronyd.service – NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2016-12-16 10:04:34 CET; 4s ago
# Das Paket, welches den Dienst enthaelt ist nicht installiert
root@ansible-control-machine>ansible all -m command -a’/usr/bin/systemctl status chronyd.service‘ -i staging -l host01.example.com
host01.example.com | FAILED | rc=4 >>
Unit chronyd.service could not be found.
Anhand der Ausgaben ist zu erkennen, dass Ansible den Task als „| SUCCESS |“ markiert, wenn der Dienst läuft und als „| FAILED |“, wenn der Dienst gestoppt bzw. gar nicht installiert ist. Durch Verknüpfung des Kommandos mit grep kann man sich nun schnell einen Überblick über den Dienststatus auf seinen Rechnern verschaffen:
root@ansible-control-machine> ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\|| FAILED |'
host01.example.com | SUCCESS | rc=0 >>
host02.example.com | SUCCESS | rc=0 >>
host03.example.com | FAILED | rc=3 >>
host06.example.com | SUCCESS | rc=0 >>
host07.example.com | SUCCESS | rc=0 >>
Anhand der Ausgabe ist leicht zu erkennen, dass der Dienst chronyd auf host03 nicht läuft. Anhand des Return-Codes rc=3 lässt sich weiterhin erkennen, dass das notwendige Paket offensichtlich installiert ist, der Dienst jedoch nicht gestartet wurde. Dies kann nun jedoch schnell durch folgenden Befehl korrigiert werden (Ausgabe gekürzt):
root@ansible-control-machine>ansible host03.example.com -m systemd -a'name=chronyd state=started' -i staging
host03.example.com | SUCCESS => {
"changed": true,
"name": "chronyd",
"state": "started",
"status": {...}
}
Eine erneute Ausführung des ersten Kommandos bestätigt, dass der Dienst nun auch auf dem Node host03 ausgeführt wird.
root@ansible-control-machine> ansible all -m command -a'/usr/bin/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\|| FAILED |'
host01.example.com | SUCCESS | rc=0 >>
host02.example.com | SUCCESS | rc=0 >>
host03.example.com | SUCCESS | rc=0 >>
host06.example.com | SUCCESS | rc=0 >>
host07.example.com | SUCCESS | rc=0 >>
In diesem Beispiel möchte ich die installierte Version des Pakets tzdata abfragen. Dies geschieht auf einem einzelnen Host mit dem Kommando rpm -qi :
# rpm -qi tzdata
Name : tzdata
Version : 2016i
Release : 1.el7
Architecture: noarch
Install Date: Wed Nov 9 08:47:03 2016
Group : System Environment/Base
Size : 1783642
License : Public Domain
Signature : RSA/SHA256, Fri Nov 4 17:21:59 2016, Key ID 199e2f91fd431d51
Source RPM : tzdata-2016i-1.el7.src.rpm
Build Date : Thu Nov 3 12:46:39 2016
Build Host : ppc-045.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor : Red Hat, Inc.
URL : https://www.iana.org/time-zones
Summary : Timezone data
Description :
This package contains data files with rules for various timezones around
the world.
Mich interessiert lediglich die zweite Zeile, welche die Version des Pakets enthält. Die frage ich nun wie folgt ab:
root@ansible-control-machine> ansible all -m command -a'/usr/bin/rpm -qi tzdata' -i staging --limit=e-stage | grep 'SUCCESS\|Version'
host01.example.com | SUCCESS | rc=0 >>
Version : 2016f
host02.example.com | SUCCESS | rc=0 >>
Version : 2016g
host03.example.com | SUCCESS | rc=0 >>
Version : 2016i
host06.example.com | SUCCESS | rc=0 >>
Version : 2016i
host07.example.com | SUCCESS | rc=0 >>
Version : 2016i
Ohne Ansible hätte ich diese Aufgaben entweder mit Iteration in einem kurzen Shell-Skript lösen müssen, oder zuerst ein Kochbuch, Manifest, etc. schreiben, welches dann anschließend ausgeführt werden kann. So wurde mir hingegen einiges an Zeit gespart, die ich für andere Dinge verwenden konnte.
Quellen und weiterführende Links
Mozilla hat einen Firefox Hardware Report veröffentlicht. Dieser beinhaltet Informationen darüber, was für Hardware von den Firefox-Nutzern genutzt wird, und soll Webentwicklern zu verstehen helfen, was für die Entwicklung komplexer Anwendungen wie Spiele vorausgesetzt werden kann – und was nicht.
Der Firefox Hardware Report ist eine neue Webseite von Mozilla, welche basierend auf den Telemetrie-Daten der Firefox-Nutzer auf dem Release-Kanal Auskunft über die von den Firefox-Nutzern verwendeten Systeme gibt. So ergibt sich ein Bild, wie verbreitet bestimmte Hardware-Konfigurationen sind und was vorausgesetzt werden kann und was nicht – quasi wie caniuse.com, bloß für Hardware statt für unterstützte CSS-Features.
Da der Firefox Hardware Report auf Telemetrie-Daten basiert, werden natürlich nur jene Nutzer berücksichtigt, welche die Telemetrie-Funktion von Firefox aktiviert haben.
Der Bericht beinhaltet Informationen zur Verbreitung der folgenden Dinge:
Wer mehr darüber erfahren möchte, wie dieser Bericht generiert wird, findet diesbezüglich weitere Informationen auf dem Mozilla Tech Blog. Der Quellcode der Webseite ist, wie man es von Mozilla nicht anders gewohnt ist, Open Source.
Der Beitrag Mozilla veröffentlicht Firefox Hardware Report erschien zuerst auf soeren-hentzschel.at.
Bald nach Saints Row 2 wollte ich den dritten Teil anspielen, aber es war absolut unspielbar. Komplette Diashow. Mich hat das etwas überrascht, denn obwohl schon der zweite Teil auf dem System (Radeon HD 7950) nicht toll lief, hatte ich gelesen, dass der dritte besser optimiert sei. Aber da ging nichts.
Vor ungefähr einem Monat, nach einigen Systemupdates, funktionierte Saints Row 3 dann plötzlich. Es lief nicht toll, aber es war gerade so spielbar – auf minimalen Einstellungen und 1280×720, mit massiven FPS-Schwankungen je nach Geschehen auf dem Bildschirm, nach erneutem Übertakten des Prozessors. Und heute, pünktlich zur finalen Mission, läuft es flüssig. Auf Full-HD und in mittleren Einstellungen. Es ist einfach nur großartig, dabei zuzusehen, wie sich der Linux-Desktop in eine valide Spieleplattform verwandelt.
Der folgende Screenshot ist von heute, der weiter unten schon etwas älter. Ich meine man kann deutlich erkennen, wie viel schlechter die Grafikqualität im zweiten ist. Eine solche Änderung durch einen kleinen Treiberupdate, das ist beeindruckend.
Und Saints Row 3 selbst? Es ist wieder ein gutes Spiel. Ich fand es schwieriger hineinzukommen, und ein paar der Nebenmissionen wieder ätzend. Aber man findet dann doch hinein und dann ist es wie der zweite, nur viel überdrehter und absurder. Mit GTA hat das nicht mehr viel zu tun, und das ist gut so, denn es ist schlicht spaßiger.
Wieder gibt es eine Story, in der mehrere gegnerische Banden bekämpft werden müssen. Die sind direkt mit einem überbösen Syndikat verbündet, später kommt dann noch mit STAG das (Scifi-)Militär hinzu. Die vorherigen Kollegen sind wieder mit dabei, wobei Shaundi ziemlich verändert wurde. Die Missionen gleiten alle ins absurde, wenn eine sich anfangs wie eine normale Mission eines GTA anfühlt, kann man sicher sein, dass drei Sekunden später laserschießende Weltraumtentakelmonster aus der Kanalisation kriechen. Wieder gibt es Upgrades, Waffenupgrades, Kleidung und Tattoos, und der Charakter kann ziemlich angepasst werden. Doch anders als im vorigen Teil – man ahnt es – ist es kein Problem, einen völlig absurden Charakter zu erschaffen, z.B. ein hell-blaues Monster statt eines Menschen. Und dem kann dann noch ein Hotdogkostüm angezogen werden. Oder eine Toilette.
Das war fast zu viel für mich. Nicht immer ist alles witzig oder gelungen, es gibt einige Sequenzen (z.B. das Fallen aus dem Flugzeug), die spielerisch komplett anspruchslos sind. Aber Anspruch ist sowieso nicht das Markenzeichen von Saints Row. Es will absurd und spaßig sein, und kriegt das gut hin. Ich freu mich auf den vierten Teil, den ich im letzten Steam-Sale gekauft habe – mal schauen, ob für den ein weiteres Treiberupdate nötig ist.