Grundsatzüberlegungen vor Neuinstallation

[dirk11]

Hi Leute,

ich überlege seit geraumer Zeit, einen neuen Server aufzusetzen. Notwendig wird dies, weil ich a) von 32Bit auf 64Bit wechseln will und weil ich damit b) alte Config-Leichen loswerden will, welche sich innerhalb von 10 Jahren doch mal so anhäufen.
Gegeben ist dafür ein Athlon64, hinzu kommen zwei 3TB-Festplatten, welche als SoftRAID-1 laufen sollen.
Die Installation will meiner Meinung nach wohlüberlegt sein, damit alles glatt geht und ich eventuelle Problempunkte schon vorher abgeklärt habe. Kommen wir also zu den Punkten:

1. Ist eine SWAP-Partition noch notwendig?
2. Benötigt man wirklich LVM? Macht es ein System nicht unnötig kompliziert?
3. Welches Filesystem ist momentan am empfehlenswertesten? Zur Auswahl würde ich XFS, ext4 oder BTRFS stellen. XFS nutze ich momentan, bin damit aber nicht zu 100% zufrieden. Ich will auch nur ein FS nutzen, nicht mehrere gleichzeitig.
4. Dinge, die sich eigentlich ausschliessen: der Server soll vollverschlüsselt werden, gleichzeitig aber ferngestartet werden können. Die Überlegungen dazu sind noch nicht ganz ausgereift, entweder bedeutet das einen lokal z.B. auf einem USB-Stick oder Netzspeicher hinterlegten Schlüssel (nein, es geht nicht um NSA-Zugriffe), oder der Server müsste beim Start auch eine DynDNS-Anmeldung machen und die Eingabe eines Passwortes sowohl lokal als auch per ssh zulassen.

5. Partitioniert werden soll so wenig wie möglich, ich halte nicht viel von Fragmentierung durch viele Partitionen. Meine jetzigen Systeme laufen problemlos mit einer Partition, auf welcher / und alles darunterliegende drauf ist. Mit Vollverschlüsselung müßte ich wohl zumindest noch eine unverschlüsselte Partition haben, richtig?

6. Zu guter letzt:
Wie würde die Reihenfolge aussehen, und was hat es für Auswirkungen, wenn man die ändert? Erst md, dann LVM, dann Filesystem und dann Verschlüsselung? Oder erst LVM, dann md, dann Filesystem und dann Verschlüsselung? Oder doch ganz anders?

Grüße,

Dirk

[peschmae]

1. Das solltest du eigentlich besser wissen als wir, kommt auf die Belastung und die Art der Belastung an. Für Server würde ich jetzt mal sagen: nein.

2. Wenn du eh nur eine Partition willst und das Raid mit md machst sehe ich nicht was LVM da noch soll.

3. Inwiefern bist du mit XFS nicht zufrieden? Ansonsten benutze ich immer mehr btrfs, wegen der Checksummen, Kompression, Deduplikation und Subvolumes (die ich statt Partitionen für / und /home benutze).

4. Unlocken per ssh geht recht Problemlos, bei Debian ist da schon fast alles vorgespurt - guck mal in die /usr/share/doc/cryptsetup/README.remote.gz. Dyndns müsste man noch von Hand einbauen.

5. Ja, du brauchst ein unverschlüsseltes /boot, den Rest kannst du dann für / hernehmen. Ich selber habe meistens noch ganz gerne ein separates /home (mittlerweile auch auf einem btrfs subvolume), damit ich falls nötig das System neu aufsetzen kann ohne die Daten anzurühren.

6. Erst md (oder LVM, wer auch immer dir das Raid macht), dann Verschlüsselung, dann Filesystem würde ich sagen, wenn du nur eine verschlüsselte Partition willst (oder btrfs mit Subvolumes). Ansonsten auf der Verschlüsselung noch LVM.

Man könnte natürlich auch erst Verschlüsselung, darauf md und darauf das Dateisystem machen. Aber dann musst du wohl beide Festplatten getrennt entschlüsseln - zweimal Passwort eingeben und so. Langsamer wird das auch, weil für die beiden Platten die gleichen Daten jeweils verschieden verschlüsselt werden.

MfG Peschmä

[syssi]

1. Ist eine SWAP-Partition noch notwendig?

Noe aber manchmal ist es schoener, wenn das System im Ausnahmefall etwas langsamer zuckelt, als wenn der Out-of-Memory-Killer vorbei schaut und Dienste killt, weil gerade zu wenig Arbeitsspeicher verfuegbar war. Ich wuerde weiterhin auf Swap setzen und die Swappiness entsprechend herab setzen.

2. Benötigt man wirklich LVM? Macht es ein System nicht unnötig kompliziert?

