Debian GNU/kFreeBSD in Xen HVM DomU mit Verschlüsselung und ZFS

Ich will Backup und ich will ZFS, da brauch ich glaube ich in beiden Fällen nicht drauf eingehen warum. Auf dem Server läuft ein Debian Wheezy (amd64) und mit Xen werden diverse virtuelle Maschinen ausgeführt. Für’s Backup sind vier Platten vorgesehen und da soll ZFS drauf und die Daten sollen verschlüsselt werden.

Wie ich jetzt darauf gekommen bin das ganze mit Debian GNU/kFreeBSD zu realisieren, sei mal nicht in Frage gestellt, ist jetzt so und es gibt eine VM, die mittels Hardware-Virtualisierung der CPU installiert wurde, hatte ich ja hier schon erwähnt wie. Probleme mit der I/O-Performance hab ich dank der passenden Mailingliste auch beheben können.

Bevor wir jetzt ZFS installieren, soll noch Crypto drunter. Das könnte man auch anders schichten, aber so rum scheint empfohlen zu sein. Ebenfalls empfohlen ist es Crypto nicht auf die nackte Platte zu tun (auch wenn das ginge) sondern die Platten noch zu partitionieren. Bei BSD scheint da mittlerweile GPT der Standard zu sein und das passende Tool bei FreeBSD wäre gpart. Beim Debian GNU/kFreeBSD haben wir aber Debian Userland und da gibt’s dieses Tool nicht. Partitioniere ich also mit gdisk, dachte ich mir, aber das ist dann auch wieder nicht so einfach, weil gdisk sich beschwert, dass /dev/da0 ein character device sei. Ist es auch, scheint bei BSD so zu sein, bedeutet aber, dass ich die Platten nicht in der VM partitionieren kann, sondern das bereits im Wirt tun muss. Mit gdisk war das kein Problem und als Partitionstyp hab ich mal FreeBSD ZFS benutzt aka 0xA504.

Nächster Schritt: Verschlüsselung. Da benutzt man bei FreeBSD das Tool geli und das ist dann wieder Kernel Space genug, dass es auch verfügbar ist. Befehle hier:

Und dann:

Beim Initialisieren kann man auch noch Keydateien angeben und alle möglichen Optionen setzen. Details dazu hat das FreeBSD-Handbuch. Analog wird mit den anderen Platten verfahren und es stehen einem dann die aufgeschlossenen Devices zur Verfügung, für die erste verschlüsselte Partition der ersten Platte hier /dev/da0p1.eli welches dann gleich einem zpool hinzugefügt wird.

Den zpool namens tank erzeugte ich dann so:

Das entspricht de facto einem RAID-6 und ist auch bereits unter /storage gemountet. Für den nächsten Systemstart fehlt also nur noch ein Skript, was mir die Crypto-Devices aufmacht. Bei Debian GNU/kFreeBSD kann man da mal in /etc/default/geom schauen. Das darauf liegende ZFS wird dann automatisch gefunden und eingebunden.

Alles weitere ist dann Anwendung von ZFS, das wäre thematisch aber was für einen anderen Artikel. ;-)

ksplash’d

Auf dem neuen Rechner im Büro ist (natürlich) Debian installiert, mit KDE, so wie auf allen meinen Rechnern. Flotte Kiste und ich hab mir nichts weiter dabei gedacht, dass nach dem Einloggen kein Splash Screen erschien, schnell halt die Mühle. Durch einen Zufall bin ich aber heute nochmal bei den Einstellungen der Splash-Screens gelandet und stellte fest, dass »Default« zwar funktionierte, das von mir bevorzugte »joy« des aktuellen Debian-Release Wheezy jedoch nicht. Warum? Gar nicht so leicht rauszufinden, aber was aufgerufen wird, ist wohl sowas wie das hier:

Huch, was ist da denn das Problem? Mein Monitor läuft in keiner der Auflösungen, wo im Paket desktop-base Bilder mitgeliefert werden, also mal mit strace geschaut, was er da öffnen will:

Hmm, da hat wohl wer umgerechnet und abgelegt, und …

Na sowas?! Also kurzerhand die leere Datei gelöscht und schon geht das! :-)

Link

Wunderbarer Beitrag von Lena:

“Non-coders” in Open Source projects or: On aliens – Confessions of a “non-coder” (1).

Gut geschrieben und amüsant illustriert. Eine Freude zu lesen, auch für Coder. ;-)

(via Twitter)

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

Problemchen mit approx beheben

