Beim Versuch den Simfy Desktop Player zu installieren überraschte zypper gerade mit folgender Meldung:

2 neue Pakete zu installieren.
Gesamtgröße des Downloads: 22,4 MiB. Nach der Operation werden zusätzlich 47,5 MiB belegt.
Fortfahren? [j/n/?] (j): j
Ungültige Antwort 'j'. [j/n/?] (j): j

Bleibt die Frage, was er damit sagen wollte:

• Diese Software willst du eigentlich gar nicht verwenden?
• Heißt ja, wirklich immer ja?
• …

As KDE3 is again part of the official openSUSE 12.1 repositories (thanks to all who made this happen), I took the chance to create an installable livecd. Besides a preconfigured KDE3 desktop, it contains additional software like Mozilla Firefox, Thunderbird and LibreOffice. YaST2 is available for administrative tasks like system configuration or software management. The media does not contain all language packs due to size limitations, but they could be easily installed. The KDE3 language packages are named kde3-i18n-$LANG, e.g. kde3-i18n-eo.

In order to to emphasize the feeling of good old times, the artwork is based on SUSE 10.1. The kde3-gtk-qt-engine is included to give a unique experience over GTK and QT applications and KDE4 applications make use of the Plastique widget style and Plastik colors.

The x86_64 and the i686 iso images have been created using the kiwi tools. You can download the kiwi description and build your customized version. Just make sure you have kiwi and kiwi-config-openSUSE-12.1 installed and run create_livecd.sh from the archive. (You can adjust the image_arch variable within the script according to your build architecture)

If you got any further questions concerning KDE3 on openSUSE, please take a look at the openSUSE KDE3 wiki page and join the mailinglist.

PS: And please don’t forget to vote for me

Den Artikel Doppelmoppel – IPv6-Zugang fürs LAN nachrüsten in der aktuellen c't möchte ich nutzen um auf zwei Punkte hinzuweisen welche in den meisten Dokumentationen zum Thema leider fehlen, ohne die es unter openSUSE aber nicht funktioniert.

• Das mit dem LAN verbundene Netzwerkinterface benötigt eine gültige IPv6-Adresse aus dem LAN-Subnetz. Diese muss von Hand vergeben werden, da die Zuweisung per radvd am lokalen Interface nicht funktioniert.

  Diese Adresse kann man via ifconfig add <in radvd eingetragenes prefix>:<mac addresse>/64 vergeben. Ist die Link-lokale Addresse z.B. fe80::442b:39ff:f231:95cd/64 und das Prefix 2a01:498:4c8::/64 so wäre die Addresse 2a01:498:4c8:0:4a5b:39ff:feed:95cd/64.

  Hat das lokale Interface keine gültige IPv6 im LAN-Subnetz werden die aus dem LAN kommenden Pakete vom Router verworfen.

• Nutzt man die SuSEfirewall2 muss man diese so konfigurieren, dass sie Verbindungen vom LAN ins IPv6 zulässt. Per Default blockt die SuSEfirewall2 nämlich alle durchzuleitenden IPv6-Pakete.

  Hierzu editiert man die Datei /etc/sysconfig/SuSEfirewall2 und ändert den Wert FW_FORWARD auf "<lokales IPv6-Netz>,2000::/3". 2000::/3 bezeichnet alle gültigen IPv6-Adressen. Im obigen Beispiel wäre der Eintrag dann FW_FORWARD="2a01:498:4c8::/64,2000::/3". Wichtig bei diesem Eintrag ist die Reihenfolge, denn Verbindungen sind immer vom ersten zum zweiten möglich. Wer die Einträge vertauscht erlaubt also dem ganzen Internet Zugriff aufs LAN, kommt aber nicht raus.

Zum Abschluss möchte ich noch auf ein allgemeines Problem bei IPv6 hinweisen. Ein Teil der eigenen IPv6-Adresse wird aus der MAC-Adresse des eigenen Rechners abgeleitet. Dadurch ist man natürlich dauerhaft im Netz identifizierbar. Um das dadurch entstehende Datenschutzproblem zu entschärfen gibt es die IPv6 Privacy Extension, deren Aktivierung ich jedem ans Herz legen möchte. Wie das geht beschreibt ein ausführlicher Artikel bei Heise-Netze für alle Betriebssysteme. Ob die Aktivierung der Privacy Extensions erfolgreich war kann man z.B. durch den Aufruf von sixxs.net prüfen, welches oben rechts die aufrufende IPv6-Adresse anzeigt.

