Beiträge von maxblue

  • Leap - Partitionierung mit getrennter /boot Partition + BTRFS mit LUKS - GRUB-Eintrag zum Booten von Snapshots fehlt

    Hi,


    ich bin mit Leap unterwegs und habe vor ein paar Tagen das System neu aufgesetzt und das Partitionslayout geändert. Ich hatte eine EFI Partittion und ansonsten nur ein verschlüsselte BTRFS Partition auf / eingehängt. Das führte dazu, dass ich bei jedem Systemstart 2x das Kennwort eingeben musste und LUKS1 verwendet wurde, da GRUB kein LUKS2 entsperren kann. Zudem dauert das erste Entsperren ewig..


    Ich habe mir dann mit den genialen Möglichkeiten des Suse Setup-Tools folgendes Layout eingerichtet:


    - 512MB EFI Partition FAT32 auf /boot/efi

    - 1024MB Partition EXT4 auf /boot

    - Rest BTRFS mit LUKS verschlüsselt auf /

    - kein SWAP


    Das führt dazu, dass das System soweit unverschlüsselt bootet, dass LUKS2 entsperrt werden kann und ich nur 1x das Kennwort eingeben muss. Das Problem ist nun aber, das trotz gemountetem .snapshots, installiertem grub2-snapper-plugin und passenden Configs kein GRUB Eintrag zum Booten von Snapshot angezeigt wird.


    Ich hatte im Netz gelesen, dass es diesbezüglich wohl mal ein Problem bei Verwendung einer getrennten /boot Partotion und BTRFS auf / gab.


    Kann jemand dazu etwas sagen?


    Gruß,

    Max

  • BTRFS - Compress mit seltsamen Ergebnissen

    EDIT zu meinem Post:


    Ich lesen in den DOCs zu BTRFS gerade folgenden Satz im Abschnitt "How to enable Compression"


    Typically the compression can be enabled on the whole filesystem, specified for the mount point. Note that the compression mount options are shared among all mounts of the same filesystem, either bind mounts or subvolume mounts. Please refer to btrfs(5) section MOUNT OPTIONS.


    Das würde bedeuten, wenn compress=zstd für den mount point "/" bereits aktiviert ist, dann gilt dies auch für alle darunter liegenden Subvols. Es würde ebenfalls erklären, warum im Installer, wenn man manuell partitioniert, diese Option für die Subvols nicht zur Verfügung steht. Zudem könnte das nachträgliche Hinzufügen des Parameters bei allen Subvols zu dem oben beschriebenen Verhalten führen. Bemerkenswert allerdings, dass dann diverse HowTo's im Netz ebenfalls falsch wären.

  • BTRFS - Compress mit seltsamen Ergebnissen

    Moin zusammen,


    ich habe bei der Installation meine Platte manuell mit BTRFS partitioniert und für / bereits den Paramater compress=zstd:3 eingerichtet. Für die Subvols kann man das scheinbar erst später in der /etc/fstab anpassen.


    Das habe ich wie folgt getan:



    Meine sonstige Orgie an weiteren Parametern habe ich mir gespart, weil ich denke, dass die bei Suse schon wissen was sie tun und das sont angepasst hätten. Hatte bisher bei anderen Distros noch folgende Paramater mit drin (was z.T. auch Standard ist):


    defaults,noatime,space_cache=v2

    Nach Anpassung der  /etc/fstab  dann ein Neustart und mit folgendem Aufruf die Komprimierung angestoßen:


    sudo btrfs fi defragment / -r -czstd


    Als Ergebnis erhalte ich dann eine Platte die mehr belegt ist wie vorher. Sonst hat das immer funktioniert und es waren nach der Komprimierung nur noch ca. 60-70 belegt im Gegensatz zu vorher.


    Hat jemand eine Idee dazu?

  • Angepasste Konfig in /etc/pam.d wird überschrieben

    Herzlichen Dank für die Beiträge und Schande über mein Haupt. Hätte direkt in den Konfig Dateien lesen können wie es geht und dazu noch eine gute Doku bei Suse...


    Ehrlich gesagt war ich in letzter Zeit so viel in der Shell unterwegs, dass ich mir die Bemerkungen in den Konfig Dateien nicht mehr durchgelesen hab. Obwohl es immer ratsam ist dies zu tun.


    Hab mich für die von Suse vorgeschlagene Lösung entschieden, die Links entfernt und die Dateien ohne -pc dahinter angepasst. Sollte jetzt erledigt sein.

  • Angepasste Konfig in /etc/pam.d wird überschrieben

    Moin zusammen,


    kurz zu mir: ich bin neu im Forum und seit kurzem mit Tumbleweed unterwegs. Vorher habe ich einige Jahre eine Ubuntu-basierte LTS Distro genutzt und bin dann übereifrig zu Arch gewechselt, was mir etwas sehr "zu Fuß" war. Man lernt halt eine Menge. An Tumbleweed schätze ich die Aktualität bei gleichzeitiger Stabilität und die richtig gute BTRFS-Integration mit allem was man sich wünscht. Ich nutze Snapshots und möchte bei Problemen ein Rollback durchführen können. So viel dazu.


    Ich nutze ein mit gocryptfs verschlüsseltes Home Verzeichnis, welches per PAM_MOUNT bei der Anmeldung eingebunden wird. Das funktioniert auch prima, jedoch hat das letzte Update per Zypper meine angepassten Konfigs in /etc/pam.d überschrieben, so dass ich diese erneut anpassen musste.


    Meine Frage: Ist das normal, das angepasste Konfigs einfach überschrieben werden? Es galt ja ziemlich lange als Thema bei OpenSuse, das man Konfigs möglichst per Yast anpasst, damit sie nicht überschrieben werden. In Yast habe ich aber keine Möglichkeit gefunden die common-auth und die common-session anzupassen. Habe ich etwas übersehen? Wie kann ich das Überschreiben ggf verhindern?


    Gruß,

    Max

  • /home Laufwerk nachträglich verschlüsseln

    Sehr schöner Link. Das wäre die dritte von mir genannte Lösung, hier allerdings vernünftig aufbereitet.


    Nachteil gegenüber Gocryptfs ist die starre Größe des LUKS Containers der direkt in voller Größe vom Gesamtplatz abgezogen wird. Hier müsste man beim Erstellen eine Balance finden zwischen dem was noch an sonstigem Platz benötigt wird und was du im Home benötigst. Sollte das Verhältnis nicht mehr passen, müsste die Größe des Containers angepasst werden, was mit einer gewissen Gefahr von Datenverlust einher geht. Solltest du sowieso eine eigene Partition (statt nur eines Subvolumes) für Home nutzen, dann ist das ggf. nicht relevant.


    Vorteil gegenüber Gocryptfs ist die Tatsache, dass die Daten besser gegen andere User des Systems abgesichert sind. Wie erwähnt, kann die eingehängte Home Partition ggf. nicht korrekt ausgehängt werden, so dass sich nach dem Abmelden andere User mit SUDO Rechten Zugriff verschaffen können. Für dich ggf. nicht relevant.


    Ich würde deine Anforderungen auf jeden Fall vorher in einer VM testen. Ebenfalls gibt es mit den verschiedenen Lösungen ggf. Probleme beim Hybernate/Suspend to Disk - solltest du das auf deinem Notebook nutzen.

  • /home Laufwerk nachträglich verschlüsseln

    Moin zusammen,


    ich bin neu im Forum und gerade eben bei OpenSuse angekommen. Linux im Allgemeinen betreibe ich schon seit einigen Jahren, insofern ist eine gewisse Erfahrung vorhanden.


    Ich würde zu dem Thema gerne etwas schreiben, da ich mich in den vergangenen Wochen/Monaten ausgiebig mit Verschlüsselung unter Linux im Allgemeinen beschäftigt habe. Und es sieht schlechter aus als man denken mag. Aktuell ist eigentlich nur LUKS2 + Argon2ID als wirklich sicher zu bezeichnen. Das können schon mal viele Distros per Installer gar nicht bereitstellen. Hier gibt es das Problem, das GRUB aktuell nicht in der Lage ist solch eine Partition zu entsperren. Insofern behelfen sich einiges Distros mit einer kleinen unverschlüsselten BOOT-Partition, über die dann die LUKS Partition entsperrt wird. Übrigens zu erkennen an dem grafischen Entsperr-Bildschirm (z.B. Fedora oder Ubuntu). Alternativ kann man sich eine gepatchte GIT-Variante von GRUB besorgen, die solch eine LUKS Partition entsperren kann, dafür allerdings mangels Optimierung sehr lange benötigt (ca. 30sec). Zudem eher Bastel-Lösung.


    Vor dem oben verlinkten systemd-homed kann ich aus persönlicher Erfahrung nur warnen. In meinen Augen ist es noch nicht ausgereift und steht meines Wissen unter LEAP gar nicht offiziell zur Verfügung. Ich habe systemd-homed auf zwei anderen Distros jeweils ca. 2 Wochen betrieben und endete beide Male in einem nicht mehr zu öffnenden LUKS Container, sodass ich auf meine Daten im Home nicht mehr zugreifen konnte. Auf Recherche & Versuche der Reparatur habe ich verzichtet, da die Lösung für mich schon raus war. Das muss einfach zuverlässig laufen.


    Welche Möglichkeiten gibt es denn aktuell überhaupt?


    Kurzer Überblick (ggf. unvollständig):


    - Komplette Partition verschlüsseln mit LUKS -> Unkomfortabel, da 2x Kennwort erforderlich & Problematik wie oben erläutert

    - Systemd-homed verwenden -> nach meiner Erfahrung noch unzuverlässig - siehe Erläuterung oben

    - Einen LUKS Container erzeugen und per LOOP Device nach der Anmeldung als Home einhängen -> Es gibt dazu einige HowTo's, halte ich aber eher für eine Bastellösung (Funktion ähnlich wie systemd-homed)

    - Ecryptfs verwenden und das Home Verzeichnis per PAM.MOUNT nach der GUI-Anmeldung automatisch entsperren und einhängen -> ecryptfs ist EOL, wird nicht mehr aktiv entwickelt und gilt als veraltet

    - Gocryptfs verwenden und ebenfalls per PAM.MOUNT nach der Anmeldung automatisch einhängen -> Nur 1x anmelden, zudem wird Gocryptfs aktiv entwickelt und gilt als ziemlich sicher.


    Ich nutze aktuell die Lösung mit Gocryptfs in Verbindung mit Tumbleweed und es funktioniert bisher sehr zuverlässig. Sollte mit Leap ebenfalls funktionieren. Problem könnte hierbei sein, dass ich kein HowTo für OpenSuse gefunden habe. Man muss also vorhandene Anleitungen etwas "umdenken" auf Suse. Bei Interesse würde ich ein HowTo erstellen und hier im Forum zur Verfügung stellen.


    Diese Lösung funktioniert zudem auch einwandfrei in Verbindung mit Snapper und mit dem BTRFS Layout, das OpenSuse bereitstellt um Snapshots erstellen und z.B. booten zu können. Übrigens einer der Gründe, warum ich zu OpenSuse gewechselt bin. Richtig klasse gemacht.


    EDIT:


    - Durch die Tatsache, das LUKS in den Kernel integriert ist und Gocryptfs per FUSE läuft, ergeben sich leichte Nachteile in der Schreib/Lesegeschwindigkeit.

    - per Gocryptfs eingehänge Home Verzeichnisse könne nach dem Abmelden meist nicht wieder ausgehängt werden, da Prozesse (Audio) noch zugreifen. Die Daten bleiben also lesbar.



    Gruß,

    Max