Geschmachssache. Wenn sich deine Partitionierung nie aendert, dann gibts fuer LVM keinen Grund. Setze es ein, wenns fuer dich einen praktischen Nutzen haben koennte.

3. Welches Filesystem ist momentan am empfehlenswertesten? Zur Auswahl würde ich XFS, ext4 oder BTRFS stellen. XFS nutze ich momentan, bin damit aber nicht zu 100% zufrieden. Ich will auch nur ein FS nutzen, nicht mehrere gleichzeitig.

BTRFS ist nicht ausreichend stabil. Ext ist man gewoehnt.. also wieso nicht dabei bleiben?

4. Dinge, die sich eigentlich ausschliessen: der Server soll vollverschlüsselt werden, gleichzeitig aber ferngestartet werden können. Die Überlegungen dazu sind noch nicht ganz ausgereift, entweder bedeutet das einen lokal z.B. auf einem USB-Stick oder Netzspeicher hinterlegten Schlüssel (nein, es geht nicht um NSA-Zugriffe), oder der Server müsste beim Start auch eine DynDNS-Anmeldung machen und die Eingabe eines Passwortes sowohl lokal als auch per ssh zulassen.

Alles moeglich. Du musst halt alles in die Initrd stopfen, was das System so zum oeffnen der Laufwerke benoetigen koennte. Natuerlich sind die Maßnahmen irgendwie sinnbefreit, wenn man den Schluessel direkt dazu legt.

5. Partitioniert werden soll so wenig wie möglich, ich halte nicht viel von Fragmentierung durch viele Partitionen. Meine jetzigen Systeme laufen problemlos mit einer Partition, auf welcher / und alles darunterliegende drauf ist. Mit Vollverschlüsselung müßte ich wohl zumindest noch eine unverschlüsselte Partition haben, richtig?

Richtig. (/boot)

6. Zu guter letzt:
Wie würde die Reihenfolge aussehen, und was hat es für Auswirkungen, wenn man die ändert? Erst md, dann LVM, dann Filesystem und dann Verschlüsselung? Oder erst LVM, dann md, dann Filesystem und dann Verschlüsselung? Oder doch ganz anders?

Erst das Raid, dann das LVM, dann die Encryption. Nutz doch einfach den Debian-Installer. Der schafft das alles OOTB. Anschliessend wartet das System mit einem Passwort-Prompt. Diesen Part ersetzt du dann durch deine Wuensche.

[Cae]

1. Ist eine SWAP-Partition noch notwendig?

Kommt auf's RAM an. Typischerweise hat man so viel ungenutzten RAM, dass die Kiste gar nicht swappt, andererseits tuen ein paar GB belegter Festplattenspeicher nicht weh. Bei Verschluesselung solltest du beachten, dass eventueller Swap-Speicher unbedingt verschluesselt ist, da man sonst nach einem harten Ausschalten moeglicherweise kritische Teile vom RAM einfach von der Platte lesen kann.

2. Benötigt man wirklich LVM? Macht es ein System nicht unnötig kompliziert?

LVM kann Snapshots, was fuer sich schon ein nettes Feature ist, und man kann damit einzelne "Partitionen" innerhalb eines Crypto-Containers bilden. Ich persoenlich mag es, aber man kann problemlos fuer jeden Mountpunkt eine eigenes Crypto-Device auf eine Partiton legen oder alle Daten in / packen.

3. Welches Filesystem ist momentan am empfehlenswertesten? Zur Auswahl würde ich XFS, ext4 oder BTRFS stellen. XFS nutze ich momentan, bin damit aber nicht zu 100% zufrieden. Ich will auch nur ein FS nutzen, nicht mehrere gleichzeitig.

ext4. Wobei ich nicht furchtbar viel rumexperimentiert habe, moeglicherweise hat das dir vielleicht besser bekannte XFS andere Killerfeatures.

4. Dinge, die sich eigentlich ausschliessen: der Server soll vollverschlüsselt werden, gleichzeitig aber ferngestartet werden können. Die Überlegungen dazu sind noch nicht ganz ausgereift, entweder bedeutet das einen lokal z.B. auf einem USB-Stick oder Netzspeicher hinterlegten Schlüssel (nein, es geht nicht um NSA-Zugriffe), oder der Server müsste beim Start auch eine DynDNS-Anmeldung machen und die Eingabe eines Passwortes sowohl lokal als auch per ssh zulassen.

Der einzitge Vorteil ist dann noch, dass man 'ne Platte einfach aus dem RAID ziehen und ohne Shreddern aus dem Haus geben kann. /boot muss unverschluesselt sein, also kann jeder mit physikalischem Zugriff deinen SSHd manipulieren oder auf welchem Weg auch immer du den Key auch uebertraegst.