OpenSUSE bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners. Glücklicherweise bietet LUKS aber die Möglichkeit diese auf einem USB-Stick zu speichern, womit auch bei solchen Maschinen ein komfortabler Start möglich ist.

Achtung: Diese für openSUSE 11.3 erstellte Anleitung funktioniert bis einschließlich openSUSE 13.1. Auf openSUSE 13.2 und openSUSE Leap 42.1 habe ich sie nicht getestet. Auf openSUSE Leap 42.2 funktioniert sie nicht mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.

Ist ein USB-Stick als Schlüssel sicher?

Sicherheit ist immer relativ zur Bedrohung zu sehen. Auch beim USB-Stick stellt sich also die Frage wovor er schützen soll. Beim stationär zuhause stehenden Rechner hat die Verschlüsselung vor allem eine Funktion, sie schützt die Daten wenn die betroffen Festplatten mal das eigene Haus verlassen. Hierbei gibt es im Prinzip nur zwei Fälle. Stellt sich eine Platte während der Garantiezeit als defekt heraus so erspart einem die Verschlüsselung das heutzutage sehr zeitaufwendige Löschen der Platte. Wird die Festplatte entwendet, so ist sie ohne den USB-Stick, der natürlich in diesem Fall nicht im Rechner gesteckt haben darf, auch nicht auszulesen.

Ein großer Vorteil des USB-Sticks besteht hier darin, dass er sehr lange Passwörter ermöglicht. Möchte man lange Passwörten auf klassischem Weg verwenden kommt man um ein Aufschreiben des Passworts oft auch nicht herum. Außerdem gewinnt man eine Möglichkeit die Herausgabe des Passworts zu verweigern, sollte man je dazu aufgefordert werden. Bei einem langen Passwort welches man nie getippt hat ist die Chance sich zu erinnern nicht existieren. Auch hier gilt natürlich, der USB-Stick darf dann nicht trivial dem Rechner zuzuordnen sein.

Die Anleitung

Backup

Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl mkinitrd sonst dennoch aktualisiert werden.

cp /boot/initrd-2.6.34-12 /boot/safe-initrd-2.6.34-12
cp /boot/vmlinuz-2.6.34-12 /boot/safe-enable-vmlinuz-2.6.34-12

title SafetyNet -- openSUSE 11.3 - 2.6.34-12
    root (hd0,0)
    kernel /safe-vmlinuz-2.6.34-12 root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x317
    initrd /safe-enable-initrd-2.6.34-12

Anlegen des Schlüssels

mkfs.ext2 -L keystick /dev/sdb

tune2fs -L keystick /dev/sdb

Das Label kann natürlich frei gewählt werden. Es dient später zur Identifizierung des Sticks. Dies hat zwei Vorteile:

• Der USB-Stick unabhängig von hinzugekommenen oder entfernten Datenträgern gefunden
• Anders als bei der Identifizierung über die ID des Sticks kann man einen zweiten Stick mit gleichem Label als Backup verwenden. Ich recycle gerne nutzlose Werbegeschenke für diese Aufgabe. Sollte mal eines kaputt gehen spare ich mir das Zeitaufwendige zurückspielen des Backups der ganzen platte, da ich den Schlüssel ja noch von einem zweiten USB-Stick laden kann.

Anschließend sollte ein Passwort generieren und auf dem USB-Stick hinterlegen. Meine bevorzugte Methode ist diese:

pwgen -s 1024 1 > /media/keystick/keyfile

Nun kann man den erzeugten Schlüssel der verschlüsselten Partition hinzufügen. Leider verhält sich LUKS leicht unterschiedlich was interaktiv eingegebene Schlüssel und Schlüsseldateien angeht. Deshalb müssen wir unseren Schlüssel "interaktiv" eingeben. Hierzu erzeugt man zunächst eine Datei welche eine Zeile mit dem bei der Installation gewählten Schlüssel und eine mit dem neuen enthält.

cat oldkey /media/keystick/keyfile > tmp

