dnf und alte Metadaten

Dnf wird demnächst in FC22 den Paketmanager yum ersetzen. Dnf kann man jetzt schon im Parallelbetrieb testen. Dabei fiel mir auf, dass yum und dnf Updates ganz unterschiedlich finden:
Nicht selten hatte yum schon eine ganze Stange Aktualisierungen parat, während dnf noch meinte, alles sei aktuell. Der Grund liegt in den Metadaten, die bei yum öfters aktualisiert bzw schneller als veraltet angesehen werden.
dnf -refresh upgrade umgeht dieses Problem zwar, allerdings werden dann immer wieder die neusten Metadaten der Repos heruntergeladen, was u.U. etwas dauern kann.
Um dnf das Verhalten von yum beizubringen, reicht es das Timeout, wann die Metadaten als veraltet gelten, zu ändern. Bei yum sind die Daten nach 6 Stunden veraltet, bei dnf nach 48 Stunden! (Siehe https://www.mankier.com/8/dnf.conf und http://linux.die.net/man/5/yum.conf, jeweils unter “metadata_expire”)
Mit metadata_expire=21600 unter /etc/dnf/dnf.conf verhält sich dnf wieder genau wie von yum gewohnt.

Fedora 21, KDE-NetworkManager, OpenVPN, tun0

Unter Fedora 21 und KDE hat der Netzwerk-Manager die Eigenart die von einer OpenVPN-Verbindung erstellten tun0-Adapter aus seiner Netzwerkliste nicht zu löschen, wenn die Verbindung getrennt wird. Man kann sie zwar per Hand löschen, eine dauerhafte Lösung ist dies aber nicht.
Ein Script mit
#!/bin/bash
[[ ${1::3} == tun ]] && [[ $2 == down ]] && /usr/bin/nmcli connection delete $1
exit 0

unter /etc/NetworkManager/dispatcher.d/tun löst das Problem temporär bis das Verhalten korrigiert wird.

via https://bbs.archlinux.org/viewtopic.php?id=191044

Kompletten Netzwerkverkehr per iptables umleiten

Um den kompletten Netzwerkverkehr per iptables zu einer anderen Adresse umzuleiten, muss zunächst die Weiterleitung von IP-Paketen im System aktiviert werden (sysctl -w net.ipv4.ip_forward=1).
Als nächstes aktiviert man die eigentliche Weiterleitung mit folgenden Regeln:
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p all -j DNAT --to-destination $ipdeszielsystems
iptables -t nat -A POSTROUTING -j MASQUERADE

Bei mir kommt die Umleitung immer dann zum Einsatz, wenn ich einen vServer migriert habe, sich die IP gewechselt hat und nur noch die neuen Einstellungen des DNS-Servers wirksam werden müssen. Dies kann 24h dauern, wodurch Zugriffe auf das alte und neue System erfolgen können. Damit dies nicht passiert, leitet das alte System auf das neue um.
Nachteil: Auch der SSH-Zugriff wird umgeleitet, sodass auf dem Altsystem nur noch per VNC-Konsole über den Host zugegriffen kann. Zudem erscheinen alle umgeleiteten Zugriffe auf dem neuen System mit der IP-Adresse des alten Systems.

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!

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.

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.

pfSense – “Unable to check for updates”

pfSense auf einem Alix-Board ersetzt seit kurzem unseren Border-Router, was auch sehr gut funktioniert. Die Firewall-Distribution hat einen Auto-Updatemechanismus, welcher aber immer mit “Unable to check for updates” oder “Could not contact pfSense update server http://updates.pfsense.org/_updaters” ins Leere lief. Aus dem privaten Netzwerk war die Adresse aber ohne Probleme erreichbar. Die Lösung war schließlich die Aktivierung des DNS-Forwaders auch über das lokale Interface.

pfsense_dnsmask_localhost
Danach konnte der Update-Server problemlos gefunden werden.

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.