5. Partitioniert werden soll so wenig wie möglich, ich halte nicht viel von Fragmentierung durch viele Partitionen. Meine jetzigen Systeme laufen problemlos mit einer Partition, auf welcher / und alles darunterliegende drauf ist. Mit Vollverschlüsselung müßte ich wohl zumindest noch eine unverschlüsselte Partition haben, richtig?

Genau. Oder du packst /boot mit allen Keys/SSHd auf einen USB-Stick (oder auf zwei im RAID1 ) und hast auf den Platten nur das RAID bzw. eine Partition mit dem RAID drin.

6. Zu guter letzt:
Wie würde die Reihenfolge aussehen, und was hat es für Auswirkungen, wenn man die ändert? Erst md, dann LVM, dann Filesystem und dann Verschlüsselung? Oder erst LVM, dann md, dann Filesystem und dann Verschlüsselung? Oder doch ganz anders?

Normalerweise (MBR|GPT->)MD->LUKS->(LVM->)fs. Es kann aber auch Sinn ergeben, wenn man (MBR|GPT->)LUKS->MD->(LVM->)fs macht, weil LUKS leider nur single-threaded ist. Auf dem Weg hat man moeglicherweise mehr Durchsatz. MD funktioniert eigentlich auch mit ganz normalen Dateien, aber so ein Setup mit LUKS unter MD ist (gefuehlt) anfaelliger.[Edit: Unnoetig, der Wheezy-Kernel kann LUKS/dm-crypt multi-threaded fahren, siehe unten.]

Gruss Cae

[wanne]

weil LUKS leider nur single-threaded ist.

Seit Kernel 2.6.38 und damit seit wheezy falsch.

[wanne]

1. Ist eine SWAP-Partition noch notwendig?

Ja. Wenn dir der RAM ausgeht (und das kann schnell mal passieren, wenn ein Programm ein leak hat.) läuft der Rechner Ammok. Sobalt der SWAP angetastet wird, werden zuerst mal buffer entfernt. (Stimmt das noch?)
Und mal ganz ehrlich wenn man die gleiche Menge an SWAP wie RAM hat ist praktsich kein preislicher unterschied. Aber das system hällt viel länger durch auch weil sich der SWAP nicht so schnell füllt.

BTRFS ist nicht ausreichend stabil.

Ich habe BTRFS mittlerweile seit Jahren und hatte nie Probleme. (Außer in der performance.) Nutze aber auch die ganzen features nicht.
Gibt's hier irgend jemand der mit BTRFS und nem 3.X kernel schonmal auf die nase geflogen ist?

Dinge, die sich eigentlich ausschliessen: der Server soll vollverschlüsselt werden

Das ist schwachsinn, solange der nciht bei dir zuhause steht. Allerdings gibt's ein paar projekte die Mitlerweile Speicher anbieten, der erst auf dem Client entschlüsselt wird. Finde keine Links mehr aber habe das was gelsen. Das ist für dich eher interessant.

[syssi]

BTRFS ist nicht ausreichend stabil.

Ich habe BTRFS mittlerweile seit Jahren und hatte nie Probleme. (Außer in der performance.) Nutze aber auch die ganzen features nicht.
Gibt's hier irgend jemand der mit BTRFS und nem 3.X kernel schonmal auf die nase geflogen ist?

Ich habe BTRFS vor einem Jahr auf Embedded Linux Geraeten mit USB-Stick / CF-Karte versucht zu nutzen. Dabei hat mir das Dateisystem harte Abstuerze (power loss) sehr sehr uebel genommen. Ext4 hat bei mir einen robusteren Eindruck hinterlassen.

[Cae]

weil LUKS leider nur single-threaded ist.

Seit Kernel 2.6.38 und damit seit wheezy falsch.

Hups. Dann ist aber /usr/share/doc/cryptsetup/README.keyctl aus Wheezy verkehrt, da heisst es naemlich

The current state for dm-crypt in Linux is that it is single threaded, [...]

Was ist die Quelle deiner Aussage? Ich kann's zwar experimentell nachvollziehen, wenn ich ein Image im tmpfs mit cryptsetup luksOpen und cryptsetup luksOpen behandele und das entstehend Device mit /dev/zero befuelle, gehen in htop auf allen Kernen die Kernel-Balken auf Vollanschlag. Also ist's threaded.

Gruss Cae

[peschmae]

1. Ist eine SWAP-Partition noch notwendig?

Ja. Wenn dir der RAM ausgeht (und das kann schnell mal passieren, wenn ein Programm ein leak hat.) läuft der Rechner Ammok. Sobalt der SWAP angetastet wird, werden zuerst mal buffer entfernt. (Stimmt das noch?)
Und mal ganz ehrlich wenn man die gleiche Menge an SWAP wie RAM hat ist praktsich kein preislicher unterschied. Aber das system hällt viel länger durch auch weil sich der SWAP nicht so schnell füllt.

Buffer wegmachen tut er ja immer zuerst, wenn der Ram langsam volläuft. Im Zweifel verlängert Swap nur das Leiden - ich habs schon auf ein paar Systemen gesehen dass da der Unterschied war, dass der Amokgelaufene Prozess dann halt den Rechner solange hat trashen lassen bis auch der Swap komplett voll war, was im Zweifelsfalle durchaus ein paar Stunden dauern kann in denen der Rechner nicht ansprechbar ist...

Könnte man jetzt natürlich entsprechende Limits setzen oder so, wenn man denn admin wäre auf dem konkreten System

Was ist die Quelle deiner Aussage? Ich kann's zwar experimentell nachvollziehen, wenn ich ein Image im tmpfs mit cryptsetup luksOpen und cryptsetup luksOpen behandele und das entstehend Device mit /dev/zero befuelle, gehen in htop auf allen Kernen die Kernel-Balken auf Vollanschlag. Also ist's threaded.

Das steht z.B. hier mit Verweis auf den commit.

MfG Peschmä

[wanne]

Buffer wegmachen tut er ja immer zuerst, wenn der Ram langsam volläuft. Im Zweifel verlängert Swap nur das Leiden - ich habs schon auf ein paar Systemen gesehen dass da der Unterschied war, dass der Amokgelaufene Prozess dann halt den Rechner solange hat trashen lassen bis auch der Swap komplett voll war, was im Zweifelsfalle durchaus ein paar Stunden dauern kann in denen der Rechner nicht ansprechbar ist...

Dir fehld die gedult... Man kann swapende Systeme schon noch bedienen. Auch mit schnarch lahmen Festplatten. Nur halt tippen 30sekunden warten.. tippen... (ein ps + grep und dann der nötige kill ist gut auch in nem ordentlich swappenden System über ssh machbar. Man braucht nur 2-3 Minuten.)
Wie gesagt, ich habe mal gehört das der nur langsam zurück fährt und keine neuen mehr anlegt. Und das es durchaus sein könnte, dass da mal ein NULL-Pointer zurück kommt obwohl sich einiges im RAM noch entfernen ließe.

Könnte man jetzt natürlich entsprechende Limits setzen oder so, wenn man denn admin wäre auf dem konkreten System

Naja ohne swap sind die limits schwer zu setzen. Gerade mit limits lohnt sich der SWAP. Weil man dann getrost gucken kann ob das sich noch beruhigt und dann abschießen kann wenn nicht. Wegen 8GiB RAM-Verbrauch will ich nichts abschießen Da gib't durchaus sachen die das machen. (wget leakt z.B. ordentlich aber ich nutze es halt trotzdem gerne.) Aber ein paar von den 8GiB Prozessen und dein RAM ist voll.

[syssi]

Buffer wegmachen tut er ja immer zuerst, wenn der Ram langsam volläuft. Im Zweifel verlängert Swap nur das Leiden - ich habs schon auf ein paar Systemen gesehen dass da der Unterschied war, dass der Amokgelaufene Prozess dann halt den Rechner solange hat trashen lassen bis auch der Swap komplett voll war, was im Zweifelsfalle durchaus ein paar Stunden dauern kann in denen der Rechner nicht ansprechbar ist...

Dir fehld die gedult... Man kann swapende Systeme schon noch bedienen. Auch mit schnarch lahmen Festplatten. Nur halt tippen 30sekunden warten.. tippen... (ein ps + grep und dann der nötige kill ist gut auch in nem ordentlich swappenden System über ssh machbar. Man braucht nur 2-3 Minuten.)

Ich wollte es ja schon initial schreiben aber ist es moeglich, dass das Feature "Swap" mit den Jahren gelitten hat? Ich kann mich an Systeme erinnern (Kernel 2.2, Kernel 2.4), die immer noch wie ein Uhrwerk liefen, auch wenn das System nichts anderes Tat als den halben Tag zu swappen. Kann aber auch eine subjektive Wahrnehmung sein.

Gruss syssi

[wanne]

Glaube das das vor allem dran liegt, das man hute halt mehr oder weniger aktiv in den SWAP reinsteuert. Früher wurde halt oft geswapt weil ein paar prozesse zu viel liefen. Da hat das OS gut sachen finden können, die man wegswappen kann, weil sie selten gebraucht werden. Heute leuft da meist wirklich was aus dem Ruder und man ist im Normalfall dauernt am neu allozieren, solange geswapt wird. Außerdem ist Crypto wohl girft für die SWAP performance.

[ChronoBoost]

2. Benötigt man wirklich LVM? Macht es ein System nicht unnötig kompliziert?

Also ich persönlich wollte auf pvmove nicht mehr verzichten müssen. Überhaupt finde ich, dass LVM die Dinge eher vereinfacht als verkompliziert.

[dirk11]

Guten Abend!

Komme gerade von der Arbeit und bin überwältigt von den vielen hilfreichen Antworten, die ich jetzt schon hier vorfinde! Danke schön dafür erstmal!

Einige kurze Reaktionen gebe ich schonmal ab, einiges anderes muss ich noch ein wenig sacken lassen.

Es handelt sich um einen Heimserver, der einen vorhandenen auf Pentium-3-Basis ersetzen soll. Bisher läuft selbiger nicht im 24/7-Betrieb, es sei denn, ich bin längere Zeit abwesend. Das soll sich mit dem neuen Server aber eventuell ändern. An Diensten läuft der übliche Kram: DHCP, DNS, VPN, NFS, Samba, Mail, News (INN), Webserver, Datengrab.

Zunächst: ich glaube, ich werde auch in Zukunft auf LVM verzichten. Es macht die Sache nur um eine Schicht komplizierter, und mir hat noch niemand das Killerfeature nennen können, welches für mich die Initialzündung bedeutet hätte, LVM doch unbedingt zu wollen. pvmove sollte man vielleicht auch erläutern, was das überhaupt ist...
Die Frage nach LVM hat sich halt deshalb gestellt, weil sowieso komplett neu aufgesetzt werden soll.

Mit XFS bin ich nicht zufrieden, weil es mir ein paar mal nach Systemhängern/Stromausfall inkonsistente Files übriggelassen hat. In erster Linie geöffnete Logfiles, in denen dann nur noch @ und . drinstanden, was dazu geführt hat, dass der jeweilige Dienst seine Arbeit komplett eingestellt hat. Und ein xfs_check dauert auf den derzeitig vorhandenen 120GB schon seine Zeit (und ist umständlich, weil ich von CD booten muss), auf 3TB dürfte das ein Geduldspiel werden...
Anders gesagt: Probleme gab es ausschließlich bei Kernel-Oops, Hängern ohne ersichtlichen Grund oder hartem Abschalten durch Stromausfall (gegen letzteres gibt es mittlerweile eine USV). Frage wäre, wie sich da ext4 verhält. Wenn ich da keinen Mega-Vorteil bekomme, sondern mir das da genauso passieren kann, kann ich problemlos bei XFS bleiben! Ich habe übrigens immer nur die Standard-Einstellungen benutzt, nix "getunet".

SWAP Mein derzeitiger Server hat 768MB RAM und mWn noch nie geswappt. Ich werde es aber dennoch einrichten, weil man es wohl für Suspend to disk benötigt. Der neu zu bauende Server ist erstmal mit 2GB (DDR-2) geplant, mehr als 4GB wird er wohl niemals bekommen und auch nicht benötigen. 10GB SWAP werden da wohl locker ausreichen, oder!?
Mein System musste ich zehn Jahre nicht neu aufsetzen, weshalb ich einfach mal frech behaupte, ich brauche keine Unterteilung unterhalb von /. Aber gesetzt den Fall, ich möchte doch insgesamt vier Partitionen einrichten - wie groß sollten die sein?
/SWAP: 10GB
/boot: ??GB
/: ??GB
/home: den großen Rest.

Eine unverschlüsselte /boot Partition müsste idealerweise wie groß sein, vor allem unter dem Aspekt, das wohl noch etwas mehr in die initrd muss als üblich?
Was das Wie angeht bzgl. initrd, da werde ich sicherlich noch einen separaten thread für eröffnen!
Der Server steht übrigens @home (weil jemand meinte, Verschlüsselung mit vorliegendem Key sei in jedem anderen Fall nutzlos, womit er natürlich recht hat!). Ach ja: wieviel Performance/Rechenleistung benötigt eine Verschlüsselung eigentlich?

Reihenfolge wäre demnach Partitionierung->2-3*md->Filesystem->Verschlüsselung? Es war zwar im thread bisher die Rede von erst Verschlüsselung, dann Filesystem, da sehe ich aber den Nachteil, dass ich für einen Filesystem-check immer auf ein Notfallsystem (von USB z.B.) angewiesen bin, welches die Partition entschlüsseln kann. Wäre die Reihenfolge 1. filesystem, 2. Verschlüsselung unter diesem Gesichtspunkt nicht viel sinnvoller?
Was ist also die ultimative Reihenfolge, wenn ich nur einmal einen Key eingeben will, aber mindestens drei zu verschlüsselnde Partitionen (inklusive SWAP) habe?