cryptsetup luksAddKey /dev/sda2 < tmp

rm tmp

Um zu testen ob der Schlüssel korrekt hinzugefügt wurde kann man probehalber einen leeren Schlüssel hinzufügen. LUKS ist schlau genug diesen Schlüssel nicht wirklich aufzunehmen:

cryptsetup luksAddKey /dev/sda2 < /media/keystick/keyfile

Erstellen der neuen Initramdisk

usb_storage scsi_mod

Um LUKS den Schlüssel zu übergeben benötigt man ein Skript welches ihn vom USB-Stick liest. Dies kann an einer beliebigen Stelle im Dateisystem liegen, es wird beim erstellen der Initramdisk in diese gepackt:

#!/bin/sh

STICK=/dev/disk/by-label/keystick
FSTYPE=ext2
slumber=150
modprobe usb-storage 1>&2
modprobe scsi_mod 1>&2
mkdir /keystick 1>2&
sleep 5 1>2&

while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
      sleep 1
      slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /keystick ; then
   $( echo 'FAILED!!!' ) 1>2&
   echo ''
   exit 1
fi

cat /keystick/keyfile

umount /keystick 1>2&

Damit LUKS weiß, dass es den Wert von einem Skript erhält muss die Datei /etc/crypttab angepasst werden:

cr_sda2         /dev/sda2       none    initrd,luks,keyscript=/root/keyscript.sh

• Ist keyscript gesetzt ist keine interaktive Eingabe mehr möglich. Deshalb sollte man die alte Initramdisk (welche die alte Konfiguration enthält) vorher sichern.
• Der Wert initrd ist notwendig, da openSUSE bei der Generierung der Initramdisk sonst nicht merkt, dass es das Keyscript mit einpacken muss.

Zu guter letzt kann durch den Aufruf von mkinitrd die neue Initramdisk erstellt werden. Ein Neustart sollte den Schlüssel dann vom USB-Stick lesen anstatt diesen interaktiv zu erwarten.

Hat man die neue Konfiguration hinreichen getestet kann man den bei der Installation vergebenen Schlüssel aus LUKS entfernen und die gesicherte Initramdisk löschen.

Eine Anmerkung zur Distributionsaktualisierung

Diese Anleitung habe ich ursprünglich anhand von openSUSE 11.3 erstellt. Sie gilt aber auch für aktuellere Versionen bis 13.1. Auf openSUSE Leap 42.2 funktionierte diese methode aber nicht! Auf neuere Versionen kann man über das normale DVD-Update aktualisieren. Hierbei muss man allerdings die verschlüsselte Partition über einen eingetippten Schlüssel öffnen. Hierzu hilft es den bei der initialien Installation verwendeten Schlüssel nicht deaktiviert zu haben, oder aber temporär per cryptsetup luksAddKey einen kürzeren Schlüssel hinzuzufügen. Getestet habe ich auf diese Weise das Update von 11.3 auf 11.4 und von 11.4 auf 12.1. Der Installer warnt einen zwar, dass es Probleme geben kann, wenn man Partitionen per Kernel Device Name mountet, dies hat sich aber bisher nicht als Problem herausgestellt.

Quellen

Da die Literatur — was openSUSE angeht — zu diesem Thema leider noch sehr dürftig ist habe ich mich vieler Quellen bedient, von denen ich hier nur die wichtigsten nennen möchte:

• http://forum.ubuntuusers.de/topic/luks-root-partition-mit-schluessel-auf-usb-st/#post-1928847 lieferte die Vorlage für mein Keyscript.
• http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions hilft enorm beim Verständnis.
• http://forums.fedoraforum.org/showthread.php?t=241942 zeigt im Prinzip den ganzen Vorgang, funktioniert leider nicht 1:1 für openSUSE.
• http://wejn.org/how-to-make-passwordless-cryptsetup.html zeigt mehrere Variationen des Themas, aber passt auch nicht direkt auf openSUSE.
• http://raftaman.net/?p=300 ist inspirierend, löst aber nicht ganz das gleiche Problem (der verwendete USB-Stick ist cool).
• https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Remote_unlocking_of_the_root_.28or_other.29_partition liefert Grundlagen, wenn man dies möchte.

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert.

