Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment

Nach den Überlegungen in den letzten Artikeln dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

sind wir gut gerüstet, um für Tests zur Voll-Verschlüsselung eines Laptops passende LVM-Volumes anzulegen und mit einem “LUKS on LVM”-Layer zu versehen. (LVM on LUKS wenden wir uns später zu). Ich sage aus guten Gründen “Tests” – nicht finale Installation. Es gibt Einiges, was man falsch machen kann oder was zu unpraktikablen Konsequenzen führt. Im Besonderen, wenn man sich ein wenig abseits der normalen Installationsprozeduren (hier von Opensuse) bewegt.

Ich werde nachfolgend den Umgang mit einer jungfräulichen SSD diskutieren. Arbeitet ihr nicht mit einer leeren SSD/HDD und wollt ihr alte Installationen nicht verlieren, empfehle ich vorherige vollständige Backups – mit zusätzlichem Aufschreiben von UUIDs plus ggf. separatem Backup der Verzeichnisse “/etc/” und “/boot”. Der Verlust vorhandener Daten ist bei Fehlern möglich.

Bevor man eine vorhandene Laptop-SSD mit funktionstüchtigen Installationen komplett durch eine neue SSD ersetzt, liegt es nahe, die Voll-Verschlüsselung zunächst separat zu testen. Dazu nutzt man die neue SSD vorübergehend als externes, bootbares Laufwerk am USB-3-Anschluss eines laufenden Linux-Systems. Im besten Fall kann man die Test-Installation nach einem Einbau in den Laptop und Anschluss an den dortigen SATA-III-Bus direkt weiter nutzen. Dachte ich so …

Dieses Vorgehen führte bei mir aber zu Problemen mit dem Alignment der anzulegenden Partitionen und Volumes. Das war durchaus lehrreich. Ich werde deshalb darauf eingehen, obwohl es unser Kernthema nur am Rande berührt. Ein weiteres wichtiges Thema dieses Artikels sind die Einstellungen zur Verschlüsselung. Dabei ist vor allem die Anzahl der “PBKDF2”-Iterationen interessant.

Hinweis: Diejenigen, die sich mit der Funktionsweise von LUKS noch nicht so gut auskennen, mögen jetzt einen Blick in den Artikel
crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
und den Nachfolge-Artikel werfen. Dort sind etliche weiterführende Links angegeben. Hilfreich ist ferner ein Blick in die man-Seiten zum Kommando “cryptsetup“. LVM-Grundkenntnisse setze ich voraus.

Continue reading

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

In den letzten Beiträgen dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

haben wir etliche Vorüberlegungen zur Voll-Verschlüsselung eines Linux-Laptops mit SSD unter Opensuse Leap 15 angestellt. Für die anstehenden Tests muss ich noch planen, welche Partitionen das Layout meine (noch jungfräuliche) SSD prägen sollen. Ich kann hier natürlich nur einen Vorschlag vorstellen, der u.a. durch Platz für virtualisierte Gastsysteme geprägt ist und den Test von “LUKS on LVM”, “LVM und LUKS” sowie Hibernation ermöglichen soll. Bei mir persönlich gibt es zudem eine Präferenz für “LUKS on LVM”.

Das root-Filesystem bezeichne ich nachfolgend mit “/”-FS.

Continue reading

Eclipse Photon unter KDE Plasma – Dark Scheme unter Opensuse Leap 15 nicht mit dem Default-GTK3-Design kombinieren

Eclipse Photon ist es wert, zumindest testweise installiert zu werden. Ich habe das neulich unter Opensuse Leap 15 und KDE Plasma getan. Im Vergleich zu Eclipse Oxygen finde ich das Zusammenspiel mit GTK3 unter KDE Plasma inzwischen relativ zufriedenstellend.

Was mich allerdings weniger begeistert, ist z.B. die verschlechterte Performance der Content Assist Funktionalität. (Nachtrag 26.09.2018: Gilt so nur für die “R”-Version, aber nicht mehr für die neue September-Version; tarball “eclipse-php-2018-09-linux-gtk-x86_64.tar.gz”). Auch der Start von Eclipse für PHP mit PDT ist z.Z. erstaunlich langsam; zumindest phasenweise wird dabei offenkundig nicht auf Multithreading gesetzt. Da bleibt wohl nur, auf Updates zu hoffen.

Es gibt aber auch optische Punkte, die beim Einsatz des GTK3-lastigen Eclipse Photon zumindest unter KDE Plasma nicht zufriedenstellend sind: Der eine betrifft die Skalierung der Icons in den Menüleisten – hier gibt es anscheinend grundlegende Probleme mit dem Zusammenspiel der aktuellen SWT-Komponenten mit KDE Plasma. Dazu wurden bereits mehrere Bug-Meldungen verfasst, deren Aussagen ich nur bestätigen kann: Eine GTK-Skalierung funktioniert unter KDE Plasma weder über Environment-Variablen, noch über Einstellungen in der eclipse.ini wie erwartet. Siehe etwa https://bugs.eclipse.org/bugs/show_bug.cgi?id=536542. Auch hier hilft nur Warten und Tee trinken.

Ein anderer wunder Punkt ist die Kombination des Dark Scheme mit SWT-gesteuerten Oberflächenelementen, wie sie etwa in vielen Eclipse Dialogen zum Tragen kommen. In meinem Alter halten die Augen nicht mehr so lange durch wie früher; muss man mehrere Stunden am Tag entwickeln, ist man froh über einen dunklen Bildschirm-Hintergrund. Also habe ich bei mir das Dark Scheme aktiviert.

Leider erwiesen sich dann Checkboxen und Radioboxen in einer Vielzahl von SWT-gesteuerten Dialogen unter Opensuse Leap 15 mit KDE Plasma als kaum erkennbar. Das betraf einerseits “Preference”-Dialoge, andererseits aber auch “Remote System”-Dialoge, u.a. für den Export von Files auf Remote-Systeme. Letzteres ist für die praktische Arbeit wirklich ein Dilemma:

Auf einem hochauflösenden 2K bis 4K-Schirm wird das zum Problem. Aus einiger Distanz lässt sich der Checkbox-Haken kaum erkennen. Vieles lässt sich über die Eclipse Preference-Seiten ja einstellen und korrigieren, aber gerade das nun mal nicht.

Dieses Problem lässt sich aber Gott sei Dank lösen. Man muss nur wissen, dass die Lösung nicht innerhalb von Eclipse sondern bei den Einstellungen für das GTK-Design unter Plasma zu suchen ist. Als GTK-Design hatte ich nach dem Upgrade auf Leap 15 bislang die Opensuse-Einstellung “Default” belassen. Das führt zu den dargestellten Problemen.

Unter KDE Plasma hilft es dann, das Dark Scheme von Eclipse mit dem “Breeze”-Design oder dem “Adwaita-Design” für GTK3-Anwendungen zu kombinieren. Die entsprechende Einstellungen nimmt man unter
“systemsettings5 >> Erscheinungsbild >> Anwendungs-Stil > > Gnome Anwendungs-Stil (GTK)”
vor.

Mit Breeze erhält man folgende Darstellung:

Adwaita liefert folgendes:

Breeze und Adwaita als GTK3-Designs (unter KDE Plasma) machen die Steuerungselemente in den Eclipse Dialogen also viel besser erkennbar! Ich hoffe, dem einen oder anderen, der Eclipse unter KDE mit dem Dark Scheme einsetzen und sich nicht die Augen verderben will.