Mit Netz und doppeltem Boden – Backup für den vServer

Wer einen eigenen Server betreibt sollte auf jeden Fall eine Backup-Strategie fahren, um im Falle eines Crashes/Angriffes keine wichtigen Daten zu verlieren. Bis jetzt bestand meine Lösung aus einem NFS-Share, welches mein Hoster zur Verfügung stellte, und einem Scrip, welches den kompletten vServer in ein TAR-Archiv schob, komprimierte und verschlüsselte:


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
systemctl stop mariadb
key=`openssl rand 128 -hex`
echo $key > key
path=/storage/`date +"%d-%m-%y"`
mkdir $path
openssl rsautl -encrypt -inkey public.key -pubin -in key -out $path/key.`date +"%d-%m-%y"`.enc
rm key
tar -cO --exclude='/proc' --exclude='/sys' --exclude='/backup' --exclude='/storage' --exclude='buildroot.img' /* | pbzip2 -c | ccrypt -K $key > $path/backup.`date +"%d-%m-%y"`.tar.bz2.cpt
systemctl start mariadb
umount /storage

Was tut dieses Script? Es generiert einen 128 Bit langen Verschlüsselungsschlüssel, welcher mit einem öffentlichen Schlüssel verschlüsselt wird. Der Verschlüsselungsschlüssel wird zur (symmetrischen) Verschlüsselung des komprimierten TAR-Archives genutzt. Beides wird anschließend auf dem NFS-Share gespeichert. Damit das TAR-Archiv nicht zwischengespeichert werden muss, werden alle Vorgänge (Packen, Komprimieren und Verschlüsseln) durch Pipes miteinander verbunden. Der große Nachteil dieser Lösung ist, dass es sehr zeitaufwändig ist, eine einzelne Datei wiederherzustellen. Zuerst muss das Archiv entschlüsselt, dekomprimiert und entpackt werden, was entsprechend dauern kann.
Auf der Suche nach einer besseren Lösung bin ich über duplicity gestolpert. Das Tool bietet die Möglichkeit, verschlüsselte, inkrementelle und einfach wieder herzustellende Sicherungen zu erstellen.


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
#systemctl stop mariadb
PASSPHRASE='GPGSCHLÜSSELHIERREIN'
SIGN_PASSPHRASE='GPGSCHLÜSSELHIERREIN'
export PASSPHRASE
export SIGN_PASSPHRASE
duplicity --exclude /var/tmp --exclude /tmp --exclude /proc --exclude /sys --encrypt-key 987AAD58 --sign-key 987AAD58 -v 8 / file:///storage > /var/log/backup/backup.log
duplicity remove-older-than 3W file:///storage > /var/log/backup/backup_cleanup.log
#systemctl start mariadbi
unset PASSPHRASE
unset SIGN_PASSPHRASE
umount /storage

Die Handhabung ist relativ einfach. Zunächst erstellt man einen GPG-Schlüssel. Anschließend läuft bei mir obiges Script, gesteuert per Cronjob, alle zwei Stunden durch. Über duplicity remove-older-than 3W werden alle Sicherungen, welche älter als 3Wochen sind, gelöscht. Die Wiederherstellung von Dateien erfolgt über duplicity –file-to-restore. Im Moment macht die Lösung einen ganz soliden Eindruck. Hoffentlich tut sie das im richtigen Ernstfall weiterhin.
Ach ja:
Auf jeden Fall die GPG-Schlüssel und den zugehörigen Key extra sichern! Ohne ist das Backup nicht mehr zu entschlüsseln!

Androids Vollverschlüsselung und ein anderes Passwort

Wer unter Android die Vollverschlüsselung aktiviert, muss ein Passwort oder eine PIN festlegen, mit welchem das Gerät wieder entschlüsselt werden kann. Dummerweise wird dieser Schlüssel auch für die Sperrung des Gerätes verwendet, wodurch fast nur schwache Passwörter zum Einsatz kommen. Wer hat schon Lust jedes mal beim Einschalten ein komplexes Kennwort einzugeben? Je kürzer und weniger komplex das Kennwort ist, desto schneller und einfacher lässt sich die Vollverschlüsselung angreifen. Daher liegt es nahe, für beide Szenarien, Verschlüsselung und Displaysperre, verschiedene Kennwörter mit unterschiedlicher Komplexität festzulegen. Leider bietet dies Android nicht von Haus aus an. Wer sein Telefon gerootet hat, kann dies über Umwege trotzdem erreichen. Über die Konsole kann das Passwort der Verschlüsselung mit

geändert werden. Man muss nur höllisch aufpassen, dass man das neue Passwort korrekt eingibt - eine zweite Abfrage, welche Tippfehler abfängt, gibt es nicht!

FC20: Touchpad beim tippen deaktivieren

Beim tippen kann ein aktiviertes Touchpad am Laptop sehr nervig sein. Schnell ist man in der Zeile versprungen und tippt irgendwo im Nirvana weiter. Die einfachste Lösung ist die Deaktivierung des Touchpads während des Tippens. Unter Fedora 20 (sehr wahrscheinlich auch unter anderen Linux-Distributionen) geht dies ganz einfach mit dem kleinen Programm “syndaemon”.

Mit

syndaemon -d -i 1

wird das Programm als Dienst im Hintergrund gestartet (-d) und deaktiviert bei Tastatureingaben das Touchpad. Mir war die standardmäßig eingestellt Zeit, ab wann das Touchpad nach einer Eingabe wieder aktiviert wird, von 2 Sekunden zu lang, deshalb habe ich sie mit dem Parameter “-i 1” verändert.

Wenn das Rad eiert…

…etwa weil der Mantel nicht korrekt auf der Felge sitzt und so eine Unwucht hat, sollte man es mit Spülmittel versuchen.
Genau dieses Problem hatte ich mit den Schwalbe Marathon Tour Plus. Der Mantel des hinteren Laufrads wollte sich partout nicht richtig setzten. Alles ziehen, drücken und kneten half nichts, der Mantel saß stellenweise einfach zu tief in der Felge sobald man den Schlauch aufgepumpt hatte – mit der Folge eines unruhigen Laufs.
Schließlich war eine gute Portion Spülmittel die Lösung. Den Reifen an der Flanke (dort, wo er mit der Felge in Kontakt kommt) gut eingeschmiert und normal montiert, rutschte er mit einem schmatzenden Geräusch in die richtige Position und die Eierei war vorbei.

Fedora und der Realtek RTS5139 Kartenleser…

Fedora bringt standardmäßig keinen Treiber für den Realtek RTS5139 Kartenleser mit, welcher in vielen Laptops verbaut ist.
Die Installation von kmod-staging löst dieses Problem, aber nur bis ein neuer Kernel veröffentlicht wird. Da es mir zu doof war, ein paar Tage ohne Kartenleser da zu stehen, habe ich einen anderen Weg gesucht. Dies führte dazu, dass ich mir den Kernel selbst kompiliere – MIT Treiber. Im Prinzip ist es auch gar nicht schwierig, die Fedora Docs bieten eine ganz gute Anleitung: https://fedoraproject.org/wiki/Building_a_custom_kernel?rd=Docs/CustomKernel

Da ich keine Lust hatte, die Befehle immer wieder manuell einzugeben sind die folgenden Scripte entstanden (die in oben verlinkter Anleitung genannten Tools müssen noch installiert werden):

1_prepare.sh

#!/bin/sh
cd ~
rpmdev-setuptree
yumdownloader --source kernel
rpm -Uvh kernel-*
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ~/rpmbuild/BUILD/

2_configure_kernel.sh

#!/bin/sh
#copy to BUILD/kernel-$ver.$subver.$fedver/linux-$ver.$arch/
make oldconfig
make xconfig
cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic

3_make_kernel.sh

#!/bin/sh
rpmbuild -bb --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec

cleanup.sh

#!/bin/sh
rm -rf BU* S* ~/kernel-*.rpm

Zuerst habe ich in meinem Homeverzeichnis einen Ordner “rpmbuild” erstellt und alle Scripte dort hinein kopiert. Anschließend wird das erste Script ausgeführt. Es lädt den Quellcode des Kernels herunter und entpackt diesen. Danach wir das 2. Script in den Ordner BUILD/kernel-*/linux-*/ kopiert und darin ausgeführt. In dem sich anschließend öffnenden Dialog kann der Kernel konfiguriert werden. Hier sucht man über die Suchfunktion den entsprechenden Treiber, aktiviert das Häkchen und speichert die Konfiguration ab. Dann startet man den Kompiliervorgang mit dem 3. Script. Dies dauert je nach Rechner eine Weile. Ist der Kernel kompiliert finden sich die installierbaren rpms im Ordern RPMS.