In Zeiten vieler Rechner und dennoch langsamer Internetverbindungen1 kann ein Paketproxy ein wahrer Segen sein. Updates und Pakete für Debian und auf Debian basierenden Betriebssystem werden dann im lokalen Netz zwischengespeichert und es muss nicht jeder einzelne Rechner immer alles von einem Debian-Spiegel aus dem Netz holen. Ich setze dazu approx ein. D.h. ich betreibe keinen eigenen Mirror, sondern halte nur die nötigen Pakete lokal nochmal vor. Ein spezialisierter Proxy wie approx, der über die Struktur des Paketservers bescheid weiß, kann hier meiner Meinung nach bessere Dienste leisten, als ein generischer Proxy.

Während die Idee an sich gut ist, gibt es im Detail ein paar Problemchen. Sowohl approx vermurkst sich manchmal seine Daten als auch clientseitig das apt auf dem Rechner. Auf beiden Seiten kann man das wieder bereinigen und ich zeige kurz wie.

approx

Ein häufiges Problem, das ich bei approx festgestellt habe, sind 0 Byte große Dateien. Sind solche unter /var/cache/approx solche vorhanden, kommt es auf Clientseite zu allerlei komischen Fehlern, heute hatte ich da beispielsweise HTTP 404 für Dateien, die auf dem Mirror vorhanden sind. Auf dem Server, wo approx läuft, habe ich dann zwei Sachen ausgeführt:

apt

Die Probleme hier entstehen vermutlich ähnlich wie serverseitig durch unterbrochene Updatevorgänge, nutzer- oder netzwerkseitig, egal, es ist halt was kaputt. Es gibt natürlich aptitude clean und dergleichen und manchmal scheint das aber nicht zu helfen. Zuletzt behalf ich mir dann damit:

So sind Updates jetzt wieder möglich. Ich weiß zwar nicht, was genau und warum das ab und zu kracht, aber so kann man’s wenigstens in einen funktionierenden Zustand zurücksetzen.

  1. Breitbandausbau am Arsch! []

Git unter Windows

Ganz ehrlich, ich hab die Schnauze voll von Windows. Es begann damit, dass ich mehrere Tage gebraucht habe, um Qt 4.8.x selbst zu kompilieren, weil die pre-built Binaries mit einem alten MinGW mit GCC 4.4.x gebaut wurden, dieses aber nicht mit Qt mitgeliefert wird. MinGW selbst stellt aber keine älteren Releases bereit und wegen ABI-Änderungen bei GCC lässt sich Qt (GCC 4.4) nicht mit aktuellem MinGW (GCC 4.8) zusammen nutzen. Das allein schon war frustrierend genug, aber es tauchen dann ja noch so Schwierigkeiten auf, wie dass der Snakeoil Virenscanner selbst kompilierte Software hart löscht. Jetzt habe ich endlich ein Qt und dann beschwert sich CMake noch lange vor dem Build der Anwendung, dass es ein “sh” im PATH gefunden hat. Git für Windows bringt das mit, wozu auch immer. Dachte ich, schauste mal, ob das unbedingt nötig ist, aber die Git-GUIs für Windows brauchen das und auch sonst ist das mit den GUIs für Git unter Windows höchst schmerzhaft. Eine Liste gibt es zwar, aber das ist alles unbrauchbar:

GitHub for Windows
Verbirgt große Teile der Komplexität von Git, ist damit für gewisse Workflows unbrauchbar und arbeitet, oh Wunder, nur mit GitHub.
Git Extensions
Ist nicht plattformunabhängig und installiert mir Dinge mit, die ich schon habe.
git-cola
Braucht erstmal noch Python und PyQt und letzteres wiederum bringt im Binary-Installer gleich wieder ein ganzes Qt mit. Was hatte ich noch gleich selbst kompiliert?
GitEye
Ist ein komplettes Eclipse, für Git, also riesengroß, nur für ein Versionsverwaltungssystem. Irre.
SmartGit
Nicht frei.
SourceTree
Braucht mindestens Windows 7.

Dann wäre da noch TortoiseGit, aber das ist nur ein Fork von dem für Subversion super geeigneten TortoiseSVN und dementsprechend ungeeignet für einen Git-Workflow. Git ist halt kein zentralisiertes Versionsverwaltungssystem wie CVS, wie soll ich dafür dann das selbe Interface gebrauchen können?

Bei Mercurial hat man wenigstens ein schönes plattformunabhängiges GUI in Qt geschrieben. Das heißt zwar auch TortoiseHg, hat aber von der Bedienung her kaum was mit den zuvor genannten gemein und spült mir auch keine zusätzliche kaputte Shell auf meinen Rechner.

Hölle, ist das alles broken. Ich will mein Linux zurück. :-/

Ach so ja, das Problem mit CMake lässt sich übrigens lösen, indem man das CMake-GUI mit einem sauberen PATH startet, bspw. mit einer Batch-Datei cmake-gui.bat:

