Installation "state of the art" Fragen

[debianx]

Hallo an alle,

seitdem ich gefühlt 100 Jahre keine Neuinstallation mehr machen musste (spricht für Linux), ist es nun soweit. Ein paar Dinge haben sich seitdem geändert, wie zB dass es nun eine SSD ist und das ich SWAP möchte, auch das Btrfs scheinbar an Macht gewinnt, daher ein paar Fragen.
Basis soll ein vollverschlüsseltes System sein. Die komplette Platte bzw alles was geht soll verschlüsselt sein. Bei der Installation ist die Vollverschlüsselung wohl automatisch mit LVM auswählbar was ich so anstreben würde weil es auch einfacher ist.

Meine Fragen die aufgekommen sind:

- Ich benötige SWAP um Suspend-to-Disk nutzen zu können. Wenn man bei der Installation mit LVM vollverschlüsselt, ist dann der SWAP-Speicher auch wirklich sicher verschlüsselt?
(Im Netz finden sich viele Diskussionen darum die zwar teilweise sagen, mit LVM ist es verschlüsselt aber in Summe sieht es so aus, als wäre eher ein unverschlüsselter SWAP bei Linux Normalität gewesen..., was ja heftig ist und nichts anderes als ein Backdoor wäre aber vielleicht so auch heute nicht mehr Stand der Dinge ist).

- Ist es korrekt das bei der verschlüsselten LVM Installation TRIM aus Sicherheitsgründen komplett deaktiviert und man nichts weiter tun muss? (was ja prima wäre)

- SSD komplett Verschlüsseln oder einen Teil zB 15 GB frei lassen? Ist das bei heutigen SSDs noch nötig?
SSDs haben ja heute Reservespeicher. Reicht dieser aus und man kann einfach alles Vollverschlüsseln ohne die Haltbarkeit stark zu beeinflussen?
Ich verstehe es so: alles was verschlüsselt ist, ist für die SSD komplett belegter Speicherbereich, ob dieser nun im Dateisystem gefüllt ist oder nicht. Aus diesem Grund müsste nach meiner Logik die SSD zur gleichmäßigen Nutzung der Zellen, die belegten Zellen (alles vollverschlüsselte) immer wieder unter sich umschichten um eine gleichmäßige Abnutzung zu garantieren. Natürlich gibt es den Reservespeicher aber auch dieser besteht ja aus Zellen die irgendwann öfter genutzt wurden als bereits Belegte wenig genutzte. Somit werden zwangsläufig Zellen auf denen nie genutzte oder lang ungenutzte Daten liegen (also frisch sind) irgendwann für neue Daten benutzt wenn die Mehrzahl der anderen Zellen älter sind.
Ein bisschen Mehrverschleiß wäre mir total egal zB die Platte hält statt 30 Jahre eben 25 Jahre. Wie seht ihr das, SSD komplett Vollverschlüsseln oder ein paar GB unformatiert frei lassen?

- Dateisystem: nimmt man heute noch als normaler User ext4 oder besser inzwischen Btrfs? Btrfs soll ja wohl die Zukunft sein... Schnappschüsse sind mir jetzt nicht so wichtig denn Backups mach ich mit rsync. Komprimierung find ich aber spannend (geht die auch Ordnerweise?) ist aber nicht wichtig. Habe aber auch kritische Stimmen gelesen dass Btrfs wohl viel Auslastung verursacht (freut SSDs ja auch nicht unbedingt) und Dinge noch nicht funktionieren (vielleicht war das aber auch alter Content und nicht mehr zeitgemäß).

Viele Grüße

[schwedenmann]

Hallo

Dateisystem: nimmt man heute noch als normaler User ext4 oder besser inzwischen Btrfs? B

ist eine Entscjeidung,die jeder anders trifft.

