Monat: Mai 2020

 Nachdem ich die LiveCD vier Tage benutzt hatte, bin ich dabei geblieben und habe es kurzerhand über mein Altsystem mit der manuellen Installation drüber installiert. Das ist nicht sauber, den die Binaries der alten Installation bleiben dabei erhalten. Die Paketliste ist dabei dann die von Linux Mint und es liegt damit natürlich viel altes Zeug auf der Festplatte herum.  Andererseits will ich ja auch alle Programme, die ich vorher benutzt habe auch nachher wieder benutzen.  Mit find . -type f in /mnt/sda1 > dateien habe ich mir eine Liste gemacht, was so alles rumliegt und

#!/bin/bash
awk '{printf "dpkg -S %s\n", $1}' dateien | sh | grep Kein

zeit mir alle Dateien an, die zu keinem Paket gehören. Leider funktioniert ein Pipe auf

awk '{printf "apt-file find %s\n", $8}' 

nicht, dann hätte ich die Liste der zu installierenden Pakete gleich, die noch fehlen. Aber das macht nichts, wenn ich die Ausgabe in eine Datei umleite, dann mache ich es halt auf die Datei  ./suchkeinpaket.sh &> ausgabe und

awk '{printf "apt-file find %s\n", $8}' ausgabe | sh

So fällt dann auf, dass gewisse Pakete in Buster einfach nicht existieren. gif2png zum Beispiel oder auch mp4tag – nicht das ich die Tools jetzt aussergewöhnlich oft benutze, aber manchmal sind sie halt nützlich und in irgendwo in der Gewohnheit verankert. Die Pakete existieren an sich entweder in testing, unstable oder oldstable. Ubuntu 18.04 baute auf buster/sid und nicht auf buster auf.  Deswegen ist die Wahrscheinlichkeit hoch, dass die Pakete in sid sind. In der Zwischenzeit ist sid aber bullseye und nicht mehr buster.

Einerseits will ein stabiles System und andererseits will ich auf gewohnte Pakete nicht verzichten. Das hat mich jetzt dazu gebracht an LMDE folgende Änderungen für apt vorzunehmen.

#/etc/apt/apt.conf.d/00default 
APT::Default-Release "stable";

Das stellt mir zunächst mal sicher, dass ich eigentlich „stable“ haben will, es sei denn Stable hat das nicht, was ich will. Linux Mint Debian arbeitet auch mit /etc/apt/preferences.d
 und hat für die Mintpakete einen Präferenz von 700 und 750 angegeben. Deswegen habe ich mir für Debian stable

# /etc/apt/preferences.d/stable.pref
# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent 

Package: *
Pin: release a=stable
Pin-Priority: 600

mit einem geringeren Wert erstellt um Linux Mint vor Debian Buster zu nehmen, wird das gewünschte Paket dort nicht gefunden, soll apt in testing nachschauen.

# /etc/apt/preferences.d/testing.pref
# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent

Package: *
Pin: release a=testing
Pin-Priority: 400

Und war das immer noch nicht erfolgreich, dann gibt es vielleicht noch ein altes Paket:

#/etc/apt/preferences.d/oldstable.pref
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=oldstable
Pin-Priority: 99

Auch dann kann es sein, dass ich immer noch nicht mein Paket habe, also gehe ich noch eine Stufe weiter und werde instabil:

# /etc/apt/preferences.d/unstable.pref
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=unstable
Pin-Priority: 50

Und in der letzten Verzweiflung, weil das Paket immer noch nicht da ist schliesslich die experimentelle Pakete:

#/etc/apt/preferences.d/experimental.pref
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=experimental
Pin-Priority: 1

Die Quellen für oldstable, stable, testing müssen dann natürlich auch in /etc/apt/sources.list.d vorhanden sein

