Grundsatzüberlegungen vor Neuinstallation

[liNixchecker]

Hi,
Swap mit zufälligem Schlüssel:
zuerstmal im Expertmode, dann bei Partition verwenden als "verschlüsseltes Device" und anstelle von "Passphrase" "zufälliger Schlüssel" einstellen. Dann wird sie auch automatisch als Swap formatiert (mein ich doch)

Macht keinen Sinn, wenn alles auf einer Platte liegt.

Du kannst beim erstellen eines LVs auch mitgeben, auf welchem pysikalischem Volume dieses LV liegen soll. Außerdem ist LV-Mirror nur möglich, wenn sich die Volume Group über mindestens zwei pysikalische Devices erstreckt.

Und wenn ich wg. LVM crypt über mehrere physikalische Platten brauche? Geht das auch?

Jede Platte hat ihr eigenes Keyfile, dann bilden die entschlüsselten mapper-devices jeweils ein PV für die Volume Group. Kein Problem.

Die Frage ist, ob man das so einrichten kann, das erst nach einem File geschaut wird, und wenn das nicht vorhanden ist, wird auf die Eingabe der Passphrase gewartet.

Macht LUKS automatisch, kein Keyfile - Passphrase.
Edit: geht über /etc/crypttab: dort muss dann name UUID=bla PFAD-ZUM-KEYFILE luks stehen
MfG,
Martin

[dirk11]

Und wenn ich wg. LVM crypt über mehrere physikalische Platten brauche? Geht das auch?

Jede Platte hat ihr eigenes Keyfile, dann bilden die entschlüsselten mapper-devices jeweils ein PV für die Volume Group. Kein Problem.

Also doch ein Problem. Wenn ich nachträglich Platten einfüge, habe ich doch wieder einen zweiten Key, den ich ja gerade mit LVM vermeiden will.

[NAB]

Mal ehrlich, ist das mit LVM nicht insgesamt auch vorteilhafter, weil ich dann wirklich noch die Möglichkeit habe, mittels LVM meine /-Partition unter Zuhilfenahme einer neuen Platte zu vergrößern, ohne dass es ein neues device dafür gibt?

Genau das willst du nicht haben. Dabei pappt LVM nämlich die beiden Devices einfach zu einem großen Device zusammen, und sobald eines davon ausfällt, hast du im gesamten LVM nur noch Datenmüll. Außerdem vergrößerst du damit nur das LVM ... danach musst du noch irgendwie das Dateisystem vergrößern ... bei ext4 hast du dann wieder das inode-Limit und bei XFS weiß ich nicht mal, ob sich das vergrößern lässt. Genau solche Probleme will btrfs angehen.

(Gut, du kannst beide LVM-Teile mit einem Raid1 absichern, das verringert die Probleme, dann hast du aber zwei Raid1, die jedes einzeln mit einem Passwort abgesichert werden müssen, falls du verschlüsseln willst)

Mir scheint gerade die LVM-Lösung die einfachere zu sein, bisher war ich auch nur deshalb gegen LVM, weil ich die leise Befürchtung habe, das bei einem upgrade von Wheezy auf das nächste Stable eine Schicht mehr vorhanden ist, die Probleme bereiten kann. Ich bin wie man sieht immer noch im Findungsprozeß...

Die Sorge halte ich für unbegründet. Ich betreibe Debian seit Sarge und LVM hat noch nie Probleme gemacht.

Gerade auf Desktopsystemen halte ich inzwischen aber gar nichts mehr von übermäßigem Partitionieren, und damit verschwindet auch der Bedarf an LVM - außer dass der automatische Debian-Installer es bei jeder Verschlüsselung unbedingt einrichten möchte.

Jipp. Ich sehe keinerlei Vorteile in mehreren Partitionen, bis dato ist auch noch nie ein Prozeß so explodiert, das er mir eine Platte bis zum bitteren Ende vollgeschrieben hätte. Und das wäre IMHO der einzige Vorteil einer Aufteilung.

Selbst wenn das passiert ... du bist der einzige Admin, der das beheben kann, und der einzige Anwender, den das behindern kann, in Personalunion. Wenn eine Partition randvoll ist, musst du dich drum kümmern, egal welche es ist. Im Serverbetrieb hingegen kannst du einzelne Dienste oder einzelne Anwender durch Partitionierung voreinander schützen.

Ok. Und sowas wie cryptsetup und der LVM-Kram ist mittlerweile standardmäßig in jeder halbwegs brauchbaren Live-Distribution enthalten? Also grml, knoppix oder was es da sonst noch gibt.

Mit Knoppix hatte ich da vor Jahren mal Ärger und griff deswegen zu grml. Inzwischen packe ich mir einfach eine zweite Debian-Installation auf die Platte ... bei 3TB kann man sich die 10 GB ruhig leisten. Ein Debian auf einem flotten USB3-Stick macht auch Freude, aber USB3 hast du nicht.

a) MBR/GPT->md->LVM->Crypt->FS
b) MBR/GPT->md->Crypt->LVM->FS

Tja, blöd ... b) ist richtig
Bei a) würdest du jedes Logical Volume im LVM einzeln verschlüsseln, hättest also wieder das Problem mit mehreren Passwörtern.

Ok, das ist logisch. Also wäre die optimale Reihenfolge die von b) - wobei sich mir da bei näherem Hinsehen die Frage stellt, wie ich ein crypt über mehrere physikalische Devices mache, wenn ich z.B. eine Platte zur Vergrößerung eines LVM-Volume hinzufügen will. Oder geht das dann wieder nicht?

"Geht nicht" gibt's nicht;)
Aber du hast das Problem richtig erkannt ... auf die neue Platte muss erst eine Crypto-Schicht, und diese muss dann dem LVM hinzugefügt werden. Danach hast du dann die oben genannten weiteren Probleme.

Beispiel: in einem Jahr gibt es billige 8TB-Platten, ich will mein 3TB-/ vergrößern, also kaufe ich zwei 8TB-Platte für ein zusätzliches RAID-1-md - und dann?

Dann erzeugst du auf dem Raid einen Cryptocontainer mit cryptsetup luksFormat.
Den trägst du dann erst mal in die /etc/crypttab ein, so dass er mit einem Keyfile geöffnet wird, das auf deinem verschlüsselten 3TB-Raid liegt.
Der Cryptocontainer erscheint dann unter /dev/mapper/maechtigvielplatz.
Dem gönnst du dann ein ext4: mkfs.ext4 /dev/mapper/maechtigvielplatz
Danach mountest du ihn:
mount /dev/mapper/maechtigvielplatz /daten/samba/meinefilme/meineverdammtgroßenfilme
(das trägst du dann natürlich in die /etc/fstab ein)
Danach verschiebst du deine verdammt großen Filme von /daten/samba/meinefilme nach /daten/samba/meinefilme/meineverdammtgroßenfilme

Upps, jetzt hab ich LVM vergessen einzubauen ... naja, geht ja auch ohne:)

Manchmal bieten Installer einem nur eine einfache oder Standardlösung als Vorschlag. Ich möchte Optimum. Beispiel aus dem WLAN-Bereich: aus Kompatibilätsgründen wird überall 802.11b/g/n voreingestellt. Ich habe aber kein b-Gerät mehr, also ist 802.11g/n zu bevorzugen. Oder es wird immer WPA+TKIP voreingestellt, WPA2+AES/CCMP ist aber sicherer.
An solche Hinweise hatte ich da gedacht.

Wenn du vom Zwangs-LVM wegkommen willst, musst du die manuelle Partitionierung bemühen, ja.

Neinneinnein, das stammt auch noch aus Vorüberlegungen. Wenn ich swap im LVM habe, kann ich das ja quasi dynamisch anpassen, oder? Bei der Plattenpartitionierung ginge das ja nicht mehr.

Mit LVM kannst du nur die Größe der Logical Volumes anpassen. Die innenliegenden Dateisysteme sind ein anderes Problem. Also hast du entweder noch ungenutzen Platz im LVM, oder du musst ein anderes Logical Volume verkleinern und das irgendwie dem Dateisystem beibringen.

Und die avisierte Größe stammt aus folgenden Gedanken:
der neue Server hat momentan 3GB RAM. Ich nutze seit ca. 13 Jahren Linux, ich glaube seit 10 Jahren habe ich kein einziges System mehr swappen sehen, selbst mein aktueller Server mit 768MB RAM hat noch nie geswappt. Aber es hieß früher mal swap=2xRAM. Der neue Server hat vier DDR2-Steckplätze. Gesetzt den Fall, er kann das und ich käme mal durch irgendwelche Umstände an 2GB-Riegel, dann könnte ich maximal 8GB RAM einbauen. 2x=swap, also swap 16GB, und auch das eigentlich leicht mehr, damit ich auch Suspend to Disk machen kann und mir nicht plötzlich 20MB fehlen. Ich gehe nicht davon aus, dass das System jemals auslagert. So entstand (unter dem Grundgedanken, dass ich die Partitionsgröße des swap nachträglich nicht mehr ändern kann) die Größe.

Das sind so Überlegungen, die nicht falsch sind, aber soviele wenns und abers enthalten, dass dir eigentlich niemand mehr was dazu sagen kann.

P.S.: Das Swap mit zufälligem Schlüssel geht natürlich auch und ist eine weitere Methode, die Swap-Partition aus dem _einen_ Cryptocontainer und somit aus dem LVM zu nehmen. Dadurch machst du aber ein "suspend-to-disk" unmöglich. Das wäre meiner Meinung nach nicht so tragisch, denn suspend-to-ram ist eh viel cooler.

Weitere Überlegungen: Was soll eine Swap-Partition auf einem Raid1? Da wäre es netter, auf der einen Raid-Platte 16 GB für Swap abzuknappsen, auf der anderen 16 GB für eine Rescue-Installation. Damit verlässt du aber endgültig den Pfad der automatischen Partitionierung des Installers.

[ChronoBoost]

Beispiel: in einem Jahr gibt es billige 8TB-Platten, ich will mein 3TB-/ vergrößern, also kaufe ich zwei 8TB-Platte für ein zusätzliches RAID-1-md - und dann?

Dann erzeugst du auf dem Raid einen Cryptocontainer mit cryptsetup luksFormat.
Den trägst du dann erst mal in die /etc/crypttab ein, so dass er mit einem Keyfile geöffnet wird, das auf deinem verschlüsselten 3TB-Raid liegt.
Der Cryptocontainer erscheint dann unter /dev/mapper/maechtigvielplatz.
Dem gönnst du dann ein ext4: mkfs.ext4 /dev/mapper/maechtigvielplatz

