Linux Mint Debian

 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. 

Cinnamon Menü
Cinnamonmenü sprengt die Anzeige

 

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.




LMDE 4.0 oder Mint Debian

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….

~~

ecryptfs

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 ….

 

Beowulf und Buster

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 ….

Debian Buster und Ubuntu Focal Fossa 20.04

Wie angekündigt Von der Vielfalt oder Qual der Wahl  ist hier nun die Fortsetzung. Auf einem meiner Systeme hatte ich ein Ubuntu 16.04 auf Debian Bullseye migriert. Insofern ist Debian für mich durchaus eine Option.  Was nun Ubuntu betrifft, nutze ich das seit Dapper Drake. Ich bevorzugte dabie die LTS-Versionen und bin damit jahrelang  gut gefahren. Ubuntu war stabil, lief einbahnfrei und eine Migration der Maschine von einem Ubuntu LTS zur nächsten verlief bis auf Kleinigkeiten eigentlich immer problemlos. Selbst den Weg zur Unity bin ich mitgegangen und hatte mich ein wenig mit den Lenses zu kämpfen. Letztlich habe ich mich auch damit abgefunden, dass Ubuntu nach Hause telefoniert bei jedem Start der Maschine und war machmal zu faul, das zu beseitigen.

Es ist nicht so, dass mit die Schwächen von Ubuntu nicht bewusst waren, aber ein gewisse Bequemlichkeit und das System lässt sich ja einbahnfrei benutzen, ist halt auch dabei. Debian läuft auf der anderen Maschine problemlos und einbahnfrei, so war das eine Überlegung wert. Buster hat mich aber mit einem Kernelcrash beglückt:

das kommt in einer Testphase irgendwie nicht gut und hinterlässt ein ungutes Gefühl. Jetzt verwende ich ausserdem ecryptfs-utils und das ist in Buster kein Standardpaket. Irgendwie habe ich keine Lust die verschlüsselten Verzeichnisse umzuziehen. Käme eigentlich dann nur Debian sid in Frage, aber genau das will ich auf meiner Alltagsmaschine nicht. Ich will was das sich „Stable“ nennt und regelmässig Sicherheitsupdates bekommt. Damit ist jetzt Debian Buster erstmal raus, nicht weil es schlecht wäre, sondern weil es so nicht meinen Anforderungen genügt.

In der Bequemlichkeit könnte ich natürlich bei Ubuntu bleiben und einfach auf Focal Fossa upgraden. Tatsächlich schreibe ich hier ja gerade unter Ubuntu 20.04 und offensichtlich lässt sich ja einbahnfrei damit arbeiten. Es gibt aber so ein paar Dinge, die mich stören.

Es betrifft zwar nicht diese Maschine, aber 32bit ist bei Focal Fossa raus. Ich bevorzuge auf den verschiedenen Maschinen den gleichen Versionsstand. Das hat einfach damit zu tun, dass der Wartungsaufwand pro Maschine einfach geringer ist. Wenn ich es erstmal auf der einen Maschine getestet habe und die Migration von der einen Version auf eine andere geklappt hat, dann sind eventuell auftretende Probleme auf allen Maschinen eigentlich gleich. Einmal die Migration durchgezogen und bei den anderen Maschinen, kennt man mögliche Stolpersteine schon und begeht den Fehler nicht noch einmal. Spätestens bei der fünften Maschine habe ich dass dann sogar geskriptet und der Zeitaufwand ist minimalst. So läuft auch dieser Webserver hier auf Ubuntu 18.04. Gleiche Software auf allen Maschinen hat seine Vorteile. Konfigurationen können einfach einmal entwickelt auf allen Maschinen verwendet werden. Die Postfixkonfiguration auf dem Webserver kann ich dann locker auch auf dem Desktop testen.

Aber snap auf dem Webserver hier? – Nein! –  Das will ich nicht! Richtig abschalten lässt sich snap nicht, denn das Beispiel mit chromium-browser hat mir gezeigt, dass die Distribution mit mit dem apt install chromium-browser anlügt und eine Transitionalpaket installiert, das einfach auf snap zeigt. Ich weiss dabei nicht bei wie vielen Paketen das Ubuntu noch macht. Das ist mir suspekt.  Ich will wissen, was ein Befehl macht und nicht auf snap zwangsmigriert werden. Es gibt Kontexte, da halte ich snap durchaus für sinnvoll, aber ich will mir das nicht vorschreiben lassen, wann ich snap einsetze und wann nicht.

Die Migration von init auf systemd stört mich schon länger. Hierbei halte ich es auch für unverantwortlich, dass eine Kompilation und Installation von systemd in einer anderen Version als der von der Distribution dir das gesamte System zerschiessen kann. Wenn udev nicht mehr funktioniert, dann funktionieren auch alle Geräte nicht mehr. Das System gerät in einen inkonsistenten Zustand.  Systemd und udev sind hier zwangsverbunden. Devuan löst das indem es eudev verwendet. 

Ich weiß, dass sehr sehr viele auf systemd in der Zwischenzeit schwören. Im Prinzip nutzen das alle großen Distributionen. Es ist also kein Fehler von Ubuntu Focal Fossa alleine, sondern das wird mir auch bei RedHat (Fedora), SuSE (OpenSuSE), Mint, Debian und sonstwas begegnen. Aber das erst mal zu den beiden ersten getesteten Distributionen, gegen die von der Qualität nichts generell zu sagen ist. Linux ist an sich ein tolles Betriebssystem auch in diesen beiden Geschmacksvarianten, aber konkret sind die beiden Varianten erstmal für mich raus.

To be continued…


Von der Vielfalt oder Qual der Wahl

Linux ist nicht Linux ist nicht gleich Linux und schon gar nicht nur Ubuntu. Es ist mir häufig genug passiert, dass schon ein simpler Wlanstick beworben wurde, dass er Linuxunterstützung hätte. Hinterher stellte sich heraus, dass der Chip in Version 7 des Wlansticks, der in Version 1 noch vollkommen linuxkernelkompatibel war, von Larry Finger gar nicht gepflegt wird, sondern nur die Version 1 und dass der mitgelieferte Treiber für genau eine Ubuntuversion funktionierte. Der USBwlanstick, dessen Herstellernamen ich vergessen habe, habe ich dann zurückgegeben und mir einen 40 Euro billigeren genommen, der Raspberry Pi unterstützte. Kernel ist Kernel und siehe da der funktionierte dann auch mit dem neuesten Ubuntu aber eben nicht nur, sondern wohl mit allen Viererkernel und Fünferkernel.

Die Behauptung, dass etwas auch unter Linux bei der Hardware funktioniert, sollte nur jenen Herstellern gestattet sein, die es geschafft haben mit ihrem Treiber im Linux Maintree zu landen und dessen Treiberquelltext vollkommen veröffentlicht ist. Dann allerdings geht die Post ab, denn dann funktioniert das mit so vielen Linuxvarianten und Derivaten über Jahrzehnte. Mein AsusEEE-Netbook funktioniert noch heute bis zu Ubuntu 18.04 und das ist jetzt über 10 Jahre. Die erste Hardware kam mit  Linux raus – leider habe ich ein Windows-AsusEEE, von der Hardware her fast identisch allerdings mit 1 GB weniger Arbeitsspeicher. Windows wurde es damals, weil die blöde Steuersoftware der GmbHs nur Windows konnte und ich die Bilanz halt in Windows erstellte. Die GmbHs sind in der Zwischenzeit liquidiert und ich muss mir den staatlich verordneten Windowszwang nicht mehr geben. Der Windowszwang entsteht hierbei lediglich über die revisionssichere Zertifizierung, es ist nicht so, dass Linux die ganzen Kontenrahmen usf. nicht könnte, aber ist das alles halt vom Staat nicht offiziell zertifiziert.

Zurück zur Überschrift und der Vielfalt und der Qual das richtige Linux zu wählen. Wenn ich also die Grundentscheidung getroffen habe, Linux zu verwenden, dann lande ich zumindest in der Gewohnheit bei irgendwas ohne echten Vergleich. Denn die Auswahl ist unendlich so scheint es. Oder nein, mein Entscheidungsprozess ist nicht nur Gewohnheit. Das beginnt eigentlich schon Anfang der 90er Jahre. Mein Compaq Presario mit 10 Megabyte Arbeitsspeicher und einem i386 bekam ein Slackware, den Rechner hatte ich ziemlich lange, bis ich ihn dann doch wegwarf. Wiederverkaufen konnte ich ihn nicht, weil die Mehrheit der Menschen glaubte, dass ein DOS-Rechner entweder 8 oder 12 Megabyte haben müsste und bei 10 Megabyte doch etwas faul sein müsste. Faul war daran gar nichts er hatte nur nicht die üblichen Speicherslots sondern eine riesige Speicherkarte über die ganze Länge des Rechners verbaut.

Bevor ich Linux entdeckte hatte ich einen Atari 1024 ST mit GemDOS, war ein feines Stück. Windows kannte ich nur vom Hörensagen und als ich das erste Mal ein Windows 3.1 erblickte bekam ich mehr oder weniger einen Lachanfall. Was da geboten wurde kannte mein Atari schon in den 1980ern. Windows war noch nie State of the Art. OS/2 war das bessere Windows konnte auch gut mit Windowsprogrammen umgehen, aber OS/2 lebte nicht lange.

Ab den Anfang der 90er Jahre fuhr ich aber dann DOS/Linux bzw später Windows/Linux im Dualboot gleichzeitig. Mein letztes Windows war ein Windows 7 – seitdem fasse ich Windows nur noch gegen viel viel Geld an – freiwillig eigentlich gar nicht. Was nichts daran ändert, dass ich hier und da noch Windowssupport mache, weil ich mich ja in IT auskenne. Aber Windows fasse ich nur noch gegen Geld an. Ab Windows 10 sind die Dinger nicht mehr ruhig zu stellen und ein Datenschleudergau meines Erachtens, der kriminell ist. Ursprung diese Artikels ist, das ich mir mein Ubuntu 18.04 geschrottet habe, weil ich systemd von den Quelltexten kompiliert habe und damit udev unbrauchbar machte. Deswegen habe ich mir Backups eingespielt und da kam auch die Windows 7 Partition wieder auf den Rechner. Die Partition habe ich seit 2014 nicht mehr angefasst, wanderte aber mit den Backups immer schön brav mit. Dann schaute ich mich mal um, was da so alles rumliegt. Irgendwie hat es mich gerissen, was /Windows/CSC/ so alles speichert.

In dem Ordner, den ich mir auf der Partition anschaute, waren Daten gespeichert, von denen ich gar nicht wusste das ich sie habe. In einem Unterordner namespace befanden sich unter dem Schema Rechnername von jedem verbundenen Windowsrechner von denen der Laptop mal einen Share gesehen hat im Prinzip Komplettkopien des Shares. Unter Windows selbst sieht man den Ordner normalerweise nicht. Vorteil dieser lokalen Kopien dieser fremden Rechnershares ist natürlich, dass Windows damit schneller arbeitet, weil es sich nicht jedes Mal die Dateien aus dem Netz holen muss. Der datenschutztechnische Nachteil ist, dieses Windows zieht sich viel zu viele Daten. So hatte ich alle Mitgliederdaten der Piratenpartei Oberbayern aus dem Jahr 2012 dort rumliegen und wusste es nicht mal. Ich war damals Generalsekretär der Piraten Oberbayern und habe eigentlich nur mal eine Datei von meinem PC auf den Windowspiratenpc in der Landesgeschäftsstelle kopiert. Das Windows sich bei dieser Gelegenheit gleich eine Kopie des Shares von der Geschäftsstelle zieht, wer ahnt denn sowas.

Nein Datenschutztechnisch ist Windows eine Katastrophe und hier habe ich keine Qual der Wahl, das Zeug kommt mir erst Recht nicht mehr ins Haus.




 

Derzeit habe ich den Artikel hier auf einer LiveCD mit Linux Ubuntu 20.04 begonnen. Nachdem ich jetzt dargestellt habe, warum Windows definitiv nicht in Frage kommt, mal kurz, warum das Ubuntu weg muss. Ubuntu kam irgendwann 2006 bei mir daher. Es war das Neue auf dem Linuxparkett und man hörte viel Gutes.  Ubuntu basierte auf Debian und Debian war mir bekannt. Ich allerdings war kein Fan vom Debianpackagemanagement. Ich beherrscht RPMs. Wie man so ein DEB baut, war mir suspekt und zu kompliziert. Deswegen war ich gegenüber Wartdog, Hedgehog oder Badger skeptisch. Ähnlich wie ich mir jetzt mein Ubuntu 18.04 zerschossen hatte ich mir mein SuSE mit einem Update zerschossen bzw. von dem NeunerRelease auf das Zehner lief alles nicht. Schaue ich heute bei Wikipedia stelle ich gerade fest, dass waren sowieso die letzten SuSE Linux – danach wurde es OpenSuSE. Auch damals war ich auf der Suche nach einer neuen Distribution. Da SuSE sich nicht mehr gut anfühlte landete ich zunächst bei Gentoo. Da hatte Gentoo noch Jahreszahlen in den Releases. Eigentlich war das System gar nicht so schlecht, aber der Zeitaufwand der Kompilation bei schwachbrüstigen Rechnern war auch nicht ohne. Obwohl es mir zwar irgendwie gefiel, war es doch nicht wirklich meins. Nach dem RPMs aber mit Gentoo eh gestorben waren, warum nicht dann nicht doch ein DEB-Distri probieren.