Hat man den Treiber nach der Anleitung auf der Webseite installiert, so kann man mit dkms status prüfen ob dieser im System erfolgreich installiert wurde. Auf System mit Kernel 2.6.30 aufwärt bekommt man hier nur die enttäuschende Meldung: hdjmod, 1.28: added. Wäre die installation erfolgreich gewesen müsste hier installed stehen.

Der nächste Schritt nach dem add ist der build. Ein Blick in das Logdatei /var/lib/dkms/hdjmod/1.28/build/make.log zeigt das Problem:

/var/lib/dkms/hdjmod/1.28/build/device.c:1663: error: implicit declaration of function ‘snd_card_new’

Der Patch behebt das Problem indem er für neuere Kernel den Funktionsaufruf durch auf die neue Funktion snd_card_create ändert. Um ihn anzuwenden wechselt man in das Verzeichnis /usr/src/hdjmod-1.28 und ruft dort sudo patch -p1 < /path/to/hdjmod_kernel_2.6.30.patch auf. Anschließen baut man mit sudo dkms build -m hdjmod -v 1.28 das Modul und installiert es mit sudo dkms install -m hdjmod -v 1.28.

Anschließend kann man im DJ Control Panel sehen, dass der Treiber beim Anschließen der Konsole erfolgreich geladen wird. Insgesamt ein gutes Beispiel dafür, wieso man Treiber Open Source halten sollte, aber leider auch ein gute Beispiel, wieso man Treiber nicht außerhalb des Kernels pflegen sollte.

>Hier kann man den Patch herunterladen<

Mystic Mine ist ein lustiges Independent-Spiel das man ähnlich wie Frozen Bubble mal schnell zwischendurch spielen kann. Und das beste daran, es gibt eine native Linuxversion.

Leider scheiterte mein Versuch diese Linuxversion zu nutzen mit folgender Meldung:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/cx_Freeze/initscripts/Console.py", line 29, in 
  File "monorail.py", line 34, in 
  File "koon/app.py", line 10, in 
  File "koon/snd.py", line 4, in 
  File "ExtensionLoader_pygame_mixer.py", line 12, in 
ImportError: libSDL_mixer-1.2.so.0: cannot open shared object file: No such file or directory

Das ist mal ein schönes Beispiel für eine zielführende Fehlermeldung. SDL_mixer ist nicht installiert, die Installation der passenden Bibliothek hilft. sudo zypper in SDL_mixer

Möchte man ein System auf ein RAID5 migrieren reichen dafür die drei Festplatten. Für Ubuntu ist dies auf Netzpiraten.ch schön beschreiben.

Ist der Grund für die Migration ein Hardwarefehler, so dass man die Ausgangsfestplatte anschließend tauschen möchte, kann man, statt wie auf Netzpiraten.ch beschreiben, auch erst einmal ein RAID5 mit nur zwei Platten anlegen. Dies entspricht zwar eigentlich einem RAID1 mit unnötig umständlicher Paritätsberechnung, lässt sich aber später problemlos zu einem echten RAID5 erweitern und bietet bereits während der Wartezeit auf den Austausch die gewünschte Fehlertoleranz.

Ein solches, einem RAID1 entsprechendes RAID5, weigert sich YaST allerdings anzulegen. Nutzt man allerdings die auf Netzpiraten.ch oder im The Software-RAID HOWTO beschreibenen Befehle gelingt dies problemlos.

mdadm --create /dev/md0 -n2 -l5 /dev/sdb3 /dev/sdc3

Die hierfür zuvor notwendige Partitionierung lässt sich am besten aus dem laufenden openSUSE-System mit YaST machen. Um die Dateien zu kopieren lässt sich das RAID unter Knoppix einbinden. Dort kann man die Dateien mit cp --archive kopieren.

Möchte man das RAID5 später um eine Festplatte, zum Beispiel die zuvor eingesparte Dritte, erweitern, hilft die Beschreibung auf isomerica.net. Wer ext3 verwendet muss nur statt xfs_growfs resize2fs verwenden. Der komplette Vergrößerungsvorgang kann komplett aus dem laufenden System erfolgen. Hierbei hilft watch den Fortschritt zu beobachten.