Ach ja, wichtig:
Der neue Server soll unter allen Umständen dieselben UID/GID-Nummer für Systemdienste, User und alles, was UID/GID anfordert, haben wie der alte Server. Mein jetziger Stand dazu ist: neuen Server so minimal wie möglich aufsetzen, dann die /etc/group und die /etc/password durch die alte vorhandene ersetzen/erweitern und erst danach weitere Dinge installieren. Gibt es einen eleganteren Weg, mit dem ich schon vorher die vorhandenen UID/GID unterbringen kann und mir die Unterbrechung sparen kann?
Hintergrund: Ich nutze im heimischen Netz sehr gerne und hauptsächlich so Software wie den mc. Wenn UID/GID gleicher User/Dienste auf dem Client und dem Server identisch sind, erkennt der dies und alles ist problemlos bei der Rechtevergabe. Unterscheiden sich UID/GID, so wird alles unnötig kompliziert, und das will ich vermeiden!

[wanne]

Eine unverschlüsselte /boot Partition müsste idealerweise wie groß sein, vor allem unter dem Aspekt, das wohl noch etwas mehr in die initrd muss als üblich?

Ich gebe ihr immer so 250MiB. Da kann man dann auch ein paar Kernels parken. Im Prinzip kann man wohl auch mit 50 oder so auskommen aber die 250 tun niemand weh und man hat garaniert nie wieder Platzprobleme.

Ach ja: wieviel Performance/Rechenleistung benötigt eine Verschlüsselung eigentlich?

Kommt auf den durchsatz an.
Bei mir machts so 20% von einem Kern aus, wen wenn ich von meiner HD mit voller Geschwindigkeit lese. (Was sehr selten vorkommt.) Mit SSDs kommt man da aber natürlich in ganz andere Kategorien.

Reihenfolge wäre demnach Partitionierung->2-3*md->Filesystem->Verschlüsselung? Es war zwar im thread bisher die Rede von erst Verschlüsselung, dann Filesystem, da sehe ich aber den Nachteil, dass ich für einen Filesystem-check immer auf ein Notfallsystem (von USB z.B.) angewiesen bin, welches die Partition entschlüsseln kann. Wäre die Reihenfolge 1. filesystem, 2. Verschlüsselung unter diesem Gesichtspunkt nicht viel sinnvoller?

Naja du verrätst sehr viel wenn, du nur Dateien verschlüsselst und das sicher und transparent mit immer dem gleichen Key hinzubekommen ist nochmal so eine Sache.

Aber wie schon angemerkt gibt's einige Ansätze die so aussehen: Partitionierung->2-3*md->Filesystem->Netzwerk->Verschlüsselung Das ist eigentlich das was du willst. Ist aber alles beides nicht so einfach hinzubasteln wie eine LUKS-Partition.

[wanne]

Hups. Dann ist aber /usr/share/doc/cryptsetup/README.keyctl aus Wheezy verkehrt, da heisst es naemlich

The current state for dm-crypt in Linux is that it is single threaded, [...]

Habe gerade versucht einen Bugreport zu schreiben und bin mal wieder an reportbug gescheitert. Das ding ist einfach grauenhaft...

[dirk11]

Eine unverschlüsselte /boot Partition müsste idealerweise wie groß sein, vor allem unter dem Aspekt, das wohl noch etwas mehr in die initrd muss als üblich?

Ich gebe ihr immer so 250MiB. Da kann man dann auch ein paar Kernels parken. Im Prinzip kann man wohl auch mit 50 oder so auskommen aber die 250 tun niemand weh und man hat garaniert nie wieder Platzprobleme.

Hups. Wollte ihr schon 2GB geben. Also bekomme ich selbst mit 500MB in den nächsten 10 Jahren keine Probleme!?

Bei mir machts so 20% von einem Kern aus, wen wenn ich von meiner HD mit voller Geschwindigkeit lese. (Was sehr selten vorkommt.) Mit SSDs kommt man da aber natürlich in ganz andere Kategorien.

Es sollen momentan normale 3,5" SATA-HDD mit je 3TB werden. SSD gibts nicht in der Größe, und wenn wären sie mir zu teuer. Einzige Alternative wäre die 2,5"-2TB von WD, aber auch das wäre mir zu teuer.

Aber wie schon angemerkt gibt's einige Ansätze die so aussehen: Partitionierung->2-3*md->Filesystem->Netzwerk->Verschlüsselung Das ist eigentlich das was du willst. Ist aber alles beides nicht so einfach hinzubasteln wie eine LUKS-Partition.