HowTo: GnuPG mit unbegrenztem Signing-Key und ablaufendem Encryption-Key

Sperrig, die Überschrift, also worum geht’s? Ich zitiere mal aus dem GnuPG-Handbuch:

Wenn Sie ein neues Schlüsselpaar erzeugen, werden standardmäßig ein DSA-Hauptschlüssel zum Unterschreiben und ein ElGamal-Unterschlüssel zum Entschlüsseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schlüssel verschieden sind und es sinnvoll sein könnte, den beiden Schlüsseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschlüssel wird benutzt, um digitale Unterschriften zu leisten, und er bestätigt Ihre Identität dadurch, daß andere ihn signiert haben. Der ElGamal-Unterschlüssel wird nur benutzt, um an Sie geschickte verschlüsselte Daten zu entschlüsseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte Gültigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schlüssel, die Sie mühsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschlüssel in gewissen Zeitabständen gewechselt werden, um Ihre Datensicherheit zu erhöhen, da ein Angreifer, wenn der ElGamal-Unterschlüssel geknackt ist, alle Dokumente lesen kann, die für diesen Schlüssel verschlüsselt worden sind oder es noch werden.

Darauf folgt noch ein kurzer Hinweis, dass das etwas umständlich ist, aber wie genau man das anstellt, ist quasi als Hausaufgabe überlassen und deswegen1 zeige ich das jetzt hier.

Zunächst erstellt man sich einen Schlüssel ohne Ablaufdatum, der Wizard packt sonst auf beide Unterschlüssel ein Ablaufdatum und das wollen wir ja eigentlich nicht:

Heutzutage ist das kein DSA/ElGamal-Paar, sondern beides sind RSA-Schlüssel, aber Details kann man in einem beliebigen HowTo zur Schlüsselerstellung nachlesen. In meinem Fall hab ich zu Testzwecken das hier erhalten:

Als nächstes bearbeite ich diesen Schlüssel:

Hier gibt es jetzt eine Reihe von Befehlen, die man sich mit help anzeigen lassen kann. Zunächst ist list ganz hilfreich. Die Ausgabe davon:

Den Unterschlüsseln ist ein »sub« vorangestellt, allerdings nicht nummeriert. Man wählt nun den Encryption-Key aus mit key 1 oder wenn man bereits mehrere Unterschlüssel hat, muss man durchzählen, die sind freundlicherweise geordnet. GnuPG markiert den soeben ausgewählten Unterschlüssel mit einem Sternchen:

Der nächste Befehl ist expire. Zuvor kann man sich mit list nochmal überzeugen, dass auch nur der Unterschlüssel ausgewählt ist. GnuPG ist an der Stelle aber so freundlich bei der Nachfrage nochmal klar zu stellen, dass man nur das Ablaufdatum des Unterschlüssels ändert. Sieht dann so aus:

Hier sieht man jetzt, dass der Key, dem das »pub« vorangestellt ist und bei dem es sich um den Signing-Key (SC) handelt, immernoch kein Verfallsdatum hat, der Encryption-Key (E) hingegen schon.

Bis hier hin wäre das das Vorgehen, wenn man sich einen neuen Schlüssel erstellt oder bereits einen hat, der bisher kein Ablaufdatum hat. Hat man seinen Schlüssel bereits auf einen Keyserver geladen, empfehle ich nicht am Ablaufdatum rumzufummeln. Solche Änderungen kommen womöglich nie beim Gegenüber an. Dann lieber neuen Schlüssel machen.

Was nun, wenn der Encryption-Key droht abzulaufen? Man fügt mit addkey einen neuen hinzu. GnuPG fragt dann nach allerlei Details, u.a. wie lange der neue Unterschlüssel gültig sein soll. Bei der Frage, was für ein Unterschlüssel es werden soll, wählt man einen für »nur verschlüsseln« und dort sinnvollerweise die Variante RSA mit der vorgebenen oder einer größeren Schlüssellänge:

Hier hab ich jetzt gleichzeitig zwei gültige Encryption-Keys, aber das diente ja nur zum Zeigen und Ihr werdet den Key auch auf keinem Keyserver finden.

Mit save verlässt man den Editiermodus und dann lädt man den mit neuem Encryption-Key versehenen Schlüssel wie gewohnt auf den Keyserver hoch.

