Login
Login-Name Passwort


 
Newsletter

Thema: VirtualBox-Abbilder verkleinern

17 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 20:43 #

Bblöderweise musst du für zerofree das Filesystem unmounten, zeig mal wie du das mit / machen willst

  • 0
    Von XYZ am Do, 19. Oktober 2017 um 20:52 #

    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.

    • 0
      Von Verfluchtnochmal am Do, 19. Oktober 2017 um 21:24 #

      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

      • 0
        Von XYZ am Do, 19. Oktober 2017 um 21:46 #

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

        • 0
          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)

          0
          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)

          • 0
            Von XYZ am Do, 19. Oktober 2017 um 22:58 #

            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.

            • 0
              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

              ABER NOCHMAL: Themenverfehlung, Setzen, 6

              • 0
                Von XYZ am Do, 19. Oktober 2017 um 23:34 #

                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

              0
              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

              • 0
                Von XYZ am Do, 19. Oktober 2017 um 23:37 #

                ... 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.

                • 0
                  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

                  • 1
                    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 ...

                0
                Von XYZ am Do, 19. Oktober 2017 um 23:40 #

                > 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.

    0
    Von XYZ am Do, 19. Oktober 2017 um 21:33 #

    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...

    • 0
      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

      • 0
        Von XYZ am Do, 19. Oktober 2017 um 23:00 #

        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...

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten