SUN iLOM, Remote Console und veraltete Verschlüsselungsprotokolle

Eine Remote Console am Server ist gut und schön, wenn sie denn erreichbar ist. SUNs Remote Console unter iLOM wird, zumindest in den älteren Versionen, über Java angesprochen, die Verbindung ist mit SSLv3 gesichert. SSLv3 ist unsicher und sollte daher nicht verwendet werden. Neuere Java JREs bieten SSLv3 nicht mehr an, die Verbindung zur Remote Console schlägt daher mit “No appropriate protocol (protocol is disabled or cipher suites are inappropriate)” fehl.
Und jetzt?
Das Protokoll kann über den Parameter
jdk.tls.disabledAlgorithms=SSLv3
in der java.security des JREs (bei mir wars /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64/jre/lib/security/java.security) reaktiviert werden, damit funktioniert auch die Remote Console wieder.

Youtube mit HTML5 unter FC22 + Firefox

Kürzlich hatte ich Flash von meinem System komplett heruntergeschmissen, um zu sehen ob es nicht auch ohne geht. Mit Youtube gab es allerdings kleine Probleme, so funktionierte die Video-Wiedergabe mit HTML5 nicht sofort, da der H.264 nicht mitgeliefert wurde.
Mit dnf install gstreamer1-libav gstreamer1-vaapi gstreamer1-plugins-{good,good-extras,ugly} und einem Neustart von Firefox wurde die H.264-Unterstützung unter https://www.youtube.com/html5 angezeigt und Videos liefen wieder wie gewohnt.

via http://martin.preisler.me/2014/08/h264-html5-video-in-firefox-on-fedora-20/

OpenStack schnell und einfach auf einem Host installieren

OpenStack auf einem einzigen Host aufzusetzen kann viel Handarbeit bedeuten, muss aber nicht. Über packstack des RDO-Projekts lässt sich OpenStack schnell und einfach installieren und konfigurieren. Zwar bringt Ferdora 22 Packstack von Haus aus mit sich, das Skript scheint aber noch nicht angepasst zu sein. Auf CentOS 7 lief die Installation ohne Probleme durch – nach 30 Minuten war OpenStack installiert und einsatzbereit.

Von den Toten auferstanden – Linux auf einem MacBook 2.1

Durch Zufall bin ich recht günstig an ein MacBook älteren Semesters (2.1, Ende 2006) gekommen. Da die Hardware doch schon etwas betagt ist, laufen aktuelle Versionen von OS X nicht bzw mehr schlecht als recht. Und naja, an OS X bin ich eh nicht interessiert ;-).
Also sollte als Betriebssystem Linux ins Spiel kommen, komplett ohne Dualboot. Das am MacBook verbaute UEFI macht die Sache dabei nicht einfacher.
Es beginnt beim booten des Installationsmediums:
Meine, auf verschiedenste Weisen, erstellten USB-Sticks wurden nicht erkannt. Erst Installations DVDs/CDs wurden erkannt und von ihnen gestartet. Meine erste Distribution, welche ich testete, war Fedora 21 64 Bit. Das Problem kam später, als die Installation fertig und das System sich selbst neu startete. Weil die UEFI-Firmare des MacBook unter 32 Bit läuft, Fedora aber nur 64 Bit Varianten unterstützt, schlägt der Bootvorgang fehl. Die 32 Bit Version startete im Live-System ohne Probleme. Auch die Installation lief ohne Probleme durch. Allerdings hatte ich Anaconda die Festplatte automagisch partitionieren lassen. Dadurch wurde auch die EFI-Partition getötet, welche den Bootloader enthielt. Das Reslutat war ein System, welches nicht mehr booten wollte. Die Lösung war schließlich ein alternativer Bootloader, welcher das System nach OS-Installationen durchsucht und diese auch starten kann. Um rEFInd zu installieren, musste ich die Platte neu partitionieren (GPT, kein MBR) und eine ESP erstellen, auf welcher später der Bootloader landen sollte. Die Partition habe ich an den Anfang der Platte gesetzt (/dev/sda1), 500MB groß, FAT32 mit aktiviertem Boot-Flag. Dies kann man sehr gut mit einem Fedora Live-System erledigen. Auch die anschließende Installation des Bootloaders erfolgte aus dem System:
1. Mounten der ESP nach /boot/efi
2. Ausführen des Installationscripts aus uder rEFInd-Paket
3. Fertig
Wichtig bei der Installation von Linux-Distris ist jetzt, dass /dev/sda1 nicht als Boot-Partition genutzt wird, sondern eine eigene erstellt werden. Bei mir hat es so regelmäßig wieder das System zerschossen.
Danach habe ich mehrer Distributionen ausprobiert ob sie auf dem MacBook überhaupt laufen. Letztendlich bin ich bei Debian 7 hängen geblieben. Die Installation dauerte zwar vergeleichsweise lange, aber im Moment scheint es am stabilsten zu sein. Auch die Performance ist um einiges besser als ich erwartet hatte.

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!

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