Das ist wohl wirklich, was ich will, aber wieso ist das nicht so einfach?

Habe gerade versucht einen Bugreport zu schreiben und bin mal wieder an reportbug gescheitert. Das ding ist einfach grauenhaft...

Sorry, aber muss das hier im thread sein? Interessiert mich nicht wirklich, stört nur den Lesefluss. Mach dafür doch bitte gerne einen zweiten thread auf! Danke.

Dirk

[MarkusF]

3. Inwiefern bist du mit XFS nicht zufrieden? Ansonsten benutze ich immer mehr btrfs, wegen der Checksummen, Kompression, Deduplikation und Subvolumes (die ich statt Partitionen für / und /home benutze).

Entweder bist du mutig oder ich bin feige Wie produktiv setzt du das ein, welche Debianversion/Kernel und unter welcher Last? Es juckt mich in den Fingern! Lokal gespielt habe ich schon und hatte keine Probleme...

[peschmae]

Entweder bist du mutig oder ich bin feige Wie produktiv setzt du das ein, welche Debianversion/Kernel und unter welcher Last? Es juckt mich in den Fingern! Lokal gespielt habe ich schon und hatte keine Probleme...

Mit Btrfs angefangen habe ich vor zwei Jahren für meine Backupfestplatten ab Kernel 3.0, weil da die Features (Kompression, Checksummen, Deduplikation) am meisten bringen. Mittlerweile auch auf meinem Mailserver, Arbeitslaptop und OpenWRT Router mit Kernelversionen zwischen 3.3 und 3.10. Läuft sehr zuverlässig bisher, irgendwelche Performancevergleiche habe ich allerdings nie gemacht.

MfG Peschmä

[wanne]

Aber wie schon angemerkt gibt's einige Ansätze die so aussehen: Partitionierung->2-3*md->Filesystem->Netzwerk->Verschlüsselung Das ist eigentlich das was du willst. Ist aber alles beides nicht so einfach hinzubasteln wie eine LUKS-Partition.

Das ist wohl wirklich, was ich will, aber wieso ist das nicht so einfach?

Keine ahnung gibt einfach keine gute SW. Vermutlich weil halt lange alles was privat war lokal gespeichert wurde.

(Stichwort ist wohl client side encryption)

Hier mal das was man so findet: http://www.syncany.org/
Dem gibt man ein ganz normales SSHFS/FTP/WebDAV und der speichert dann verschlüsselt rein. Kenn das Ding aber nciht.

[dirk11]

Sorry, aber ich verstehe Deine Antwort nicht. Ich dachte, auf das Filesystem kommt eine Art Container, in welchem alles verschlüsselt gespeichert wird. Oder wird im Normalfall das FS selbst verschlüsselt? Ist also eigentlich
Partitionierung->2-3*md->Verschlüsselung->Filesystem
das, was ich benötige? Ich habe sowieso nicht verstanden, wieso Du da noch "Netzwerk" in's Spiel bringst, ich kann doch nicht das Internet verschlüsseln? Meine Platten in Utah sind noch nicht alle da, so schnell ist mein Auftragnehmer nicht. Ich glaube, meine Outsourcing-Abteilung hat das an jemanden namens NSA oder so vergeben...

[Cae]

Ich dachte, auf das Filesystem kommt eine Art Container, in welchem alles verschlüsselt gespeichert wird. Oder wird im Normalfall das FS selbst verschlüsselt? Ist also eigentlich
Partitionierung->2-3*md->Verschlüsselung->Filesystem

Genau so ist es. Man koennte zwar auch Filesystem->Crypto-Container->Filesystem machen, aber das ergibt nur begrenzt Sinn, da man normalerweise eh' alle Dateien im "inneren" Dateisystem halten wird.

Gruss Cae

[wanne]

Etwas ausführlicher:

Also das Problem mit luks ist folgendes: Sobalt du luksOpen ausgeführt hast, ist der Server ungeschützt, bis er wieder runterfährt.
Wenn man jetzt normale Vollverschlüsslung wo das cryptodevice beim booten geöffnet wird einsetzt hat man bei einem Server das Problem das der halt ein mal bootet und dann die ganze zeit an ist. => Die ganze Zeit ungeschützt ist.
Die eine Idee ist, dass man erst nach dem anmelden luksOpen ausführt. Das Problem bleibt aber: Man steht für gewöhnlich nicht neben dem server wenn man ihn benutzt. => In der Zeit in der man ihn benutzt ist er ungeschützt. Außerdem bekommt man die Keys nicht so einfach wieder los, ohne Runterzufahren und ne weile rumstehen zu lassen. (Gerade wenn der Rechner geswapt hat ist das richtig fieß, weil man nicht weiß wo im Speicher der Key überall stand. Das ist ein Grund der gegen swap sprechen könnte. Weil wenn alles da liegen bleibt wo es war überschreibt cryptsetup am ende mit nullen. Aber auch dann geistern Caches der unverschlüsselten Daten weiter im RAM rum.)