Ich persönlich setze kein btrfs auf Systemen ein,wo mir Daten wichtig sind,auf Servern erst Recht nicht,da kommt eher FreeBSd mit zfs zum Einsatz. Anderre hier im Forum setzen btrfs auch auf produktiven servern ein soweit ich deren Kommenatre verstanden habe. Auf einem normalen Pc benutz ich ext4 für / und für andere große Partition meist /home jfs,aber ich bin afaik hier im DE der Einzige der jfs einsetzt


mfg
schwedenmann

[rhHeini]

Filesystem: als Anwender rate ich Dir zu ext4. Bewährt. sicher, ausgereift. Keine Spielwiese wie btfrs, jfs, und wie sie nicht alle heissen. So was brauchst Du nicht.

Vollverschlüsselung: Standard ist nach wie vor ein unverschlüsseltes /boot, dann kannst Du in einem Volume für Verschlüsselung ein LVM anlegen das root und swap umfasst. Brauchst nur einen Key um das zu entschlüsseln. /home würd ich separat halten, auch verschlüsselt. Kann in einem zweiten Schritt von root aus entschlüsselt werden. So mach ich es jedenfalls.

Ein LVM ist für sich nicht verschlüsselt.

Ich lass auf meinen NVME und SSD immer etwas Platz frei. Die sind alle so groß das ich es mir leisten kann. Und discard steht überall drin in der fstab.

Rolf

[mcb]

Wie weit bist du denn?

'State of the art':

- alles außer /boot (& efi) in einem verschlüsseltem Cryptodevice
- ext4
- Trim nach Geschmack (ich habe es aus gelassen) ...

[debianx]

Danke, alles klar dann bleibe ich bei ext4. Kam jetzt erst dazu alles weiter auszuprobieren.
Bei der geführten Installation von Debian hat man leider keinerlei Einfluss auf Parameter wie auf die Größe vom SWAP und kann auch kein Platz auf der SSD frei lassen daher hab ich ein bisschen mit manuell rumprobiert.
Ich hab diese Anleitung mal durchgeführt: https://itectec.com/unixlinux/debian-ho ... -swapfile/
Hab aber nur root boot und swap in der Volumengruppe erstellt, brauche keine weitere Trennung zu home usw.
Klingt nach mehr Sicherheit, dass /boot auf diese Weise wohl auch in die LUKS Partition mit in eine Volumengruppe reinkommt. Aber das hat so bei mir nicht funktioniert und da hat nichts gestartet, es wurde nichts gebootet oder nach Passwort gefragt, nur was von GRUB wo man dann was eingeben konnte. Das ganze Thema mit Legacy/CSM oder nur EFI spielt auch rein und man muss sich entscheiden. Mache jetzt erst mal mit dem EFI weiter da muss man sich wohl dran gewöhnen vermute ich.
Ich bin daher jetzt daran gegangen mir mal die geführte Standartinstallation (LVM + LUKS) des Installers anzuschauen, was der da anlegt, um das dann die Tage mal per manueller Installation nachzubauen und dadurch SWAP-Größe zu beeinflussen und etwas unpartitionierten SSD-Speicher zu bekommen.
Was wundert, sind 2 für mich unnütze Partitionen, die der Installer bei der geführten Installation anlegt, hier mal alle Dinge die er anlegt:
- partition_1MB: freier speicher
- partition_536MB: ESP (ist wohl FAT32)
- partition_511MB: ext2 /boot
- partition_1TB: crypto
- partition_73KB: freier speicher
aus crypto ergibt sich verschlüsseltes volumen lvm mit:
- LVM root ext4 /
- LVM swap swap swap

Was sollen denn bitte diese 1MB und 73KB Partitionen freier Speicher die der Installer da anlegt??
Kann man /boot nicht auch in das LVM packen wie in der Anleitung? bringt das überhaupt ein Sicherheitsvorteil?

Gruß

[debianx]