Update 18.9.2014: Die neuen Treiber sind jetzt unter rtxs* (siehe https://bbs.archlinux.org/viewtopic.php?pid=1448633) zu finden.

Update 15.12.2014: Wie es scheint sind die Treiber unter Fedora 21 und Kernel 3.17 schon von Haus aus in den Kernel integriert. Zumindest funktionierte der Kartenleser ohne erneute Kompilierung.

Fedora: Opera unter KDE als Standardbrowser

Opera unter KDE als Standardbrowser einrichten ist auf den zweiten Blick doch irgendwie schwieriger. Der erste Schritt bei mir war in den Einstellungen die folgende Option anzupassen:opera_default_browser
Dadurch wurden zumindest schon mal die meisten Links in Opera geöffnet. Aber nicht alle. Ein paar Anwendungen (wie z.B: der Twitterclient Polly) haben immer noch den vorher eingestellten Browser geöffnet.

Erst die Datei /usr/local/share/applications/defaults.list hat mich auf die richtige Spur gebracht. Hier war immer noch die alte Konfiguration hinterlegt, welche auf /usr/share/applications/firefox.desktop als Standardbrowser für HTTP-Links gezeigt hat. Da Opera solch eine Datei scheinbar nicht erstellt/mitliefert habe ich die von Firefox gegebene als Grundlage genommen. Die entscheidende Änderung war die Zeile

Exec=firefox %u

welche zu

Exec=opera %u

wurde.

Letztendlich sah die Datei dann so aus:

[root@daedalus ~]# cat /usr/share/applications/firefox.desktop
[Desktop Entry]
Version=1.0
Name=Firefox
GenericName=Web Browser
GenericName[ca]=Navegador web
GenericName[cs]=Webový prohlížeč
GenericName[es]=Navegador web
GenericName[fa]=مرورگر اینترنتی
GenericName[fi]=WWW-selain
GenericName[fr]=Navigateur Web
GenericName[hu]=Webböngésző
GenericName[it]=Browser Web
GenericName[ja]=ウェブ・ブラウザ
GenericName[ko]=웹 브라우저
GenericName[nb]=Nettleser
GenericName[nl]=Webbrowser
GenericName[nn]=Nettlesar
GenericName[no]=Nettleser
GenericName[pl]=Przeglądarka WWW
GenericName[pt]=Navegador Web
GenericName[pt_BR]=Navegador Web
GenericName[sk]=Internetový prehliadač
GenericName[sv]=Webbläsare
Comment=Browse the Web
Comment[ca]=Navegueu per el web
Comment[cs]=Prohlížení stránek World Wide Webu
Comment[de]=Im Internet surfen
Comment[es]=Navegue por la web
Comment[fa]=صفحات شبکه جهانی اینترنت را مرور نمایید
Comment[fi]=Selaa Internetin WWW-sivuja
Comment[fr]=Navigue sur Internet
Comment[hu]=A világháló böngészése
Comment[it]=Esplora il web
Comment[ja]=ウェブを閲覧します
Comment[ko]=웹을 돌아 다닙니다
Comment[nb]=Surf på nettet
Comment[nl]=Verken het internet
Comment[nn]=Surf på nettet
Comment[no]=Surf på nettet
Comment[pl]=Przeglądanie stron WWW
Comment[pt]=Navegue na Internet
Comment[pt_BR]=Navegue na Internet
Comment[sk]=Prehliadanie internetu
Comment[sv]=Surfa på webben
Exec=opera %u
Icon=firefox
Terminal=false
Type=Application
MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;
StartupNotify=true
Categories=Network;WebBrowser;
Keywords=web;browser;internet;
X-Desktop-File-Install-Version=0.21

In wie weit der Rest relevant ist/gebraucht wird habe ich nicht ausprobiert ;-)