Übrigens habe ich meinem eigenen PGP-Schlüssel mit dieser Methode auch gerade einen frischen Encryption-Key spendiert. Falls sich Euer Mailprogramm beschwert, dass Ihr mir keine verschlüsselten Mails mehr schicken könnt, ladet Euch mal meinen aktuellen Public-Key! ;-)

  1. und weil ich Frank Lanitz das mal auf einer Keysigningparty bei den Chemnitzer Linux-Tagen versprochen hatte, ach und wegen der im Netz39 bevorstehenden Keysigningparty, na und natürlich, weil der Encryption-Key bei mir bald abläuft … []

Sessionname in Statuszeile von GNU screen

Grml ist das Live-Linux meiner Wahl für allerlei Zwecke. Das coole ist die Config, die dort für Zsh, Vim und GNU screen mitgeliefert wird und da ich wenig Lust hab, mir sowas selbst zusammenzubasteln und ich ebenso gern ein vertrautes Nutzerinterface habe, nutze ich die Configs auch auf anderen Rechnern, indem ich dort einmal grml-config.sh ausführe und dann nur noch kleine Anpassungen machen muss.

Screen benutze ich ausgiebig und meistens mit mehreren sessions und ab und zu kommt man da mal durcheinander. Deswegen habe ich die .screenrc jetzt doch mal ein bisschen angepasst und statt

steht da jetzt bei mir

und dank des zusätzlichen Parameters %S hab ich die aktuelle Session direkt im Blick. :-)

HowTo: KMail wechselt Online/Offline je nach Netzwerkverbindung

Einige Probleme lassen sich schnell lösen. Zum Beispiel, dass KMail versucht, E-Mails abzuholen, selbst wenn es keine Netzwerkverbindung gibt.

Über den DBus lässt sich jede KDE-Anwendung fernsteuern, sofern die entsprechenden Interfaces angeboten werden. Mit dem Aufruf von

erhält man eine Übersicht der Methoden, die KMail anbietet. Darunter sind auch stopNetworkJobs und startNetworkJobs – genau das, was wir brauchen.

Über die Toolbox des Network Managers, speziell nm-tools, ist es möglich, den Netzwerkstatus zu ermitteln. Jetzt fehlt nur noch ein kleines Script, das je nach Vorhandensein einer Netzwerkverbindung KMail in den Online- bzw. Offline-Modus versetzt.

Diese Script wird in der Ereignisverwaltung des Network Managers beim Ereignis “Schnittstellenstatus geändert” eingetragen und setzt nun den KMail-Status abhängig von der Verfügbarkeit einer Netzwerkverbindung.

Die Lösung ist sehr einfach, behebt aber die Fehlermeldungen und ist ein Ausgangspunkt für weitere Verbesserungen.

Nachtrag: Schöner wäre es, wenn KMail die Jobs beenden würde, bevor die Verbindung abbricht. Wer spontan einen Ansatzpunkt hat, bitte ab in die Kommentare damit.

Nachtrag2: Eigentlich brauchen wir eine Internetverbindung, d.h. streng genommen müsste ein Internet-Zugriff ausgeführt und dann abhängig vom Erfolg der KMail-Status gesetzt werden.

HowTo: FreeBSD als HVM-DomU in Xen auf Debian Wheezy

Zu Hause und im Netz39 e.V. läuft je ein Server mit Debian Wheezy auf amd64 und als Virtualisierungssystem wird Xen benutzt. Linux-Gäste werden paravirtualisiert und das läuft schon seit Jahren fluffig. Für bestimmte Zwecke muss es aber auch mal ein anderes System sein und das ist im Hackerspace ein aktuelles FreeBSD 9.1 und zu Hause ein Debian GNU/kFreeBSD, also kein Debian GNU/Linux, sondern eben das Debian mit dem ganzen GNU Userland und einem FreeBSD-Kernel. In beiden Fällen ist auch die VM die 64-Bit-Variante und die Hardwarevirtualisierung der jeweiligen Prozessoren soll genutzt werden. Was fehlt: die initiale Config für die VM und da hab ich gesucht, recherchiert und probiert und präsentiere jetzt, was bei mir funktioniert hat. Zu Hause sieht’s so aus:

Und im Space:

In beiden Fällen hatte ich zuvor Xen nach der Anleitung im Debian-Wiki aufgesetzt. Die XX in den Mac-Adressen sind durch zufällige Werte zwischen 00h und FFh zu ersetzen. Die Erzeugung von Zufallszahlen und die Umrechnung ins Hexadezimalsystem überlasse ich als Hausaufgabe.

Nach dem Start der DomU macht man einen SSH-Tunnel auf für den VNC-Port und verbindet sich mit seinem bevorzugten VNC-Client1 auf localhost:

Nach der Installation in der Config die Bootreihenfolge anpassen bzw. das CD-Image rausnehmen, fertig.

  1. unter KDE benutze ich krdc, auch wenn ich den Namen grauslig finde []