Oder Du fügst das neue physical volume mit vgextend zu Deiner volume group hinzu.

Den zusätzlichen Platz kannst Du dann nach Deiner Wahl entweder

• mit zusätzlichen logical volumes füllen, die Du dann mit einem Dateisystem ausstattest, oder
• für ein bestehendes logical volume nutzen in dem Du dieses mit lvextend und resize2fs erweiterst.

Oder Du schmeist Deine 3TB-Platten in den Müll/auf ebay und migrierst Dein System im laufenden Betrieb mit pvmove auf Deine zwei neuen 8TB-Platten.

[dirk11]

Shice, Du verwirrst mich einerseits, andereseits klärst Du aber mein fehlendes Wissen auf

Genau das willst du nicht haben.

Boah ey. Was will ich denn? So langsam verliere ich den Überblick vor lauter Möglichkeiten. Also, mittels LVM die / Partition im laufenden Betrieb über mehrere Festplatten erweiten, verschlüsselt haben und nur einmal Key eingeben geht nicht, verstehe ich dich da richtig? Das wäre für mich der einzige Grund für LVM, das / über eine neue Festplatte (natürlich doppelt als RAID-1) vergrößern, ohne irgendwas anderes am System ändern/anpassen zu müssen! Wenn ich das System von Anfang an gut durchdacht einrichte, muss ich an der Partitionierung nie wieder rumschrauben, an allen meinen Rechnern musste ich nie im Nachhinein etwas an der Partitionierung ändern. Es geht nur um die Frage, irgendwann mal den Speicherplatz zu erhöhen.

Inzwischen packe ich mir einfach eine zweite Debian-Installation auf die Platte ... bei 3TB kann man sich die 10 GB ruhig leisten. Ein Debian auf einem flotten USB3-Stick macht auch Freude, aber USB3 hast du nicht.

Das mit Knoppix/grml ist mir exakt genauso gegangen. Die 10GB auf Platte könnte ich mir selbstverständlich auch leisten, aber ich brauche so ein "Wartungssystem" nur bei Hängern, um das filesystem zu checken, einen anderen Grund für "Fremdboot" hatte ich noch nicht. Und ich kann mir vorstellen, dass von USB booten schnell genug ist, bisher muss ich dafür von CD booten.

Wenn du vom Zwangs-LVM wegkommen willst, musst du die manuelle Partitionierung bemühen, ja.

Ich fang damit an, sobald ich sicher bin, wie es aussieht und in welcher Reihenfloge die Schritte durchgeführt werden.

Mit LVM kannst du nur die Größe der Logical Volumes anpassen. Die innenliegenden Dateisysteme sind ein anderes Problem. Also hast du entweder noch ungenutzen Platz im LVM, oder du musst ein anderes Logical Volume verkleinern und das irgendwie dem Dateisystem beibringen.

Also ist LVM auch nicht der Weisheit letzter Schluß.

Das sind so Überlegungen, die nicht falsch sind, aber soviele wenns und abers enthalten, dass dir eigentlich niemand mehr was dazu sagen kann.

P.S.: Das Swap mit zufälligem Schlüssel geht natürlich auch und ist eine weitere Methode, die Swap-Partition aus dem _einen_ Cryptocontainer und somit aus dem LVM zu nehmen. Dadurch machst du aber ein "suspend-to-disk" unmöglich. Das wäre meiner Meinung nach nicht so tragisch, denn suspend-to-ram ist eh viel cooler.

Ich möchte die Option Suspend-to-disk eigentlich gerne haben. Mache ich das durch die Verschlüsselung des swap generell unmöglich oder durch den zufälligen Schlüssel oder durch das "im LVM"?

Weitere Überlegungen: Was soll eine Swap-Partition auf einem Raid1? Da wäre es netter, auf der einen Raid-Platte 16 GB für Swap abzuknappsen, auf der anderen 16 GB für eine Rescue-Installation.

Einspruch. Geht eine der beiden Platten kaputt, ist im einfachen Fall der Swap futsch, im ärgerlichen Fall die Rescue-Installation. Ich habe zwei Platten im System, weil ich die ausschliesslich für RAID-1 benutzen will, sonst könnte ich mir den 2. Stromfresser gleich ganz sparen.

Sag mal, wieviel Hauptspeicher ist für einen Heim-Server überhaupt sinnvoll? Ich bin ja vom Oberglücksfall 8GB ausgegangen, aber braucht man die jemals? Es sollte doch wohl dicke reichen, wenn ich davon ausgehe, dass ich mal von 3GB auf 4GB aufrüste, oder wie sieht man das hier?

Also, wieder zurück an den Anfang, doch ohne LVM. Alles jeweils gespiegelt auf beiden Platten für RAID-1:
- 1MB "Reserviert für BIOS"
- 17GB Swap (also doppelter Speicher+Sicherheit)
- /boot mit 10GB, um sie eventuell doch anstatt als boot komplett für das Betriebssystem nutzen zu können
- Rest wird /
Reihenfolge wird MBR/GPT_mit_denPartitionen-SWAP,boot,root->md->crypt->FS
oder? Kann ich auch hier mit _einem_ PW booten?

Nachtrag @NAB: auch hier empfehlen sie LVM. Merkwürdig.

[NAB]

Shice, Du verwirrst mich einerseits, andereseits klärst Du aber mein fehlendes Wissen auf

Ach, die restlichen Klarheiten kriegen wir auch noch beseitigt

Was will ich denn? So langsam verliere ich den Überblick vor lauter Möglichkeiten. Also, mittels LVM die / Partition im laufenden Betrieb über mehrere Festplatten erweiten, verschlüsselt haben und nur einmal Key eingeben geht nicht, verstehe ich dich da richtig?

"geht nicht" gibt's nicht;)
Das Problem ist, dass die einzelnen Layer ziemlich dumm sind. Der Raid-Layer weiß nichts vom draufliegenden Dateisystem (soll er auch nicht, da ist ja die Verschlüsselung dazwischen), die Verschlüsselung weiß nichts vom draufliegenden LVM und das LVM stellt letztendlich auch nur Partitionen zur Verfügung, die sich mit LVM statt mit gparted verschieben lassen, und in denen dann wieder die Dateisysteme hausen, die nichts davon wissen, was unter ihnen alles los ist.

Optimal wäre es, wenn das Dateisystem sich selbstständig über mehrere Partitionen erstrecken ließe und es sich selbstständig um redundante Speicherung kümmern würde. Genau das soll mal btrfs können. Noch besser wäre es, wenn das Dateisystem auch noch verschlüsseln könnte ... aber das scheint bei btrfs in weiter Ferne zu liegen.

Willst du also nur eine Verschlüsselungsschicht (und ein Passwort) haben, so bleibt dir bis auf weiteres nur der Ansatz, erst ein dm-raid-Device einzurichten, und darauf eine Verschlüsselungsschicht. Dadurch fällt der Raid1-Teil von LVM oder btrfs schon mal weg.

Das nächste Problem ist dann die Erweiterung auf ein zweites Raid1 (deine zwei 8TB-Platten). Dieses Raid1 braucht auch wieder ein Passwort ... das speicherst du am besten als Keyfile in deinem ersten verschlüsselten Raid1 (oder du musst es jedesmal eingeben). Dann kannst du dein LVM aber nicht auf das zweite Raid1 erweitern, denn das erste Raid1 muss erst laufen und das Dateisystem darauf ansprechbar sein, um an dein Keyfile ranzukommen. Da kannst du drumherumbasteln, wenn du LVM um des LVM willens haben willst, indem du eine verschlüsselte root-Partition mit den Keyfiles außerhalb des LVM anlegst ... eh ... du wolltest es doch einfach haben, oder?

Danach hast du erst mal das LVM vergrößert ... dann musst du noch das Dateisystem vergrößern ... hoffentlich reichen die inodes ...

Das wäre für mich der einzige Grund für LVM, das / über eine neue Festplatte (natürlich doppelt als RAID-1) vergrößern, ohne irgendwas anderes am System ändern/anpassen zu müssen! Wenn ich das System von Anfang an gut durchdacht einrichte, muss ich an der Partitionierung nie wieder rumschrauben, an allen meinen Rechnern musste ich nie im Nachhinein etwas an der Partitionierung ändern. Es geht nur um die Frage, irgendwann mal den Speicherplatz zu erhöhen.

Ich will dir LVM keineswegs ausreden, ich halte es auch nicht für schädlich. Du musst selber entscheiden, ob dir trotz der Probleme noch genug Vorteile übrig bleiben.

Und ich kann mir vorstellen, dass von USB booten schnell genug ist, bisher muss ich dafür von CD booten.

Aber klar ist USB2 schnell genug für ein Rettungssystem - achte auf einen einigermaßen schnellen Stick.

Wenn du vom Zwangs-LVM wegkommen willst, musst du die manuelle Partitionierung bemühen, ja.

Ich fang damit an, sobald ich sicher bin, wie es aussieht und in welcher Reihenfloge die Schritte durchgeführt werden.

Der einfachste Aufbau ist Raid1 -> Cryptsetup -> Dateisystem für "/". Dazu sollte jede Platte eine Boot- und Grub-Partition haben. Wo du swap lässt, ist dann erst mal egal, entweder auf einer einzelnen Platte, oder auf dem Raid1, _neben_ der Cryptpartition (und nicht innerhalb).

P.S.: Das Swap mit zufälligem Schlüssel geht natürlich auch und ist eine weitere Methode, die Swap-Partition aus dem _einen_ Cryptocontainer und somit aus dem LVM zu nehmen. Dadurch machst du aber ein "suspend-to-disk" unmöglich. Das wäre meiner Meinung nach nicht so tragisch, denn suspend-to-ram ist eh viel cooler.

Ich möchte die Option Suspend-to-disk eigentlich gerne haben. Mache ich das durch die Verschlüsselung des swap generell unmöglich oder durch den zufälligen Schlüssel oder durch das "im LVM"?