Da man bei diesen Aktionen auch durchaus mal die falsche Partition zerstören kann empfiehlt sich generell ein vorheriges Backup. Auch etwas Training in VirtualBox kann nicht schaden bevor man sich auf sein Live-System stürzt, dort können viele Unklarheiten beseitigt werden solange man noch ein komplett laufendes System hat.

Der Import meiner in MySQL abgelegten Amarok 1.4-Datenbank in Amarok 2 wollte zunächst nicht klappen. Ich scheiterte immer mit QMYSQL: Verbindungsaufbau nicht möglich. Zum Glück war vorher schon jemand über den Fehler gestolpert und hat eine Lösung gefunden, nämlich anstatt des Hostnamens die IP des Servers anzugeben. Nachlesen kann man dies alles unter KDE Bug 174269. Kaum war die Voreinstellung localhost in 127.0.0.1 geändert schon rödelte die Kiste los.

Will man unter openSUSE wissen zu welchem Paket eine Datei gehört lässt sich dies ganz leicht herausfinden. Leider gibt es in RPM oder Zypper keine expliziete Funktion um dies Abzufragen, aber sie lässt sich ganz leicht bauen aus vorhandenen Komponenten zusammenbauen.

RPM zeigt im Abfrage-Modus (-q) mit -l alle Dateien einem Pakets an. Mit -a arbeitet der Abfrage-Modus auf allen Paketen. Es liegt also nahe alle Dateien aller Pakete anzuzeigen und alle unbenötigten Informationen mit grep auszufiltern. In meinem Beispiel suche ich das Paket glibc-devel welches die Datei /usr/include/gnu/stubs.h enthält.

marix@eddie:~> rpm -qal | grep "/usr/include/gnu/stubs.h"
/usr/include/gnu/stubs.h

Leider funktioniert dies wie im Beispiel zu sehen ist nicht so richtig. Zwar wird die Datei gefunden, das Paket aber noch nicht mit angezeigt. RPM zeigt mit -l ja nur die Dateien an, aber nicht die Paketnamen. Zum Glück lässt sich RPM aber über die Option --queryformat genau sagen, welche Informationen es zu einem Paket wie anzeigen soll. Unter http://rpm.org/max-rpm-snapshot/s1-rpm-query-parts.html#S3-RPM-QUERY-QUERYFORMAT-OPTION ist auch der passende Formatierungstext zu finden.

marix@eddie:~> rpm -qa --queryformat '[%{=NAME}: %{FILENAMES}\n]' | grep /usr/include/gnu/stubs.h
glibc-devel: /usr/include/gnu/stubs.h

Momentan erfordert die Installation von KDE 4.1 unter openSUSE 11.0 etwas Handarbeit. Dennoch ist sie schnell und leicht erledigt. Für x86-Systeme gibt es unter http://de.opensuse.org/KDE/KDE4 auch Links zur Installation mit einem Klick. Wer ein x64-System hat oder es sowieso lieber per Hand macht findet hier eine kurze Anleitung.

Zunächst sind in Yast über den Punkt Software-Repositories folgende Repositories hinzuzufügen:

• http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0/
• http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0/
• http://download.opensuse.org/repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop/

Wie unter http://de.opensuse.org/KDE/KDE4 erwähnt, benötigt man außerdem auch noch das Qt-Repository, da KDE 4.1 eine neueres Qt benötigt als bei 11.0 mitgeliefert wird. Fehlt dieses erscheint bei der Auswahl von KDE 4.1-Paketen die Fehlermeldung nichts bietet libqt-x11 >= 4.4.2 benötigt von kdebase4-runtime-4.1.1-48.2.i586.

• http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/

Sind alle Repositories hinzugefügt kann man in in Yast unter "Software installieren oder löschen" das Schema "KDE 4 Desktop-Umgebung" auswählen. Möchte man alle zum Schema gehörende Software installieren kann man, nachdem man das Schema ausgewählt hat, bei einem Rechtsklick in die Paketliste "Alle in dieser Liste"->"Installieren" auswählen. Hatte man schon KDE 4.0 installiert kann man auch einfach in der Menüleiste "Paket"->"Alle Pakete"->"Aktualisieren falls neuere Version verfügbar" auswählen. Dies aktualisiert dann KDE 4.0 auf 4.1.