Ubuntu mit Dapper Drake überraschte dann und so blieb ich bei Ubuntu hängen. Meine Frau migrierte ich zu Kubuntu von Windows weg. Das klappte hervorragend. OpenOffice/LibreOffice war so gut gediegen, dass meine Frau problemlos vom damaligen Microsoft Office umsteigen konnte. Heutzutage kommt sie mit Windows nicht mehr zurecht, wenn sie es in der Arbeit verwenden muss. Sie ist Kubuntu gewöhnt. 

Mit dem jetzigen Kubuntu 18.04 kommt meine Frau noch besstens zurecht. Mein Sohn nutzt das selbe System auf einem eigenen Rechner oder wenn die Rechenleistung des AsusEEE zu schwach ist auch mal auf dem Rechner meiner Frau. Aber da kommen wir schon zu dem Punkt, dass ein Update auf 20.04 beim AsusEEE nicht geht, das ist ein 32bitter und der wird von Ubuntu in 20.04 nicht mehr unterstützt.

Und dann hat Ubuntu mit 20.04 eine Seuche, die nennt sich snap. Ein apt install chromium-browser führt nicht dazu, dass chromium als deb installiert wird, nein der Benutzer bekommt ein Snappaket untergejubelt, dass sich beim Start dann so verhält:

mkdir: cannot create directory ‚/home/ubuntu/snap/chromium/1143/.config‘: Permission denied
mkdir: cannot create directory ‚/home/ubuntu/snap/chromium/1143/.local‘: Permission denied
mkdir: cannot create directory ‚/home/ubuntu/snap/chromium/common/.cache‘: Permission denied
mkdir: cannot create directory ‚/run/user/0‘: Permission denied
/snap/chromium/1143/bin/desktop-launch: line 270: /home/ubuntu/snap/chromium/1143/.config/user-dirs.dirs: No such file or directory
/snap/chromium/1143/bin/desktop-launch: line 271: /home/ubuntu/snap/chromium/1143/.config/user-dirs.dirs.md5sum: No such file or directory
cp: cannot create regular file ‚/home/ubuntu/snap/chromium/1143/.config‘: Permission denied
/snap/chromium/1143/bin/desktop-launch: line 276: /home/ubuntu/snap/chromium/1143/.config/user-dirs.locale.md5sum: No such file or directory
Can’t create dir /home/ubuntu/snap/chromium/1143/Schreibtisch
Can’t create dir /home/ubuntu/snap/chromium/1143/Downloads
Can’t create dir /home/ubuntu/snap/chromium/1143/Vorlagen
Can’t create dir /home/ubuntu/snap/chromium/1143/Öffentlich
Can’t create dir /home/ubuntu/snap/chromium/1143/Dokumente
Can’t create dir /home/ubuntu/snap/chromium/1143/Musik
Can’t create dir /home/ubuntu/snap/chromium/1143/Bilder
Can’t create dir /home/ubuntu/snap/chromium/1143/Videos
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
realpath: “: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
/snap/chromium/1143/bin/desktop-launch: line 410: /home/ubuntu/snap/chromium/1143/.config/fontconfig/fonts.conf: No such file or directory
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.local/share‘: No such file or directory
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.themes‘: Permission denied
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/common/.cache’: Permission denied
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.config/dconf‘: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.local’: Permission denied
ln: target ‚/home/ubuntu/snap/chromium/common/.cache/gio-modules‘ is not a directory
/snap/chromium/1143/bin/desktop-launch: line 504: /home/ubuntu/snap/chromium/common/.cache/gdk-pixbuf-loaders.cache: No such file or directory
Unable to open directory /home/ubuntu/snap/chromium/common/.cache/gio-modules: Error opening directory “/home/ubuntu/snap/chromium/common/.cache/gio-modules”: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.local’: Permission denied
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.config/gtk-3.0/settings.ini‘: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.config/gtk-3.0/bookmarks‘: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.config/gtk-2.0/gtkfilechooser.ini‘: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/1143/.config’: Permission denied
ln: failed to create symbolic link ‚/home/ubuntu/snap/chromium/1143/.config/ibus‘: No such file or directory
mkdir: cannot create directory ‘/home/ubuntu/snap/chromium/common/.cache’: Permission denied
ln: target ‚/home/ubuntu/snap/chromium/common/.cache/immodules‘ is not a directory
/snap/chromium/1143/bin/desktop-launch: line 580: /home/ubuntu/snap/chromium/common/.cache/immodules/immodules.cache: No such file or directory
/snap/chromium/1143/bin/desktop-launch: line 591: /home/ubuntu/snap/chromium/1143/.last_revision: Permission denied
Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)

Herrlich nicht wahr? Und wie erkläre ich das meiner Frau, wenn sowas passiert? Nein, geht weg, das kann ich ihr nicht erklären, das führt nur zur Schwierigkeiten.

To be continued….