Arch Linux Tux

[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

U2F in Firefox 57 aktivieren

Die aktuelle Firefox Version (57/Quantum) kann, sofern aktiviert, auch mit dem beliebten U2F Standard umgehen.

Was ist U2F?

U2F ist ein Standard zur Anbindung eines zweiten Faktors (2FA) zur Authentifizierung gegenüber von Webanwendungen und Diensten, für viele eine beliebte Alternative zum Google Authenticator. Der Vorteil ist, das selbst bei bekanntem Benutzernamen und Passwort, ohne den zusätzlichen Faktor, ein Login und Missbrauch eines Dienstes ausgeschlossen ist. Vor allem für zentrale Dienste wie E-Mail oder dem Online Banking ist dies sehr wichtig, wobei gegenwärtig vor allem typische Nerd Dienste 2FA unterstützen. Das Prinzip von 2FA ist, das zum Login sowohl Wissen (Benutzername/Passwort) als auch Besitz (USB Dongle) notwendig sind.

U2F in Firefox aktivieren

Die Firefox Unterstützung für U2F muss gegenwärtig über about:config aktiviert werden, und zwar indem der Schlüssel security.webauth.u2f auf den Wert true gestellt wird. Ist dies erledigt funktioniert zumindest beim Test über die Yubico Demo Seite, sowohl die Registrierung als auch die spätere Anmeldung ohne Probleme. Ich gehe stark davon aus, das im Laufe der nächsten Firefox Versionen das manuelle aktivieren der U2F Unterstützung entfällt.

Aktuelle Probleme

Leider gibt es noch einige Seiten, vor allem von Google, welche U2F zwar offiziell unterstützen, diese Unterstützung jedoch auf bestimmte Browser (Chrome) limitieren. Hintergrund ist, dass diese Seiten prüfen, welcher Client verwendet wird, anstatt wie technisch korrekt zu prüfen, ob der Client bestimmte Features bereitstellt.

Das größte Problem ist aber die nach wie vor geringe Verbreitung von U2F oder 2FA im allgemeinen, vor allem die meisten deutschen Banken befinden sich hier noch in der Steinzeit. Allerdings ist die Branche auch erst damit beschäftigt die Sache mit der Digitalisierung zu lernen, in 5-10 Jahren klappt es dann auch mit der sicheren Authentifizierung ;)


Zufälliges Video mit ffplay abspielen

2017-11-24 22:30 | Kategorien: arch debian linux opensource software ubuntu

Im Laufe der Zeit sammelt sich auf der Festplatte sicherlich der das ein oder andere Porno Musikvideo. Oft verbringt man dann, ähnlich wie bei Streaming Diensten wie Netflix oder Amazon Instant Video, mehr Zeit mit der Auswahl, als mit dem tatsächlichen Konsum.

Das muss nicht sein, denn zumindest für lokale Dateien leistet die bash und ffplay (aus ffmpeg) wirklich gute Dienste.

#!/bin/bash
ls | sort -R | tail -n 1 | xargs -I A ffplay "A"
Das ganze einfach als randvideo.sh abspeichern und per chmod 0755 randvideo.sh die passenden Rechte setzen, schon wählt ./randvideo.sh innerhalb dieses Ordners für euch das passende Unterhaltungsprogramm aus dem Datengrab.

Doch was macht dieser Befehl? Nun, er macht folgendes:

  1. Ausgabe der Dateien im aktuellen Ordner
  2. Sotieren der Dateien nach zufälliger Reihenfolge
  3. Erstes Ergebnis nehmen, den Rest verwerfen
  4. Programm mit zuvor gewähltem Ergebnis ausführen
Das Script wurde bewusst einfach gehalten und es wird kein Anspruch darauf erhoben, dass dieses in jeder Situation fehlerfrei arbeitet. Vielmehr soll es als Inspiration dienen ;)

Update #1

Der liebe Rasi hat mir eine alternative Implementierung per Mail vorgeschlagen, welche ich euch nicht vorenthalten möchte:

foo=(*); rand=$[ $RANDOM % ${#foo[@]} ]; ffplay "${foo[$rand]}"
Der Vorteil dieser Lösung ist, dass alles innerhalb der bash abläuft und auf die Pipes meiner Lösung verzichtet wird. Der Nachteil ist, dass es IMHO für Laien schwerer zu verstehen ist was passiert.

Der Ablauf ist beinahe gleich, der einzige Unterschied ist, dass ich bei meiner Lösung die Dateien zufällig sortiere, während die Lösung von Rasi einfach einen zufälligen Eintrag aus der Liste auswählt.


Strom sparen mit udev und hdparm

Für meine Datensicherungen nutze ich ausschließlich Platten vom Typ Western Digital Green, oder wie in Technikforen immer liebevoll Ökoplatten genannt. Diese werden per Wechselrahmen in das System eingebunden und regelmäßig rotiert um die Sicherungen auf verschiedene Datenträger zu verteilen. Die Platten werden nur für wenig Betriebszeit pro Tag wirklich benötigt, eben immer dann, wenn eine neue Sicherung zu erstellen ist. Aus diesem Grund fahren die Platten automatisch nach 20 Minuten in den Standby Betrieb. Gemäß Spezifikation benötigt dieser Typ Platten dann lediglich 0,4 Watt statt 2,5 Watt Leistung.

Eine einfache, und sehr dynamische Lösung, ist durch udev möglich. Man prüft, welcher Typ ein Datenträger ist, und stellt dementsprechend das Energiemanagement eben dieser Platte passend ein. Hierzu legt man die Datei /etc/udev/rules.d/50-wdgreen-hdparm.rules mit folgendem Inhalt an:

ACTION=="add|change", KERNEL=="sd*", ATTRS{model}=="WDC WD10EZRX*" RUN+="/usr/bin/hdparm -S 240 /dev/%k"
Durch den Befehl sudo udevadm control --reload lädt udev seine Regeln neu. Ab dem nächsten Plattentausch werden die Regeln dann automatisch angewendet.

Der Trick ist hierbei wirklich den Typ der Festplatte zu verwenden, man möchte ja nicht versehentlich die Platten aus seinem RAID ständig in den Standby schicken. Den für mein ständig verfügbares Datengrab verwende ich ausschließlich Platten, die auch 24/7 tauglich sind, für welche ein ständiger Wechsel zwischen Standby und Normalbetrieb als schädlich sein könnte.

Der genaue Typ einer Festplatten kann per udevadm info --query=all --attribute-walk --name=/dev/sdd | grep model ermittelt werden. Bevorzugt kürzt man die Typenbezeichnung etwas ein, um verschiedene Chargen des gleichen Typs mit zuvor genannter Regel zu treffen. In meinem Beispiel wurde so WDC WD10EZRX-00L auf WDC WD10EZRX* gekürzt.


borgbackup: LZMA, ZLIB und LZ4 im Vergleich

2016-11-12 16:07 | Kategorien: arch debian linux opensource python software ubuntu

Seit einigen Wochen experimentiere ich mit Borg Backup als mögliche Lösung für mein neues, privates, Backup Konzept. Die Ziele dieses Konzeptes würden den geplanten Umfang dieses Artikels sprengen, ich möchte an dieser Stelle daher nur auf einen älteren Artikel von mir zum Thema Datensicherung verweisen.

Im Zuge der Planung für dieses neue Konzept habe ich verschiedene Backup Programme getestet und anschließend rein subjektiv bewertet. Neben einer möglichst einfachen Benutzbarkeit war es mir auch wichtig, möglichst effektiv an meine gesicherten Daten zu kommen und gleichzeitig gut mit inkrementellen Sicherungen arbeiten zu können.

Ohne die Alternativen zu erwähnen, war Borg Backup das Resultat meiner "Forschungsarbeit", es vereint die Möglichkeiten der Kompression, Deduplizierung als auch Verschlüsselung in einem Tool, zusätzlich ist es möglich, ältere Datenstände per FUSE Dateisystem direkt verfügbar zu machen.

Sobald man sich für ein Backup Programm/Tool entschieden hat, geht es jedoch schon an dessen Konfiguration. Ein wesentlicher Aspekt, ist hierbei das verdichten von Daten mittels Kompression, und der sich daraus ergebende Gewinn an Speicherplatz unter Einsatz wertvoller CPU Zyklen. CPU Zyklen kosten Geld, bedingt durch die dafür nötige Energie. Je nach verbautem Prozessor, im für die Datensicherung notwendigen Rechner, wird Wärme erzeugt und Energie beim Energieversorger verrechnet.

Doch nicht nur die ökologischen und wirtschaftlichen Gesichtspunkte sollte man beachten, sondern auch das ein größerer Zeitverbrauch auch bedeutet das die Sicherungszyklen länger werden müssen. Als Referenz dient hierbei die Zeit, welche erforderlich ist, eine inkrementelle Sicherung zu erzeugen. Dauert es 2 Stunden die 500 GiB zu sichernden Daten auf Änderungen zu prüfen, diese zu komprimieren und anschließend zu sichern, dann kann minimal alle 2 Stunden eine neue Sicherung erzeugt werden.

Lange Sicherungszyklen führen dabei automatisch zu einem Zeitfenster in welchem ungesicherte Änderungen im Schadensfall verloren gehen. Die beiden Ziele, eine möglichst gute Kompression zu erreichen, und gleichzeitig möglichst schnell zu sichern, stehen also im Widerspruch. Bei den heute erzielbaren Preisen für zusätzlichen Speicherplatz (€/TB) ist es eine Überlegung wert nicht bestmöglich, sondern stattdessen so gut wie nötig, zu komprimieren.

Zuletzt bestehen unsere heute verfügbaren und sehr großzügig bemessenen Datenmengen auch primär aus Daten, die sich schlecht bis kaum komprimieren lassen. Wer eine große Musik und Filme Sammlung sein eigen nennt, kann hiervon sicherlich ein Lied singen.

Nach all diesen, hier zumindest grob dargestellten Überlegungen, stellte sich mir die Frage aller Fragen: Wie groß ist der Zeit und Platz Unterschied für die von Borg Backup unterstützten Kompressionsmöglichkeiten? Aktuell bietet Borg Backup folgende Möglichkeiten:

Da es sich bei meinem Testsystem um den Homeserver handelt, schwankte die zu sichernde Datenmenge mit jeweils +/- 10 GiB pro Testlauf. Der Einfluss hiervon auf das Gesamtergebnis ist aber deutlich niedriger als erwartet. Hier kurz und schmerzlos die Ergebnisse im Überblick:

Name: 2016-11-02_17:17:43
Fingerprint: e1a2cf764b5e8f1f024507ec1a9149ffa547583c72e56e0ff0c47c95304be368
Hostname: server
Username: root
Time (start): Wed, 2016-11-02 17:17:43
Time (end):   Wed, 2016-11-02 21:54:29
Command line: /usr/bin/borg create --lock-wait 3600 -s -C none /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244822

                       Original size      Compressed size    Deduplicated size
This archive:              532.15 GB            532.15 GB            501.53 GB
All archives:              532.15 GB            532.15 GB            501.53 GB

                       Unique chunks         Total chunks
Chunk index:                  407311               442322
Name: 2016-10-29_20:22:10
Fingerprint: 19e4c5ada051047065cefad817022a72fe6e3dc24bde1ead47c4080fe41749c8
Hostname: server
Username: root
Time (start): Sat, 2016-10-29 20:22:10
Time (end):   Sun, 2016-10-30 01:03:44
Command line: /usr/bin/borg create -s -C lz4 /mnt/backup/weekly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249949

                       Original size      Compressed size    Deduplicated size
This archive:              540.24 GB            533.61 GB            503.59 GB
All archives:              540.24 GB            533.61 GB            503.59 GB

                       Unique chunks         Total chunks
Chunk index:                  414894               450402
Name: 2016-10-30_13:00:22
Fingerprint: da644b0301e9bcc76ecafa5b221ff3382d0525725a6a502b951d466eb433fadb
Hostname: server
Username: root
Time (start): Sun, 2016-10-30 13:00:22
Time (end):   Sun, 2016-10-30 22:58:35
Command line: /usr/bin/borg create --lock-wait 3600 -s -C zlib,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249302

                       Original size      Compressed size    Deduplicated size
This archive:              530.58 GB            515.89 GB            486.54 GB
All archives:              530.58 GB            515.89 GB            486.54 GB

                       Unique chunks         Total chunks
Chunk index:                  410586               446084
Name: 2016-10-31_18:00:11
Fingerprint: 4e0678501bf551fa57458f9762aacb1c2ee13380a18f1612cf930e786fb93061
Hostname: server
Username: root
Time (start): Mon, 2016-10-31 18:00:11
Time (end):   Wed, 2016-11-02 13:28:34
Command line: /usr/bin/borg create --lock-wait 3600 -s -C lzma,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244775

                       Original size      Compressed size    Deduplicated size
This archive:              532.14 GB            514.07 GB            485.11 GB
All archives:              532.14 GB            514.07 GB            485.11 GB

                       Unique chunks         Total chunks
Chunk index:                  407571               442572

Lässt man diese Ergebnisse etwas auf sich wirken, kommt man auf folgendes Ergebnis:

  • Keine Kompression dauert ca. 16606 Sekunden bei 532.15GB zu 501.53GB
  • LZ4 Kompression dauert ca. 16894 Sekunden bei 540.24GB zu 503.59GB
  • ZLIB Kompression dauert ca. 35893 Sekunden bei 530.58GB zu 486.54GB
  • LZMA Kompression dauert ca. 70103 Sekunden bei 532.14GB zu 485.11GB

Die Zeiten hier noch als Tabelle, für den schnellen Vergleich:

KompressionZeit (Sekunden/Minuten/Stunden)Zeit (Differenz)Original vs. Compressed Size
Keine16606 / 276 / 4.61--
LZ416894 / 281 / 4.69+1.73%-1.23%
ZLIB35893 / 598 / 9.97+116.14%-2.77%
LZMA70103 / 1168 / 19.47+322.16%-3.4%

Zu beachten ist, dass ich in der zuerst aufgeführten Liste die Größe inkl. Deduplizierung als Referenz genommen habe, in der Tabelle aber tatsächlich nur die Kompression als solches. Deduplizierung brachte unabhängig von der Kompression ca. 6% an Platz ein, was jede der getesteten Kompressionsmöglichkeiten schlägt.

Meine Empfehlung lautet daher LZ4 als Kompression zu benutzen und sich mit dem Rest erst nicht zu beschäftigen, eine Ausnahme dürften Personen sein, deren Daten weitgehend aus komprimierbaren Inhalten bestehen, also z.B. lokale Kopien der Wikipedia oder Quelltext von Programmen. Beim durchschnittlichen Anwender dürfen jedoch Mediendaten der größte Teil der genutzten Datenmenge sein, welche sich eben nur sehr schlecht weiter komprimieren lassen.


Disk Images platzsparend archivieren

2016-11-12 15:00 | Kategorien: arch debian linux opensource software ubuntu windows

Windows ist bei mir vor allem ein Zweitsystem, es dient für Steam zum Spielen und für Lightroom um meine Fotos zu bearbeiten. Das alte Windows 7 wollte seinerzeit durch Windows 10 ersetzt werden, denn der aktuelle PC soll noch länger genutzt werden als es der Service für Windows 7 gestattet.

Ein wichtiger Aspekt für große Veränderungen an einem System ist natürlich das Backup, während die Mediendaten, welche ich nutze entweder auf dem Homeserver liegen (Fotos) oder aus der Cloud kommen (Steam) ist das Betriebssystem als solches bei mir nicht im Backupkonzept vorgesehen. Zu groß der Platzverbrauch, zu gering der Profit.

Die einfachste Möglichkeit eine komplette Festplatte 1:1 zu sichern ist ein Disk Image, doch dafür benötigt man Platz mit der gleichen Größe, wie die Quelle von welcher man ein solches erstellen möchte. Die Nutzung einer Festplatte ist aber in der Regel kleiner, meist sogar deutlich, als die tatsächlich vorhandene Kapazität eben dieser. Die Idee ist daher mit möglichst geringem Aufwand, möglichst viel Platz zu sparen.

Windows verkleinern

Zuerst kann man, sofern Windows auf der Quelle ist, die Auslagerungsdateien und die Hibernation Files zu deaktivieren, das allein spart in der Regel schon deutlich Platz. Der nächste Schritt ist die obligatorische und großzügige Datenträgerbereinigung mit dem gleichnamigen Tool.

Jetzt kommt das Wichtigste: Das überschreiben der nicht vom Betriebssystem benötigen Blöcke im Dateisystem mit nullen. Der Hintergrund liegt in der Struktur moderner Betriebssysteme versteckt, den dort werden Dateien und dementsprechend auch Blöcke auf dem Datenträger, nicht mehr gelöscht, sondern lediglich als frei markiert. Ein Verhalten, das gut für die Geschwindigkeit und eventuell erforderliche Wiederherstellungsmaßnahmen ist, aber sehr schlecht um davon ein Image zu machen.

Um zuvor genanntes Problem zu umgehen, kann man sich das Tool sdelete herunterladen, und anschließend in einer Befehlszeile mit Administratorrechten ausführen: sdelete.exe -z c:. Dieser Prozess dauert je nach Geschwindigkeit des zugrunde liegenden Datenträgers etwas. Nach Abschluss sollte man das Betriebssystem herunterfahren und in sein Lieblingslinux booten.

Möglichkeiten

In meinem Fall waren nach dieser Aktion noch ca. 96GiB Nutzdaten (inkl. Betriebssystem) vorhanden, auf einem Datenträger mit einer Kapazität von 250GB. Die Frage, die sich mir nun stellte, war, wie viel Platz benötige ich tatsächlich um die Bruttodatenmenge, also die Kapazität vom Datenträger, als Image zu sichern. Zur Auswahl standen für mich dabei 2 Verfahren:

Nun stelle sich für mich die alles entscheidende Frage: Was ist der Größen und Zeitunterschied zwischen Sparse File mit dd_rescue und lzop?

Sparse File

Mit dem Befehl dd_rescue -a -d -b 32M /dev/sdb sdb_backup.img erzeugte ich zuvor genanntes Sparse File, basierend auf dem Block Device /dev/sdb. Der gesamte Vorgang dauert bei meinem System 9 Minuten und 12 Sekunden, je nach Kombination aus HDD/SSD dauert dies mehr oder weniger lang. Das Ergebnis ist eine Datei die zwar mit 239GiB angegeben ist, aber nur 145 GiB auf dem Datenträger verbraucht:

[root@pc2007:/srv] 21s $ ls -l -h -s
145G -rw-r----- 1 root   root  239G 17. Jun 16:53 sdb_backup.img

LZO Compression

Der nächste Versuch war es mittels lzop < /dev/sdb > sdb_backup.image.lzo ein LZO Komprimiertes Images zu erzeugen. Dieses mal dauerte der Vorgang 10 Minuten und 7 Sekunden, ein marginaler Unterschied, wenn man bedenkt, dass noch eine Kompression der Daten durchgeführt wird. Das Ergebnis in diesem Fall ist eine Datei welche 107 GiB groß ist, also ca. 26% weniger Platz im Vergleich zum Sparse File benötigt:
[stefan:~] 10m32s $ ls -l -h -s /srv/sdb_backup.image.lzo 
107G -rw-r--r-- 1 root root 107G 17. Jun 17:17 /srv/sdb_backup.image.lzo

Fazit

Als kurzes Fazit lässt sich sagen das sich die Kompression mit lzop bewährt hat, vor allem weil ein derartiges Image auch auf Dateisysteme kopiert werden kann, die nicht Sparse fähig sind. Für mein neu geplantes Backup Konzept werde ich einen weiteren Blick auf die Kompression mittels LZO und LZ4 werfen, doch dazu später mehr. Mit anderen Kompressionsmöglichkeiten kann zweifelsfrei eine noch kleinere Datei (Image) erzeugt werden, der Zeitaufwand darf hierbei jedoch nicht unterschätzt werden.