Die andere Idee (die von syncany) ist, den Server einfach dumm zu halten. Der client verschlüsselt, parkt das zeug auf dem Server der speichert ohne zu verstehen was es ist und ein anderer Client, der den Key hat kann's da abholen. Holt sich jetzt jemand den Server ist das sinnlos, weil der sowiso nur ne Menge Datenmüll beherbergt, von der er selbst nicht weiß was es ist.

[dirk11]

Ok, so langsam verstehe ich den Ansatz.
Allein, so weit will ich in meiner ganz persönlichen Paranoia nicht gehen, denn es gibt immer Schwachstellen. Schon allein die Tatsache, dass ich den Server überhaupt aus den Augen verliere, ist eine Sicherheitslücke...

Sobalt du luksOpen ausgeführt hast, ist der Server ungeschützt, bis er wieder runterfährt.

...insofern ist das mal völlig klar.
Mir geht es halt in erster Linie darum, dass die Daten verschlüsselt gespeichert werden. Sprich, man nicht einfach nur durch Hochfahren an die Daten drankommt - jedenfalls dann nicht, wenn ich es nicht will. Anders gesagt: ändert sich z.B. der Standort oder der Hochfahrende bin nicht ich, dann sollen die Daten nicht frei zugänglich sein. Ich gehe nicht so weit, dass ich auch logs uswusf. verschlüsselt haben "muss", denn ich mache wie gesagt keine zum jetzigen Zeitpunkt nicht legalen Dinge - jedenfalls nicht wissentlich
Es geht halt mehr darum, dass jemand, der den Server oder die Platte unauthorisiert in Händen hält (das kann schon eine Platten-Reparatur beim Hersteller sein oder sowas), z.B. nicht einfach so meine Fotosammlung anschauen und Bilder für eigene Zwecke klauen kann (also zur beispielhaften Verdeutlichung ein Bild von einem Baum von mir klaut, selbst an eine Bildagentur verkauft, damit Geld verdient und dann noch behauptet, es sei sein Bild).
Oder ähnlich einem Laptop: er wird hochgefahren vom Security-Mann am Flughafen, an die Daten kommt er aber ohne mein Einverständnis nicht dran. Ich will auch gar nicht auf versteckte Verschlüsselung mittels Steganografie uswusf. eingehen, kenne ich, tut hier aber denke ich nichts zur Sache.

Die andere Idee (die von syncany) ist, den Server einfach dumm zu halten. Der client verschlüsselt, parkt das zeug auf dem Server der speichert ohne zu verstehen was es ist und ein anderer Client, der den Key hat kann's da abholen. Holt sich jetzt jemand den Server ist das sinnlos, weil der sowiso nur ne Menge Datenmüll beherbergt, von der er selbst nicht weiß was es ist.

Das wäre ungefähr das, was ich jetzt schon mache: bestimmte Files mit GnuPG verschlüsseln. Will ich eben nicht mehr, weil man auf die einzelnen Files achten muss.

Ich überlege nur mittlerweile, ob es einfachere Ansätze gibt, als das komplette System zu verschlüsseln. Z.B. nur /home verschlüsseln. Dann kann der Rechner problemlos z.B. per WOL hochfahren und alle Dienste laufen lassen, die gewünscht sind, er kann halt nur auf das verschlüsselte /home nicht zugreifen.

Bin mit dem Thema noch nicht durch, überzeugt hat mich bisher noch keiner der Ansätze...

[wanne]

Die andere Idee (die von syncany) ist, den Server einfach dumm zu halten. Der client verschlüsselt, parkt das zeug auf dem Server der speichert ohne zu verstehen was es ist und ein anderer Client, der den Key hat kann's da abholen. Holt sich jetzt jemand den Server ist das sinnlos, weil der sowiso nur ne Menge Datenmüll beherbergt, von der er selbst nicht weiß was es ist.

Das wäre ungefähr das, was ich jetzt schon mache: bestimmte Files mit GnuPG verschlüsseln. Will ich eben nicht mehr, weil man auf die einzelnen Files achten muss.

Genau das Problem behebt syncany: Du gibst einmal das pw an und sobalt du auf den Server speicherst veschlüsselt syncany – Ohne dein zutun und ohne das du davon was merkst.
Ansonsten genau das gleiche wie GnuPG.