Fedora 20: KDE + Bluetooth-Kopfhörer = segmentation fault

Die Kombination aus Fedora 20 Beta, KDE und Bluetooth Kopfhörer funktioniert zum jetzigen Zeitpunkt eher schlecht als recht. Versucht man, einen Kopfhörer zu verbinden, stürzt bluedevil-audio mit einem segmentation fault reproduzierbar ab. Der Bug ist bekannt, aber noch nicht gelöst. Ein Workaround: bluetoothctl über die Kommandozeile. Es ist zwar etwas umständlicher, funktioniert aber.

bluetoothctl
devices
//Bluetooth MAC des Kopfhörers/Headsets suchen
connect $Bluetooth-MAC

Die Verbindung trennt man dann mit “disconnect”. Logisch irgendwie ;-)
Update 21.12.13: Das Problem ist behoben, eine gepatchte Version von bluedevil ist in den fedora-updates-testing repos.

Fedora: Freeze beim kopieren von größeren Dateien per USB

Warum auch immer, aber beim kopieren von größeren Dateien auf USB-Geräte wurde jeder Rechner unter Fedora 19 langsamer bis unbenutzbar. Die Lösung war die dirty_ratio mit

echo 1 > /proc/sys/vm/dirty_ratio && echo "echo 1 > /proc/sys/vm/dirty_ratio" >> /etc/rc.local

