Windows Zen, Windows in Quarantäne

Einleitung:

Wir alle lieben unser Windows. Die einen kommen ohne Power nie auf den Point, die anderen ohne Word nie zum geschriebenen Wort. In diesem Beitrag soll es aber um jene kleine Gruppe gehen, die Windows so sehr lieben, dass sie es zum eigenen (doppeldeutig 😉 ) Schutz in Quarantäne schicken, die Virtualisierer. (Die Genderversuche haben der Lesbarkeit des Betrag leider nicht gut getan. Alle Formen sind aber bitte doch genderneutral zu verstehen.)

Es soll hier aufgezeigt werden, wie Windows mit Hilfe von Virtualisierung so betrieben werden kann, dass dies von den Benutzer kaum bemerkt wird und sie ihrer Arbeit wie gewohnt nachgehen können.

Ziel dieser Umsetzung ist daher eben nicht der einzelne versierte Poweruser, sonder alle jene Benutzer eines größeren Netzwerkes, die aus erst genannten Gründen Windows benötigen und es einfach nur benutzen wollen.

Die Konzepte sind im Folgenden mit Virtualbox umgesetzt, aber grundsätzlich ist jede Virtualisierungssoftware, die sich per Kommandozeile steuern lässt, vorstellbar.

Die Lösung wird schrittweise erarbeitet, um auf die jeweils auftretenden Probleme detailliert eingehen zu können.

Ausgangssituation:

Wir haben ein funktionierendes Netzwerk mit beliebig vielen Linux – Clients mit einem Standard – User und zusätzlich User mit personalisiertem LDAP – Logins.

Auf all diesen Clients soll eine wartungsarme Windowsinstallation zur Verfügung gestellt werden. Daraus folgt, dass auf Double – Boot und eigene Windows – Domäne liebend gerne verzichtet wird und Windows jedem User virtuell zur Verfügung gestellt werden soll.

Da Windows nun nicht neben Linux läuft, sondern gleichsam als „normales“ Programm, hat es in unserem Netz den Spitznamen „Windows on Top“, im nachfolgenden Text kurz „WonT“, bekommen.

Ansatz 1, jedem User sein eigenes virtuelles Windows:

Da Virtualbox seine virtuellen Maschinen als Verzeichnis abspeichert, könnte sich jeder User eine vorinstallierte Maschine mit Standard – Benutzer in sein Homeverzeichnis laden.

Nachteile:

• Pro User werden etwa 15 GB zusätzlicher Speicher benötigt und jeder Plattenzugriff von WonT erzeugt Netzlast.
• WonT muss über das Virtualbox Verwaltungsprogramm gestartet werden. Hier könnten wichtige Einstellungen versehentlich verändert werden.

Ansatz 2, jedem PC seine eigenes virtuelles Windows:

Vorteil:

• Speicherplatz und Netzlast gelöst, aber

zusätzlicher Nachteil:

• wenn mehrere Benutzer die virtuelle Maschine nutzen, wird es schwer einen definierten Zustand zu erhalten.

Anforderungen an eine Lösung:

Hier wird klar, dass es sinnvoll ist, wenn WonT

1. auf dem lokalen PC liegt, um Netzlast zu vermeiden
2. die Benutzer nicht mit Verwaltungstools der Virtualisierungssoftware in Berührung kommen, und möglicherweise fatale Änderungen vornehmen.
3. in definiertem Zustand, d.h. unveränderbar bleibt

Lösung:

Etwas Technik:

Zuerst etwas Technik, die zwar trivial erscheint, deren Rekapitulation aber Sinn macht, um Zuständigkeiten später klar trennen zu können.