ok die Aufteilung so zu machen, wie es der geführte installer macht, hat funktioniert.
Der Unterschied zur Anleitung war auch, dass bei der Anleitung das verschlüsselte Volumen als ext4 statt "physikalisches volumen für LVM" eingestellt war und die crypto-Partition bei der Anleitung ein boot-flag hatte. Sehr kompliziert alles und verstehen tu ich jetzt nicht wirklich was die Unterschiede zur Anleitung bewirken und warum diese nicht funktioniert aber jetzt funktioniert schon mal eine Variante und so hat man jetzt zumindest mal Einfluss auf SWAP und kann der SSD etwas unpartitionierten Platz lassen.
Ich probiere dann bei Gelegenheit dann noch bisschen weiter rum, bin echt nicht auf dem Stand der Dinge, sofern ich das jemals war
Ich frage mich dann noch mit der EFI Partition, wofür ist dann noch die ext2 /boot Partition gut? Sind echt 2 boot Partitionen nötig?

[mcb]

Ja echt zwei nötig. Mir haben die beiden Anleitungen schon geholfen:

Full disk encryption, including _boot Unlocking LUKS devices from GRUB:

https://cryptsetup-team.pages.debian.ne ... -boot.html

How to install debian alongside Windows (dual boot) with full disk encryption - Ertugrul Harman's Notebook

https://ertugrulharman.com/en/2017/09/0 ... ncryption/

Auf reddit stand das /boot jetzt auch mit verschlüsselt wird vom Textmodeinstaller?

Edit: Ich blicke nicht durch es gibt zwei ?!? graphische Installer ?!?

[debianx]

Edit: Ich blicke nicht durch es gibt zwei ?!? graphische Installer ?!?

Bei live cd hat man wie es aktuell aussieht 3 Möglichkeiten:
- direkt von boot: "nicht grafisch" (nur tastatur)
- direkt von boot: grafisch
- live cd vom Desktop environment: grafisch
somit 2x grafisch ist nicht falsch, wobei definiere "grafisch" denn auch "nicht grafisch" (nur tastatur) ist "grafisch" also deutlich mehr als konsole und es macht den eindruck je grafischer desto weniger Einstellmöglichkeiten. Bei den verschiedenen Installermöglichkeiten kommen auch leicht andere Partitionsergebnisse raus wenn man die geführte nimmt.
sicherlich gibts auch profis die alles komlett im terminal machen können, ich gehöre nicht dazu

Auf reddit stand das /boot jetzt auch mit verschlüsselt wird vom Textmodeinstaller?

Also ich hab es manuell versucht /boot mit ins LVM zu tun aber es funktioniert nicht, da steht dann von GRUB: Minimal BASH-like line editing is supported. For the first word, usw
Also entweder man muss da noch was bestimmtes beachten oder es geht einfach doch nicht.

[mcb]

Zu Buster Zeiten brauchte es ein mit LUKS Ver.1 verschlüsseltes /boot oder eben LUKS Ver.1 für / inkl. /boot ...

Steht alles in den Links. Eine der drei bullseye Installationsmethoden macht jetzt etwas ähnliches Man hat dann US-Layout am Promt.

Ich habe gerade keinerlei Muße mein System neu aufzusetzen, sonst würde ich es mal probieren.

[debianx]

- partition_1MB: freier speicher
- partition_73KB: freier speicher

habe jetzt gelesen, dass die Startposition jeder Partition ein vielfaches von 4kByte betragen soll. Vielleicht ist das der Grund für diese 2 unnötigen aussehenden Partitionen die angelegt werden?

[rhHeini]

habe jetzt gelesen, dass die Startposition jeder Partition ein vielfaches von 4kByte betragen soll. Vielleicht ist das der Grund für diese 2 unnötigen aussehenden Partitionen die angelegt werden?

Genau so ist es. Das sind keine! Partitionen, sondern freigelassener Speicher.

[wanne]

habe jetzt gelesen, dass die Startposition jeder Partition ein vielfaches von 4kByte betragen soll.