# Beispiel für Testing /etc/apt/sources.list.d/testing.list
deb http://security.debian.org /debian testing main
deb http://debian.mirror.net-d-sign.de/debian/ testing main contrib non-free
deb http://debian.mirror.net-d-sign.de/debian/ testing-updates main contrib non-free
deb http://debian.mirror.net-d-sign.de/debian/ bullseye-backports main contrib non-free

Ein paar Pakete sind wohl auch nur in http://www.deb-multimedia.org/  zu finden

deb https://ftp-stud.hs-esslingen.de/pub/Mirrors/debian-multimedia/ stable main
deb-src https://ftp-stud.hs-esslingen.de/pub/Mirrors/debian-multimedia/ stable main

Und was ich jetzt nicht nachinstallieren kann, werde ich mir wohl überlegen, ob ich es lösche oder was es genau ist und warum das mal auf die Festplatte gelandet ist. Sowas wie ldapauthsearch.c ist ein kleines Progrämmchen, welches Authorisierung bei einem konkreten LDAP-Server vornimmt und natürlich kein Paket kennt, aber vielleicht mal gegen die neue Distribution kompiliert werden sollte. Das alte Binary funktioniert allerdings übrigens auch das alte gif2png tat es ohne klagen, würde aber eben nicht durch das Packagemanagement gepflegt und upgedated.

Bis jetzt gefällt mir Linux Mint Debian sehr gut. Cinnamon ist ein schöner Fenstermanager, der nur ein klitzekleines Problem hat, wenn zuviele Menüpunkte vorhanden sind, dann sprengt er das Display. Das gleiche macht Cinnamon bei zuvielen Wlans in der Networkmanageranzeige. 

 

Auf obigen Screenshot ist die Auswahl auf Barrierefreiheit, welche aber bereits nicht mehr zu sehen ist und die Untereinträge hat 6 Menüpunkte, wobei der erste Cellwriter ist und  davon ist gerade noch der letzte Screenmagnifier zu sehen. Die Eingabezeile oberhalb des Menüs zu erreichen ist da erst Recht unmöglich. Das ist äusserst ungeschickt von Cinnamon.  Leider ist es im Menüeditor nicht möglich die Hauptmenüs umzuarrangieren um zum Beispiel Barrierefreiheit als Untermenü von Zubehör zu machen. Das ist schade, der Fenstermanager an sich gefällt mir nämlich. Der Workaround schaute dann so aus, einfach Menüeinträge zu löschen, was aber dann natürlich die dazugehörigen Programme nicht mehr über das Menü zugänglich hält. Was für mit mit Alt+F2 an sich kein Problem ist, wenn ich weiß, was ich starten will. Aber manchmal hat man den dazugehörigen Befehlsnamen einfach vergessen oder weiß ihn schlicht nicht. Die Befehle sind ja meist auf Englisch und was schnell über „Einstellungen“ gefunden wird, heisst dann in Wirklichkeit cinnamon-settings oder „Benutzer“ ist dann in Wirklichkeit cinnamon-settings-users. 

Wen wie mich stört, dass bei einem update-initramfs ein ‚dead_belowmacron‘ auftaucht, der kann sich ja einfach das in der  Datei /usr/bin/ckbcomp