Durch den zufälligen Schlüssel machst du ein Suspend-To-Disk unmöglich ... er speichert dann seinen Zustand auf der verschlüsselten Swap-Partition, schaltet sich dann aus und vergisst dabei den Schlüssel (schön blöde .

Mit dem decrypt_derived (oder mit einem Keyfile auf deiner "/"-Partition) verschlüsselst du swap immer mit dem gleichen Schlüssel, dann geht auch "suspend-to-disk". Zum Aufwecken musst du allerdings immer das Passwort für deine "/"-Partition eingeben (oder von einem USB-Stick lesen).

Packst du die Swap-Partition in ein LVM. wird sie immer zusammen mit der "/"-Partition mit dem gemeinsamen Passwort entschlüsselt. Auch damit ist suspend-to-disk möglich. Auch damit musst du beim Booten immer dein eines Passwort eingeben.

Bei einem suspend-to-ram speichert er seinen Zustand nicht auf Platte sondern im RAM. Darum musst du beim Aufwecken kein Passwort angeben. Allerdings ist bei einem Stromausfall alles weg und er macht quasi einen Neustart und braucht ein Passwort. Suspend-to-Ram funktioniert unabhängig von einer Swap-Partition.

Einspruch. Geht eine der beiden Platten kaputt, ist im einfachen Fall der Swap futsch, im ärgerlichen Fall die Rescue-Installation. Ich habe zwei Platten im System, weil ich die ausschliesslich für RAID-1 benutzen will, sonst könnte ich mir den 2. Stromfresser gleich ganz sparen..

Gutes Argument! Einspruch stattgegeben!
Trotzdem stellt sich die Sinnfrage nach einem Swap auf Raid1 - dann lieber zwei Swap-Partitionen - wenn eine wegfällt, nimmt er halt die andere.

Sag mal, wieviel Hauptspeicher ist für einen Heim-Server überhaupt sinnvoll? Ich bin ja vom Oberglücksfall 8GB ausgegangen, aber braucht man die jemals? Es sollte doch wohl dicke reichen, wenn ich davon ausgehe, dass ich mal von 3GB auf 4GB aufrüste, oder wie sieht man das hier?

Öhm ... wieviel hatte der Raspberry Pi noch? 512 MB glaub ich. Das soll ja nur ein einfacher Fileserver werden, der muss ja keine großen Datenmengen im Speicher halten, da sollten 512 MB reichen. Allerdings stoße ich mit einem fetten Desktop-System bei 512 MB schnell an die Grenze zum swappen. Ich denke, 2 GB sind ganz okay, kost ja kaum noch was. Wenn du noch ein paar virtuelle Maschinen laufen lassen willst, sind 32 GB natürlich eher knapp, und wenn du eine Blu-Ray komplett in der Ram-Disk mastern lassen willst, sind 32 GB natürlich viel zu wenig.

Also, wieder zurück an den Anfang, doch ohne LVM. Alles jeweils gespiegelt auf beiden Platten für RAID-1:
- 1MB "Reserviert für BIOS"
- 17GB Swap (also doppelter Speicher+Sicherheit)
- /boot mit 10GB, um sie eventuell doch anstatt als boot komplett für das Betriebssystem nutzen zu können
- Rest wird /
Reihenfolge wird MBR/GPT_mit_denPartitionen-SWAP,boot,root->md->crypt->FS
oder? Kann ich auch hier mit _einem_ PW booten?

Na, dann fangen wir doch mal wirklich am Anfang an. Du hast zwei Festplatten, partitionieren kannst du aber nur eine zur Zeit.
sda:
sda1 -> 1MB für BIOS_grub
sda2 -> Boot mit 1 GB (es ist nämlich nach wie vor eine Scheiß-Idee, dir deine Bootpartition mit einer Installation zu killen
sda3 -> 15 GB (wenn's denn unbedingt sein muss, für eine Rescue-Installation)
sda4 -> 9 GB Swap
sda5 -> Raid1
(dahinter lässt du bitte noch ein paar MB frei, falls die Ersatzplatte ein wenig kleiner ist)

sdb partitionierst du nach exakt dem gleichen Schema.
Dann startest du den Debian-Installer.
sda2 verwendest du als /boot.
Aus sda5 und sdb5 machst du ein Raid1. Auf dieses Raid1 setzt du eine Crypto-Schicht. Diese Crypto-Schicht formatierst du als ext4 und verwendest sie als "/".
Außerdem setzt du eine Crypto-Schicht auf die nackten Partitionen sda4 und sdb4. Beide verwendest du als "Swap".
Reboot, schauen ob's läuft. Dabei musst du geschlagene 3 Passwörter eingeben! (Du wirst es schaffen).
Wenn das System läuft, änderst du die Crypttab erst mal dahingehend, dass die beiden Swap-Partitionen ihre Passwörter aus Keyfiles kriegen, welche du im verschlüsselten "/" ablegst (oder du nimmst das decrypt_derived Script).
Danach musst du dich noch darum kümmern, dass das Booten von beiden Platten klappt:
Im laufenden System installierst du Grub auf sdb. Ich weiß nicht genau, wie man Grub dazu bringt, auch sdb1 mit seinem Loader zu füllen ... zur Not muss der mit dd rüberkopiert werden. Außerdem muss sdb2 noch formatiert werden und der Inhalt von sda2 nach sdb2 umkopiert werden. Du solltest Tests machen, ob das System auch von jeder Platte einzeln bootet.

Soweit mal als Vorschlag ...

Nachtrag @NAB: auch hier empfehlen sie LVM. Merkwürdig.

Naja ... achte auf's Kleingedruckte .. sie empfehlen LVM, wenn du z.B. /home/ auf einer eigenen Partition hast. Oder wenn du mehrere Systeme installieren willst - was ich aber auch nicht verstehe.

Der Haken an meiner Lösung oben ist, dass du die Passwörter zu deinen Swap-Partitionen als Dateien auf der Verschlüsselten "/"-Partition liegen hast. Das macht man eigentlich nicht - vorallem nicht, wenn der Rechner als Server im Netz hängt - dann reicht eine Leseberechtigung als "root", um die Passwörter auszuspionieren (für decrypt_derived brauchst du schon eine Ausführ-Berechtigung als root) ... da gab's erst kürzlich eine nette Sicherheitslücke für die Admin-Gruppe von Cups.

Aber da es erstens nur die Swap-Partitionen sind und du zweitens keinen Hochsicherheitstrakt brauchst, halte ich diese Lösung für einfacher als LVM.

Aber die Frage, ob nun LVM oder nicht, musst du immer noch selber entscheiden ... ich wollte dir nur zeigen, wie es auch ohne geht.

[dirk11]

Du musst selber entscheiden, ob dir trotz der Probleme noch genug Vorteile übrig bleiben.

Es hätte ja überhaupt nur einen Grund für LVM gegeben. Der war ein Irrtum, also fällt LVM wieder raus.

Durch den zufälligen Schlüssel machst du ein Suspend-To-Disk unmöglich ... er speichert dann seinen Zustand auf der verschlüsselten Swap-Partition, schaltet sich dann aus und vergisst dabei den Schlüssel (schön blöde .

Allerdings...

Packst du die Swap-Partition in ein LVM. wird sie immer zusammen mit der "/"-Partition mit dem gemeinsamen Passwort entschlüsselt. Auch damit ist suspend-to-disk möglich. Auch damit musst du beim Booten immer dein eines Passwort eingeben.

Das wäre dann also noch der eine Punkt, der für LVM spräche.

Bei einem suspend-to-ram speichert er seinen Zustand nicht auf Platte sondern im RAM. Darum musst du beim Aufwecken kein Passwort angeben. Allerdings ist bei einem Stromausfall alles weg und er macht quasi einen Neustart und braucht ein Passwort. Suspend-to-Ram funktioniert unabhängig von einer Swap-Partition.

Im Prinzip ist suspend-to-ram ja optimal, aber: was passiert beim Stromausfall mit den Daten bzw. dem Dateisystem? Ist das dann schon in einem Zustand wie nach einem umount, oder kann dieser Fall die gleichen Probleme heraufbeschwören, wie ich sie beim Stromausfall mit XFS beschrieben habe? Denn mir scheint es so zu sein, dass im suspend-to-ram-Zustand und einem ausgerechnet dann stattfindenden Stromausfall die weinerlichen "Fahr Dich runter"-Rufe der USV ungehört verhallen...

Also, wieder zurück an den Anfang, doch ohne LVM. Alles jeweils gespiegelt auf beiden Platten für RAID-1:
- 1MB "Reserviert für BIOS"
- 17GB Swap (also doppelter Speicher+Sicherheit)
- /boot mit 10GB, um sie eventuell doch anstatt als boot komplett für das Betriebssystem nutzen zu können
- Rest wird /
Reihenfolge wird MBR/GPT_mit_denPartitionen-SWAP,boot,root->md->crypt->FS
oder? Kann ich auch hier mit _einem_ PW booten?

Na, dann fangen wir doch mal wirklich am Anfang an. Du hast zwei Festplatten, partitionieren kannst du aber nur eine zur Zeit.
sda:
sda1 -> 1MB für BIOS_grub
sda2 -> Boot mit 1 GB (es ist nämlich nach wie vor eine Scheiß-Idee, dir deine Bootpartition mit einer Installation zu killen
sda3 -> 15 GB (wenn's denn unbedingt sein muss, für eine Rescue-Installation)
sda4 -> 9 GB Swap
sda5 -> Raid1
(dahinter lässt du bitte noch ein paar MB frei, falls die Ersatzplatte ein wenig kleiner ist)

Frage 1: Swap wird beim Partitionieren auch wie üblich als Swap gekennzeichnet und nicht als Filesystem?
Frage 2: Auf z.B. sda5 kommt ja erst crypt, dann das FS. Beim Partitionieren aber wie üblich ein Filesystem angeben, oder?
Frage 3: Wieso bei sda5 ein paar MB freilassen, also nicht den restlichen Platz verwenden? Es sind identische Platten, mit identischer Firmware. Und wieviel ist "ein paar MB"?

sdb partitionierst du nach exakt dem gleichen Schema.

Warum eigentlich getrennt? Kann ich (so weit war ich noch nicht) im Installer nicht angeben, dass ich ein RAID-1 will, und er partitioniert mir praktischerweise beide Platten gleich?

Aus sda5 und sdb5 machst du ein Raid1. Auf dieses Raid1 setzt du eine Crypto-Schicht. Diese Crypto-Schicht formatierst du als ext4 und verwendest sie als "/".

So weit verstanden. Ob ich XFS oder ext4 nehme, weiss ich immer noch nicht. Ich habe mal in meinen hier vorhandenen Systemen df -i gemacht, selbst bei 80% mit Daten belegter Platte meint er, mit XFS habe ich nur 1% der inodes belegt. Wenn das stimmt, kann ich ja problemlos ext4 verwenden.

Außerdem setzt du eine Crypto-Schicht auf die nackten Partitionen sda4 und sdb4. Beide verwendest du als "Swap".

Die sind ja beim Partitionieren schon als Swap gemeldet worden, korrekt?

Reboot, schauen ob's läuft. Dabei musst du geschlagene 3 Passwörter eingeben! (Du wirst es schaffen).

Drei? Ach ja, /, swap1 und swap2.

Im laufenden System installierst du Grub auf sdb. Ich weiß nicht genau, wie man Grub dazu bringt, auch sdb1 mit seinem Loader zu füllen ... zur Not muss der mit dd rüberkopiert werden. Außerdem muss sdb2 noch formatiert werden und der Inhalt von sda2 nach sdb2 umkopiert werden. Du solltest Tests machen, ob das System auch von jeder Platte einzeln bootet.

Hätte jetzt gedacht, dass ich das irgendwie mit den mdadm-tools erreiche.

Der Haken an meiner Lösung oben ist, dass du die Passwörter zu deinen Swap-Partitionen als Dateien auf der Verschlüsselten "/"-Partition liegen hast. Das macht man eigentlich nicht - vorallem nicht, wenn der Rechner als Server im Netz hängt - dann reicht eine Leseberechtigung als "root", um die Passwörter auszuspionieren (für decrypt_derived brauchst du schon eine Ausführ-Berechtigung als root) ... da gab's erst kürzlich eine nette Sicherheitslücke für die Admin-Gruppe von Cups.

Aber da es erstens nur die Swap-Partitionen sind und du zweitens keinen Hochsicherheitstrakt brauchst, halte ich diese Lösung für einfacher als LVM.

Ist sie, ganz klar. Aber die "Sicherheitslücke", die Du hier aufzeigst, halte ich persönlich für vernachlässigbar/nicht soo schlimm. Wenn jemand so weit vorgedrungen ist, dass er root-Leseberechtigung hat, dürfte ich ganz andere Probleme haben. Ich glaube auch, dass das unterm Strich immer noch sicherer als ein unverschlüsseltes swap ist.

Aber die Frage, ob nun LVM oder nicht, musst du immer noch selber entscheiden ... ich wollte dir nur zeigen, wie es auch ohne geht.

Nunja, ich war ja anfangs dagegen und dann nur dafür, weil ich mir einen Vorteil erhofft hatte. Der Vorteil war ein Trugschluß, also benötige ich weiterhin kein LVM.

[dirk11]

BTW: wenn ich das alles vor-eingerichtet habe, wäre die nächste Frage, an welcher Stelle ich dem System am besten die vorhanden /etc/group und /etc/passwd vom alten System unterjuble, damit ich identische UID/GID erhalte!?

[cosmac]

hi,

wenn du die komplette Datei kopieren möchtest, geht das nur direkt nach einer Minimal-Installation. Viele Pakete brauchen eine eigene UID. Die wird bei der Installation des Pakets dynamisch vergeben, d.h. sie hängt davon ab, in welcher Reihenfolge zusätzliche Pakete installiert werden. Diese "Problem-UIDs" liegen zwischen 100 und 999 inkl. und werden z.B. für den sshd, statd oder mpd benutzt.

Die UIDs von 0 bis 99 werden von base-passwd verwaltet und sind immer gleich; um die muss man sich nicht kümmern.

Wirklich wichtig sind ja vor allem die echten User mit UIDs ab 1000. Das einfachste wäre also, aus dem alten passwd genau die Zeilen mit UIDs zwischen 1000 und 59999 ins neue System zu kopieren und ansonsten die Unterschiede in Kauf zu nehmen.

Mehr dazu:
http://www.debian.org/doc/debian-policy ... .html#s9.2
/usr/share/doc/base-passwd/users-and-groups.txt.gz
/usr/share/doc/base-passwd/README

[wanne]

sda:
sda1 -> 1MB für BIOS_grub
sda2 -> Boot mit 1 GB (es ist nämlich nach wie vor eine Scheiß-Idee, dir deine Bootpartition mit einer Installation zu killen
sda3 -> 15 GB (wenn's denn unbedingt sein muss, für eine Rescue-Installation)
sda4 -> 9 GB Swap
sda5 -> Raid1
(dahinter lässt du bitte noch ein paar MB frei, falls die Ersatzplatte ein wenig kleiner ist)

sdb partitionierst du nach exakt dem gleichen Schema.

So würde ich das auch machen. Noch ein kleiner verbesserungsvorschlag: Die beiden SWAP-Partitionen auf nen RAID-0. Läuft schneller und den Ausfall von ner swap partition kann man verkraften. Und dafür läuft das schneller.

Zu LVM:
LVM erleichtern das vergrößern/verkleinern von Partitionen (Über mehrere HDs) enorm. Wenn man sich überlegt das zu machen ist das auf jeden Fall eine Überlegung wert.
Aber es geht auch da nicht ganz von selbst wer in erster Linie auf Stabilität setzt, spielt mit sowas so oder so besser nciht rum.
Ich persönlich habe mir mal nen LVM ins Grab geschickt indem ich mir den Anfang überschrieben hab. Ich bin bis heute nicht wider an die Daten gekommen. Das ist ohne LVM wesentlich einfacher.
Die Krücke zum einsparen von Passworteingaben finde ich dagegen doof. Dafür gibt's keyfiles. Und für unsicherer ist das auch nicht wenn der schlüssel des 2. Cryptocontainers im erstel liegt, wie wenn beide im gleichen liegen. Wer Zugriff auf den ersten hat hatt in beiden fällen auch zugriff auf den 2.

Zum „Ich habe schon ewig nicht mehr geswapt“: Wer ne SSD un 4GiB RAM hat und da nie gewappt wird der hat die Swappiness zu niedrig.

[NAB]

Packst du die Swap-Partition in ein LVM. wird sie immer zusammen mit der "/"-Partition mit dem gemeinsamen Passwort entschlüsselt. Auch damit ist suspend-to-disk möglich. Auch damit musst du beim Booten immer dein eines Passwort eingeben.

Das wäre dann also noch der eine Punkt, der für LVM spräche.

Nein. Dieser Punkt alleine spricht nicht für LVM. Das selbe Verhalten kannst du auch mit Keyfiles oder decrypt_derived und ohne LVM erzielen.

Im Prinzip ist suspend-to-ram ja optimal, aber: was passiert beim Stromausfall mit den Daten bzw. dem Dateisystem? Ist das dann schon in einem Zustand wie nach einem umount, oder kann dieser Fall die gleichen Probleme heraufbeschwören, wie ich sie beim Stromausfall mit XFS beschrieben habe? Denn mir scheint es so zu sein, dass im suspend-to-ram-Zustand und einem ausgerechnet dann stattfindenden Stromausfall die weinerlichen "Fahr Dich runter"-Rufe der USV ungehört verhallen...

hmmm ... vor dem Einfrieren des Systems in das RAM wird noch ein Sync ausgeführt, das Dateisystem ist also in einem konsistenten Zustand. Wenn du allerdings noch einen Text in der Textverarbeitung hast, der bisher nicht gespeichert wurde, dann ist der bei einem Stromausfall natürlich weg.

Zu XFS kann ich nix sagen, aber da ich eine faule Socke bin, ziehe ich Rechner im Suspend-to-Ram einfach von Strom ab, wenn ich dran rumbasteln muss ... das hat mit ext3/4 und Cryptolayer noch nie irgendwelche Probleme gemacht.

Übrigens sind auch Stromausfälle mit ext4 herzlich undramatisch ... dank Journal weiß der fsck recht genau, wo was nicht stimmt und repariert das sehr schnell. Ob man danach eine zerschossene Datenbank auf seinem konsistenten Dateisystem hat, ist natürlich ne andere Frage.

Frage 1:[/b] Swap wird beim Partitionieren auch wie üblich als Swap gekennzeichnet und nicht als Filesystem?

Ohm ... also "Swap" hat eine eigene Partitionskennung namens "Linux Swap", aber damit kommst du im Debian-Installer gar nicht in Berührung, da gibst du einfach "use as: Swap" ein. Ein Filesystem muss auf keinen Fall drauf.

ABER: Du kommst (wenn du meinem Vorschlag oben folgst) gar nicht dazu, eine "echte" Partition als "Swap" zu benutzen. Du benutzt sie als "crypto" (dafür gibt es keine eigene Partitionskennung), und benutzt dann im Debian-Installer dieses "crypto" als "Swap".

Frage 2: Auf z.B. sda5 kommt ja erst crypt, dann das FS. Beim Partitionieren aber wie üblich ein Filesystem angeben, oder?

Nein, auf sda5 kommt eben nicht "erst crypt". Darum hab ich mit den beiden Festplatten angefangen ... du denkst immer in den Bahnen einer Festplatte.
Auf sda5 kommt erst mal ein "Use as: Raid", ebenso auf sdb5. Diese dann für Raid bestimmten Partitionen konfigurierst du dann als Raid1, dann kommst du zum nächsten Schritt des Installlers, wo du dieses Raid als "Use as: crypt" verwurstest. Nachdem er es als "crypt" eingerichtet hat, kommst du zum nächsten Schritt, wo du das "crypt" als ext4 mit dem Mountpoint "/" verwurstest.

Frage 3: Wieso bei sda5 ein paar MB freilassen, also nicht den restlichen Platz verwenden? Es sind identische Platten, mit identischer Firmware.

Richtig. Und wenn eine der beiden Platten ausfällt, was dann? Mit etwas Glück kriegst du noch eine identische Platte, sonst musst du eine andere 3TB-Platte nehmen ... und die variieren gerne mal um ein paar MB.

Wobei du natürlich keine 3TB-Platte nehmen musst ... du kannst auch 4TB nehmen, dann hast du keine Probleme mit sowas.

Und falls du mein Schema oben so ähnlich umsetzt, kannst du natürlich auch bei einer anderen Partition ein paar MB abknappsen ... Hauptsache, die Raid-Partition ist nicht kleiner auf der Ersatz-Platte.

sdb partitionierst du nach exakt dem gleichen Schema.

Warum eigentlich getrennt? Kann ich (so weit war ich noch nicht) im Installer nicht angeben, dass ich ein RAID-1 will, und er partitioniert mir praktischerweise beide Platten gleich?

Nö ... du willst ja nicht "Raid1". Du willst Raid1 für eine einzige Partition. Was ist mit den anderen Partitionen?

Oder anders ausgedrückt ... erst kommt die Partitionierung, dann kommt das Raid. Das Raid lebt in einer Partition, nicht umgekehrt.

Außerdem setzt du eine Crypto-Schicht auf die nackten Partitionen sda4 und sdb4. Beide verwendest du als "Swap".

Die sind ja beim Partitionieren schon als Swap gemeldet worden, korrekt?

Nein. Wenn du vom Debian-Installer ausgehst - da ist Partitionieren und "verwenden als" ein Arbeitsgang. Und da verwendest du sie erst mal als "Crypto" (jede einzeln) und danach verwendest du diesen Crypto-Container als "Swap".

Wenn du mit Parted Magic oder so partitionierst, da gibt es keinen Partitionstyp "cryptsetup" oder so. Du musst im Debian-Installer trotzdem noch ausdrücklich sagen, dass er diese vorhandenen Partitionen als "crypt" verwenden soll.

Im laufenden System installierst du Grub auf sdb. Ich weiß nicht genau, wie man Grub dazu bringt, auch sdb1 mit seinem Loader zu füllen ... zur Not muss der mit dd rüberkopiert werden. Außerdem muss sdb2 noch formatiert werden und der Inhalt von sda2 nach sdb2 umkopiert werden. Du solltest Tests machen, ob das System auch von jeder Platte einzeln bootet.

Hätte jetzt gedacht, dass ich das irgendwie mit den mdadm-tools erreiche.

Nein. sda2 und sdb2 sind die Boot-Partitionen - die haben mit mdadm überhaupt nichts zu tun. Das sind zwei einzelne Partitionen, die auf seperaten Festplatten existieren und mit einem Dateisystem bespielt werden, ganz normal, ohne Raid, ohne Crypto und ohne LVM und somit ohne mdadm.

Wobei mein Vorschlag oben natürlich verbesserungsfähig ist.

Und wo wir schon bei den Verbesserungsvorschlägen sind ... aus den beiden Swap-Partitionen ein Raid0 zu machen, ist natürlich ne coole Idee. (Danach kommt da noch ne Verschlüsselung drauf, dann erst das Swap). Allerdings ist ein Raid0 eher ein "aid", da fehlt nämlich die Redundanz. Aber egal, wenn dir eine Platte abraucht, musst du eh was tun, also kannst du derweil auch ohne Swap mit dem System arbeiten.

Eine andere gute Idee ist es, aus den beiden Boot-Partitionen ein Raid1 zu machen, und da ein ext3 draufzusetzen (ohne Verschlüsselung). Unter Squeeze musste ich das noch manuell zusammenpfrickeln, weil Grub zu blöd war, aber ich glaube, unter Wheezy müsste das per Debian-Installer funktionieren ... probiere es aus.

Du könntest auch noch überlegen, sda3 und sdb3 zu einem Raid1 zusammenzufassen, und da dein Rettungssystem draufzuspielen. Oder du installierst auf jeder der Partitionen ein eigenes Rettungsssystem ... oder du lässt die Idee ganz fallen und nimmst nen USB-Stick.

Ist sie, ganz klar. Aber die "Sicherheitslücke", die Du hier aufzeigst, halte ich persönlich für vernachlässigbar/nicht soo schlimm. Wenn jemand so weit vorgedrungen ist, dass er root-Leseberechtigung hat, dürfte ich ganz andere Probleme haben. Ich glaube auch, dass das unterm Strich immer noch sicherer als ein unverschlüsseltes swap ist.

Ich denke auch, dass diese Lösung für dich ausreicht. Aber du fragtest, warum Ubuntu LVM empfiehlt. Damit kannst du bei mehreren Partitionen vermeiden, dass Passwörter auf der Platte liegen. Und Ubuntu weiß nicht, ob der Rechner nachher ein Heim-Laptop oder ein Server in einem Firmen-LAN oder gar im Internet ist.

Übrigens ... du müsstest den Crypto-Layer auf dem Raid auch mit einem ganz normalen Partitionierungsprogramm statt mit LVM bearbeiten können. Dann hast du ebenfalls mehrere Partitionen und nur ein Passwort, aber kein LVM.

Und du könntest statt einer Swap-Partition auch eine Swap-Datei nehmen ... aber gut, ich hab dich schon genug verwirrt

BTW: wenn ich das alles vor-eingerichtet habe, wäre die nächste Frage, an welcher Stelle ich dem System am besten die vorhanden /etc/group und /etc/passwd vom alten System unterjuble, damit ich identische UID/GID erhalte!?

Mal von den Ausführungen von cosmac abgesehen ... warum solltest du das tun? Sind das so viele User und Gruppen?

Ich vermute mal, da sollen ganze /home/-Verzeichnisse kopiert werden ... die passenden UIDs/GIDs könntest du auch von Hand eintragen. Und die Passwort-Hashes findest du in /etc/shadow.

Und mal nebenbei ... der Debian-Installer ist ein verdammt tolles Tool, was die manuelle Partitionierung und derartig komplexe Sachen wie crypto-Layer, LVM und Raid-Arrays auf mehreren Platten angeht, man muss sich nur etwas reindenken und lernen damit umzugehen. Soweit ich dich verstanden habe, hast du alles zuhause um loszulegen, also mach das doch einfach. Du hast doch alles da zum Üben und Ausprobieren, und kaputtmachen kannst du auch nichts.

Nimm zum Ausprobieren sehr einfache Passwörter für den Crypt-Layer und überspringe das Überschreiben der Crypt-Container mit Zufallszahlen - das dauert nämlich ewig.

[dirk11]

wenn du die komplette Datei kopieren möchtest, geht das nur direkt nach einer Minimal-Installation.

Genau das ist meine Frage: was zählt als "Minimal-Installation". Muss ich irgendwo abbrechen, wo ich später nahtlos weitermachen kann, oder was ist damit gemeint?

Viele Pakete brauchen eine eigene UID. Die wird bei der Installation des Pakets dynamisch vergeben, d.h. sie hängt davon ab, in welcher Reihenfolge zusätzliche Pakete installiert werden. Diese "Problem-UIDs" liegen zwischen 100 und 999 inkl. und werden z.B. für den sshd, statd oder mpd benutzt.

Ich weiss, und um die geht es mir.

Wirklich wichtig sind ja vor allem die echten User mit UIDs ab 1000. Das einfachste wäre also, aus dem alten passwd genau die Zeilen mit UIDs zwischen 1000 und 59999 ins neue System zu kopieren und ansonsten die Unterschiede in Kauf zu nehmen.

Nein, es geht mir neben denen ganz klar auch um die UID/GID ab 100. Es vereinfacht das Leben doch sehr, wenn die auf allen Rechnern im eigenen Verbund gleich sind, weil z.B. nicht unerwarteterweise Files auftauchen, die auf einmal "nobody" gehören oder sowas.

Noch ein kleiner verbesserungsvorschlag: Die beiden SWAP-Partitionen auf nen RAID-0.

No. Die Platte ist als RAID-1 geplant, und zwar für jeden erdenklichen Fall. Vom Swap-Geschwindigkeitszuwachs habe ich nichts, wenn ich erstmal sowieso davon ausgehe, dass das System nicht swapt. Und ich kann mich noch daran erinnern, wie sich ein swappendes System anfühlt - als ob es sich aufgehangen hat. Da ist es egal, schneller als die Platte is sowieso nicht.

hmmm ... vor dem Einfrieren des Systems in das RAM wird noch ein Sync ausgeführt, das Dateisystem ist also in einem konsistenten Zustand. Wenn du allerdings noch einen Text in der Textverarbeitung hast, der bisher nicht gespeichert wurde, dann ist der bei einem Stromausfall natürlich weg.

Das mit dem sync ist wichtig. Das mit dem Text ist klar, ich hatte halt bei XFS Probleme mit Files mit @ und . als Inhalt nach Kernel-Oops, anderen Hängern oder Stromausfall.

Nö ... du willst ja nicht "Raid1". Du willst Raid1 für eine einzige Partition. Was ist mit den anderen Partitionen?
Oder anders ausgedrückt ... erst kommt die Partitionierung, dann kommt das Raid. Das Raid lebt in einer Partition, nicht umgekehrt.

Doch. Ich will RAID-1. Da das beim Softraid natürlich nicht pro Platte geht, also für jede mögliche Partition.

Und deshalb

Nein. sda2 und sdb2 sind die Boot-Partitionen - die haben mit mdadm überhaupt nichts zu tun.

haben die für mich natürlich auch mit mdadm zu tun.

Du könntest auch noch überlegen, sda3 und sdb3 zu einem Raid1 zusammenzufassen, und da dein Rettungssystem draufzuspielen. Oder du installierst auf jeder der Partitionen ein eigenes Rettungsssystem ... oder du lässt die Idee ganz fallen und nimmst nen USB-Stick.

Das mit dem Stick ist ja schon beschlossene Sache, ein Rettungssystem auf Platte ist nicht notwendig.
sda3 wird vermutlich dennoch für spätere Zwecke "reserviert" angelegt. Falls mal eine NTFS-Austauschpartition notwendig wird oder sowas in der Art hatte ich mir gedacht.

Ich vermute mal, da sollen ganze /home/-Verzeichnisse kopiert werden ... die passenden UIDs/GIDs könntest du auch von Hand eintragen. Und die Passwort-Hashes findest du in /etc/shadow.

Ja, wo ich die hashes finde, ist mir bekannt. Ich schreibe immer nur von /etc/group und /etc/passwd als "Platzhalter", gshadow und shadow gibts auch noch.

Soweit ich dich verstanden habe, hast du alles zuhause um loszulegen, also mach das doch einfach. Du hast doch alles da zum Üben und Ausprobieren, und kaputtmachen kannst du auch nichts.

Ich will's halt erst zu Ende durchdacht haben und dann loslegen.

Nimm zum Ausprobieren sehr einfache Passwörter für den Crypt-Layer und überspringe das Überschreiben der Crypt-Container mit Zufallszahlen - das dauert nämlich ewig.

Hätte ich sowieso übersprungen, weil die Platten ja flammneu sind und noch nichts schützenswertes drauf war.

Überhaupt - in der Konfiguration meines derzeitigen Server sind im Laufe der Jahre so viele "Spezialitäten" von mir eingebaut worden - bis der neue Server genauso läuft wie der alte, das wird sicherlich Monate dauern. Das fängt mit so simplen Sachen wie einem per bashrc personalisierten Prompt an und geht weiter über spezifische Einstellungen in hylafax oder innd, Scripten, die sich um Auto-poweroff kümmern uswusf.. Und das liegt eben leider auch nicht alles unter /etc, da wird noch so manche Nacht bei draufgehen...
Übrigens auch einer der Gründe, wieso ich /etc/group und /etc/passwd "mitnehmen" will - Vereinfachung. Kompliziert wird's an anderen Stellen schon genug.

Noch einfacher würde es wohl nur, wenn ich dem neuen Rechner sagen könnte "geh, hol' Dir UID und GID von XY", dann müsste ich die Installation nichtmal unterbrechen oder nur mit einem Minimalsystem ausführen.

BTW: auch wichtig: hat jemand eine Idee zum initrd-Problem mit dem nVidia? Ein System, welches danach nicht hochfährt, ist unbrauchbar. Was muss ich tun, damit es kein Problem mit der nVidia-Grafik gibt?

[cosmac]

was zählt als "Minimal-Installation". Muss ich irgendwo abbrechen, wo ich später nahtlos weitermachen kann, oder was ist damit gemeint?

Das Prinzip ist ja klar: du darfst erstmal kein Paket installieren, das dynamische UIDs braucht. Eine Möglichkeit: die expert-Installation macht nach jedem Schritt eine Pause und man bekommt mit ALT-F2 eine Konsole. Dort könnte man die passwd usw. bearbeiten, sobald sie unter /target/etc/ auftauchen. Das wäre besser als abbrechen und später weitermachen, dafür sehe ich keine Möglichkeit.

Außerdem bekommt man mit der expert-Installation eine Task-Auswahl mit "Desktop", "Print Server" usw. bis "Standard System". Normal wären da "ssh" und "standard system" angekreuzt. "ssh" muss man sicher abwählen, "standard" hoffentlich nicht und "desktop" braucht man ja sowieso nicht. Danach läuft die Installation normal weiter und anschließend hat man ein Minimalsystem, das man von der Konsole aus ziemlich normal benutzen kann. Sobald die passwd usw. angepasst sind, kann man ganz normal die gewünschten Pakete installieren. Wer seine Pakete sowieso gezielt auswählt und nicht pauschal einen "File Server" installiert, merkt keinen Unterschied.

Es geht noch minimaler, nämlich ohne die letzte Task "standard system", aber dann wird's umständlich. Oder ganz minimal mit debootstrap, aber ich würde es erstmal nicht so extrem versuchen.

[NAB]

Doch. Ich will RAID-1. Da das beim Softraid natürlich nicht pro Platte geht, also für jede mögliche Partition.

Öhm ... doch, auch das geht ... du kannst auch aus /dev/sdg und /dev/sdh mit mdadm ein Raid1 aufbauen. Allerdings kannst du dann nicht davon booten, da das BIOS am Anfang der Platte einen MBR mit Bootloader und keinen Raid-Header erwartet.

Das wäre übrigens auch eine denkwürdige Alternative ... die /boot/ und grub-Partitionen auf einen USB-Stick auslagern, und die beiden Festplatten als eine große verschlüsselte Raid1-Systempartition nutzen.

sda3 wird vermutlich dennoch für spätere Zwecke "reserviert" angelegt. Falls mal eine NTFS-Austauschpartition notwendig wird oder sowas in der Art hatte ich mir gedacht.

Find ich gut.

Nimm zum Ausprobieren sehr einfache Passwörter für den Crypt-Layer und überspringe das Überschreiben der Crypt-Container mit Zufallszahlen - das dauert nämlich ewig.

Hätte ich sowieso übersprungen, weil die Platten ja flammneu sind und noch nichts schützenswertes drauf war.

Nein ... der Gedanke dahinter ist, dass der gesamte Partitionsinhalt wie ein großer Haufen Zufallszahlen aussehen soll, damit ein Angreifer nicht weiß, wo sich Daten befinden und welche Bereiche leer sind. Aber da du eh keinen solchen Angreifer erwartest, hast du recht:)

Überhaupt - in der Konfiguration meines derzeitigen Server sind im Laufe der Jahre so viele "Spezialitäten" von mir eingebaut worden - bis der neue Server genauso läuft wie der alte, das wird sicherlich Monate dauern. Das fängt mit so simplen Sachen wie einem per bashrc personalisierten Prompt an und geht weiter über spezifische Einstellungen in hylafax oder innd, Scripten, die sich um Auto-poweroff kümmern uswusf.. Und das liegt eben leider auch nicht alles unter /etc, da wird noch so manche Nacht bei draufgehen...

Das wäre dann ja auch mal die Gelegenheit zu schauen, wie du deine Änderungen am System geschickt zusammenfasst. Debian hat inzwischen vielfältig statt /etc/configx ein Verzeichnis /etc/configxd/ eingeführt, wo du deine Konfigurationsschnippsel lassen kannst. Von dort könntest du nach /usr/local linken.

BTW: auch wichtig: hat jemand eine Idee zum initrd-Problem mit dem nVidia? Ein System, welches danach nicht hochfährt, ist unbrauchbar. Was muss ich tun, damit es kein Problem mit der nVidia-Grafik gibt?

Ideen hab ich ... KMS ausschalten, nouveau blacklisten, "nvidia" ausprobieren (und falls es dasselbe Problem wie bei mir ist, mal am BIOS rumspielen) ... aber ich denke, das ist einen neuen Thread wert, und genaue Fehlermeldungen von dir.

[wanne]

Noch ein kleiner verbesserungsvorschlag: Die beiden SWAP-Partitionen auf nen RAID-0.

No. Die Platte ist als RAID-1 geplant, und zwar für jeden erdenklichen Fall. Vom Swap-Geschwindigkeitszuwachs habe ich nichts, wenn ich erstmal sowieso davon ausgehe, dass das System nicht swapt. Und ich kann mich noch daran erinnern, wie sich ein swappendes System anfühlt - als ob es sich aufgehangen hat. Da ist es egal, schneller als die Platte is sowieso nicht.

Nein, nortorischen RAM mangel darfst du nicht damit vergleichen, dass man den KDM, der sowieso erst wieder beim Runtefahren braucht, (doofes beispiel für nen Server aber der ist mir halt gerade eingefallen.) mal auf die SWAP partition auslagerst um nochmal ne häufig genutzte Datei in den RAM zu ziehen, die du sonst jedes mal von der Festplatte laden musst. (DAS ist nämlich genuasolangsam und geschieht viel öfter.) Wenn dein System weniger speicher hat als die Prozesse brauche wird es lahm. Da hilft dir Auch ein RAID-0 auf ner ultraschnellen HD kaum was. Aber davor kann so ne swap das System durchaus sogar beschleunigen.
Trotzdem wird dein SWAP so gut wie nie genutzt werden. => Der geschwindigkeitsgewinn ist minimal.
Aber was für Nchteile bringt dir das RAID-0? Wenn tatsächlich eine HD ausfällt ist dein swap weg. Und? Wenn du umbedingt ganz schnell wieder eine haben willst, bevor du die HD ersetzt killst du halt das RAID und machst ne SWAP ohne RAID. Aber ich denke du kannst die Zeit (Die im Vergleich zur gesamtlaufzeit verschwindend gering ist.) auch einfach ohne leben.

[dirk11]

Das Prinzip ist ja klar: du darfst erstmal kein Paket installieren, das dynamische UIDs braucht. Eine Möglichkeit: die expert-Installation macht nach jedem Schritt eine Pause und man bekommt mit ALT-F2 eine Konsole. Dort könnte man die passwd usw. bearbeiten, sobald sie unter /target/etc/ auftauchen. Das wäre besser als abbrechen und später weitermachen, dafür sehe ich keine Möglichkeit.

Das klingt super. Wenn jetzt noch bekannt wäre, an welcher Stelle das erstmalig möglich ist (was meinst Du mit "Schritt"?), wäre das perfekt. Einfach /etc/group, gshadow, passwd und shadow vom Altsystem übernehmen und dann weitermachen. Wenn nämlich eine Gruppe oder ein User mit passendem Namen schon vorhanden ist (beispielsweise saned 144/144), dann erkennt der Installer bzw. apt* das sehr wohl und nutzt die UID/GID. Auf die fünf vorhandenen User kommt es mir nicht an, die kann ich schnell mit Angabe der UID selbst wieder anlegen (mindestens zwei fallen zukünftig sowieso weg). Aber wie gesagt, die Dienste zwischen 100 und 999 sind mir wichtig. Grund ist wie gesagt, ich mache viel in einer (grafischen) Konsole auf/von meinem Desktop, sehr oft auch mit'm mc, und wenn die IDs auf den beteiligten Rechnern identisch sind, zeigt er sie mir namentlich an. Sind sie das nicht, sehe ich nur die Nummer, was nicht nur umständlich, sondern auch anstrengend ist, weil man jedesmal abgleichen muss "was war denn nochmal 134?".

"ssh" muss man sicher abwählen, "standard" hoffentlich nicht und "desktop" braucht man ja sowieso nicht. Danach läuft die Installation normal weiter und anschließend hat man ein Minimalsystem, das man von der Konsole aus ziemlich normal benutzen kann.

Warum würdest Du ssh abwählen?

Wer seine Pakete sowieso gezielt auswählt und nicht pauschal einen "File Server" installiert, merkt keinen Unterschied.

Ich werde mir sowieso eine Paketliste vom alten Server erstellen und anhand derer vorgehen. Die werde ich zwar nicht automatisch übernehmen, aber daran kann ich dann sehen, ob ich etwas vergessen habe oder ob etwas nicht mehr notwendig wird.

Es geht noch minimaler, nämlich ohne die letzte Task "standard system", aber dann wird's umständlich. Oder ganz minimal mit debootstrap, aber ich würde es erstmal nicht so extrem versuchen.

Was ist der Nachteil an den Extrema "ohne Standard-System" oder "debootstrap"?

Öhm ... doch, auch das geht ... du kannst auch aus /dev/sdg und /dev/sdh mit mdadm ein Raid1 aufbauen. Allerdings kannst du dann nicht davon booten, da das BIOS am Anfang der Platte einen MBR mit Bootloader und keinen Raid-Header erwartet.

Ebend.

Das wäre übrigens auch eine denkwürdige Alternative ... die /boot/ und grub-Partitionen auf einen USB-Stick auslagern, und die beiden Festplatten als eine große verschlüsselte Raid1-Systempartition nutzen.

Sehr spannende Idee! Nachteile: Belegt einen USB-Steckplatz, und ich habe keine Ahnung, wie lange ein USB-Stick sowas aushält, bevor er kaputtgeht.
Anders gesagt: ich bin der Lebensdauer von USB-Sticks gegenüber skeptischer eingestellt als der Lebensdauer einer Festplatte, bei der ich grub und /boot wg. RAID-1 auf beiden Platten habe und bei Ausfall einer davon direkt weitermachen kann.

Ideen hab ich ... KMS ausschalten, nouveau blacklisten, "nvidia" ausprobieren (und falls es dasselbe Problem wie bei mir ist, mal am BIOS rumspielen) ... aber ich denke, das ist einen neuen Thread wert, und genaue Fehlermeldungen von dir.

Ok, neuer thread wird gemacht.

[NAB]

Sehr spannende Idee! Nachteile: Belegt einen USB-Steckplatz, und ich habe keine Ahnung, wie lange ein USB-Stick sowas aushält, bevor er kaputtgeht.
Anders gesagt: ich bin der Lebensdauer von USB-Sticks gegenüber skeptischer eingestellt als der Lebensdauer einer Festplatte, bei der ich grub und /boot wg. RAID-1 auf beiden Platten habe und bei Ausfall einer davon direkt weitermachen kann.

hmmm ... also ich hab zuhause /var/ auf ein Raid1 aus zwei USB-Sticks ausgelagert, damit die Festplatten ins Standby fahren. Der eine USB-Stick hat kürzlich nach 2 Jahren seinen Geist aufgegeben und musste ersetzt werden. Wohlgemerkt, nach ausgiebiger Schreibbelastung ... von Grub und /boot/ wird ja fast nur gelesen.

Aber du hast natürlich recht ... du solltest dich nicht auf _einen_ USB-Stick verlassen, bei solchen Basteleien.

Denkbar wäre auch, den USB-Stick auf eine CD-R zu brennen und von der zu booten.

Wie auch immer, das verlangt etwas Planung, denn bei jedem Kernel-Update musst du sämtliche Kopien der Boot-Partition aktualisieren - oder auf zwei USB-Sticks mit einem Raid1 für /boot/ setzen ... oder auf drei ... oder vier ... geht auch mit einem USB-HUB. Du kannst auch einen dritten USB-Stick als "Spare" definieren, der springt dann erst ein, wenn ein anderer ausfällt.

So viele Möglichkeiten ...

[dirk11]

ich hab zuhause /var/ auf ein Raid1 aus zwei USB-Sticks ausgelagert, damit die Festplatten ins Standby fahren.

Und dafür ist es ausreichend, /var auszulagern? Mein System wird auch Mailserver.

[NAB]

Und dafür ist es ausreichend, /var auszulagern? Mein System wird auch Mailserver.

Mailserver für wieviele 100 User?
Ich meine ... theoretisch ist USB2 ja nicht soooo viel langsamer als ne Netzwerkkarte, und irgendwie müssen die Mails ja auf den Rechner kommen.

Praktisch ist es nahezu unmöglich, einen USB2-Stick zu finden, der auch nur annährend an die 60MB/s herankommt. Mit USB3 sieht es da komische Weise ganz anders aus.

Ursprünglich hatte ich auch den Plan, ein Raid10 aus vier USB-Sticks aufzubauen, aber da die Kiste eh niemals Geschwindigkeitsrekorde erzielen wird, hab ich es bei einem Raid1 belassen.

Und mir ging's vorallem um die Größe ... hätte ich 4GB-SSDs für 5 Eur bekommen, hätte ich lieber die verwendet.

Bei nem Mail-Verzeichnis kommst du ja je nach Anzahl und Attachements mit 4GB nicht weit, da bist du wohl mit ner SSD mit 32GB besser, günstiger, stabiler und schneller bedient.

Aber das sind alles Sachen, die kannst du dir nachher noch nach Bedarf zusammenpfrickeln.

Für ne Neuinstallation ist erst mal die Frage interessant, ob du dir die Boot-Partitionen auf einen bis 127 1GB-USB-Sticks vom Grabbeltisch auslagerst.

[dirk11]

Ich werd's erstmal nicht machen. Stabilität ist mir wichtiger.

[cosmac]

Das Prinzip ist ja klar: du darfst erstmal kein Paket installieren, das dynamische UIDs braucht. Eine Möglichkeit: die expert-Installation macht nach jedem Schritt eine Pause und man bekommt mit ALT-F2 eine Konsole. Dort könnte man die passwd usw. bearbeiten, sobald sie unter /target/etc/ auftauchen. Das wäre besser als abbrechen und später weitermachen, dafür sehe ich keine Möglichkeit.

Das klingt super. Wenn jetzt noch bekannt wäre, an welcher Stelle das erstmalig möglich ist (was meinst Du mit "Schritt"?), wäre das perfekt.

Schritt 1: Auswahl der Sprache, Schritt 2: Tastaturlayout,..., Schritt n: Partitionierung, Schritt n+1: Installation des Basissystems -- ab jetzt müsste man auf der Konsole nachschauen, ob die Dateien schon ins Zielsystem (/target) kopiert wurden.

Auf die fünf vorhandenen User kommt es mir nicht an, die kann ich schnell mit Angabe der UID selbst wieder anlegen

naja, wenn du schon dabei bist, übernimmst du die natürlich auch. Das wäre mir wichtig, weil die alten UIDs auch auf externen Datenträgern verwendet wurden und die werden weiterhin benutzt (von mir zumindest).

wenn die IDs auf den beteiligten Rechnern identisch sind, zeigt er sie mir namentlich an. Sind sie das nicht, sehe ich nur die Nummer, was nicht nur umständlich, sondern auch anstrengend ist, weil man jedesmal abgleichen muss "was war denn nochmal 134?".

keine Frage! Noch besser: die Namen werden angezeigt, aber falsch zugeordnet "warum gehören die ganzen *.html jetzt dem exim @#$?!"

Warum würdest Du ssh abwählen?

das ist eins der Pakete, die eine dynamische UID bekommen und es wird normal automatisch installiert; das darf also nicht sein. Aber Obacht: ich habe zwei alternative Methoden gemeint: a) sich mit ALT-F2 bei der Installation dazwischen mogeln und b) alles abwählen, was dynamische UIDs braucht und ansonsten normal installieren. Für a) darf ssh angekreuzt bleiben, weil man die UIDs rechtzeitig bearbeitet hat. Mit b) bearbeitet man sie erst im fertig installierten Minimalsystem und installiert dann erst ssh.

Was ist der Nachteil an den Extrema "ohne Standard-System" oder "debootstrap"?

In den Fällen werden viele kleine Pakete nicht installiert und man müsste sie alle von Hand nachinstallieren. Das ist nicht schwierig, die Pakete sind nicht soo wichtig, aber viel Fleißarbeit. Und wenn man eins vergisst, geht später irgendeine Kleinigkeit nicht wie gewohnt; dann wird's mühsam.

Noch ein kleiner verbesserungsvorschlag: Die beiden SWAP-Partitionen auf nen RAID-0. (...) Aber was für Nchteile bringt dir das RAID-0? Wenn tatsächlich eine HD ausfällt ist dein swap weg. Und?

Und? In dem Moment werden alle Prozesse gekillt, die Seiten im Swap hatten. D.h., hoffentlich werden sie sauber mit SIGKILL gekillt, zunächst mal können sie auf einen Teil ihres Speichers nicht mehr zugreifen, darauf ist kein Programm vorbereitet.

[dirk11]

Danke, das ist sehr hilfreich, sobald ich das nVidia-Problem gelöst habe, wird installiert!

Auf die fünf vorhandenen User kommt es mir nicht an, die kann ich schnell mit Angabe der UID selbst wieder anlegen

naja, wenn du schon dabei bist, übernimmst du die natürlich auch. Das wäre mir wichtig, weil die alten UIDs auch auf externen Datenträgern verwendet wurden und die werden weiterhin benutzt (von mir zumindest).

Ja klar, ich wollte damit auch nur zum Ausdruck bringen, dass ich die ja ganz zuletzt mit Angabe der Id anlegen kann. Bei anfangs nur drei anzulegenden Usern ist das übersichtlich - jedenfalls im Vergleich zur group, in welcher schätzungsweise 30-40 Dienste oberhalb von 100 liegen.

keine Frage! Noch besser: die Namen werden angezeigt, aber falsch zugeordnet "warum gehören die ganzen *.html jetzt dem exim @#$?!"

Ja genau, sowas ist in meinen Augen einfach eine große Fehlerquelle, wenn man sich nicht 100%ig konzentriert, und selbst dann ist das als Fehlerquelle vermeidbar.

Obacht: ich habe zwei alternative Methoden gemeint:

Danke für die zusätzliche Erläuterung, ich werde wohl a) nehmen.
Wird sicherlich auch anderen helfen, die dasselbe Problem haben!

[dirk11]

Frage 1:[/b] Swap wird beim Partitionieren auch wie üblich als Swap gekennzeichnet und nicht als Filesystem?

Ohm ... also "Swap" hat eine eigene Partitionskennung namens "Linux Swap", aber damit kommst du im Debian-Installer gar nicht in Berührung, da gibst du einfach "use as: Swap" ein. Ein Filesystem muss auf keinen Fall drauf.

ABER: Du kommst (wenn du meinem Vorschlag oben folgst) gar nicht dazu, eine "echte" Partition als "Swap" zu benutzen. Du benutzt sie als "crypto" (dafür gibt es keine eigene Partitionskennung), und benutzt dann im Debian-Installer dieses "crypto" als "Swap".

Frage 2: Auf z.B. sda5 kommt ja erst crypt, dann das FS. Beim Partitionieren aber wie üblich ein Filesystem angeben, oder?

Nein, auf sda5 kommt eben nicht "erst crypt". Darum hab ich mit den beiden Festplatten angefangen ... du denkst immer in den Bahnen einer Festplatte.
Auf sda5 kommt erst mal ein "Use as: Raid", ebenso auf sdb5. Diese dann für Raid bestimmten Partitionen konfigurierst du dann als Raid1, dann kommst du zum nächsten Schritt des Installlers, wo du dieses Raid als "Use as: crypt" verwurstest. Nachdem er es als "crypt" eingerichtet hat, kommst du zum nächsten Schritt, wo du das "crypt" als ext4 mit dem Mountpoint "/" verwurstest.

Ich stelle gerade fest, dass der ganze Installer (CUI, Experte) bei so einer individuellen Einrichtung totale Grütze ist. Mir ist immer noch nicht klar, wie und in welcher Reihenfolge ich vorgehe und was für eine Kennzeichnung unterm Strich jede der Partitionen erhalten muss bzw. wie sie angelegt werden muss. Ich habe mich jetzt zu folgender Partitionierung entschieden:

/sda1: 1MB reserviert für BIOS / Grub
/sda2: 20GB ein md-device, reserviert für spätere Zwecke
/sda3: 17GB ein md-device, verschlüsselter Swapspace für das System bzw. suspend_to_disk
/sda4: 1GB ein md-device, UNVERSCHLÜSSELT /boot
/sda5: kompletter Rest, ein md-device, verschlüsselt /

So. Und nun? Partitioniere ich zuerst sda in die o.g. Einzelteile und lasse sdb generell links liegen? Oder partitioniere ich sofort sda und sdb identisch?
Lege ich erst ein Softraid über beide Platten an und partitioniere danach (das scheint nämlich auch zu gehen, allerdings sähe ich da den Fehler, dass /boot innerhalb des md-device wäre, oder ist das kein Fehler?)? Gibt es Partitionen, die sich nicht "raid-en" lassen, die ich also getrennt anlegen muss (ich denke da an sda1)?
Und danach nehme ich das alles dann als crypto-Basis? Was ist mit sda3/swap? Auch als verschlüsseltes Filesystem, welches dann als swap benutzt wird? Ich werde nämlich beim Anlegen von sda3/swap nach einem Einhängepunkt gefragt, ohne den wird nicht zuende gemacht. Das ist mir eben noch nicht klar: wird swap auf einem "normalen" Device mit filesystem (z.B. auch XFS) angelegt? Oder kriegt die Partition doch die Kennung "LinuxSwap"?
Sorry, aber für mich ist der Installer da einfach nicht logisch aufgebaut.

So langsam blicke ich es. Zuerst partitioniere ich beide Festplatten identisch, gebe dabei schon Filesystem, Mountpoint/swap an:
/sda1: 1MB reserviert für BIOS / Grub
/sda2: 20GB reserviert für spätere Zwecke
/sda3: 17GB als swap
/sda4: 1GB /boot
/sda5: kompletter Rest /

Dann erstelle ich von allen gewünschten davon ein md-device, muss den Vorgang "Software-RAID konfigurieren" also genau so oft durchführen, wie ich md-devices erstellen will, und dabei jeweils eines von sda und den passenden Spiegel von sdb auswählen.
Welche der o.g. Partitionen muss ich dabei auslassen? Unsicher bin ich mir bei sda1 und 3. sda 4 und 5 werden sicherlich je ein md-device.

Und danach schnappe ich mir dann das md-device, welches sda3 und sdb3 enthält und das, welches sda5 und sdb5 enthält, und verschlüssele diese?

Wäre das so korrekt? Ich frage deshalb, weil das "damals" vor 10 Jahren vollkommen anders funktioniert hat. Ich habe mir mal mit cfdisk die Partitionierung meines derzeitigen Servers angeschaut, dort ist die Swap-Partition als Swap gekennzeichnet, die beiden Daten-Partitionen als Linux raid autodetect.

Mich irritiert total, dass ich erst die Partitionen mit Angabe des Filesystem uswusf. anlege. Oder ist das falsch, und ich muss bei den Partitionen "Benutzen als "Physikalisches Volume für RAID" ankreuzen?

War auch falsch.
Ich partitioniere sda und sdb identisch, wie oben schon mehrfach geschrieben.
sda1 (also den reservierten Teil) kann ich nicht als md-device zusammenfassen. Den Rest scheinbar schon. Dann erstelle ich noch in sda3 und sda5 ein crypt-device, und in diesem erstelle ich dann einerseits swap und andererseits / mit xfs.
Ganz schön kompliziert, man muss quasi hierarchisch vorgehen.
Das einzige, was mich letztlich noch irritiert ist die Frage, warum keine Partition das Boot-flag hat und das auch nicht mehr angemeckert wurde...

[NAB]

/sda1: 1MB reserviert für BIOS / Grub
/sda2: 20GB ein md-device, reserviert für spätere Zwecke
/sda3: 17GB ein md-device, verschlüsselter Swapspace für das System bzw. suspend_to_disk
/sda4: 1GB ein md-device, UNVERSCHLÜSSELT /boot
/sda5: kompletter Rest, ein md-device, verschlüsselt /

So. Und nun? Partitioniere ich zuerst sda in die o.g. Einzelteile und lasse sdb generell links liegen? Oder partitioniere ich sofort sda und sdb identisch?

hmmm ... stimmt ... der Installer hat da so seine Macken ...
Ob du nun erst sda oder erst sdb oder beide abwechselnd partitionierst, ist ziemlich wurst, aber bei der Verwendung als Raid/Crypt u.s.w. kommt es dann auf die Reihenfolge an.
Also nehmen wir mal an, die Partitonen existieren - die hast du zum Beispiel vorher mit Gparted angelegt (geht natürlich auch mit dem Debian-Installer, aber der verwirrt dich dabei vielleicht mit zuvielen Informationen).
Danach markierst du sda2, sdb2, sda3, sdb3, sda4, sdb4 sda5 und sdb5 für "use as raid". Dann sagst du dem Installer, dass du jetzt fertig bist mit Partitionieren und gerne weitermachen möchtest damit, deine Raids einzurichten. Du kommst dann in die nächste Phase des Installers, wo du deine Raids zusammenpuzzeln musst. Hier sagst du, du hättest gerne ein Raid1 und das soll aus sda2 und sdb2 bestehen ... u.s.w. Hier trägst du auch ein, dass dein md2 mit ext3 formatiert und als "/boot/ eingehängt werden soll. Für md0 trägst du ein "do not use". Für md1 und md3 trägst du ein "use as crypto".
Dann sagst du ihm, dass du jetzt mal wieder mit dem Partitionieren fertig bist und nun gerne deine Crypto-Devices einrichten willst.
Dann kommst du zur nächsten Stufe dess Installers, in der du deine Crypto-Geräte einrichtest. Hier kannst du ihm auch sagen, dass du md1_crypt als "Swap" nutzen willst, und md3_crypt als "/".
Ja ... das war es auch schon.

Lege ich erst ein Softraid über beide Platten an und partitioniere danach (das scheint nämlich auch zu gehen, allerdings sähe ich da den Fehler, dass /boot innerhalb des md-device wäre, oder ist das kein Fehler?)?

Ja, du kannst auch die Innereien eines Raid partitionieren ... das kannst du zum Beispiel machen, wenn du /home/ auf einer eigenen Partition haben willst.
Du solltest allerdings Swap nicht im selben Raid1 haben wie den Rest des Systems ... bei einem Absturz kommt das Swap-Raid öfter mal aus dem Tritt und muss dan Resynchronisiert werden ... und wenn er dir dann deine gesamten 3 TB synchronisieren will, ist das überflüssiger Aufwand. Also bleib lieber bei dem Plan mit den mehreren Partitionen.
Ob Grub so ein /boot/ auf so einer Partition innerhalb eines Raids erkennt, weiß ich nicht ... probiere es aus.

Gibt es Partitionen, die sich nicht "raid-en" lassen, die ich also getrennt anlegen muss (ich denke da an sda1)?

Eigentlich müsste sich Grub auch ohne diese Partition installieren lassen, solange du einen MBR nimmst (und keine GPT).
Ob Grub seine BIOS-Partiton auch innerhalb eines Raids findet, weiß ich nicht. Probiere es aus.
Technisch spricht nichts dagegen - der Grub-Bootloader springt einfach an die Blockadresse, an der diese Partition anfängt und liest sie dann linear. Ob diese Blockadresse nun hinter einem Raid-Header liegt oder nicht, sollte ihm egal sein.

Ebenso spannend ist es übrigens,. ob Grub seine grub.cfg, Kernel und Initramfs in so einem partitionierten Raid findet. Probiere es aus.

Ich werde nämlich beim Anlegen von sda3/swap nach einem Einhängepunkt gefragt, ohne den wird nicht zuende gemacht.

Schau mal genau hin ... sobald du "use as swap" auswählst, sollte kein Einhängepunkt mehr angeboten werden. Ebenso kannst du "do not use" auswählen.

Das ist mir eben noch nicht klar: wird swap auf einem "normalen" Device mit filesystem (z.B. auch XFS) angelegt? Oder kriegt die Partition doch die Kennung "LinuxSwap"?

Swap hat die Kennung "Linux Swap" und keinen Einhängepunkt und auch kein Dateisystem. Im Debian-Installer vergibst du allerdings keine Partitionskennungen, sondern suchst dir bei "use as" was aus. Und in diesem Fall hier wählst du für die nackte Swap-Partition auf der Platte eh nicht "use as Swap" aus, sondern "use as Raid".

Sorry, aber für mich ist der Installer da einfach nicht logisch aufgebaut.

Stimmt ... das Ding ist gewöhnungsbedürftig, aber wenn man es mal verstanden hat, ausgesprochen mächtig. Darum sagte ich ja - spiel damit rum!

Edsit: sorry, ich hab deine Änderungen nicht mitbekommen. Aber du scheinst ja Fortschitte zu machen

Das boot-Flag brauchst du, wenn im MBR kein Bootloader steht (sondern nur in der Boot-Partition) oder wenn das BIOS zickig ist und unbedingt eins haben will.

[dirk11]

Hmm. Ich bin mir nicht so ganz sicher, aber es scheint dann doch alles so funktioniert zu haben, wie ich mir das vorgestellt habe. War auch ne schwere Geburt:

sda1 und sdb1 ist 1MB für bios_grub
sda2 und sdb2 sind 20GB md1 "reserved" unbenutzt
sda3 und sdb3 sind 17GB md2 crypted swap
sda4 und sdb4 sind 1GB md3 /boot
sda5 und sdb5 sind 2,9TB md4 crypted /

Glaube ich jedenfalls anhand der Ausgabe von parted print all:
(parted) print all
Model: ATA Hitachi HDS5C303 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios-grub bios_grub
2 2097kB 20,0GB 20,0GB xfs reserved raid
3 20,0GB 37,0GB 17,0GB linux-swap(v1) swap raid
4 37,0GB 38,0GB 1000MB xfs boot raid
5 38,0GB 3001GB 2963GB xfs debian64 raid


Model: ATA Hitachi HDS5C303 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios-grub bios_grub
2 2097kB 20,0GB 20,0GB xfs reserved raid
3 20,0GB 37,0GB 17,0GB linux-swap(v1) swap raid
4 37,0GB 38,0GB 1000MB xfs boot raid
5 38,0GB 3001GB 2963GB xfs debian64 raid


Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/md4_crypt: 2962GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
1 0,00B 2962GB 2962GB xfs


Error: /dev/md1: unrecognised disk label

Error: /dev/md2: unrecognised disk label

Model: Linux Software RAID Array (md)
Disk /dev/md3: 1000MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
1 0,00B 1000MB 1000MB xfs


Error: /dev/md4: unrecognised disk label

Nur woher stammt "unrecognised disk label", und wie kann ich später md1 (also sda2/sdb2) aktivieren? Die habe ich "nur" als md eingerichtet und dann als "unused" belassen.