Für drehende Platten. SSDs sind komplexer und haben unter der Haube weit größere "zusammenhängende" Bereiche. Deswegen nimmt man heute eher 1MiB Grenzen. Man verschenkt durch den Verschnitt nicht viel. Und es kann deutliche Performance-Unterschiede machen.

Schnappschüsse sind mir jetzt nicht so wichtig denn Backups mach ich mit rsync.

Ist dann halt unnötig kompliziert, nicht konsistent und du brauchst ein vielfaches des Speichers, weil du keine diffs speichern kannst. Auf der anderen Seite hast du halt vermutlich dein Setup, dass seit Jahren tut.

Komprimierung find ich aber spannend (geht die auch Ordnerweise?)

Prinzipiell geht das Dateiweise. Das ist dann aber eben aufwändig. Alternativ kann btrfs subvolumes. Die verhaten sich wie ordner haben aber eben eigene Eintellungen wie Kompression etc.

und Dinge noch nicht funktionieren (vielleicht war das aber auch alter Content und nicht mehr zeitgemäß).

RAID5 ist noch immer experimentell. Aus performance Gründen würde ich bei RAID0/5/6/s aber eh immer DM-RAID Dateisysteminternen Varianten vorziehen.

Habe aber auch kritische Stimmen gelesen dass Btrfs wohl viel Auslastung verursacht

btrfs kann noch schlechter als andere Dateisysteme mit annähernd vollen platten umgehen. Sonst kann dir die Kompression sogar ein paar Schreibzyklen sparen. Fette Empfehlung: Setze, wie ext4 per default, 5% reserved und schreibe den wirklich nicht voll.

SSDs haben ja heute Reservespeicher. Reicht dieser aus und man kann einfach alles Vollverschlüsseln ohne die Haltbarkeit stark zu beeinflussen?

Ja.

als Anwender rate ich Dir zu ext4. Bewährt. sicher, ausgereift.

Wenn dir deine Daten Wurst sind, kannst du auch ext4 nutzen. Prinzipiell stecken da sehr unterschiedliche Ideen dahinter. btrfs hat zum Zwecke der Datensicherheit Checksummen und wenn es irgend wann feststellt, dass die nicht mehr stimmen läuft da meistens darauf raus, das es nur noch read only wird damit du dir gerade bei RAID1 noch möglichst umfassend korrekte Daten backupen kannst aber das System selbst wird unnutzbar. Bei ZFS steht Verfügbarkeit im Vordergrund. Ein RAIDZ nutz die Checksummen um auch mit einer kaputten Platte noch problemlos weiter zu laufen. Dafür fährt man halt größere Gefahr, dass irgend wann Daten verfälscht sind, wenn Teile einer weiteren Platte sterben. ext4 hat nur für Metadaten Cheksummen und stellt Fehler in Daten erst gar nicht fest bzw. wird nur bis zum nächsten reboot ro, wenn die Platte einen Fehler explizit wirft. Deswegen ist es sehr attraktiv für Desktopnutzer: Es läuft bis zum bitteren Ende weiter und hat tolle Reperationstools die auch ein sehr angeschlagenes Dateisystem unter Datenverlust wieder nutzbar machen.

[debianx]

Danke für die Infos!
Ich hab noch eine Frage. Wenn ich ein System aufsetze wo in einer lukspartition ein LVM ist, dann steht noch vor der Passwortabfrage:

Volume group "xyz" not found
Cannot process volume group xyz

Wieso steht da bitte vor der Entschlüsselung schon der Name der Volumengruppe "xyz"? Sollte das LVM nicht in der Lukspartition versteckt sein?, muss man sich Sorgen machen, dass die verschlüsselung nicht wirksam ist?

[rhHeini]

Die Meldungen sind normal. Du hast bereits in grub Verweise auf die noch versteckten root-Einträge. Schau mal in die grub.cfg.

Rolf

[debianx]

ok super, solange da nicht auch das Passwort drin steht ist ja dann ok