Ein normaler PC besteht aus Hardware, die für uns meist recht unveränderlich ist und aus jenen Daten, die auf der Festplatte/SSD gespeichert sind.
3% Linuxbenutzer wissen, dass sie bei einem defekten PC die Festplatte ausbauen, wo anders einbauen und weiterarbeiten können. Der Rest kümmert sich um das Reaktivieren seiner Windows und Office – Lizenzen ;-(

Funktionsweise Virtualisierungssoftware:

Virtualisierungssoftware funktioniert ähnlich.

1. Man baut sich in der Verwaltungssoftware ein PC zusammen.
2. Man installiert das Betriebssystem und arbeitet mit dem virtuellen PC.

Und so, wie eine PC eine Festplatte hat, besitzt ein virtueller PC eine Datei, die eben diese Festplatte simuliert.

Gibt es nun die Möglichkeit den Zusammenbau eines virtuellen PC zu automatisieren und ihn anschließend mit einer gewünschten Festplattendatei zu starten, haben wir Punkt 2 unserer Anforderungen an eine Lösung umgesetzt

VboxManage Befehle:

Diese Befehle heißen bei Virtualbox VBoxManage, und sind bei https://www.virtualbox.org/manual/ im Kapitel 8 genau erklärt.

So erzeugt nachfolgender Befehl eine virtuelle Maschine, registriert sie beim Virtualisierer und weist ihr ein Arbeitsverzeichnis für Snapshots und Einstellungen zu.

VBoxManage createvm –name $MACHINE_NAME –register –basefolder $MACHINE_WORK_DIR

Erzeugen einer Netzwerkkarte von bestimmtem Typ, die im NAT Modus arbeite, sieht wie nachfolgend aus.

VBoxManage modifyvm $MACHINE_NAME --nictype1 82540EM

VBoxManage modifyvm $MACHINE_NAME --nic1 nat

Definierten Zustand erhalten:

Besondere Beachtung verdient dieser Befehl, ohne den die reibungslose Umsetzung des Konzeptes nicht so einfach möglich wäre.

VBoxManage storageattach $MACHINE_NAME --storagectl SATA-Controller-$MACHINE_NAME --port 0 --device 0 --type hdd --medium $MACHINE_PATH_AND_FILE --mtype immutable

Die Option –mtype immutable ganz am Ende bindet die Festplattendatei, bei Virtualbox mit Dateiendung .vdi, nur lesbar ein. So kann das vdi – File im Filesystem mittels read-only vor unerlaubten Zugriffen geschützt werden und vom Virtualisierer überhaupt erst eingebunden werden. Ein Normalzugriff würde Schreibrechte benötigen um Änderungen in die vdi – Datei zu schreiben.

Änderungen an der virtuellen Maschine werden ab jetzt in einen Snapshot, geschrieben. Diese Snapshots liegen anders als bei einer „normalen“ Verwendung von Virtualbox nicht direkt neben dem vdi – File, sondern an einer Stelle im Filesystem, wo der User Schreibrechte besitzt. Da diese Snapshots beim Herunterfahren verworfen werden, bietet sich das /tmp Verzeichnis an, da es lokal liegt und bei PC Neustart aufgeräumt wird. WonT erscheint so bei jedem Start unverändert, die Änderungen der Benutzer werden nicht gespeichert und somit ein definierter Zustand garantiert.

Im Skript startVM.sh (https://github.com/edvapp/autoinstall/blob/master/vms/startVM.sh) kann ab Zeile 130 das Erzeugen einer virtuellen Maschine nachgelesen und später ausprobiert werden.

So erzeugt und startet nachfolgender Befehl einen virtuellen PC mit der Festplattendatei win7.vdi, die in /opt/vms gespeichert ist.

>> startVM.sh /opt/vms/win7.vdi --acpi off

Bevor wichtige Konzepte des Skriptes erläutert werden, eine kurze Kurzanleitung, wie man selbst zu einem vdi – Festplattenfile gelangt.

Eigene Virtuelle Festplatte erzeugen:

In der Virtualbox – GUI ist das Erstellen einer eigen Maschine selbsterklärend. Daher Maschine mit dem Assistenten erzeugen und Betriebssystem und Programme wie gewohnt installieren. Bei Bedarf Snapshots der jeweiligen Situation, möglichst bei ausgeschalteter Maschine erzeugen. Bei Fehlern kann dann jederzeit zu diesen Snapshots zurückgekehrt werden. Es wird wahrscheinlich noch ein Weile dauern, bis dieses Feature auch am realen PC mit modernen Filesystemen flächendeckend zur Verfügung steht. Wenn der virtuelle PC fertig ist, muss ein vollständigen Klon vom aktuellen Zustand erzeugt werden. Dieser Klon fasst nun alle Snapshots zu einer einzigen virtuellen Festplatte in einer vdi – Datei zusammen.

Wichtige Erläuterungen zum Skript:

Die meisten Teile des Skriptes sollten sich durch die Dokumentation selbst erklären, ansonsten werden Hinweise, damit das so wird, gerne eingearbeitet. 🙂

Ein paar Konzepte bedürfen jedoch einer ausführlicheren Erklärung zum leichteren Verständnis.

Datenaustausch:

WonT läuft wie jedes andere Programm auf dem realen PC (Host). Während die meisten Programme jedoch einen Öffnen/Speichern – Dialog zum Holen und Speichern von Daten besitzen, fehlt das einer virtuellen Maschine vorerst noch.

Dies übernehmen virtuelle Laufwerke, die mit Verzeichnisse am Host verknüpft sind. D.h. die Verzeichnisse am Host erscheinen in WonT als Netzwerklaufwerke. Das hat zu echten Netzwerklaufwerken, die in WonT natürlich auch möglich sind, den Vorteil, dass das vdi – File nur vom Host abhängig ist. Ändert sich z.B. ein Netzlaufwerk, wird die Änderung am Host durchgeführt und das immutable vdi – Image kann gleich bleiben. Das spart auf Dauer Arbeit.

Das virtuelle Laufwerk myHome zeigt auf das Homverzeichnis des Nutzers und wird wohl in allen Szenarien Sinn machen. Es ermöglicht jedem Nutzer auf sein Homeverzeichnis zuzugreifen, so wie er das von allen anderen Programmen gewohnt ist.

Zusätzliche Optionen:

Verschieden virtuelle Maschinen benötigen leicht verschieden Einstellungen, sodass dem Skript zusätzliche VboxManage Optionen mitgegeben werden können, die Einstellungen ergänzen bzw. rückgängig machen. In einer while [ ! -z $1 ]; do … done Schleife, werden zusätzliche Optionen angehängt.

VBoxManage setextradata:

Um WonT ohne Nachfragen/Meldungen und im Vollbildmodus zu betreiben, müssen einige Parameter des Virtualbox GUI – Verwaltungstools gesetzt werden.

Original Virtualbox Einstellungen sichern:

Damit die vom Skript erzeugte Maschine nicht mit evt. vorhandenen virtuellen Maschinen kollidiert und Einstellungen überschreibt, wird das Original Virtualbox – Verzeichnis VirtualBox VMs beim Start gesichert und am Ende wiederhergestellt.

Ubuntu 20.04 Fix:

In Ubuntu 20.04 kann die Virtuelle Maschine nicht mehr mit

>> VirtualBox --startvm $MACHINE_NAME

gestartet werden, sondern nur mehr mit dem Befehl

>> VirtualBoxVM --startvm $MACHINE_NAME

der aber erst mittels Link

>> cd /usr/bin

>> ln -s ../share/virtualbox/VBox.sh VirtualBoxVM

erzeugt werden muss. (Komisch 🙁 ?)

Die Druckerlösung:

Zu Beginn dieses Konzeptes gab es noch ein Sammelsurium an Netzwerkdruckern auf WonT. Jeder Druckertausch verlangte dann die Neuinstallation eines Druckertreibers in WonT und das Aufspielen des neuen vdi – Files auf all jenen Hosts, die diesen Drucker bedienten.

Daher war es das Ziel auch die real existierenden Drucker aus WonT zu verbannen. An ihre Stelle treten 2 PDFs Drucker, bei uns PDF7 und PDF24, die die Ausdrucke in ein Verzeichnis pdf-spooler bzw pdf-spooler/color im Homverzeichnis speichern. Dieses Verzeichnis wird mit dem Programm inotify überwacht und schickt bei Änderungen die erzeugten PDFs an den Standarddrucker bzw. den Farbdrucker des Systems.

Die USB – Lösung:

Da USB zu Beginn noch nicht ganz einfach in WonT funktionierte, wurde ein anderer Lösungsansatz gewählt. Ein virtuelles Laufwerk ist auf /media gesetzt und überlässt dem Host die Verwaltung von USB Sticks.

Die Sticks werden dann zwar nicht ganz sauber ausgeworfen, doch es scheint in der Praxis funktioniert zu haben, denn die Beschwerden hielten sich in Grenzen.

Tipps und Hinweise für die Virtuelle Windows Maschine:

Wichtig:

Updates von Windows und allen Programmen ausschalten. Für Firefox siehe (https://github.com/mozilla/policy-templates/blob/master/README.md)

Druckerinstallation gut überlegen (siehe oben)

Angenehm:

Für Benutzer angenehm ist ein Standard – Benutzer, der sich automatisch einloggt.

Standard Benutzer kann ohne Probleme der Administrator sein, beim nächsten Neustart ist alles beim Alten.

ToDo und Verbesserungen:

Nur Änderungen verteilen:

Kleinste Änderungen an WonT bedeutet, dass das komplette vdi – File ~ 15GB neu verteilt werden muss. Selbst rsync liest hier nicht nur Differenzen.

D.h. ein schnelleres, Bandbreite schonenderes Updaten von WonT wäre schön. Schön, wäre eine Nachinstallation der Snapshots.

USB:

Jetzige USB Lösung evt. durch Durchschleifen von USB ersetzen. Fragt sich aber ob es dann besser wird?

Diverses:

Änderungen von WonT beim Start:

Mit einem Hook- Skript beim Start von WonT nach außen zum Host wurde experimentiert. Es wurde folgende Idee umgesetzt. Beim Start erzeugt ein Windows Startskript ein Netzwerklaufwerk zum Host und ruft dort weitere von Host zu Host verschieden Windows – Skripte auf.

Eine Aufgabe wäre gewesen, alle Netzwerkdruckern bis auf den passenden zu löschen. Die Idee ist am Windows Rechtesystem gescheitert, 🙁 hat aber zur PDF – Lösung geführt 🙂

USB:

USB lässt sich nach WonT durchschleifen, schaltet dann aber USB am Host aus. Die USB Tools benötigen eine Lizenz, die aber automatisch installiert werden kann.

Viel Spaß beim Ausprobieren 🙂