Nachdem sich zeigte das ein User, als root, auf eine Platte mit dd geschrieben hat und diese Platte "zufälligerweise" die Systemplatte ist (mit dem Bootloader, Wurtelverzeichnis und Swap-Partition), suche ich eine DAU-Sicherung, hauptsächlich für Linux, aber möglichst auch für Cygwin unter Windows, denn da hat man auch dd. Eine Möglichkeit wäre Installieren auf einem USB-Stick mit Schreibschutzschalter oder ein Live-System auf DVD/CD aber zum Arbeiten muss auch mal etwas gespeichert werden, z. B. Image-Dateien, aber damit gibt es einen Datenträger den man mit dd kaputt bekommt. Gibt es dazu Alternativen, beispielsweise eine dd-Version die nichts gemountetes überschreibt?
geht vielleicht mit selinux, aber das eigentliche problem ist:
1 | ein User, als root |
c.m. schrieb: > geht vielleicht mit selinux, aber das eigentliche problem ist: >
1 | > ein User, als root |
Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn werden, beispielsweise damit ein Image davon, nach einer nachfolgenden Installation, möglichst gut komprimiert werden kann.
> Eine Möglichkeit wäre Installieren auf einem USB-Stick mit > Schreibschutzschalter oder ein Live-System auf DVD/CD [..] Noch besser: Booten übers Netz und Dateisystem über nfs.
dd umbenennen
Rolf F. schrieb: > Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn > werden, beispielsweise damit ein Image davon, nach einer nachfolgenden > Installation, möglichst gut komprimiert werden kann. Wrapper Script fuer dd und sudo, fertig.
Rolf F. schrieb: > c.m. schrieb: >> geht vielleicht mit selinux, aber das eigentliche problem ist: >>
1 | >> ein User, als root |
> > Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn > werden, beispielsweise damit ein Image davon, nach einer nachfolgenden > Installation, möglichst gut komprimiert werden kann. unnötig, weil geeignete backupprogramme (z.b. clonezilla) nicht ganze partitionen dumpen und komprimieren, sondern nur vom dateisystem benutzte bereiche. probiers mal :)
Rolf F. schrieb: > c.m. schrieb: >> geht vielleicht mit selinux, aber das eigentliche problem ist: >>
1 | >> ein User, als root |
> > Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn > werden, beispielsweise damit ein Image davon, nach einer nachfolgenden > Installation, möglichst gut komprimiert werden kann. Wenn du wirklich das komplette device sichern willst statt nen tool zu nutzen das das dateisystem versteht geht das aber trotzdem ohne DD du kannst die nullen auch einfach ins dateisystem schreiben, vorm sichern. das image ist dam im besten fall sogar besser komprimierbar als das vorher genullte, weil die blocks die zwischenzeitlich daten gefüllt waren, es aber nicht mehr sind, auch genullt werden. das machst du relativ einfach mit cat /dev/zero >/pfad/in/das/zu/sichernde/dateisystem rm /pfad/in/das/zu/sichernde/dateisystem Danach ist dein gezipptest image maximal so groß wie df dir als belegt anzeigt.
c.m. schrieb: > unnötig, weil geeignete backupprogramme (z.b. clonezilla) nicht ganze > partitionen dumpen und komprimieren, sondern nur vom dateisystem > benutzte bereiche. Das hilft nicht generell, denn Clonezilla kann nicht auf alle Dateisysteme zugreifen, beispielsweise verschlüsselte oder steganografische, und beim Klonen mit dd überträgt auch MBR/GPT und auch den Bootloader - auch für die exotischsten Betriebssyteme.
Rolf F. schrieb: > c.m. schrieb: >> geht vielleicht mit selinux, aber das eigentliche problem ist: >> >>> ein User, als root > Ja, ich weiß, Offenbar doch nicht. > aber es sollen auch Platten mit Null überschriebenn > werden, [...] Ja und? Ich würde versuchen, das über die Zugriffsrechte zu regeln, also: - verhindern, dass sich der User als root einloggt, - den User in eine eigens dafuer angelegte Gruppe stecken, - die Group-ID der gewuenschten Devices auf diese Gruppe setzen, - dafuer sorgen, dass die Gruppe Schreibrecht hat. Ggf. muss man noch dafür sorgen, dass das nicht mit der systemeigenen Gruppe kollidiert. -- Habe das aber noch nicht selbst gemacht; kann sein, dass ich Fallstricke übersehe...
Rolf F. schrieb: > Gibt es dazu Alternativen Regelmäßige Images an einem sichern Ort (Schrank) aufbewahren, sollte der erste Schritt gegen allerlei Datenverlust sein. Rolf F. schrieb: > Gibt es dazu Alternativen, beispielsweise eine dd-Version die nichts > gemountetes überschreibt? Du bist nie sicher, daß ein DAU eine gewünschte Version benutzt. Wenn das LW auf einem anderen Rechner liegt, wo der DAU keine Schreibrechte bekommt und kein Admin ist, wird er wenig löschen können.
Relax-and-Recover Wird aber dein eigentliches Problem nicht lösen. Wenn der Lerneffekt wirkt, ok. Wenn nicht root abnehmen und das über user/gruppen rechte regeln (udev kann das).
Rolf F. schrieb: > Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn > werden, beispielsweise damit ein Image davon, nach einer nachfolgenden > Installation, möglichst gut komprimiert werden kann. bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien raus. Das macht sie langsamer. Dein Komprimier- und vor allem Dein Entkomprimierprogramm sollten also besser wissen wo echte Daten sind und wo nicht. Wenn die Partitionen verschlüsselt sind, dann den Inhalt in unverschlüsseltem Zustand komprimieren und diesen dann wieder verschlüsseln. Den Inhalt einer bereits verschlüsselten Partition kannst Du nämlich sowieso nicht mehr komprimieren.
:
Bearbeitet durch User
Julian .. schrieb: > Relax-and-Recover > > Wird aber dein eigentliches Problem nicht lösen. > Wenn der Lerneffekt wirkt, ok. Wenn nicht root abnehmen > und das über user/gruppen rechte regeln (udev kann das). Das geht auch mit dd als nicht-root. dd if=/dev/zero of=~/nullfile bs=32768 Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs= wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert. Dann das nullfile einfach löschen und auf der Partition auf der sich das Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen gefüllt. Das funktioniert auch mit SDD und verschlüsselung.
Blockflöte -> Blockgröße Was für eine bescheuerte "Smart"phone Mimik.
Gerd E. schrieb: > Rolf F. schrieb: >> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn >> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden >> Installation, möglichst gut komprimiert werden kann. > > bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt > die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien > raus. Das macht sie langsamer. Deswegen lösch ich das file ja auch hinterher wieder :/
Ich würde da anders vorgehen. Wenn man wirklich ein bootbares komplettimage braucht, würde ich sowas versuchen. Ich habe das jetzt aber nicht getestet:
1 | #!/bin/sh
|
2 | |
3 | disk=/dev/sda # source device |
4 | image=test.img # destination image |
5 | mountpoint1=/mnt/backuptmp1 # temporary mountpoint disk |
6 | mountpoint2=/mnt/backuptmp2 # temporary mountpoint image |
7 | ddparts="1 2" # partition numbers to dd |
8 | ext4cp="4" # ext4 partition numbers to copy |
9 | |
10 | size=$(blockdev --getsize64 "$disk") # Grösse von $disk |
11 | truncate -s "$size" "$image" # sparseimage mit grösse size, das keinen Speicher belegt (sofern vom Dateisystem unterstützt) |
12 | sgdisk -P "$device" -R "$image" # (GPT) Partitionstabelle kopieren |
13 | |
14 | loop=$(losetup -Pf --show "$image") # Create loop device & setup image partition block devices |
15 | if [ $? != 0 ] # abord on error |
16 | then
|
17 | rm "$image" |
18 | echo "Error: losetup failed" |
19 | exit 1 |
20 | fi
|
21 | |
22 | for i in $ddparts # copy some small partitions, z.B. boot & efi |
23 | do dd if="$disk$i" of="$loop"p"$i" |
24 | done
|
25 | |
26 | mkdir -p "$mountpoint1" # verzeichnis für mountpoint erstellen |
27 | mkdir -p "$mountpoint2" # verzeichnis für mountpoint erstellen |
28 | |
29 | for i in $ext4cp |
30 | do
|
31 | mkfs.ext4 "$loop"p"$i" # create ext4 filesystem in image/loopdevice partition |
32 | mount -r -o ro "$disk$i" "$mountpoint1" # Platte mounten |
33 | mount "$loop"p"$i" "$mountpoint2" # image partition mounten |
34 | cp -a "$mountpoint1"/. "$mountpoint2" # Alles kopieren |
35 | umount "$mountpoint1" # platte unmounten |
36 | umount "$mountpoint2" # image partition unmounten |
37 | done
|
38 | |
39 | losetup -D "$loop" # loopdevice freigeben |
40 | gzip "$image" # image gzippen |
Könnte natürlich noch etwas error handling vertragen.
Possetitjel schrieb: > - verhindern, dass sich der User als root einloggt, > - den User in eine eigens dafuer angelegte Gruppe stecken, > - die Group-ID der gewuenschten Devices auf diese Gruppe setzen, > - dafuer sorgen, dass die Gruppe Schreibrecht hat. Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration das neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder IDE-HDD angeschlossen und dann ist die Systemplatte nicht sda sondern sdb oder sdc. Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als Wechseldatenträger.
Virtualbox und VM regelmässig exportieren + Backup an sicherem Ort.
Rolf F. schrieb: > Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn > werden, beispielsweise damit ein Image davon, nach einer nachfolgenden > Installation, möglichst gut komprimiert werden kann. Dann baut man eine "Anwendung" (hier reicht wohl ein sehr primitives bash-Script), die genau dies (und nix anderes) tut und gibt den Usern, die das machen müssen, genau nur das Recht, diese eine Anwendung mit root-Rechten auszuführen. Für alles andere bleiben sie das, was sie sein sollen: poplige Standard-User. man sudo (und Verweise) Anmerkung: wenn man dir das erst erklären muss, bist du genauso unfähig wie diese User. Du solltest ebenfalls keine root-Rechte haben... Bleibt die Frage: Hast du die bei einem Schönheitswettbewerb gewonnen oder im Lotto?
Rolf F. schrieb: > Possetitjel schrieb: > >> - verhindern, dass sich der User als root einloggt, >> - den User in eine eigens dafuer angelegte Gruppe stecken, >> - die Group-ID der gewuenschten Devices auf diese Gruppe setzen, >> - dafuer sorgen, dass die Gruppe Schreibrecht hat. > > Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration > das neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder > IDE-HDD angeschlossen und dann ist die Systemplatte nicht sda > sondern sdb oder sdc. Das ist natürlich Scheisse. > Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als > Wechseldatenträger. Nicht zwingend. Unter der Annahme, dass sich die Systemplatte nicht im laufenden Betrieb ändert, könnte man ein Boot-Script basteln, das die Schreibrechte passend setzt. Natürlich... "schön" geht anders...
Possetitjel schrieb: > Nicht zwingend. Unter der Annahme, dass sich die Systemplatte nicht > im laufenden Betrieb ändert, könnte man ein Boot-Script basteln, das > die Schreibrechte passend setzt. Dafür gibt es udev, btw. die diversen udev ersätze unter nicht systemd systemen.
Suicide Linux installieren
udev Regel für USB/eSATA Sticks/Platten erstellen, die auch nicht-root Usern den (voll-) zugriff erlaubt.
:
Bearbeitet durch User
Siggi schrieb: > Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit > bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs= > wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert. > Dann das nullfile einfach löschen und auf der Partition auf der sich das > Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen > gefüllt. Dann musst du aber ein Dateisystem benutzen, das noch keine Sparse Files kennt. Bei dem werden die Nullen nämlich einfach "wegoptimiert". > Das funktioniert auch mit SDD und verschlüsselung. Glaube nicht, dass das mit Verschlüsselung funktioniert. Es würde Angriffspotenzial bieten, wenn verschlüsselte Nullen auch wieder Nullen wären. Siggi schrieb: > Blockflöte -> Blockgröße > > Was für eine bescheuerte "Smart"phone Mimik. Das erste, was man macht, ist doch, diese dämliche Automatik abzuschalten. Dirk D. schrieb: >> bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt >> die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien >> raus. Das macht sie langsamer. > Deswegen lösch ich das file ja auch hinterher wieder :/ Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch zu einer Datei gehörten, jetzt als unbelegt gelten sollen. Andreas R. schrieb: > Virtualbox und VM regelmässig exportieren + Backup an sicherem Ort. Bzw gleich mit Snapshots arbeiten.
Rolf M. schrieb: > Siggi schrieb: >> Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit >> bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs= >> wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert. >> Dann das nullfile einfach löschen und auf der Partition auf der sich das >> Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen >> gefüllt. > > Dann musst du aber ein Dateisystem benutzen, das noch keine Sparse Files > kennt. Bei dem werden die Nullen nämlich einfach "wegoptimiert". ich weiß nicht wie es wo anders ist, unter linux sind sparse files solche bei denen bereiche NICHT beschrieben sind, das unterscheidet sich deutlich von bereichen die mit nullen gefüllt sind. Technisch geht das so:
1 | file = fopen('file','w'); |
2 | fseek(file , 1024*1024*1024, SEEK_SET); |
3 | fclose(file); |
Jetzt hab ich nen sparse-file mit nem gb. wenn ich einfach nullen in ne datei schreibe habe ich ne datei mit nullen. > Dirk D. schrieb: >>> bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt >>> die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien >>> raus. Das macht sie langsamer. >> Deswegen lösch ich das file ja auch hinterher wieder :/ > > Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch > zu einer Datei gehörten, jetzt als unbelegt gelten sollen. Das geht ja seid 8 Jahren, ab Kernel 2.6.28.
Rolf F. schrieb: > Possetitjel schrieb: > >> - verhindern, dass sich der User als root einloggt, >> - den User in eine eigens dafuer angelegte Gruppe stecken, >> - die Group-ID der gewuenschten Devices auf diese Gruppe setzen, >> - dafuer sorgen, dass die Gruppe Schreibrecht hat. > > Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration das > neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder IDE-HDD > angeschlossen und dann ist die Systemplatte nicht sda sondern sdb oder > sdc. > Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als > Wechseldatenträger. Und? Man kann mit udev auch auf z.B. Seriennummern vergleichen. Aber wie schon gesagt, einfach ein Wrapper Skript, welches die notwendigen Arbeitsbefehle im Bauch hat und von den Nutzern per sudo ausgeführt werden kann. Für ein solches Skript ist es ein leichtes zu prüfen ob das übergebene /dev/sdX die Systemplatte ist oder nicht. Ich vermute eher die Nutzer wollen Ihre root-rechte nicht abgeben...
>> [...] dd if=/dev/zero of=~/nullfile bs=32768 oder >> [...] cat /dev/zero >/pfad/in/das/zu/sichernde/dateisystem ; rm /pfad/in/das/zu/sichernde/dateisystem > Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch > zu einer Datei gehörten, jetzt als unbelegt gelten sollen. fstrim -v /<mountpoint> macht bei SSDs dasselbe in einem Rutsch, unbelegte Blöcke per TRIM freigeben. Mit hdparm -I /dev/sdX die SSD prüfen, wenn da das Flag: * Deterministic read ZEROs after TRIM gesetzt ist, dann sind die Blöcke nachher auch alle genullt.
Andreas M. schrieb: > Aber wie > schon gesagt, einfach ein Wrapper Skript, welches die notwendigen > Arbeitsbefehle im Bauch hat und von den Nutzern per sudo ausgeführt > werden kann. Für ein solches Skript ist es ein leichtes zu prüfen ob das > übergebene /dev/sdX die Systemplatte ist oder nicht. Ja, die Ausgabe von mount zu durchsuchen, und zu prüfen ob es das Block-Device auch gibt, ist ja nicht schwer. Dazu habe ich ein Skript gemacht, für die Leute die das nicht können (auch Kindersicherung genannt).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.