anzupassen. Ohne versucht Fedora wohl aus irgendeinem Grund erstmal den Cache bis 40% (der Standardwert) vollzuschaufeln und dann irgendwann auf den Datenträger zu schreiben. Naja, mit dem geänderten Kernelparameter traten zumindest bei mir keine Lags mehr auf.

via https://bbs.archlinux.org/viewtopic.php?pid=998740#p998740

Android, EAP-TLS, Zertifikate importieren

Android erwartet für die Nutzung von WLAN-Netzwerken welche mit EAP-TLS gesichert sind Zertifikate im PKCS12 Format. Liegen die Zertifikate und Keys nur im PEM Format vor, können diese mit dem folgenden Befehl konvertiert werden.

openssl pkcs12 -export -in cert.pem -certfile cacert.pem -inkey key.pem -out cert.p12

Die entstandene .p12 Datei kopiert man nun auf seinen Androiden und installiert sie mit dem Zertifikatsmanager.
Bei mir schlug der Import jedoch immer wieder fehl, eine Fehlermeldung gab es nicht. Nur im Log tauchte “Import key command failed resp->status = -17” auf, so wirklich weiter half dies aber auch nicht. Erst ein Eintrag im Android-Bugtracker gab mir den entscheidenden Hinweis: Android kam mit der verwendeten Schlüssellänge des Keys nicht klar. Scheinbar liegt das Maximum bei 2048 Bit, mein Key war aber 4096 Bit lang. Erst als ich einen neuen, kürzeren Schlüssel generiert habe, wurde der Key anstandslos akzeptiert. Ich hoffe doch sehr, dass Google hier bald nachbessert, so selten sind Schlüssel mit Längen > 2048 Bit nämlich nicht.

Update: Android 4.4 scheint 4069 Bit Schlüssel zu akzeptieren.