Von Verfluchtnochmal am Do, 19. Oktober 2017 um 19:57 #
vmware-toolbox-cmd disk shrink /
Einfach aus dem Gast heraus, freie Bereiche werden genullt, danach automatisch die vdisk in einem Tempfile neu generiert und danach ist der Gast automatisch wieder online
Wobei es schlauer wäre wenn diese Idioten alle endlich mal trim support und ein vernünftiges reuse implementieren würden damit die disks gar nicht erst wachsen weil so ist thin provisioning einfach nur für den Arsch wenn die disks nach ein paar Monaten oder Jahren auf die volle Größe anwachsen und ich beim shrink mindestens den belegten Platz kurzzeitig doppelt brauche und es damit das storage mittelfristig zerreißt
Und für SSD darunter ist das auch tödlich
Unter Windows heisst das Teil gleich nur ohne Bindestriche
Wobei es schlauer wäre wenn diese Idioten alle endlich mal trim support und ein vernünftiges reuse implementieren würden damit die disks gar nicht erst wachsen
Setzt natürlich eine virtualisierte SSD am virtualisierten AHCI oder SCSI-Anschluss voraus und ein virtualisiertes Betriebssystem, welches TRIM unterstützt. Da ich Zuhause nur Uralt-Zeugs virtualisiere, nützt es mir nichts.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Okt 2017 um 01:40.
Es gibt Tools wie z.B. das "zerofree" (wenn man ext2-4 nutzt), was die Partition wirklich säubert und keine neuen Dateien im Dateibaum anlegt.
Selbst ein rm -rf /mnt/temp würde im Verzeichnistree des Dateissystems einen neuen Eintrag generieren.
Dazu kann man mehr bei ted t'so nachlesen.
Auch würde ich im Vorfeld mittels tune2fs (bei ext2-4) den Sicherheitsbereich für das Betriebssystem (ca 2-5% per Default) erstmal auf 0 setzen, damit auch der Inhalt des Sicherheitsbereichs "genullt" wird (selbst mittels dd). Wenn ext2-4 z.B. 5% des Dateissystems für Sicherheitssachen des Betriebssystems reserviert (z.B. wenn die Festplatte voll ist, so stellt ext2-4 sicher, dass noch eine Reserve auf der Platte vorhanden ist, damit das Betriebssystem weiterhin funktionsfähig bleibt), dann sind diese 5% von z.B. 20gb oder 100gb virtuellem Speicherplatz dennoch eine große Hausnummer, die auch "genullt" werden möchte, da auf dem freien Bereich auch noch "alte" Daten vorhanden sind.
Ähnlich verhält es sich mit anderen Dateisystemen...
In grub2 per "c" oder "e" in die Kommandozeile gehen.
Dort sieht du dann die Zeile des zu bootenden Kernels.
Dort (sofern systemd benutzt wird) schreibst du am Ende noch "emergency" und das "rw" (falls rw drinne steht) noch in "ro" umwandeln (oder hinzufügen).
Danach bootet das System im "emergency" mode und "readonly". Dort kannst du dann das zerofree auf / anwenden.
Dem System passiert nix dabei, da nichts auf die Platte geschrieben wird. Du hast das System nur ro gemounted...
Ich habe hier bei mir einen automatischen Prozess (Bash Script) geschrieben, welches mir jede Nacht automatisch so das System auf "quasi factory" zurücksetzt und den ganzen Müll auf meiner Festplatte (nebst swap) löscht...
Läuft seit Jahren jede Nacht und schaltet den Rechner nach vollendeter Arbeit automatisch aus.
Du darfst es natürlich auf euren Systemen so machen, wie ihr das für euch verantworten mögt und wie auch die Prozesse z.B. in eurem Unternehmen es verlangen...
Mein Weg ist sicherlich nicht der Beste weg... Ich wollte nur beschreiben, worauf man vielleicht noch so achten sollte.
Es steht aber jedem selbst frei, wie er/sie das verantworten möchte...
Nur möchte ich keinen Quellcode auf solchen Systemen kopieren, kompilieren und deployen... Danach den Quellcode löschen, aber vergessen, dass die Pads auf der Platte sehrwohl noch Teile des Codes enthalten könnten... Selbst bei einem "shrink" oder "dd", weil hat 1 Byte einen vollen Block sperrt und die restlichen 4095 Bytes Teile des Codes beinhalten oder Passwörter, Schriftverkehr oder sonstiges..
Kommt aber auch auf die Anforderungen an und wo man arbeitet... Wenn es z.B. um VS-NFD oder VS-Vertrauliche Daten handelt... Dann sollte man "penetrant" sein
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 22:24 #
Was für ein Unsinn - Wenn es um vertrauliche Daten geht ist Verschlüsselung dein Freund und dann hat es sich mit thin provisioning und shrinking sowieso ja du kannst noch nichtmal die vdisks auf 2 GB Segmente aufteilen lassen, tut einfach nix wenn LUKS unter dem Dateisystem sitzt (Und ja das splitten macht gerade im Kontext shrinking extrem Sinn weil du temporär niemals mehr als 2 GB brauchst anstatt minimum den belegten Platz der virtuellen disk)
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 22:25 #
Was für ein Unsinn - Wenn es um vertrauliche Daten geht ist Verschlüsselung dein Freund und dann hat es sich mit thin provisioning und shrinking sowieso ja du kannst noch nichtmal die vdisks auf 2 GB Segmente aufteilen lassen, tut einfach nix wenn LUKS unter dem Dateisystem sitzt (Und ja das splitten macht gerade im Kontext shrinking extrem Sinn weil du temporär niemals mehr als 2 GB brauchst anstatt minimum den belegten Platz der virtuellen disk)
Nunja, die Vorgaben, wie man beim Kunden die Systemintegration betreibt, sind meistens vertraglich festgehalten. Da kommt man nicht einfach so mit Verschlüsselung an (wenn der Kunde das aus Gründen nicht haben will oder braucht).
Es geht mir eher um folgendes:
Ein IT-Beratungshaus bekommt einen Auftrag vom Kunden. Es soll eine Systemintegration mit MOTS Produkten auf Linux und Windows Servern/Clients durchgeführt und vernetzt werden.
Die Systeme sollen auf einem ESX Server laufen und untereinander interoperieren.
Zunächst soll ein Prototyp aufgesetzt werden (beim Beratungshaus). Nachdem der Prototyp läuft, findet eine Besichtigung seitens des Kunden statt, so dass das System begutachtet und abgenommen werden kann.
Danach wird das System beim Kunden implementiert. Hardware installiert, Betriebssysteme aufgespielt und die notwendige Software aufgespielt und ggf. Eigenentwicklungen (Programmierte Software) deployed werden.
So!
Normalerweise spielt man das alles im Beratungshaus auf... Hat seine virtuellen Maschinen auf einem USB-Stick oder Festplatte griffbereit... Macht Termin beim Kunden aus... Installiert das Ganze... Macht Funktionstests... Die QS kommt und nimmt die Anforderungen ab... Der Kunde kommt und geht die Anforderungen nochmals mit dem QS und dem PM durch und nimmt das Projekt letztendlich ab.
Best Case!
So... dann möchte ich natürlich nicht, dass auf den virtuellen Maschinen allerhand Müll vorhanden ist, was während der Installation so passiert..
Source Code den ich vielleicht vorher auf der VM übersetzen und installieren musste... Konfigurationsdateien und ggf. betriebsinterne Skripte die ich darauf laufen lasse..
Ich möchte das System "sauberst" an den Kunden übergeben, so dass der Kunde immer wieder auf die "Ursprungs VM" zurückgreifen kann, sollte mal was den Bach herunter gehen.
Da will ich schon, dass das System den sauberst möglichen Zustand hat.
Eine Verschlüsselung ist sicherlich interessant, hängt aber sehr stark von den Anforderungen des Kunden ab. Du kannst z.B. nicht überall irgendwelche Linuxinternen Verschlüsselungen benutzen, wenn die Anforderungen eine BSI Zertifizierung voraussetzen. Oder das Umfeld so "speziell" ist, dass es halt nicht anders geht.
Auch wenn du verschlüsselst, dann hat der Kunde die VM ohnehin und kann sie wieder entschlüsseln (weil er sie nutzen muss), mit einer entschlüsselten Partition kannste dann mittels
dd if=/dev/mapper/irgendwas | grep -A "Suchkriterium"
Oder indem du das Entschlüsselte auf eine andere Festplatte als Datei pipest, auch auf Fragmente der Altdaten zugreifen und wiederfinden.
Also...
Unsinn ist hier fehl am Platze! Es kommt immer auf die Anforderungen des Kunden an.
Denk daran, in der Wirtschaft arbeitet man für den Kunden. Du kannst ihm eine Verschlüsselung vorschlagen... Nur wenn der Kunde sie nicht haben will bzw. bezahlen möchte, dann ist es eben so. Du setzt halt den Vertrag und die darin festgehaltenen Anforderungen um und lässt dir das Endprodukt vom ihm abnehmen und bezahlen.
Es geht allerdings viel mehr um das "Reinemachen" einer VM. Auf deinem Rechner kannste machen, wie du möchtest. In eurer eigenen Netzwerkumgebung auch... Wenn du eine VM an den Kunden auslieferst, sollte die schon recht sauber sein.
Wie ein sauberes Live-System...
Aber wir scheinen da aus unterschiedlichen Branchen zu kommen, wo die Anforderungen sicherlich unterschiedlich sind.
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 23:17 #
Dein Problem ist eine schlichte Themenverfehlung!
Es geht hier um das Problem "wie bekomme ich eine virtuelle disk wieder verkleinert" und du kommst mit "Wie werde ich Daten restlos los" und gibst dazu auch noch die falschen Antworten weil alles was du da im Gast veranstaltest keine garantierte Auswirkung auf die Blöcke am Host hat
Alles was du da beschreibst gehört am Host erledigt nachdem die Entwicklungs-VM gelöscht wurde und auf moderner Hardware ist dein HOSTFILESYSTEM verschlüsselt ohne impact auf die Performance
Nachdem du die VM gelöscht hast nullst du den freien Platz am Host und wenn es wirklich ganz sicher sein soll schmeisst du den Key für die Partition weg und legst sie neu an, fertig, kein weg jemals auch nur an ein einzelnes Byte daten zu kommen
Das im Gast zu machen oder gar das gleiche Gastsystem für einen anderen Kunden weiter zu benutzen und zu versuchen alle Spuren loszuwerden ist einfach nur saudumm, dazu gibt's den Goldenmaster der Softwaretechnisch aktuell gehalten wird aber niemals Datenschutz relevante Daten enthält - Problem gelöst weil es erst gar nicht entsteht
Schon einmal darüber nachgedacht, dass ein anderer Leser meinen Beitrag für durchaus interessant halten könnte ?
Es gibt noch mehr Leute, die die Kommentare lesen und vielleicht das eine oder andere Interessante hieraus ableiten möchten.
Der Beitrag setzt nämlich genau an Punkt 2) dieses Artikels an.
In diesem Kontext sollte man sich ggf. nochmal mit Sparse Files auseinandersetzen bevor man zu Methoden wie dd greift... Wäre aber wieder ein anderes Thema. Ich möchte damit jetzt nicht Leute überfordern, die nicht wissen wie man eine VM / in ro mountet, um dann mit zerodisk drauf zuzugreifen...
Ich schlage vor, du akzeptierst einfach mal einen Userbeitrag in den Kommentaren als gegeben. Für dich mag das alles ok sein... Ein anderer User mag sicherlich noch etwas davon gebrauchen können.
Soll heissen: Wir beide sind hier nicht alleine auf Pro-Linux.de
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 23:24 #
Und wenn du Sourcecode auf der produktiv VM kompiliert hast bist du sowieso ein Trottel, die hat gar niemals einen Compiler zu sehen und demzufolge auch keine sources, dafür gibt es Build Maschinen und Paketverwaltungen
Ich arbeite jetzt 15 Jahren in der Branche aber auf die saudumme Idee Sourcecode oder compiler mit mit einer produktiv Maschine in Berührung zu bringen ist hier noch keiner gekommen
Es war ein Beispiel! Ein "Erklärungsansatz", damit der normale Mensch kapiert was auf der Festplatte noch so an Daten "herumgeistern" können oder könnten.
Nur weil du gelernt hast in den VMWare Produkten einen Button zu drücken, was dir deine VM verkleinert, so heisst es noch lange nicht, dass man sie nicht noch "kleiner" bekäme, wenn man etwas mehr Sorgfalt pflegt.
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 23:52 #
WTF - Logisch dass alles was du an Daten wegbekommst den shrink effizienter macht, erzähl mir was neues, ich fahre hier je nach use case production VM's die nur ein paar hundert MB gross sind
Zerofree oder nullen macht im Kontext deines "wuuu da könnten noch wo Blöcke mit Daten sein" keinerlei Unterschied, auch nicht im Kontext ehemals belegter 4k Block mit physischen Restdaten
der einzige Unterschied zu dd ist dass die disk temporär nicht auf die volle Größe anwächst und das war es dann auch schon
Von verfl...WTF.etc. am Fr, 20. Oktober 2017 um 09:55 #
Ich hoffe es liegt nicht an VMWare, dass man sich eine solche Sprache angewöhnt. Falls doch, werde ich VMWare meiden müssen, denn so will ich nicht werden ...
Das etwas bessere Vorgehen (was auch komplexer ist).
1) Man erstellt sich in der /etc/grub.d einen Eintrag, wo das eigene System als "Emergency" und "read only" gebootet wird.
2) Man bootet genau das System und lässt das eigene System sich selbst aufräumen.
3) Ich würde kurzzeitig evtl. in rw mounten (in einer Bash Datei), um folgendes durchzuführen:
unmount swap dd auf die swap partition neue swap anlegen (falls swap vorhanden) nicht erneut swap mounten journalctl das journal auf 1 tag löschen und compacten das gesamte /var aufräumen und mit dem Bash Script das automatisieren (also das Aufräumen) dnf clean all (respective apt-get clean all oder wie auch immer) tune2fs den Sicherheitsbereich auf 0% setzen e2defrag / mount ro zerofree -v /dev/sda1 (also sich selbst) tune2fs den Sicherheitsbereich wieder auf 2% shutdown -h now
Zum Sicherheitsbereich!
Wenn ihr eine Partition von 100gb habt, dann sichert sich ext4 einen Sicherheitsbereich für das Sysem von ca 2-5%.. Gehen wir von 5% bei 100gb aus, dann sind das 5gb... Diese 5gb könnten ggf. auch recht viel Müll enthalten, was man auch löschen sollte. Swap, sofern vorhanden sollte man auch löschen!
Allerdings: Auch wenn diese Methode sehr "sauber" ist, so ist sie es noch lange nicht!
Es gibt auf der Platte auch noch die Pads zwischen den Blöcken!
Sagen wir, das 1 Block 4096 Bytes belegt. Durch das hin- und herkopieren werden die Blöcke beschrieben, gelöscht, gemoved, beschrieben usw..
Wenn nun eine 1 Byte Datei einen neuen Block von 4096 Bytes belegt, dann sind dort noch 4095 Bytes frei (frei heisst aber nicht, dass diese Blöcke unbeschrieben sind... Dort sind noch Altdaten der Dateien zuvor drauf). z.B. wichtiger Code, Sources, oder Passwörter oder sontiges... Also Vorsicht, wenn ihr virtuelle Maschinen an Kunden ausliefert...
Es gibt noch so ein tool Namens "Wipedisk", was unter Linux diese "Pads" auch noch mit "Nullen" füllt. Allerdings habe ich mit dem Tool keine guten Erfahrungen machen können.
Erst, nach dem Shutdown (wenn das System runterfährt), könnt ihr mit dem vmwaretool die Partition shrinken... Das holt nochmals richtig was aus dem System heraus.
Cache wie Firefox, Chrome usw... kann man auch löschen... Man muss dem Kunden ja nicht noch mehr liefern als nötig.
Allerdings wende ich gelegentlich die dd Methode auch an... Sie ist zwar nicht 100% aber reicht in vielen Fällen auch aus... Man muss halt nur wissen was man braucht und auch sein System und seine Bedürfnisse kennen...
Was das /var Verzeichnis betrifft. Da kann u.U. auch noch sehr viel Müll drinne sein. Alte fontcache Dateien, riesige journalctl Logs, alte mandb die erstellt wurden, alte packete, die man für ein Update heruntergeladen hat (und die noch irgendwo im var herumgeistern). coredump Dateien usw...
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 22:56 #
Boah es geht hier aber nicht um wipedisk und Voodoo um Daten restlos loszuwerden sondern darum eine fucking thin provisioned disk die mit der Zeit leider weit über die Grösse des benutzten Bereichs wächst wieder klein zu bekommen
Für alles andere ist Verschlüsselung dein Freund und thin provisioning / korrekt initialisierter LUKS Layer schliessen sich prinzipbedingt aus
Du... ich wollte mich mit dir nicht streiten oder die Schwanzlänge messen. Ich habe nur einen Beitrag leisten wollen, worauf man ggf. noch achten sollte. Wenn du meinst du bist der Größte... Auch gut...
1. Root darf in den Sicherheitsbereich schreiben, deshalb kannst du dir die Umstellung sparen.
2. Das Anlegen eines Eintrags im Dateibaum durch dd ist bei den Datenmengen um die es hier geht eher irrelevant und deshalb vernachlässigbar.
3. Stimmt es trotzdem, dass man die dd-Methode auf einem Produktivsystem tunlichst nicht anwenden sollte, da es den Einsatz einer Brechstange gleichkommt und man sich über Folgeschäden nicht wundern braucht. Der Grund ist aber ein anderer:
Zwischen der Ausführung des dd-Befehls und der Ausführung von rm sind nämlich tatsächlich 0 Bytes auf dem Dateisystem frei und ein Sicherheitsbereich ist keiner mehr vorhanden (wenn dd als root ausgeführt wurde oder wie von dir empfohlen der Sicherheitsbereich auf 0 gesetzt wurde). Der Sicherheitsbereich ist aber nicht zum Spaß da sondern trägt essenziell zur Systemstabilität bei.
Jeder Prozess welcher genau in dem Moment etwas wegschreiben will, fällt nämlich nun auf die Nase. Datenverlust und Dateninkonsistenz sind die Folge. Viel Spaß bei der anschließenden Fehlersuche.
Wenn man also sowieso in den Single User Mode booten muss um diese Gefahr zu bannen, kann man auch gleich einen ro-Mount durchführen und das vorgeschlagene zerofree nutzen.
4. (Keine direkte Antwort zu deinem Kommentar) Die -z Option (Clean free space) bei sdelete.exe bringt nicht das gewünschte Ergebnis, stattdessen sollte -c (Zero free space (good for virtual disk optimization)) genutzt werden.
Von Verfluchtnochmal am Fr, 20. Oktober 2017 um 21:29 #
Ach Gott gib doch einfach sdelete ohne Parameter ein dann siehst du bei -z den Hinweis dass genau das die Option zum Nullen ist inkl Hinweis auf Optimierung für virtuelle Disks
-z Clean free space -s Recurse subdirectories -q Don't print errors (Quiet) -p passes Specifies number of overwrite passes (default is 1) -c Zero free space (good for virtual disk optimization)
Falls Microsoft verschiedene Versionen in Umlauf gebraucht haben sollte, dann ist das nicht meine Schuld.
Von Verfluchtnochmal am Fr, 20. Oktober 2017 um 21:55 #
Ich aktualisiere triviale Teile wie sdelete nicht sooooo oft aber nachdem ich doch hin und wieder irgendeine Windows VM anwerfe bzw im Büro einige für Browser Tests shared laufen hab ich mir -z mittlerweile tatsächlich gemerkt - Auf ESXi geht leider vmwaretoolscmd. exe disk shrink nicht aber das nullen nach upgrades hält zumindest dedup backups des clusters schön klein
Ich habe mir hingegen -c gemerkt, da -z nicht funktioniert hatte und dies deshalb noch in sehr guter Erinnerung.
Auf die Idee muss man erst mal kommen, von einer auf die andere Version die Kommandooptionen inkompatibel zu ändern. Diesen Unsinn muss ich jetzt gleich in meiner shrink-windows-guest.bat dokumentieren.
Bei Version 1.51 war es genau umgekehrt, siehe Link zum Sysinternals-Forum oben. Die aktuelle Version 2.0 geht zudem nicht mit alten Windows-Installationen und bei aktuellen Installationen kann man sich den Aufwand Dank SSD-TRIM ohnehin sparen.
Setzt natürlich eine virtualisierte SSD am virtualisierten AHCI oder SCSI-Anschluss voraus und ein virtualisiertes Betriebssystem, welches TRIM unterstützt. Nichts für den Uralt-Kram den ich Zuhause virtualisiere, aber wer aktuelle Systeme virtualisiert, sollte es nutzen können.
Von einem aufmerksamen Leser am Mi, 25. September 2019 um 10:56 #
Ich nutze eine VM mit dynamischer Festplatte und Linux als Gast und Host. Deswegen kommt für mich nur der Weg mit dd in Frage. Ist mir auch einleuchtend wie das funktionieren soll.
Das Problem: Die Maximalgröße wurde beim Aufsetzen der VM großzügig definiert, durch eine unerwartete Aktion wurde temporär viel dieser Größe tatsächlich genutzt, aber jetzt nicht mehr gebraucht. Deswegen sollte die Größe geschrumpft werden. Der dd Befehl erzeugt eine Datei (muss nicht in /mnt sein, da dies nur root dürfte) und schreibt die Platte voll. Abbrechen wird er aber erst, wenn die ursprünglich definierte Größe erreicht ist. Mit dieser Aktion wird also temporär der volle!!! Plattenplatz benötigt (ansonsten ist ja nicht sichergestellt, dass die nicht verwendeten Bereiche auch überschrieben werden!). Dies sollte man bedenken. Ich musste die vdi-Datei dafür auf einen anderen Mountpoint schieben, weil am Originalplatz (SSD) mittlerweile die Kapazität gar nicht mehr zur Verfügung steht (Host nutzt diese zwischenzeitlich anderweitig). Unter Linux lässt sich die verschobene vdi-Datei aber auch ohne Anpassung der VM mittels eines symbolischen Links verwenden.
Ansonsten Danke für die Anleitung
PS: Unter Linux lautet der eigentliche Befehl zum Komprimieren mit VM eigenen Mitteln mittlerweile leicht anders: VBoxManage modifymedium disk VMDatei.vdi --compact VBoxManage showmediuminfo disk VMDatei.vdi
Aber diese Info findet man leicht, wenn man einfach den VBoxManage Befehl ohne Parameter mal absetzt
vmware-toolbox-cmd disk shrink /
Einfach aus dem Gast heraus, freie Bereiche werden genullt, danach automatisch die vdisk in einem Tempfile neu generiert und danach ist der Gast automatisch wieder online
Wobei es schlauer wäre wenn diese Idioten alle endlich mal trim support und ein vernünftiges reuse implementieren würden damit die disks gar nicht erst wachsen weil so ist thin provisioning einfach nur für den Arsch wenn die disks nach ein paar Monaten oder Jahren auf die volle Größe anwachsen und ich beim shrink mindestens den belegten Platz kurzzeitig doppelt brauche und es damit das storage mittelfristig zerreißt
Und für SSD darunter ist das auch tödlich
Unter Windows heisst das Teil gleich nur ohne Bindestriche
VirtualBox kann das wohl auch: https://superuser.com/questions/646559/virtualbox-and-ssds-trim-command-support
Setzt natürlich eine virtualisierte SSD am virtualisierten AHCI oder SCSI-Anschluss voraus und ein virtualisiertes Betriebssystem, welches TRIM unterstützt. Da ich Zuhause nur Uralt-Zeugs virtualisiere, nützt es mir nichts.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Okt 2017 um 01:40.Die Variante mit "dd" sollte man nicht machen!
Es gibt Tools wie z.B. das "zerofree" (wenn man ext2-4 nutzt), was die Partition wirklich säubert und keine neuen Dateien im Dateibaum anlegt.
Selbst ein rm -rf /mnt/temp würde im Verzeichnistree des Dateissystems einen neuen Eintrag generieren.
Dazu kann man mehr bei ted t'so nachlesen.
Auch würde ich im Vorfeld mittels tune2fs (bei ext2-4) den Sicherheitsbereich für das Betriebssystem (ca 2-5% per Default) erstmal auf 0 setzen, damit auch der Inhalt des Sicherheitsbereichs "genullt" wird (selbst mittels dd). Wenn ext2-4 z.B. 5% des Dateissystems für Sicherheitssachen des Betriebssystems reserviert (z.B. wenn die Festplatte voll ist, so stellt ext2-4 sicher, dass noch eine Reserve auf der Platte vorhanden ist, damit das Betriebssystem weiterhin funktionsfähig bleibt), dann sind diese 5% von z.B. 20gb oder 100gb virtuellem Speicherplatz dennoch eine große Hausnummer, die auch "genullt" werden möchte, da auf dem freien Bereich auch noch "alte" Daten vorhanden sind.
Ähnlich verhält es sich mit anderen Dateisystemen...
Bblöderweise musst du für zerofree das Filesystem unmounten, zeig mal wie du das mit / machen willst
Du musst das system nur ro mounten!
In grub2 per "c" oder "e" in die Kommandozeile gehen.
Dort sieht du dann die Zeile des zu bootenden Kernels.
Dort (sofern systemd benutzt wird) schreibst du am Ende noch "emergency" und das "rw" (falls rw drinne steht) noch in "ro" umwandeln (oder hinzufügen).
Danach bootet das System im "emergency" mode und "readonly". Dort kannst du dann das zerofree auf / anwenden.
Dem System passiert nix dabei, da nichts auf die Platte geschrieben wird. Du hast das System nur ro gemounted...
Ich habe hier bei mir einen automatischen Prozess (Bash Script) geschrieben, welches mir jede Nacht automatisch so das System auf "quasi factory" zurücksetzt und den ganzen Müll auf meiner Festplatte (nebst swap) löscht...
Läuft seit Jahren jede Nacht und schaltet den Rechner nach vollendeter Arbeit automatisch aus.
Kosten/Nutzen, wozu all den Aufwand wenn ich bei VMware mit einem simplen Befehl das alles ohne Shutdown oder Reboot auf einmal erledigen kann
Tut auch nichts anderes als erstmal nullen
Und ja ich habe hier VM's mit dutzenden Dist-Upgrades und hunderten shrinks die seit 10 Jahren problemlos ihren Dienst tun
Du darfst es natürlich auf euren Systemen so machen, wie ihr das für euch verantworten mögt und wie auch die Prozesse z.B. in eurem Unternehmen es verlangen...
Mein Weg ist sicherlich nicht der Beste weg... Ich wollte nur beschreiben, worauf man vielleicht noch so achten sollte.
Es steht aber jedem selbst frei, wie er/sie das verantworten möchte...
Nur möchte ich keinen Quellcode auf solchen Systemen kopieren, kompilieren und deployen... Danach den Quellcode löschen, aber vergessen, dass die Pads auf der Platte sehrwohl noch Teile des Codes enthalten könnten... Selbst bei einem "shrink" oder "dd", weil hat 1 Byte einen vollen Block sperrt und die restlichen 4095 Bytes Teile des Codes beinhalten oder Passwörter, Schriftverkehr oder sonstiges..
Kommt aber auch auf die Anforderungen an und wo man arbeitet... Wenn es z.B. um VS-NFD oder VS-Vertrauliche Daten handelt... Dann sollte man "penetrant" sein
Was für ein Unsinn - Wenn es um vertrauliche Daten geht ist Verschlüsselung dein Freund und dann hat es sich mit thin provisioning und shrinking sowieso ja du kannst noch nichtmal die vdisks auf 2 GB Segmente aufteilen lassen, tut einfach nix wenn LUKS unter dem Dateisystem sitzt (Und ja das splitten macht gerade im Kontext shrinking extrem Sinn weil du temporär niemals mehr als 2 GB brauchst anstatt minimum den belegten Platz der virtuellen disk)
Was für ein Unsinn - Wenn es um vertrauliche Daten geht ist Verschlüsselung dein Freund und dann hat es sich mit thin provisioning und shrinking sowieso ja du kannst noch nichtmal die vdisks auf 2 GB Segmente aufteilen lassen, tut einfach nix wenn LUKS unter dem Dateisystem sitzt (Und ja das splitten macht gerade im Kontext shrinking extrem Sinn weil du temporär niemals mehr als 2 GB brauchst anstatt minimum den belegten Platz der virtuellen disk)
Nunja, die Vorgaben, wie man beim Kunden die Systemintegration betreibt, sind meistens vertraglich festgehalten. Da kommt man nicht einfach so mit Verschlüsselung an (wenn der Kunde das aus Gründen nicht haben will oder braucht).
Es geht mir eher um folgendes:
Ein IT-Beratungshaus bekommt einen Auftrag vom Kunden. Es soll eine Systemintegration mit MOTS Produkten auf Linux und Windows Servern/Clients durchgeführt und vernetzt werden.
Die Systeme sollen auf einem ESX Server laufen und untereinander interoperieren.
Zunächst soll ein Prototyp aufgesetzt werden (beim Beratungshaus). Nachdem der Prototyp läuft, findet eine Besichtigung seitens des Kunden statt, so dass das System begutachtet und abgenommen werden kann.
Danach wird das System beim Kunden implementiert. Hardware installiert, Betriebssysteme aufgespielt und die notwendige Software aufgespielt und ggf. Eigenentwicklungen (Programmierte Software) deployed werden.
So!
Normalerweise spielt man das alles im Beratungshaus auf... Hat seine virtuellen Maschinen auf einem USB-Stick oder Festplatte griffbereit... Macht Termin beim Kunden aus... Installiert das Ganze... Macht Funktionstests... Die QS kommt und nimmt die Anforderungen ab... Der Kunde kommt und geht die Anforderungen nochmals mit dem QS und dem PM durch und nimmt das Projekt letztendlich ab.
Best Case!
So... dann möchte ich natürlich nicht, dass auf den virtuellen Maschinen allerhand Müll vorhanden ist, was während der Installation so passiert..
Source Code den ich vielleicht vorher auf der VM übersetzen und installieren musste... Konfigurationsdateien und ggf. betriebsinterne Skripte die ich darauf laufen lasse..
Ich möchte das System "sauberst" an den Kunden übergeben, so dass der Kunde immer wieder auf die "Ursprungs VM" zurückgreifen kann, sollte mal was den Bach herunter gehen.
Da will ich schon, dass das System den sauberst möglichen Zustand hat.
Eine Verschlüsselung ist sicherlich interessant, hängt aber sehr stark von den Anforderungen des Kunden ab. Du kannst z.B. nicht überall irgendwelche Linuxinternen Verschlüsselungen benutzen, wenn die Anforderungen eine BSI Zertifizierung voraussetzen. Oder das Umfeld so "speziell" ist, dass es halt nicht anders geht.
Auch wenn du verschlüsselst, dann hat der Kunde die VM ohnehin und kann sie wieder entschlüsseln (weil er sie nutzen muss), mit einer entschlüsselten Partition kannste dann mittels
dd if=/dev/mapper/irgendwas | grep -A "Suchkriterium"
Oder indem du das Entschlüsselte auf eine andere Festplatte als Datei pipest, auch auf Fragmente der Altdaten zugreifen und wiederfinden.
Also...
Unsinn ist hier fehl am Platze! Es kommt immer auf die Anforderungen des Kunden an.
Denk daran, in der Wirtschaft arbeitet man für den Kunden. Du kannst ihm eine Verschlüsselung vorschlagen... Nur wenn der Kunde sie nicht haben will bzw. bezahlen möchte, dann ist es eben so. Du setzt halt den Vertrag und die darin festgehaltenen Anforderungen um und lässt dir das Endprodukt vom ihm abnehmen und bezahlen.
Es geht allerdings viel mehr um das "Reinemachen" einer VM. Auf deinem Rechner kannste machen, wie du möchtest. In eurer eigenen Netzwerkumgebung auch... Wenn du eine VM an den Kunden auslieferst, sollte die schon recht sauber sein.
Wie ein sauberes Live-System...
Aber wir scheinen da aus unterschiedlichen Branchen zu kommen, wo die Anforderungen sicherlich unterschiedlich sind.
Dein Problem ist eine schlichte Themenverfehlung!
Es geht hier um das Problem "wie bekomme ich eine virtuelle disk wieder verkleinert" und du kommst mit "Wie werde ich Daten restlos los" und gibst dazu auch noch die falschen Antworten weil alles was du da im Gast veranstaltest keine garantierte Auswirkung auf die Blöcke am Host hat
Alles was du da beschreibst gehört am Host erledigt nachdem die Entwicklungs-VM gelöscht wurde und auf moderner Hardware ist dein HOSTFILESYSTEM verschlüsselt ohne impact auf die Performance
Nachdem du die VM gelöscht hast nullst du den freien Platz am Host und wenn es wirklich ganz sicher sein soll schmeisst du den Key für die Partition weg und legst sie neu an, fertig, kein weg jemals auch nur an ein einzelnes Byte daten zu kommen
Das im Gast zu machen oder gar das gleiche Gastsystem für einen anderen Kunden weiter zu benutzen und zu versuchen alle Spuren loszuwerden ist einfach nur saudumm, dazu gibt's den Goldenmaster der Softwaretechnisch aktuell gehalten wird aber niemals Datenschutz relevante Daten enthält - Problem gelöst weil es erst gar nicht entsteht
ABER NOCHMAL: Themenverfehlung, Setzen, 6
Schon einmal darüber nachgedacht, dass ein anderer Leser meinen Beitrag für durchaus interessant halten könnte ?
Es gibt noch mehr Leute, die die Kommentare lesen und vielleicht das eine oder andere Interessante hieraus ableiten möchten.
Der Beitrag setzt nämlich genau an Punkt 2) dieses Artikels an.
In diesem Kontext sollte man sich ggf. nochmal mit Sparse Files auseinandersetzen bevor man zu Methoden wie dd greift... Wäre aber wieder ein anderes Thema. Ich möchte damit jetzt nicht Leute überfordern, die nicht wissen wie man eine VM / in ro mountet, um dann mit zerodisk drauf zuzugreifen...
Ich schlage vor, du akzeptierst einfach mal einen Userbeitrag in den Kommentaren als gegeben. Für dich mag das alles ok sein... Ein anderer User mag sicherlich noch etwas davon gebrauchen können.
Soll heissen: Wir beide sind hier nicht alleine auf Pro-Linux.de
Und wenn du Sourcecode auf der produktiv VM kompiliert hast bist du sowieso ein Trottel, die hat gar niemals einen Compiler zu sehen und demzufolge auch keine sources, dafür gibt es Build Maschinen und Paketverwaltungen
Ich arbeite jetzt 15 Jahren in der Branche aber auf die saudumme Idee Sourcecode oder compiler mit mit einer produktiv Maschine in Berührung zu bringen ist hier noch keiner gekommen
... du kapierst es nicht!
Es war ein Beispiel! Ein "Erklärungsansatz", damit der normale Mensch kapiert was auf der Festplatte noch so an Daten "herumgeistern" können oder könnten.
Nur weil du gelernt hast in den VMWare Produkten einen Button zu drücken, was dir deine VM verkleinert, so heisst es noch lange nicht, dass man sie nicht noch "kleiner" bekäme, wenn man etwas mehr Sorgfalt pflegt.
WTF - Logisch dass alles was du an Daten wegbekommst den shrink effizienter macht, erzähl mir was neues, ich fahre hier je nach use case production VM's die nur ein paar hundert MB gross sind
Zerofree oder nullen macht im Kontext deines "wuuu da könnten noch wo Blöcke mit Daten sein" keinerlei Unterschied, auch nicht im Kontext ehemals belegter 4k Block mit physischen Restdaten
der einzige Unterschied zu dd ist dass die disk temporär nicht auf die volle Größe anwächst und das war es dann auch schon
Ich hoffe es liegt nicht an VMWare, dass man sich eine solche Sprache angewöhnt. Falls doch, werde ich VMWare meiden müssen, denn so will ich nicht werden ...
> Ich arbeite jetzt 15 Jahren in der Branche
Dann sollte man aber solche Fragen wie das unmounten von / oder in ro re-mounten im Zusammenhang mit zerodisk nicht stellen bzw. nicht *mehr* stellen.
Das etwas bessere Vorgehen (was auch komplexer ist).
1) Man erstellt sich in der /etc/grub.d einen Eintrag, wo das eigene System als "Emergency" und "read only" gebootet wird.
2) Man bootet genau das System und lässt das eigene System sich selbst aufräumen.
3) Ich würde kurzzeitig evtl. in rw mounten (in einer Bash Datei), um folgendes durchzuführen:
unmount swap
dd auf die swap partition
neue swap anlegen (falls swap vorhanden)
nicht erneut swap mounten
journalctl das journal auf 1 tag löschen und compacten
das gesamte /var aufräumen und mit dem Bash Script das automatisieren (also das Aufräumen)
dnf clean all (respective apt-get clean all oder wie auch immer)
tune2fs den Sicherheitsbereich auf 0% setzen
e2defrag /
mount ro
zerofree -v /dev/sda1 (also sich selbst)
tune2fs den Sicherheitsbereich wieder auf 2%
shutdown -h now
Zum Sicherheitsbereich!
Wenn ihr eine Partition von 100gb habt, dann sichert sich ext4 einen Sicherheitsbereich für das Sysem von ca 2-5%.. Gehen wir von 5% bei 100gb aus, dann sind das 5gb... Diese 5gb könnten ggf. auch recht viel Müll enthalten, was man auch löschen sollte. Swap, sofern vorhanden sollte man auch löschen!
Allerdings: Auch wenn diese Methode sehr "sauber" ist, so ist sie es noch lange nicht!
Es gibt auf der Platte auch noch die Pads zwischen den Blöcken!
Sagen wir, das 1 Block 4096 Bytes belegt. Durch das hin- und herkopieren werden die Blöcke beschrieben, gelöscht, gemoved, beschrieben usw..
Wenn nun eine 1 Byte Datei einen neuen Block von 4096 Bytes belegt, dann sind dort noch 4095 Bytes frei (frei heisst aber nicht, dass diese Blöcke unbeschrieben sind... Dort sind noch Altdaten der Dateien zuvor drauf). z.B. wichtiger Code, Sources, oder Passwörter oder sontiges... Also Vorsicht, wenn ihr virtuelle Maschinen an Kunden ausliefert...
Es gibt noch so ein tool Namens "Wipedisk", was unter Linux diese "Pads" auch noch mit "Nullen" füllt. Allerdings habe ich mit dem Tool keine guten Erfahrungen machen können.
Erst, nach dem Shutdown (wenn das System runterfährt), könnt ihr mit dem vmwaretool die Partition shrinken... Das holt nochmals richtig was aus dem System heraus.
Cache wie Firefox, Chrome usw... kann man auch löschen... Man muss dem Kunden ja nicht noch mehr liefern als nötig.
Allerdings wende ich gelegentlich die dd Methode auch an... Sie ist zwar nicht 100% aber reicht in vielen Fällen auch aus... Man muss halt nur wissen was man braucht und auch sein System und seine Bedürfnisse kennen...
Was das /var Verzeichnis betrifft. Da kann u.U. auch noch sehr viel Müll drinne sein. Alte fontcache Dateien, riesige journalctl Logs, alte mandb die erstellt wurden, alte packete, die man für ein Update heruntergeladen hat (und die noch irgendwo im var herumgeistern). coredump Dateien usw...
Boah es geht hier aber nicht um wipedisk und Voodoo um Daten restlos loszuwerden sondern darum eine fucking thin provisioned disk die mit der Zeit leider weit über die Grösse des benutzten Bereichs wächst wieder klein zu bekommen
Für alles andere ist Verschlüsselung dein Freund und thin provisioning / korrekt initialisierter LUKS Layer schliessen sich prinzipbedingt aus
Du... ich wollte mich mit dir nicht streiten oder die Schwanzlänge messen. Ich habe nur einen Beitrag leisten wollen, worauf man ggf. noch achten sollte. Wenn du meinst du bist der Größte... Auch gut...
Ein paar Anmerkungen meinerseits:
1. Root darf in den Sicherheitsbereich schreiben, deshalb kannst du dir die Umstellung sparen.
2. Das Anlegen eines Eintrags im Dateibaum durch dd ist bei den Datenmengen um die es hier geht eher irrelevant und deshalb vernachlässigbar.
3. Stimmt es trotzdem, dass man die dd-Methode auf einem Produktivsystem tunlichst nicht anwenden sollte, da es den Einsatz einer Brechstange gleichkommt und man sich über Folgeschäden nicht wundern braucht. Der Grund ist aber ein anderer:
Zwischen der Ausführung des dd-Befehls und der Ausführung von rm sind nämlich tatsächlich 0 Bytes auf dem Dateisystem frei und ein Sicherheitsbereich ist keiner mehr vorhanden (wenn dd als root ausgeführt wurde oder wie von dir empfohlen der Sicherheitsbereich auf 0 gesetzt wurde). Der Sicherheitsbereich ist aber nicht zum Spaß da sondern trägt essenziell zur Systemstabilität bei.
Jeder Prozess welcher genau in dem Moment etwas wegschreiben will, fällt nämlich nun auf die Nase. Datenverlust und Dateninkonsistenz sind die Folge. Viel Spaß bei der anschließenden Fehlersuche.
Wenn man also sowieso in den Single User Mode booten muss um diese Gefahr zu bannen, kann man auch gleich einen ro-Mount durchführen und das vorgeschlagene zerofree nutzen.
4. (Keine direkte Antwort zu deinem Kommentar) Die -z Option (Clean free space) bei sdelete.exe bringt nicht das gewünschte Ergebnis, stattdessen sollte -c (Zero free space (good for virtual disk optimization)) genutzt werden.
Ach Gott gib doch einfach sdelete ohne
Parameter ein dann siehst du bei
-z den Hinweis dass genau das die Option zum Nullen ist inkl Hinweis auf Optimierung für virtuelle Disks
-z Clean free space
-s Recurse subdirectories
-q Don't print errors (Quiet)
-p passes Specifies number of overwrite passes (default is 1)
-c Zero free space (good for virtual disk optimization)
Falls Microsoft verschiedene Versionen in Umlauf gebraucht haben sollte, dann ist das nicht meine Schuld.
Edit:
https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
Haha, die haben die Optionen tatsächlich zwischenzeitlich vertauscht, so etwas kann auch nur Microsoft bringen!
Da ist man verratzt und verkauft wenn man auf so einem System Scripte schreiben muss.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 20. Okt 2017 um 21:56.Edit: Kaum zu glauben, ist aber so: https://forum.sysinternals.com/sdelete-151-bug-switches-transposed_topic22830_post123388.html#123388
Ich aktualisiere triviale Teile wie sdelete nicht sooooo oft aber nachdem ich doch hin und wieder irgendeine Windows VM anwerfe bzw im Büro einige für Browser Tests shared laufen hab ich mir -z mittlerweile tatsächlich gemerkt - Auf ESXi geht leider vmwaretoolscmd. exe disk shrink nicht aber das nullen nach upgrades hält zumindest dedup backups des clusters schön klein
Ich habe mir hingegen -c gemerkt, da -z nicht funktioniert hatte und dies deshalb noch in sehr guter Erinnerung.
Auf die Idee muss man erst mal kommen, von einer auf die andere Version die Kommandooptionen inkompatibel zu ändern. Diesen Unsinn muss ich jetzt gleich in meiner shrink-windows-guest.bat dokumentieren.
SDelete - Secure Delete v1.6
Copyright (C) 1999-2010 Mark Russinovich
Sysinternals - www.sysinternals.com
usage: sdelete [-p passes] [-s] [-q] ...
sdelete [-p passes] [-z|-c] [drive letter] ...
-a Remove Read-Only attribute
-c Clean free space
-p passes Specifies number of overwrite passes (default is 1)
-q Don't print errors (Quiet)
-s or -r Recurse subdirectories
-z Zero free space (good for virtual disk optimization)
Bei Version 1.51 war es genau umgekehrt, siehe Link zum Sysinternals-Forum oben. Die aktuelle Version 2.0 geht zudem nicht mit alten Windows-Installationen und bei aktuellen Installationen kann man sich den Aufwand Dank SSD-TRIM ohnehin sparen.
Dürfte auch für reines KVM mit qcow2 gelten. Und das geht auch mit VMs in RBD-Geräten in einem Ceph.
In der VM:
fstrim -av
Fertig :).
So einfach kann das gehen.
Und so einfach dürfen das auch Virtualbox und VMware bitte irgendwann mal hinbekommen. Dafür ist Trimming ja da.
VirtualBox kann es wohl auch: https://superuser.com/questions/646559/virtualbox-and-ssds-trim-command-support
Setzt natürlich eine virtualisierte SSD am virtualisierten AHCI oder SCSI-Anschluss voraus und ein virtualisiertes Betriebssystem, welches TRIM unterstützt. Nichts für den Uralt-Kram den ich Zuhause virtualisiere, aber wer aktuelle Systeme virtualisiert, sollte es nutzen können.
Doppelpost gelöscht (zuerst kommt ein fataler Fehler und nach einem Reload ist der Eintrag zweimal da)
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Okt 2017 um 01:38.Für Windows Gäste ist folgendes der einfachste Weg:
Gast starten, Datenträgerbereinigung inkl. Systemdateien bereinigen mit Anklicken aller Optionen. Das schafft echt viel Platz.
Am Linux Host WINE installieren. Dann folgendes Programm downloaden:
https://forums.virtualbox.org/viewtopic.php?f=6&t=22422
CloneVDI am Host mit WINE starten. Source/Destination wählen (gleichen Dateinamen!).
Optionen "Keep old UUID"und "Compact drive while copying" anklicken und dann "Proceed".
Wer das einmal gewählt hat, macht das nie wieder anders. Dieser Weg ist dermaßen schnell, das ist bestimmt 10 mal schneller als der Weg über sdelete.
Ich nutze eine VM mit dynamischer Festplatte und Linux als Gast und Host. Deswegen kommt für mich nur der Weg mit dd in Frage. Ist mir auch einleuchtend wie das funktionieren soll.
Das Problem: Die Maximalgröße wurde beim Aufsetzen der VM großzügig definiert, durch eine unerwartete Aktion wurde temporär viel dieser Größe tatsächlich genutzt, aber jetzt nicht mehr gebraucht. Deswegen sollte die Größe geschrumpft werden. Der dd Befehl erzeugt eine Datei (muss nicht in /mnt sein, da dies nur root dürfte) und schreibt die Platte voll. Abbrechen wird er aber erst, wenn die ursprünglich definierte Größe erreicht ist. Mit dieser Aktion wird also temporär der volle!!! Plattenplatz benötigt (ansonsten ist ja nicht sichergestellt, dass die nicht verwendeten Bereiche auch überschrieben werden!). Dies sollte man bedenken. Ich musste die vdi-Datei dafür auf einen anderen Mountpoint schieben, weil am Originalplatz (SSD) mittlerweile die Kapazität gar nicht mehr zur Verfügung steht (Host nutzt diese zwischenzeitlich anderweitig). Unter Linux lässt sich die verschobene vdi-Datei aber auch ohne Anpassung der VM mittels eines symbolischen Links verwenden.
Ansonsten Danke für die Anleitung
PS: Unter Linux lautet der eigentliche Befehl zum Komprimieren mit VM eigenen Mitteln mittlerweile leicht anders:
VBoxManage modifymedium disk VMDatei.vdi --compact
VBoxManage showmediuminfo disk VMDatei.vdi
Aber diese Info findet man leicht, wenn man einfach den VBoxManage Befehl ohne Parameter mal absetzt