vdc cryptfs changepw $neuespasswort

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!

Auf dem Ruhrtalradweg von Winterberg bis Arnsberg

RTR - Start
RTR – Start

Über 230 Kilometer, von der Quelle in Winterberg bis zur Mündung in den Rhein, schlängelt sich der Ruhrtalradweg (RTR) durch das Ruhrtal, meistens flussbegleitend. Gestern stand der Abschnitt Winterberg bis Arnsberg auf dem Programm (ca 70 Kilometer). Um 11:20 Uhr ging es in Winterberg los. Vom Bahnhof aus verlässt man den Ort Richtung Nord-Ost und fährt direkt auf die Ruhrquelle zu. Verfahren kann man sich hier (und auch auf der restlichen Strecke) eigentlich nicht – wenn man auf die Beschilderung achtet. Wir hatten zusätzlich noch das GPS-Gerät mit dem RTR-Track laufen, falls man etwas abseits der Route entdeckt hat und die Strecke wiederfinden möchte. Richtung Osten hatten wir einen sehr guten Ausblick auf ein Wolkenmeer, welches die darunterliegende Landschaft förmlich verschluckte. Nur vereinzelnd ragten höhere Gipfel aus der Suppe.

Ruhrwiese, direkt nach der Quelle
Ruhrwiese, direkt nach der Quelle

Nach 3.3 Kilometer gibt es dann die erste Begegnung mit dem Fluss. Naja, Fluss ist eigentlich gelogen – es ist eher ein Rinnsal, welches den Weg überquert und in einer Wiese verschwindet. Man mag es fast nicht glauben, dass dieses kleine Gewässer bald zu einem großen Fluss wird. Im weiteren Streckenverlauf begleitet man die junge Ruhr fast permanent. Immer wieder überquert man kleine Bäche, welche in die Ruhr münden. Je weiter man Richtung Norden fährt, desto besser kann man zusehen, wie der Fluss wächst und wächst. Nach 20 Kilometern erreicht man das Dörfchen Olsberg, wo die Breite schon auf ca. 10 Meter gewachsen ist. Hier laden mehrere Stellen zur Pause ein. Nebenbei kann man seine Wasserflaschen wieder auffüllen, die Wasserqualität der Ruhr macht einem keinen Strich durch die Rechnung. ;-)

Langeweile muss man auf dem RTR nicht befürchten. Die Wegführung ist abwechslungsreich. Mal führt der Weg direkt am Fluss entlang, mal mit Blick von oben über einen Höhenzug, mal durch Wälder, mal über Wiesen.
Auch gibt es immer wieder interessante Dinge zu sehen. So stehen bei Niedersfeld alte MiG-21 am Wegesrand, ein Segelflugplatz bei Oeventrop und viele alte Brücken, welche sich über die Ruhr erstrecken.
Während man Anfangs noch viel über Wald- und Feldwege fährt, werden die Wege Richtung Arnsberg immer besser. Dies merkt man auch an den gefahrenen Geschwindigkeiten: Für die ersten 10 Kilometer haben wir fast eine Stunde gebraucht, danach konnten wir den Schnitt auf 20km/h heben. Nur im Abschnitt zwischen Meschede und Freienohl fährt man parallel zur L743. Zwar ist der Radweg von der Straße getrennt, doch es gibt schönerer Strecken. Für uns endete die Route in Arnsberg. Der große Vorteil des RTR ist es, dass man mit der Routenlänge ziemlich variabel ist. Von allen größeren Ortschaften kommt man recht bequem per Bahn zurück (oder hin).

Die Strecke ist absolut empfehlenswert, gerade jetzt im Herbst. Auf den ersten 20-30 Kilometern gibt es ein paar kurze Steigungen, welche aber alle machbar sind.
Wer sich die Route auf der Karte ansehen will:
http://johnassel.de/gpxviewer/index.php?gpx=rtr_winterberg-dortmund.gpx
Und direkt die Tour als GPX: http://johnassel.de/gpxviewer/gpx/rtr_winterberg-dortmund.gpx

[map style=”width: auto; height:300px; margin:20px 0px 20px 0px; border: 1px solid black;” maptype=”OSM” gpx=”/blog/wp-content/uploads/rtr_winterberg-dortmund.gpx”]