my %xkbsym_table = (
    'dead_belowmacron' => 'fe68',
    'space' => '0020',

hinzufügen und die Fehlermeldung ist weg. Was mich betrifft, bleibe ich erstmal bei Linux Mint in der Debianvariante. Mit den obigen Änderungen habe ich vermutlich alles was ich brauche.

ecryptfsLinux Mint in der Geschmacksvariante Cinnamon und Debian überrascht positiv. Gestartet wurde die LiveCD mit dem Grubeintrag:

menuentry "lmde-4-cinnamon-64bit.iso" {
     insmod part_msdos
     insmod fat
     insmod gzio
     insmod ext2
     set root='hd0,msdos2'
     set isofile="/lmde-4-cinnamon-64bit.iso" 
     set cmdline="locales=de_DE.UTF-8 keyboard-layouts=de timezone=Europe/Berlin"
     loopback loop $isofile
     linux  (loop)/live/vmlinuz boot=live config findiso=$isofile $cmdline
     initrd  (loop)/live/initrd.lz

}

Grundlegendes zu Liveisoboot gibt es hier

Ok wie immer muss ich meine Lieblingstools wie vi reparieren mit einem apt install vim-nox aber bei Mint muss ich mir hierzu keine Quellen in /etc/apt/sources.list hinzufügen. Das Kommando genügt und ich habe einen bedienbaren vim. VI ist kein schlechter Editor er wird nur von allen Distributionen grottig ausgeliefert und in den Anleitungen wird immer nano verwendet. Ich kenne VI schon aus uralten Zeiten als es noch kein Linux gab und ja meine allererste Begegnung mit war ein ständiges Fragen des Vorgesetzten. Hat man die Tastenkombinationen aber erstmal verinnerlicht, dann möchte man diesen Editor auf der Kommandozeile nicht mehr missen. Kein Editor ist so schnell in kurz mal eine Datei editieren. Mit Nano fühle ich mich jedes mal behindert.

  LMDE 4.0 überrascht schon dadurch, dass ecryptfs bereits in der LiveCD dabei ist. Nachdem ich mir findiso mit Schreiberechtigungen remounted habe
cd /home
tar -cf mint.tar mint
cd /run/live/findiso/
tar -xf /home/mint.tar
mount -o bind /run/live/findiso /home
cd /home/mint
cp .Xauthority .ICEauthority /home/Benutzerverzeichnis
vi /etc/sudoers  und Benutzer unter root in die sudoers eintragen für den privatemount
sollte der Benutzer die ID 1000 haben gibt es noch das kleine Problem zu beheben, dass mint auch die Benutzer ID 1000 hat.
passwd mint
und gleiches Benutzerpasswort wie das verschlüsselte Verzeichnis hat vergeben.
In der /etc/passwd /home/mint auf /home/Benutzerverzeichnis ändern.
su – Benutzer

Wie sagte Boris so schön „Ich bin drin.“ verschlüsselte Daten wieder im Zugriff.  Wenn ich also Linux Mint in der Geschmacksvariante Debian installiere sollte das rankommen an meine Daten kein Problem sein.

 

 

Immer das gleich Thema bei allen bisherigen Distributionen, das kein Clipboardmanager installiert ist. Ich weiß gar nicht wie man ohne einem solchen Tool leben kann. diodon funktioniert auch unter Cinnamon unter KDE benutze ich klipper. gpaste will wohl nur unter Gnome richtigoder sowas es gibt sogar für Cinnamon ein Gpaste-Reloaded applet, aber das mag hier nicht oder aber vielleicht meldet es sich bei einer Neuanmeldung. Auf der Livecd sind keine Lokalisierungen dabei. Unter Mint heissen die Pakete nicht wie unter Ubuntu mit locale also thunderbird-locale-de zum Beispiel sonder  thunderbird-l10n-de oder chromium-I10n. Apropos Chromium ausser dass das Paket nicht chromium-browser heisst ist es ein echter Browser und kein  Snap-Paket wie bei Ubuntu Focal.

enigmail ist bei der LiveCD auch nicht dabei. Soweit ging der Service bei der LiveCD von LMDE dann doch nicht. Aber ansonsten ist eigentlich alles da. Die Oberfläche meldet sich aufgrund der Bootparameter auf deutsch. Die meisten Locales sind also da nur von einzelnen Programmen wie LibreOffice nicht. Gimp fehlt auch in der LiveCD, was ja dann bei der Festplatteninstallation kein Problem ist. Aber solange ich hier mit LiveCDs arbeite, geht halt jede Installation in das Overlay und belastet das RAM.

To be continued, dauert jetzt vielleicht länger, das System teste ich glaube ich länger. Es gefällt mir. 

To be continued….

~~

Manches ist einfach Geschichte und so bin ich rein historisch bei ecryptfs gelandet. In den 90er Jahren des letzten Jahrhunderts war Verschlüsselung noch nicht das Thema. 2006 dann zog es auch auf der Benutzerebene ein. Alles was heutzutage so als sicher gilt, gab es damals noch nicht. ecryptfs war das was in den Linuxkernel gewandert ist. Und so kommt es das mein Heimatverzeichnis damit verschlüsselt ist. Es hat die diversen Releasewechsel überlebt und ist verschlüsselt so gewachsen.

Man erzählt sich, dass der Support dadurch stirbt, dass der Entwickler von Ubuntu zu Google gewechselt ist. Ausserdem sei es unsicher. Naja es ist nicht unsicherer als es 2010 war und ist auch in 2020 noch genauso sicher oder unsicher. Aber ja es stimmt, mit einem physischen Zugriff auf die Maschine ist es möglich das Heimatverzeichnis immer zu entschlüsseln, wenn man das Passwort des Benutzers kennt. Oder wenn man das  Passwort nicht kennt als Alternative der /etc/passwd und der /etc/shadow habhaft wird.

Ich persönlich betrachte das als Vorteil dahingehend, das ich an die Daten rankomme, wenn gewisse Bedingungen erfüllt sind. Ich brauche physischen Zugriff, ich weiß mein Passwort oder habe Zugriff auf /etc/shadow und die BenutzerID. In allen anderen Fällen habe ich verloren. Allerdings brauche ich nicht einen Key in dem Büro, dass vom Tiger bewacht wird welches den Abrissbescheid der Erde veröffentlicht hat. Tatsächlich birgt die perfekte Verschlüsselung das Risiko, das beim Verlieren eines einzigen Bausteins, die Daten für immer verloren sind, denn niemand auf dieser Erde wird sie mit vertretbaren Aufwand entschlüsseln können. Es ist ein Frage der Abwägung. In diesem Sinne betrachte ich ecryptfs nicht als perfekt sicher, aber als brauchbar.

Es erhöht für mich das Sicherheitsniveau dahingehend, dass meine Daten nicht für Hinz und Kunz auf Anhieb greifbar sind, weil sie nicht unverschlüsselt auf der Festplatte liegen. Bei einem blossen Start des Systems sind die Daten auch nicht zugänglich, es sei denn jemand wüsste mein Loginpasswort. Solange ich mich nicht eingeloggt habe kann niemand mit den Daten was anfangen, auch nicht mit einer BootCD.

Dennoch ist es einfach mit einer BootCD die Daten zu entschlüsseln.  Nehmen wir Debian Buster, was hier gerade läuft. Ich hatte das Isofile auf die Gleiche Partition gelegt in dem mein verschlüsseltes Heimatverzeichnis liegt. Wie das geht steht hier. Bei Buster ist im Gegensatz zu Ubuntu das isodevice nicht im Schreibzugriff, da dort aber auch mein verschlüsseltes Home liegt, zunächst mal ein:

mount -o remount,rw /dev/sda2 /run/live/findiso

Wo auch immer /etc/shadow /etc/group und /etc/passwd gespeichert ist vom Originalsystem mit dem Home mal verschlüsselt wurde, die sind für die Schritte notwendig. Ich habe sie und deswegen mache ich ein:

cat passwd >> /etc/passwd
cat shadow >> /etc/shadow
cat group >> /etc/group

Leider gibt es kein ecryptfs in Buster also muss ich mir das bauen. Dazu brauche ich den Quellcode denn ich mit:

bzr branch lp:ecryptfs

bekomme.  Ja, bzr ist auf in der Bootcd nicht installiert aber ein apt install schafft hier Abhilfe und dann kann ich mir ja auch gleich

apt install bzr distro-info dh-autoreconf dh-python intltool libglib2.0-dev libkeyutils-dev libnss3-dev libpam0g-dev pkg-config python-dev swig

installieren. Diese ganzen Pakete  braucht ecryptfs.

cd ecryptfs und dpkg-buildpackage -b -ui baut mir dann die notwendigen Pakete für Buster, die sich alle ausser ecryptfs-utils installieren lassen, warum auch immer die Abhängigkeit libnss3-1d  in den Orginalsourcen definiert ist, aber daran scheitert es. Das macht aber nichts, das dpkg-buildpackage war eigentlich nur dazu da, damit die ganzen Pfade im make debian-like sind. Nachdem das erfolgt ist, kann ich einfach ein make install machen und ecryptfs ist nun im overlay verfügbar.

cp -r /home/user  /run/live/findiso
mount -o bind /run/live/findiso /home
vi /etc/sudoers  und Benutzername zu den sudoers hinzufügen
chmod u+s /usr/sbin/mount.ecryptfs_private
su – Benutzername

Das Verzeichnis ist dann entschlüsselt und zugänglich. Nun startet Buster unter Wayland, was ich noch nicht rausgefunden habe, wie ich die Authority in demselben Xwayland umziehe. Ein Strg+Alt+F3 auf die Konsole sich dort einloggen und dann startx bringt die alte Arbeitsumgebung zurück. Ich habe den Verdacht dass bei der LiveCD Buster kein gdm komplett konfiguriert ist. Weder abmelden noch Benutzerwechsel funktioniert nach diesen Schritten.

To be continued ….

 

Buster in die Tonne zu treten, war etwas voreilig. Der Kerneloops kommt auch bei Beowulf vor und deswegen habe ich mir das nochmal angeschaut.

Jeder Kernel der LiveCDs hat anscheinend unterschiedliche Bootparameter. Da gibt es wohl keine Standards. Unter Ubuntu liegt der Kernel in /casper  unter MX-Linux in /antiX und bei Debian und Devuan in /live – das aber alleine langt als Wissen nicht. MX-Linux ist bisher der schwerste Brocken, dessen Bootscripte suchen nach Devices eine Isodatei ist halt kein klassisches Gerät wie /dev/sr0 usf. ich habe noch nicht rausgefunden wie ich dem vmlinuz von MX-Linux beibringe auf loop zu suchen.

Ubuntu 16.04 sieht zum Beispiel so aus:

 linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile noprompt noeject locale=de_DE bootkbd=de console-setup/layoutcode=de

Ubuntu 18.04 dann so:

linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject locale=de_DE bootkbd=de console-setup/layoutcode=de

initrd (loop)/casper/initrd.lz

Und Ubuntu 20.04 wieder anders:

linux (loop)/casper/vmlinuz iso-scan/filename=$isofile file=/cdrom/preseed/ubuntu.seed boot=casper locale=de_DE bootkbd=de console-setup/layoutcode=de quiet splash ---

initrd (loop)/casper/initrd

Die Variablen set root und set isofile sind eigentlich bei allen Distributionen gleich.  Wenn das Isofile auf der ersten Festplatte der ersten  Partition liegt, dann wäre es

set root='hd0,msdos1'

Ich lege mir die zu testen LiveCDs aber immer auf die zweite Partition msdos2, da ich später das System auf die erste Partition installieren will. Die zweite Partition ist auch mein /home wo meine Daten liegen und die will ich auch bei Neuinstallation behalten. Ausserdem hat sich das bei Ubuntu bisher bewährt, dass ich damit nicht immer wieder alles neu einrichten muss und ein Rettungssystem immer im Grub zur Verfügung habe.

Nun musste ich feststellen, dass zwischen den Distribution nicht nur das Verzeichnis anders ist, sondern die Kernelbootparameter nicht übertragbar sind. Bei Devuan Beowulf funktioniert folgendes:

set root='hd0,msdos2'
set isofile="/devuan_beowulf_3.0.0_beta3_amd64_desktop-live.iso"
set cmdline="locales=de_DE.UTF-8 keyboard-layouts=de timezone=Europe/Berlin"
loopback loop $isofile
linux (loop)/live/vmlinuz boot=live config findiso=$isofile $cmdline username=devuan apparmor=0 
initrd (loop)/live/initrd.img

funktioniert unter MX-Linux leider nicht

keyboard-layouts=de 

verursacht einen Kerneloops, aber so kommt es, dass Buster nochmal eine Chance bekommen hat. Momentan schreibe ich unter Buster, weil mir das XFCE in der Konfiguration von Devuan nicht gefallen hat. Es wird sich sichelich einstellen lassen, dass das Touchpad auf Tippen reagiert, aber ich habe die Einstellung unter Devuan nicht gefunden. Buster hingegen hat zwar diese Einstellung auch, dass Tippen standardmässig ausgeschaltet ist, aber in der Oberfläche ist es dem Ubuntu sehr ähnlich und Einstellung Touchpad hat mir das wiedergegeben. In der grub.cfg für Debian Buster sieht dass dann so aus:

set root='hd0,msdos2' 
set isofile="/installdebian.iso"
set cmdline="locales=de_DE.UTF-8 keyboard-layouts=de timezone=Europe/Berlin"
loopback loop (hd0,msdos2)/$isofile
linux (loop)/live/vmlinuz-4.19.0-8-amd64 boot=live config findiso=$isofile $cmdline 
initrd (loop)/live/initrd.img-4.19.0-8-amd64

Ecryptfs kommt aus der Mode. Moniert wird bei dieser Festplattenverschlüsselung, dass es nicht ganz sicher ist. Das stimmt in gewisser Hinsicht. Für mich ist es aber kein Bug sondern eher ein Feature. Moniert wird, dass wenn sich ein Nutzer einmal mit seinem Passwort eingeloggt hat und sein /home entschlüsselt ist, dass dann das Verzeichnis entschlüsselt ist und zwar auch dann, wenn er sich wieder auslogt. Dieses Ausloggen kann zum Beispiel passieren wenn man Strg+Alt+Tab macht und den Xserver abschiesst, weil das System aus welchen gründen auch immer zuviel swapt, weil man Blödsinn angestellt hat, und das eine gute Möglichkeit ist, den wildgewordenen Prozess gewaltsam zu beenden. In diesem Moment ist das Verzeichnis dann immer noch unverschlüsselt und mit physischen Zugriff lesbar. Das kann man als Sicherheitslücke einer ordentlichen Verschlüsselung betrachten. Ja es ist nicht so sicher wie eine Verschlüsselung auf Geräteebene. Man könnte auch sagen, es ist broken bei Desigen, weil es nur eine Dateiverschlüsselung Jahrelang also so von 2006 bis 2018 hat das niemanden gestört. Irgendwann hat aber wohl ein Sicherheitsfanatiker dazu einen Bug aufgemacht. Und jetzt scheint ecryptfs aus allen Distributionen zu fliegen. So ist ecryptfs auch in  Buster nicht enthalten.  Ebenso weil die Meute dann allesamt in die gleiche Richtung rennt, ist es auch in Devuan Beowulf nicht enthalten. In Devuan Ascii ist es noch vorhanden.  Nun ich habe mein Home aber 2006 mit ecryptfs verschlüsselt und ziehe es seitdem halt immer mit. Tatsächlich hat das Heimatverzeichnis eine Größe erreicht, dass ich nicht genügend Platz auf der Festplatte habe um es so eben mal unentschlüsselt auf dieselbe Festplatte zu legen. Um ecryptfs rückgänge zu machen, sagt die Anleitung einfach entschlüssel es mach ein tar aus den entschlüsselten Daten, dann eine umount auf das private und dann wieder entpacken. Nette Empfehlung, aber die verschlüsselten Daten sind dann immer noch auf der Festplatte und man braucht den Platz quasi dreimal um das wieder rückgängig zu machen. In meinem Fall auf einer 500GB Platte also 600GB bei einem Heimatverzeichnis von 200GB.

Deswegen beinhaltet mein Test auch immer, komme ich auch wieder an meine Daten.

To be continued ….