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?
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.
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.
>> 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 :)
>> 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.
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.
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:
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.
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.
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).