noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, @MoonKid: es ist halt ein Wikiartikel und kein Howto. Heisst: wenn du was nicht verstehst bzw. Wissen (noch) nicht hast den Links folgen, inkl. denen im Wissensblock. So ist das Konzept des Wikis hier. Falls du das jetzt generell in Frage stellen möchtest → bitte einen eigenen Thread starten, weil das eine Grundsatzdiskussion ist, die hier in der Diskussion nichts zu suchen hast. Wenn du Verständnisfragen zu einzelnen Passagen hast bzw. Vorschläge zur besseren Verständlichkeit hast → hier im Thread posten. Bei grundlegenden Fragen halt im Support-Forum anfragen - hast du ja schon 😉 Gruß, noisefloor
|
MoonKid
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
V for Vortex schrieb: MoonKid schrieb: Am Anfang in der Hinweis-Box wird erwähnt, man könne auch die "Partitionierungsmethode" verwenden. In dem hinterlegten Artikel steht aber nix zur Verschlüsselung, sondern einfach nur etwas übers Partitionieren im Allgemeinen.
Weil es eben nur um die Partitionierungsmethode geht, die eben erstmal nichts mit der Verschlüsselung zu tun hat.
Die Box sugeriert jedoch, dass man mit dieser alternativen Methode ebenfalls verschlüsseln könnte.
Welche Informationen fehlen Dir konkret? Was meinst Du mit „passiert im Großen und Ganzen“ und was mit „Konzept“?
z.B. in zwei Sätzen erklären das eine LVM eine Zwischenschicht ist, etc. Problem an dem Artikel, jetzt wo ich mehr darüber nachdenke, ist die Erwartung, welche der Titel sugeriert. Hier geht es nicht darum ein "System [zu] verschlüsseln", sondern darum ein neues(!) System mit der LVM-Methode zu verschlüsseln bzw. verschüsselt zu installieren.
Mit dem Artikel wird nur eine einzige Methode behandelt, welche dann eben auch im Titel genannt werden sollte.
"System verschlüsseln" sollte einen Überblick über bestehende Methoden geben und ausreichend Infos liefern, um diese zu vergleichen. Neben ist es sehr entscheidend ob ein frisches verschüsseltes System aufgesetzt wird oder ein bestehendes veschlüsselt wird. Der Titel sugeriert letzteres. Aber verschüssele ich nun ein bestehendes System? Dazu fand ich bisher keinen Artikel im Wiki.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, alles, das Wiki dazu zu bietet, ist auf der Übersichtsseiten Daten verschlüsseln zu finden. In Bezug auf den Artikelnamen kann ich deinen Einwand verstehen - ist im Wiki halt (leider) manchmal so. Was für den einen klar ist, muss für andere noch lange nicht genau so klar sein... Gruß, noisefloor
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12084
|
Hallo MoonKid, danke für Deine weiteren Ausführungen. MoonKid schrieb: Die Box sugeriert jedoch, dass man mit dieser alternativen Methode ebenfalls verschlüsseln könnte.
Stimmt, eigentlich wäre der Text im Kasten eine gute Einleitung für den Absatz darunter, wird durch den Kasten aber von diesem getrennt. @alle: Wie wäre es, zumindest den ersten Satz des folgenden Absatzes („Alternativ ist es…“) in den Hinweiskasten zu verlegen bzw. mit dessen letztem Satz („Für Desktops…“) zu einem zu verschmelzen? Davon abgesehen finde ich den Hinweis im Kasten eigentlich unzutreffend, da ein LVM nicht viel schwieriger ist als eine partitionsbasierte Verschlüsselung und zudem seit langem die Standardmethode des offiziellen Installationsprogramms ist. Selbst bei nur einer Festplatte bietet es eine höhere Flexibilität für spätere Änderungen oder weitere Festplatten. Ich rege daher an, den Kasten ersatzlos zu streichen. Im Absatz danach wird ja bereits auf die partitionsbasierte Methode verwiesen.
Aber verschüssele ich nun ein bestehendes System? Dazu fand ich bisher keinen Artikel im Wiki.
Nach der Aufzählung in Daten verschlüsseln gibt es wohl keinen Artikel dazu. Im Prinzip musst Du aber einfach nur den Teil Installation weglassen und stattdessen ein vollständiges Systembackup in das irgendwo eingehängte /dev/mapper/vgubuntu-root zurückspielen. Danach gehts es mit ins verschlüsselte System wechseln weiter. (Ich habe jetzt nicht den ganzen Artikel haarklein auf etwaige Fußfallen untersucht, habe es aber meinerseits schon einige Male so gemacht.) Erneut ein Vorschlag an alle: Wäre es sinnvoll, den ja diesbezüglich allgemein betitelten Artikel für die Neuinstallation und die Umstellung eines bestehenden Systems umzuschreiben? Im Prinzip müsste man „nur“ den Teil Installation erweitern und den Rest auf eventuelle Unterschiede abklopfen. edit: Mir ist klar, dass das jemand™ machen müsste, und ich sage daher vorab meine aktive Mitarbeit zu. ☺
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, @V for Vortex: wenn nach heutigem Stand der Dinge Hinweisboxen falsch oder irreführend sind, kannst du dass gerne Korrigieren. Wenn du eine Baustelle brauchst → hier kurz melden. Gruß, noisefloor
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, Nachtrag: @V vor Vortex - wenn du Mitstreiter suchst, kann du das auch via "Ubuntu Wochenrückblick" machen. Bei Bedarf dazu einfach das Ikhaya-Team kontaktieren. Gruß, noisefloor
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
Hallo! Ich installiere gerade ein paar Rechner mit Vivid neu und halte mich exakt an diesen Artikel. Dabei ist mir aufgefallen, dass hier keine Aussage gemacht wird, auf welches Gerät der Bootloader installierte werden soll (Abschnitt „Installation“, siehe Screenshot). Voreinstellung des Vivid-Installers ist /dev/dm-0, was, glaube ich, keinen Sinn macht. Ich denke, der Bootloader sollte schon im MBR installiert werden, also z.B. /dev/sda (so wie auch im Screenshot). Kann/soll ich das ergänzen oder liege ich falsch? Außerdem scheint mir die Befehlssequenz unter Beenden/Neustart zum Scheitern verurteilt, weil /mnt/dev und /mnt/dev/pts in Benutzung sind (fuser -m /dev/pts und fuser -m /mnt/dev/pts liefern die identischen Prozesslisten – genauso für fuser -m /dev und fuser -m /mnt/dev). Dementsprechend lässt sich auch /mnt nicht aushängen und auch lvchange -a n vgubuntu und cryptsetup luksClose lukslvm schlagen entsprechend fehl. Sauberste Lösung scheint mir zu sein, nach dem exit und sync alle Fenster zu schließen und den Neustart über die graphische Oberfläche einzuleiten. (Ggf. kann man noch umount /mnt/boot und swapoff -a absetzen, ist aber wahrscheinlich nicht nötig.) Oder gibt es eine Alternative zu mount -o rbind, die die Dateisysteme einfacher freigibt? (edit: Link repariert.)
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
aldor schrieb: Ich installiere gerade ein paar Rechner mit Vivid neu und halte mich exakt an diesen Artikel. Dabei ist mir aufgefallen, dass hier keine Aussage gemacht wird, auf welches Gerät der Bootloader installierte werden soll (Abschnitt „Installation“, siehe Screenshot). Voreinstellung des Vivid-Installers ist /dev/dm-0, was, glaube ich, keinen Sinn macht. Ich denke, der Bootloader sollte schon im MBR installiert werden, also z.B. /dev/sda (so wie auch im Screenshot).
Ich hab das jetzt mal im Artikel erwähnt und hoffe, das ist okay so. Aber verdammt, auf welchen Screenshot hab ich mich denn bezogen? Ich weiß es selbst nicht mehr.
Außerdem scheint mir die Befehlssequenz unter Beenden/Neustart zum Scheitern verurteilt, weil /mnt/dev und /mnt/dev/pts in Benutzung sind (fuser -m /dev/pts und fuser -m /mnt/dev/pts liefern die identischen Prozesslisten – genauso für fuser -m /dev und fuser -m /mnt/dev). Dementsprechend lässt sich auch /mnt nicht aushängen und auch lvchange -a n vgubuntu und cryptsetup luksClose lukslvm schlagen entsprechend fehl. Sauberste Lösung scheint mir zu sein, nach dem exit und sync alle Fenster zu schließen und den Neustart über die graphische Oberfläche einzuleiten. (Ggf. kann man noch umount /mnt/boot und swapoff -a absetzen, ist aber wahrscheinlich nicht nötig.) Oder gibt es eine Alternative zu mount -o rbind, die die Dateisysteme einfacher freigibt?
Kann dazu jemand noch etwas sagen?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12084
|
aldor schrieb: Kann dazu jemand noch etwas sagen?
Genau das beschriebene Verhalten kenne ich aus der Praxis, habe ihm aber nie viel Bedeutung beigemessen und das System einfach neu gestartet, im Vertrauen, dass dann schon alles sauber ausgehängt wird. ☺
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
V for Vortex schrieb: Genau das beschriebene Verhalten kenne ich aus der Praxis, habe ihm aber nie viel Bedeutung beigemessen und das System einfach neu gestartet, im Vertrauen, dass dann schon alles sauber ausgehängt wird. ☺
Ich hab mal alle Befehle aus der Anleitung Beenden/Neustart rausgenommen, die offenbar Fehler verursachen. Den Text hab ich entsprechend angepasst. Spätestens beim reboot müsste es ja (hoffentlich sauber) ausgehängt werden. Besser so als Nutzern eine Anleitung an die Hand zu geben, die gar nicht funktionieren kann und potentiell panische Reaktionen auslöst.
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
aldor schrieb: Ich hab mal alle Befehle aus der Anleitung Beenden/Neustart rausgenommen, die offenbar Fehler verursachen. Den Text hab ich entsprechend angepasst. Spätestens beim reboot müsste es ja (hoffentlich sauber) ausgehängt werden. Besser so als Nutzern eine Anleitung an die Hand zu geben, die gar nicht funktionieren kann und potentiell panische Reaktionen auslöst.
Oh, Moment! Kann es sein, dass ich am falschen Ende angefangen habe zu flicken? Möglicherweise ist es einfach keine gute Idee /dev mit
mount -o rbind /dev /mnt/dev
einzubinden, wie es im Abschnitt Ins verschlüsselte System wechseln beschrieben wird. Jedenfalls sieht es im Artikel chroot/Live-CD (Abschnitt „Zusaetzliche-Schritte“) anders aus:
mount -t devtmpfs /dev /mnt/dev
mount -t devpts /dev/pts /mnt/dev/pts
mount -t sysfs /sys /mnt/sys
mount -t proc /proc /mnt/proc
mount -t tmpfs /run /mnt/run
cp /proc/mounts /mnt/etc/mtab
mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf
Ich hab leider gerade nicht die Zeit, das mit einem Live-System zu testen. (Also insbesondere, ob das Aushängen im Anschluss unproblematisch ist.) Aber vielleicht kann das hier jemand auf Anhieb beurteilen? edit: Kosmetik.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7529
|
bind ist nicht falsch, bei dynamischen /dev sogar meistens richtig... umount sollte ja trotzdem gehen, eben in umgekehrter Reihenfolge & nachdem Prozesse die da noch was blockieren entsprechend weg sind. Aber ein Journal Dateisystem überlebt auch den Filmriss, insbesondere wenn du eh noch sync machen kannst vorher (und kein Prozess irgendwie aktiv am Dateisystem herumschreibt, versteht sich).
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
frostschutz schrieb: umount sollte ja trotzdem gehen, eben in umgekehrter Reihenfolge & nachdem Prozesse die da noch was blockieren entsprechend weg sind.
Tut es aber nicht. Ich habe systematisch der Reihe nach von unten versucht die Dateisysteme wieder auszuhängen. Es ist tatsächlich so, dass einige Gerätedateien unterhalb von /mnt/dev/pts/ (aber auch in anderen Unterverzeichnissen von /mnt/dev/) noch geöffnet sind. Daraufhin habe ich mit
fuser -m /mnt/dev
getestet, welche Prozesse dafür verantwortlich sind. Es ist die identische Liste an Prozessen wie bei
fuser -m /dev
selbst. Diese Prozesse bekomme kann ich nicht killen. Das wäre ein sehr unkontrolliertes abschießen des Live-Systems. Ich werde demnächst die Variante mit
mount -t devtmpfs /dev /mnt/dev
mount -t devpts /dev/pts /mnt/dev/pts
doch mal testen.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7529
|
Folgendes geht nicht: # mount --rbind /dev /mnt/root/dev
# umount /mnt/root/dev
umount: /mnt/root/dev: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).) Das liegt daran daß --rbind eben die ganzen Submounts mitgenommen hat. Welche das sind: # mount | grep /mnt/root/
dev on /mnt/root/dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=2035741,mode=755)
devpts on /mnt/root/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
tmpfs on /mnt/root/dev/shm type tmpfs (rw,nosuid,nodev,noexec,noatime) Einzeln umounten geht aber: # umount /mnt/root/dev/pts
# umount /mnt/root/dev/shm
# umount /mnt/root/dev Alternativ: # umount --recursive /mnt/root/dev Wenn das nicht geht sollte sich ein Prozess finden lassen der eben doch in /mnt/root/dev hängt und nicht in /dev. Ein fuser -m wird aber wahrscheinlich immer die Prozesse von beiden Seiten auflisten so daß das nicht unbedingt weiterhilft in diesem Fall. Vielleicht klappt dann ein lsof | grep /mnt/root oder sowas besser - wenns kein Loop Device, mdadm, Device Mapper o.ä. ist das noch ein Binding direkt innerhalb von /mnt/root/dev hat.
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
|
frostschutz schrieb: …
Das liegt daran daß --rbind eben die ganzen Submounts mitgenommen hat.
…
Das ist mir schon klar.
Einzeln umounten geht aber: # umount /mnt/root/dev/pts
# umount /mnt/root/dev/shm
# umount /mnt/root/dev
Das ging nicht. Ich habe es definitiv mehrfach probiert. Natürlich mit root-Rechten, nach dem exit aus der chroot-Umgebung, sicherheitshalber sync, alle unnötigen Anwendungen zuvor geschlossen, darauf geachtet, dass ich außerhalb von /mnt/ bin, sichergestellt, dass nicht unterhalb von /mnt/root/dev/pts und /mnt/root/dev/shm noch weitere Dateisystem eingehängt sind und allem was man braucht; bei zwei Installation auf zwei verschiedenen Computern und anschließend mehrfach auf den bereits installierten Systemen. Es geht nicht. (Ich beziehe mich auf Xubuntu 15.04.)
Alternativ: # umount --recursive /mnt/root/dev
Das habe ich nicht getestet. Aber ich gehe davon aus, dass das aufs gleich rausläuft.
Wenn das nicht geht sollte sich ein Prozess finden lassen der eben doch in /mnt/root/dev hängt und nicht in /dev. Ein fuser -m wird aber wahrscheinlich immer die Prozesse von beiden Seiten auflisten so daß das nicht unbedingt weiterhilft in diesem Fall. Vielleicht klappt dann ein lsof | grep /mnt/root oder sowas besser - wenns kein Loop Device, mdadm, Device Mapper o.ä. ist das noch ein Binding direkt innerhalb von /mnt/root/dev hat.
Ich werde es bei Gelegenheit testen. Bin aber nicht sehr optimistsch. Ich vermute eher, dass irgendwelche Besonderheiten des dev-Dateisystems dazu führen, dass -o bind bzw. -o rbind nicht die mount-Optionen der Wahl sind.
|