Manual zu AnyOS. Axel Schöner. 22. März 2012

Transkript

1 Manual zu AnyOS Axel Schöner 22. März 2012

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Allgemeine Hinweise Vereinbarungen Thema und Zielbestimmung Zu betrachtende Betriebssysteme Protokolle für den graschen Zugriff Grundlagen COW DHCP TFTP NFS NBD BTRFS VNC RDP SPICE QEMU Hardwarevoraussetzungen Server Client Setup Serverbeschreibung Clientbeschreibung Serverinstallation Serverkonguration Manuell erstes TFTP-Image erstellen Weitere TFTP-Images erstellen Clientinstallationen Clientkongurationen Auswahl möglicher Varianten während des Bootvorgangs Nutzung 23 7 Empfehlungen Filesystem Graktreiber Grasche Zugriffsprotokolle

4 ii Inhaltsverzeichnis 8 Resume Empfohlene Einsatzzwecke Einschränkungen Anhang Skripte install server.sh congure server.sh populateservercongs.sh install.sh snapshot.sh prepare.sh populate.sh compile spice.sh create btrfs.sh delete btrfs.sh Kongurationsdateien (AnyOS) Initskript: nbd-server etc/exports pxelinux.cfg/default qemuinstance01.conf viewer01.conf xserver01.conf xorg-qxl.conf xorg-vmware.conf Literaturverzeichnis i

5 1 Einleitung Innerhalb dieser Arbeit wird auf zwei spezielle Projekte eingegangen, welche sehr unterschiedliche Ansätze zur Virtualisierung als Grundlage verwenden. Bei dem Projekt AnyOS handelt es sich um eine Netzwerkbootlösung, die mehrere Betriebssysteme gleichzeitig, in jeweils virtuellen Umgebungen, auf einem oder mehreren Rechnern zur Verfügung stellt. Als Virtualisierer dient der Emulator QEMU, zur Emulation vollwertiger Rechner. Dieser ermöglicht es unmodizierte Betriebssysteme zu betreiben. Das Projekt PAM LXC ermöglicht beim Einloggen eines Benutzers, für diesen eine virtuelle Umgebung zu erstellen. In dieser wird der Benutzer vom Betriebssystem des physischen Rechners isoliert. Dazu dient die recht junge Virtualisierungstechnik Linux Containers, welche auf der Isolation bestehender Ressourcen beruht. Mit Hilfe dieser Technik können angepasste Betriebssysteme auf Basis von Linux betrieben werden. Beide Projekte zeigen unter Anwendung verschiedener Ansätze, interessante Möglichkeiten zum Einsatz von Virtualisierern, sowie deren Stärken und Schwächen. Hinweise zur Bewertung dieser Arbeit: Die Bearbeitung des Praxisprojekts bezieht sich auf das Thema AnyOS, bestehend aus dem dritten Kapitel sowie dem entsprechenden Anhang innerhalb des fünften Kapitels. Das Thema Bereitstellung von Linux Containers über PAM, bestehend aus dem vierten Kapitels sowie dem zugehörigen Anhangs im sechsten Kapitels, repräsentiert die Bachelorarbeit. Beide Arbeiten teilen sich ein gemeinsames Literatur- und Abbildungsverzeichnis.

6

7 2 Allgemeine Hinweise Zum besseren Verständnis dieser Arbeit zu Beginn ein paar Hinweise. Auf Linux-/Unixsystemen existieren drei verschiedene Arten von Benutzertypen, man unterscheidet zwischen den Systemverwaltern(Administratoren), den Systembenutzern und den Standardbenutzern. Die Gruppe der Systemverwalter besteht mindestens aus einem Benutzer root. Dieser wird auch als privilegierter Benutzer bezeichnet, da er alle Rechte innerhalb seines Systems besitzt. Systembenutzer werden verwendet um Dienste innerhalb des Systems zu betreiben. Die Gruppe der Standardbenutzer umfasst die Endanwender, sie werden auch als unprivilegierte Benutzer bezeichnet, da Sie zum Schutz des Systems nur über eingeschränkte Rechte verfügen. Folgende Symbole haben je nach Kontext eine andere Bedeutung: # Innerhalb von Kongurationsdateien und Skripten wird # als Kommentarzeichen verwendet. Alle nachfolgenden Zeichen, innerhalb der betreffenden Zeile, dienen rein als Kommentar und werden bei der Ausführung nicht berücksichtigt. Beispiel: # Hier steht ein Kommentar echo Hello, world # Nach der # steht noch ein Kommentar. # Bei der Darstellung von Befehlen zeigt eine vorangestelltes # -Zeichen dass zur Ausführung der root -Benutzer verwendet wird. Beispiel: # whoami root $ Taucht $ innerhalb eines Befehls, eines Skripts oder einer Kongurationsdatei auf, so handelt es sich um eine Variable, welche einen bestimmten Wert an dieser Stelle repräsentiert. Beispiel: author="axel Schöner" echo $author # Gibt den Inhalt der Variable author aus. $ Steht $ vor einem Befehl so bedeutet dies, dass dieser als unprivilegierter Benutzer ausgeführt wird. Beispiel: $ whoami axel 2.1 Vereinbarungen Hochkommatas werden verwendet um besondere Begriffe hervorzuheben, sowie beim Auftauchen von mehrteiligen Fachbegriffen. Begriffe mit festen Bedeutungen, wie zum Beispiel root oder init, sind kleingeschrieben, um konsistent gegenüber dem Auftreten in der

8 4 2.1 Vereinbarungen Praxis zu sein. Dies gilt ebenfalls für Kombinationen aus solchen, wie zum Beispiel: init- Prozess oder root-verzeichnis. Unterkapitel beginnen, mit Ausnahme dieser Vereinbarungen, wie Kapitel, jeweils auf der vorderen Seite. Grund ist die bessere Möglichkeit zur Strukturierung, der beiden behandelten Themen.

9 3 Thema und Zielbestimmung Die Bereitstellung und Wartung vieler Betriebssysteminstallationen verschlingt enorme Ressourcen, sei es in Hinblick auf die Aktualisierung und Pflege der installierten Software als auch die große Anzahl unterschiedlicher Hardware. Dies betrifft beispielsweise: PC-Pools öffentlicher Einrichtungen Büros oder Labore größerer Firmen Je nach Einsatzzweck handelt es sich um identische oder speziell auf die Einzelanforderungen angepasste Kongurationen. Beide Varianten stellen das verantwortliche Wartungspersonal vor das Problem, wie man diese Kongurationen mit geringst möglichen Aufwand unter den Rechnern verteilen kann. Eine mögliche Lösung für diese Problematik wäre die zentrale Bereitstellung von Betriebssysteminstallationen (Images), welche von jedem Rechner im Netzwerk gebootet werden können. Aufgrund von Hardwareunterschieden reicht das klassische Booten über Netzwerk nicht immer aus, wenn beispielsweise die notwendige Architektur(64-Bit, SPARC, ARM...) des Rechners nicht erfüllt ist. Unter anderem lassen sich Betriebssysteme von Microsoft nicht über Netzwerk starten. Die Mehrfachnutzung von Microsoft Betriebssystemen ist bisher nur über Fernzugriff auf einen Terminal Server möglich, wobei dieser die komplette Last zu bewältigen hat. Diese Arbeit soll eine Möglichkeit schaffen, diese Probleme zu lösen. Hierzu wird ein System entwickelt, welches es ermöglicht, beliebige Betriebssysteme in einem bestimmten Zustand über Netzwerk als virtuelle Instanz zu booten. Die Idee hierzu stammt von Herr Prof. Dr.- Ing. Wilhelm Meier, der dieses Projekt [Mei10] bereits am bei sourceforge.net, einer bekannten Onlineplattform für Open-Source-Projekte, angelegt hat. Dort wurde von Ihm bereits eine Grundkonguration dieses Konzepts in Form einiger Skripte und Kongurationsdateien bereitgestellt. Basierend auf dieser Ausgangsbasis wird innerhalb dieser Arbeit die Konguration veriziert, optimiert und deren Eignung für die Praxistauglichkeit überprüft. 3.1 Zu betrachtende Betriebssysteme Ubuntu FreeDOS Windows XP FreeBSD

10 6 3.2 Protokolle für den graschen Zugriff 3.2 Protokolle für den graschen Zugriff Folgende Protokolle stehen für den graschen Zugriff auf die unterschiedlichen Betriebssysteme zur Verfügung. Hierbei wird zwischen X11 und Windows basierenden Systemen unterschieden. X11: Zugriff über VNC, X11 Forwarding als auch neuerdings über SPICE möglich. Windows: Zugriff über VNC, RDP und im Falle von XP ebenfalls über SPICE bedient werden.

11 3.3 Grundlagen 3.4 COW Copy-On-Write (COW) bezeichnet ein Verfahren, bei dem Daten erst dupliziert werden sobald diese geändert werden. Somit lassen sich Kopien anlegen, welche intern auf bestehende Daten referenzieren und nur Abweichungen von der Quelle speichern. Hauptanwendung ndet dies, beim Vorbehalten von Kopien bestehender Daten, bei dem die Quelle unverändert bleibt und nur die Kopie verändert wird. 3.5 DHCP Das Dynamic Host Conguration Protocol (DHCP) ist ein Protokoll zum Übertragen und dynamischen Zuweisen von Netzwerkkongurationen von einem DHCP-Server zu einem DHCP-Client. Es handelt sich um ein TCP-Protokoll, welches unter RFC 2131 bei der Internet Engineering Task Force (IETF) speziziert ist. [Dro97] 3.6 TFTP Das Trivial File Transfer Protocol (TFTP) ist ein primitives UDP basiertes Protokoll, welches sich rein auf die Übertragung zwischen Client und Server beschränkt. Anders als FTP besitzt es keinerlei Authentizierung und Rechteverwaltung sowie der Möglichkeit Ordnerinhalte aufzulisten. Es wird in der Regel verwendet um Rechnern zum Starten über das Netzwerk gezielt mit Dateien, wie Kernel und Ramdisk, zu versorgen. Weiterer Anwendungsbereich ist das Aufspielen von Firmwareimages. Die Spezikation dieses Protokolls(Revision 2) ndet sich unter RFC 1350 bei der Internet Engineering Task Force (IETF). [Sol92] 3.7 NFS Das Network File System (NFS) gilt als eines der bevorzugten Protokolle, wenn es darum geht unter Unix/Linux auf Dateisysteme über Netzwerk zuzugreifen. Es besitzt Mechanismen um auch bei höheren Latenzen oder dem gleichzeitigen Zugriff, durch unterschiedliche Benutzer, möglichst efzient zu arbeiten. Durch komplexe Authentizierungsmechanismen lässt sich die Authentizierung verhältnismäßig sicher, auch über unsichere Netzwerke (wie das Internet), durchführen. Durch Freigabe von kompletten Rootlesystemen können Clientrechner über das Netzwerk starten, sofern deren Kernel dies unterstützt. Es gilt zu beachten, dass es hierbei notwendig ist, auf komplexere Authentizierungstechniken zu verzichten und sich rein auf die IP basierte Authentizierung zu verlassen. Daher sollten auf diesem Weg exportierte Filesysteme, keine vertraulichen Daten beinhalten. Weiterhin ist anzumerken, dass nach der Authentizierung des Clients die Berechtigungen auf Filesystemebene durchgesetzt werden, ohne Kontrollmöglichkeit des Servers. Dies führt dazu, dass der Client auf alle Daten zugreifen kann, die für seine verwendete UID (User ID) zugänglich sind. Problematisch ist dies, da zum Beispiel als root-benutzer auf sämtliche Daten zugegriffen werden kann. Ähnlich problematisch ist die Tatsache, dass eine auf dem Server verwendete

12 8 3.8 NBD UID auf einem Client einem abweichenden Benutzer zugeordnet sein kann, womit dieser Zugriff auf Daten hat, die nicht für Ihn bestimmt sind. Als einzige Ausnahme lässt sich mit der Option root squash beim Export auf dem Server festlegen, dass der root-benutzer des Clients als nobody-benutzer auf dem Server geführt wird. Mit diesem Verfahren werden zumindest die Daten von root vor Zugriffen durch den Client geschützt. Innerhalb lokaler Netzwerke verwendet man daher in der Regel Mechanismen, wie zum Beispiel NIS, um eine einheitliche Zuordnung von Benutzernamen zu UID s zu gewährleisten. Verwendet wird zur Zeit die Version 3 von NFS, die Spezikation dieses Protokolls ist bei der Internet Engineering Task Force (IETF) unter: [BC95] zu nden. Der aktuelle Entwurf(Internet-Draft) zur Version 4 ndet sich bei der Internet Engineering Task Force (IETF) unter: [TH11]. 3.8 NBD Das Network Block Device (NBD) ist eine Implementierung zum exportieren von Blockdevices über das Netzwerk per TCP. Der Unterschied zum bereits erwähnten NFS besteht darin, dass durch Einbinden einer NBD-Ressource mittels nbd-client dem Client ein vollwertiges Laufwerk (Blockdevice) wie bei einer Festplatte vorliegt, auf welchem jegliches Dateisystem verwendet werden kann. Die Authentizierung kann lediglich IP basiert vorgenommen werden, womit eine Nutzung über unsichere Netzwerke, wie das Internet, problematisch ist. Ein eingebauter COW-Mechanismus schafft die Möglichkeit, verschiedenen Clients gleichzeitig temporären Schreibzugriff auf die gleiche Ressource zu gewähren. Bei der Verwendung von COW gelten die geänderten Daten nur für die jeweilige Clientsitzung und werden nach deren Ende verworfen. Es ist weiterhin möglich eigene COW-Mechanismen zu verwenden und für diese mittels prerun und postrun entsprechende Vorbereitungsbeziehungsweise Nachbereitungsmaßnahmen auszuführen [Ver01]. 3.9 BTRFS Bei BTRFS (B-tree FS) handelt es sich um ein Filesystem, welches zur Zeit noch als experimentell eingestuft wird. Einer der Hauptgründe für diese Einstufung ist die noch fehlende Möglichkeit der Filesystemüberprüfung (fsck). Das bedeutet, dass korrumpierte Daten, durch zum Beispiel einen Stromausfall, noch nicht repariert werden können. BTRFS arbeitet, wie der Name bereits vermuten lässt, mittels B-Bäumen zur Organisation von Daten und Metadaten, dabei werden diese von einander getrennt in eigenen Bäumen verwaltet. Das Schreiben von Daten erfolgt mittels Transaktionen unter Einsatz des COW-Konzepts, dabei werden zu ändernde Daten neu geschrieben und erst nach erfolgreichem Abschluss der Transaktion erfolgt die Freigabe der ursprünglichen Daten. Es ist möglich mehrere Wurzelverzeichnisse zu verwalten, sogenannte Subvolumes, welche sich unabhängig von einander im Dateisystem einbinden lassen. Unter Anwendung von COW besteht die Möglichkeit sogenannte Snapshots von bestehenden Subvolumes anzulegen, um platzsparende Kopien von diesen zu erstellen, welche nur für abweichende Daten Speicherplatz belegen. Es existieren weitere positive Eigenschaften, die jedoch in Hinblick auf diese Arbeit keine Rolle spielen, daher wird an dieser Stelle auf die Projekthomepage verwiesen [51].

13 Thema und Zielbestimmung VNC Virtual Network Computing (VNC) ist eine plattformunabhängige Softwarelösung für den graschen Zugriff auf entfernte Rechner. Nach dem Client-Server-Prinzip werden durch Eingabegeräte des Clients Befehle an den Server gesendet, der diese umsetzt. Die grasche Ausgabe wird vom Server, mittels Remote Framebuffer Protocol, framebasiert zum Client übertragen [4911] RDP Beim Remote Desktop Protocol handelt es sich um ein proprietäres Protokoll, welches Microsoft für den Zugriff auf entfernte Windowsrechner anbietet SPICE SPICE wurde entwickelt, um besonders efzient mit der benötigten Netwerkbandbreite umzugehen, um grasch auf virtualisierte Desktopumgebungen zuzugreifen. Dabei wird im Gegensatz zu VNC, nicht der Videospeicher framebasiert vom VNC-Server zu dessen Client übertragen. Der SPICE-Server überträgt stattdessen über einen X-Treiber(QXL) aufgezeichnete, auf dem X-Protokoll basierende Befehle zum Client. Basierend auf den Entwicklungen von Quamranet als proprietäre Lösung wurde es 2009 durch Red Hat unter der OpenSource-Lizens veröffentlicht. Es besteht dabei im wesentlichen aus drei Teilen: Server, Client und vdagent (Virtual Device Agent). Der Server lässt sich direkt in QEMU integrieren. Zur Zeit existieren mindestens zwei Clientvarianten, innerhalb AnyOS wird sich auf den Einsatz von spicec beschränkt. Um Funktionen wie zum Beispiel copy&paste zwischen dem Client und dem virtuellen System zu ermöglichen wird vdagent eingesetzt [Kha11]. Besonders bemerkenswert ist, dass es keinerlei Verzögerungen beim Bewegen des Mauszeigers oder Tastatureingaben gibt [RH11] QEMU QEMU ist ein freier Systememulator welcher von Fabrice Bellard unter der GNU GPL Version 2 veröffentlicht wurde [53]. Folgendes deutschsprachiges Buch kann dazu empfohlen werden: [RT10].

14

15 4 Hardwarevoraussetzungen 4.1 Server Minimale Anforderungen: 2 Netzwerkadapter Empfohlene Anforderungen: 2 Netzwerkadapter mit mindestens 1Gbit/s Mehrprozessor-/Mehrkernsystem 64 Bit CPU mit KVM-Unterstützung RAID 5/10 mehr als 2 GB RAM 4.2 Client Minimale Anforderungen: KVM-Unterstützung der CPU mehr als 1 GB RAM Netzwerkadapter Grakkarte Maus und Tastatur Empfohlene Anforderungen: Netzwerkadapter mit mindestens 1Gbit/s Mehrprozessor-/Mehrkernsystem 64 Bit CPU mit KVM-Unterstützung mehr als 2 GB RAM Grakkarte Maus und Tastatur

16

17 5 Setup 5.1 Serverbeschreibung Abbildung 5.1: Diensteübersicht des Servers Das hier beschriebene Setup des Servers setzt sich aus folgenden Komponenten zusammen (siehe dazu Abbildung: 5.1 Diensteübersicht des Servers): Einem DHCP-Server um das Netzwerk für die Clients zu kongurieren und um Ihnen die Adresse des TFTP-Servers mitzuteilen. Einem TFTP-Server, um die Clients über Netzwerk booten zu können. Dieser bietet anfragenden Clientrechnern einen Bootmanager pxelinux sowie auf Anfrage den Kernel und falls notwendig eine Ramdisk an. Einem NFS-Server (3.7 NFS auf Seite 7) zur Freigabe des Betriebssystems für den Bootvorgang der Clientrechner basiert auf Ubuntu, einer weitverbreiteten Linuxdistribution. Zur Freigabe der zu virtualisierenden Betriebssystemimages wird ein NBD-Server (3.8 NBD auf Seite 8) verwendet. Die ersten beiden Aufgaben übernimmt im beschriebenen Setup der Dienst DNSMASQ, welcher eine leichtgewichtige Implementierung von DHCP-, DNS- und TFTP-Server für lokale Netzwerke ist.

18 Clientbeschreibung Als Dateisystem, auf welchem die Images der virtuellen Betriebssysteme sowie der über Netzwerk zu bootenden NFS-Images hinterlegt sind, dient BTRFS (3.9 BTRFS auf Seite 8). Die fehlende Überprüfungsmöglichkeit des Filesystems stellt innerhalb dieses Setups kein Problem dar, da auf die NFS-Images nur lesend zugegriffen wird. Der Zugriff auf die virtuellen Betriebssysteme bietet zwar Schreibzugriff, jedoch nur auf temporäre Snapshots. Alternativ kann zum Beispiel auf das auf Layern basierende Dateisystem AUFS zurückgegriffen werden. Bei der Verwendung von AUFS gilt zu beachten, dass der Kernel und die entsprechende NFS-Konguration angepasst werden müssen, Informationen hierzu benden sich unter: [Oka09]. 5.2 Clientbeschreibung Abbildung 5.2: ClientServerKommunikation Eine Clientkonguration besteht aus folgenden Komponenten: Einem Rootlesystem welches per NFS zum Booten des physischen Clientrechners verwendet wird. Einem nbd-client zum Einbinden der vom Server zur Verfügung gestellten Blockdevices. Als Virtualisierer wird QEMU (siehe: 3.13 QEMU auf Seite 9) verwendet, zum Betreiben der virtuellen Betriebssysteme. Einem Xserver zu jedem virtuellen Betriebssystem. Einem Viewer zu jedem virtuellen Betriebssystem. Die Kommunikation zwischen Client und Server wird anhand der Abbildung: 5.2 ClientServerKommunikation visualisiert. Beim Starten eines Clientrechners bezieht dieser zuerst vom DHCP-Server seine eigene Netzwerkkonguration sowie die Angabe über den zuständigen TFTP-Server. Mit diesen Angaben kontaktiert der Clientrechner den TFTP-Server und erhält damit einen Bootmanager, aus welchem der Benutzer die zu ladende Konguration auswählen kann. Nach entsprechender Auswahl bezieht der Clientrechner per TFTP den benötigten Kernel und eine Ramdisk(beinhaltet notwendige Kernelmodule/Treiber und Kongurationen). Innerhalb des Bootmanagers erfährt der Clientrechner weiterhin, wie das Rootlesystem einzubinden ist. Im vorliegenden Fall handelt es sich um eine NFS-Freigabe,

19 Setup 15 welche der Clientrechner mit Hilfe des angegebenen NFS-Servers einbindet. Nachdem der Bootvorgang abgeschlossen ist, startet der Clientrechner die kongurierten Dienste die zum Betrieb der virtuellen Betriebssysteme notwendig sind. Dazu bindet er unter Verwendung von nbd-client die entsprechenden Blockdevices ein. Über QEMU werden virtuelle Rechner gestartet, welche die Betriebssysteme der davor eingebundenen Blockdevices als Quelle nutzen. Zum Zugriff auf diese virtuellen Rechner wird für jeden jeweils Xserver und Viewer gestartet. Als Viewer dienen je nach Konguration VNC (3.10 VNC auf Seite 9), SPI- CE (3.12 SPICE auf Seite 9) oder RDP (3.11 RDP auf Seite 9). X11 Forwarding wurde nicht betrachtet, da bei unterschiedlichen Displaymanagern abweichende Kongurationen notwendig sind, sowie der Abgleich eines: MIT-MAGIC-COOKIE. Für den Zugriff auf Windowsbetriebssysteme wurde sich auf VNC und RDP beschränkt, da der für SPICE notwendige Treiber (QXL) nicht auf allen Versionen zur Verfügung steht. Zur Authentizierung der erlaubten Benutzer sowie dessen Benutzerprolen werden entsprechende Netzwerklösungen empfohlen, zum Beispiel LDAP oder Kerberos zur Authentizierung sowie SAMBA oder OpenAFS als Netzwerkfreigabe. 5.3 Serverinstallation Abbildung 5.3: Empfohlene Partitionierung Für die Installation des Servers wird eine Neuinstallation von Ubuntu Natty in der 64-Bit Variante vorausgesetzt. Die Verwendung der 32-Bit Variante ist möglich, jedoch mit Einschränkungen in Hinblick auf die Installation und Wartung von 64-Bit Clientimages verbunden. Grund dafür ist, dass die Nutzung von chroot aus einem 32-Bit System in ein 64-Bit System nicht möglich ist. Dieser Umstand lässt sich umgehen, sofern die Installation und Wartung der Clientimages auf einem 64-Bit System durchgeführt werden und nach Abschluss auf den Server transferiert werden. Gründe für den Einsatz von 64-Bit Clientimages sind, Verwendung von mehr als 4GB Arbeitsspeicher auf den Clientsystemen sowie der Einsatz von SPICE als Zugriffsprotokoll. Die empfohlene Partitionierung wird anhand der Abbildung: 5.3 Empfohlene Partitionierung dargestellt. Zur Installation der notwendigen Pakete für den Server ist das Skript install server.sh (9.1.1 install server.sh auf Seite 29) auszuführen. Als Parameter erwartet dieses die gewünschte Architektur, zur Wahl stehen amd64 und i386. Sollte AUFS als Ersatz für BTRFS gewünscht sein, so ist dieser Parame-

20 Serverkonguration ter ebenfalls zu übergeben. Hinweis: Die Angabe dieser Parameter beziehen sich nicht direkt auf die Installation des Servers, sondern auf die danach automatisch ausgeführte Erstellung des ersten Clientimages innerhalb des congure server.sh Skripts. Beispiele: 1. Installation der 64-Bit Variante unter Verwendung von BTRFS: #./install_server.sh amd64 2. Installation der 32-Bit Variante unter Verwendung von BTRFS: #./install_server.sh i Installation der 64-Bit Variante unter Verwendung von AUFS: #./install_server.sh amd64 aufs 4. Installation der 32-Bit Variante unter Verwendung von AUFS: #./install_server.sh i386 aufs Das Skript ruft nach erfolgter Installation das Skript congure server.sh auf und richtet damit den Server grundlegend ein, weitere Informationen siehe nachfolgenden Abschnitt: 5.4 Serverkonguration auf Seite 16. Es wird ein erstes TFTP-Image erstellt mir dem Rechner über das Netzwerk starten können. Einzelheiten benden sich im folgenden Abschnitt 5.5 Manuell erstes TFTP-Image erstellen auf Seite Serverkonguration Die Konguration des Servers wird implizit durch das Ausführen des install server.sh - Skripts über das congure server.sh -Skript ausgeführt (9.1.2 congure server.sh auf Seite 30). Es gilt dennoch, einige Kongurationen auf deren Korrektheit zu prüfen und gegebenenfalls anzupassen. Dies betrifft zum Beispiel die Konguration der für die Serverdienste zu verwendenden Netzwerkkarte(im angegebenen Fall eth1 ). Durch hinzufügen des folgenden Eintrages innerhalb der Datei /etc/network/interfaces kann dies vorgenommen werden: # The secondary network interface auto eth1 iface eth1 inet static address netmask Zur Konguration der Datei /etc/nbd-server/cong folgendes Beispiel: [generic] authle = /etc/nbd-server/allow listenaddr = [exportswap] virtstyle = ipliteral exportname = /var/lib/tftpboot/swap/swap.%s.img #prerun = /usr/bin/mkle -n 1G %s && mkswap %s prerun = sh /root/create_swap.sh postrun = rm -f %s

21 Setup 17 port = 5051 [exportubuntu] virtstyle = ipliteral exportname = /var/lib/tftpboot/qemu/ubuntu.%s/ubuntu.img port = 5105 postrun = sh /root/delete_btrfs.sh %s prerun = sh /root/create_btrfs.sh %s [exportubuntunbdcow] exportname = /var/lib/tftpboot/qemu/ubuntu/ubuntu.img port = 5205 copyonwrite = true Die Datei ist in mehrere Abschnitte unterteilt, unter generic werden Einstellungen festgelegt, welche für alle Freigaben gelten sollen. In diesem Fall wird ein authle angegeben, dass die IP-Adressen der Clients beinhaltet, welche Zugriff auf den Server haben sollen. Wird kein authle angegeben, kann jeder Client die Freigaben nutzen. Der Parameter listenaddr gibt die IP-Adresse an, auf welcher der NBD-Server lauschen soll. Diese Parameter sollten dem eigenen Netzwerk entsprechen. Die weiteren Abschnitte denieren die eigentliche Freigaben, die jeweiligen Optionen werden, zur besseren Lesbarkeit, einzeln erklärt werden: Durch Angabe der Option virtstyle = ipliteral gibt man dem NBD-Server an, dass dieser beim Einsatz von copyonwrite (COW) die Unterscheidung der Images für die unterschiedlichen Clients auf Basis deren IP-Adresse vornehmen soll. Um dies zu nutzen, ergänzt man den Parameter exportname durch Einfügen von %s an der Stelle, wo die clientseitige IP-Adresse eingesetzt werden soll. Der Parameter exportname hat auf den Pfad eines vorbereiteten Clientimage zu zeigen (Ausnahme exportswap ). Beim Einsatz des bereits erwähnten %s ist der Pfad innerhalb des Filesystems anzugeben ohne Beachtung des %s. Über prerun und postrun werden die Aktionen angegeben, welche vor beziehungsweise nach Beendigung der Freigabe ausgeführt werden sollen. Im Fall von exportswap betrifft dies die Erstellung sowie deren Löschung der temporären swap-datei für den jeweiligen Client. Ähnlich ist dies im Fall von exportubuntu, nur dass dazu jeweils ein Skript zum Einsatz kommt, dass sich um die BTRFS-Snapshots kümmert. Bei exportubuntunbdcow sind diese Angaben nicht notwendig, da bei Verwendung des NBD eigenen COW-Mechanismus dies von NBD automatisch erfolgt. Der Abschnitt exportswap beschreibt die Freigabe eines swap-laufwerks, welches auf einem temporären Imageles basiert. Im Abschnitt exportubuntu folgt eine Freigabe eines Ubuntuimages auf Basis eines BTRFS-Snapshots. Innerhalb des Abschnitts exportubuntunbdcow wird die Freigabe eines Ubuntuimages beschrieben, dass über den COW-Mechanismus von NBD bereitgestellt wird. Zur Konguration der Datei /etc/dnsmasq.conf beschränken wir uns an dieser Stelle auf die wesentlichsten Angaben, da eine vollständige Erläuterung aller Möglichkeiten von dnsmasq den Rahmen dieser Arbeit überschreitet. Daher wird zu diesem Zweck auf die Dokumentation von dnsmasq verwiesen: [Kel]. Auszug aus der Datei /etc/dnsmasq.conf :

22 Manuell erstes TFTP-Image erstellen interface=eth1 dhcp-range= , , ,12h dhcp-boot=/boot/pxelinux.0 enable-tftp tftp-root=/var/lib/tftpboot/client_amd64.rich01 Mittels interface gibt man den zu verwendenden Netzwerkadapter an, auf welchem dnsmasq betrieben werden soll. Über dhcp-range wird der Bereich festgelegt, für den IP-Adressen vergeben werden sollen. Das zu verwendende pxelinux wird über dhcp-boot angegeben. Damit der TFTP-Server betrieben wird, ist die Option enable-tftp zu setzen. Die Angabe tftp-root speziziert wo dnsmasq nach dem benötigten Bootverzeichnis suchen soll. Aus diesem Bootverzeichnis bietet der TFTP-Server, anfragenden Clients, den dort enthaltene pxelinux.0 (Bootmanager) an sowie eine entsprechende Kongurationsdatei, im einfachsten Fall die pxelinux.cfg/default. Die Verwendung hostspezischer Kongurationsdateien wird unter: 5.9 Auswahl möglicher Varianten während des Bootvorgangs auf Seite 21 näher erläutert. Innerhalb der Datei boot/pxelinux.cfg/default hat der Parameter nfsroot auf den korrekten Pfad der NFS-Freigabe zu zeigen. 5.5 Manuell erstes TFTP-Image erstellen Hinweis: Das Skript congure server.sh wird bereits durch das Ausführen des Skripts install server.sh ausgeführt, sofern der Aufruf nicht innerhalb dieses Skriptes auskommentiert wurde. Zum Erstellen des TFTP-Images ist das Skript congure server.sh auszuführen. Es legt das BTRFS-Dateisystem an und erstellt danach ein Subvolume: client amd64.base01 welches die Grundinstallation für die Clients darstellt. Zu diesem Subvolume wird ein Snapshot client amd64.rich01 angelegt, dieser kann nach belieben angepasst werden. Bei Abschluss dieses Vorgangs sollte ein Rootpasswort gesetzt werden, dazu wechselt man in die Installationsumgebung mittels: schroot -c client amd64.rich01 und gegebenenfalls schroot -c client amd64.base01 und setzt mittels passwd ein entsprechendes Passwort. Um zumindest den Startvorgang der Clients zu gewährleisten, sind folgende Dateien innerhalb des Snapshots zu prüfen und gegebenenfalls anzupassen: 1. etc/fstab : Wichtig ist, dass der Pfad zum Server korrekt angegeben ist, dies bezieht sich sowohl auf dessen IP-Adresse als auch den Pfad zum Clientimage. 2. etc/nbd-client : Die Parameter NBD HOST sowie NBD PORT sollten mit den Freigaben des Servers übereinstimmen, die Parameter NBD DEVICE sollten bei 0 beginnend inkrementell erhöht werden.

23 Setup Weitere TFTP-Images erstellen Sollten unterschiedliche Clientkongurationen benötigt werden, empehlt sich vom Subvolume client amd64.base01 oder client amd64.rich01 einen weiterer Snapshot abzuleiten. Entscheidend ist ob eine Basisinstallation gewünscht ist oder eine bereits vorliegende angepasste Installation bevorzugt wird. Dies erfolgt über den Aufruf der folgenden Skripte (siehe Anhang ab: snapshot.sh auf Seite 35) in der angegebenen Reihenfolge: #./snapshot.sh -c aufs -r client_amd64.base01 client_amd64.rich02 #./prepare.sh $SNAPSHOTNAME #./populate.sh -r $SNAPSHOTNAME Hinweis: Die Option -c aufs ist nur anzugeben, wenn statt BTRFS alternativ AUFS verwendet werden soll. Der Parameter -r (Bedeutung: rootfs ) speziziert den nachfolgenden Parameter als Quelle für das Erstellen eines neuen Snapshots, für den die Bezeichnung durch den letzten Parameter festgelegt wird. Die Verwendung der angegebenen Skripte hat den Vorteil, dass der neue Snapshot sowohl als schroot als auch per NFS vorkonguriert wird. Alternativ kann über das Kommando btrfs subvolume snapshot /tftpboot/client amd64.base01 /tftpboot/client amd64.rich02 lediglich ein neuer Snapshot angelegt werden ohne die genannten Kongurationen. Das Erstellen mehrerer Clientkongurationen bietet sich an, um das Bereitstellen verschiedener Betriebssysteme über die Auswahl beim Booten im PXE-Bootmenü zu ermöglichen. Weiterhin ist die TFTP-Serverkonguration anzupassen, diese bendet sich innerhalb des ursprünglichen Snapshots unter boot/pxelinux.cfg/default (9.2.3 pxelinux.cfg/default auf Seite 42). Den vorliegenden Eintrag ergänzt man durch zusätzliche Einträge und passt dabei das Label und die Pfadangaben zum nfsroot an. Es gilt darauf zu achten, dass nur ein Eintrag als default ausgewiesen ist. 5.7 Clientinstallationen Um ein virtuelles Betriebssystem zu installieren legt man zuerst ein Subvolume für dieses an: # btrfs subvolume create /tftpboot/qemu/ubuntu/ Nun erzeugt man ein Festplattenimagele: # qemu-img create /tftpboot/qemu/ubuntu/ubuntu.img 5G oder mit # dd if=/dev/zero of=/tftpboot/qemu/ubuntu/ubuntu.img count=5120 bs=1024k Die Installation der zu virtualisierenden Betriebssysteme kann man per VNC oder SDL vornehmen, dazu bedient man sich einem der folgenden Kommandos: # qemu -hda ubuntu.img -cdrom ubuntu desktop-i386.iso -smp 2 \ -k de -boot d -m vnc :1

24 Clientinstallationen # qemu -hda ubuntu.img -cdrom ubuntu desktop-i386.iso -smp 2 \ -k de -boot d -m 1024 Die verwendeten Parameter haben folgende Bedeutung: Mittels -hda und einem darauffolgendem Pfad zu einer Imagedatei, physischen Festplattenpartition oder Festplatte gibt man das zu verwendende Speichermedium an. Dies ist sowohl für die Installation wie auch den Bootvorgang eines bereits existierenden Betriebssystems notwendig. Die Verwendung von -cdrom und einem darauf folgendem Pfad eines CDROM-Images oder eines physischen CDROM-Laufwerks bindet dieses in das zu startende System ein. Der Parameter -k erlaubt das Festlegen des zu verwendenden Tastaturlayouts, im angegebenen Fall durch Angabe von de wird das deutsche Tastaturlayout verwendet. Das Festlegen des Laufwerks von welchem gestartet werden soll geschieht über den Parameter -boot, in Kombination mit dem Wert d wird von CDROM zu startet. Die beiden anderen Parameterkombinationen dienen zur expliziten Zuweisen von 2 Prozessoren und 1024 MB Arbeitsspeicher, welche optional sind. Weitere mögliche Parameter können über $ qemu help oder $ man qemu eingesehen werden. Bei der Wahl von VNC kann von diesem Rechner mittels folgendem Befehl zugegriffen werden: $ vncviewer :1 Unter Verwendung von SDL startet sich automatisch eine grasche Darstellung, sofern bereits ein Xserver läuft. Zu prüfen ist ob das installierte Betriebssystem einen Treiber für den Netzwerkadapter Intel e1000 benötigt, da dieser aufgrund der innerhalb der Kongurationsdatei denierten virtuellen Netzwerkkarte benötigt wird. Dieser sollte, falls erforderlich, installiert werden. Andererseits kann innerhalb der Kongurationsdatei etc/init/qemuinstance*conf des jeweiligen Clients ein alternativer Netzwerkadapter angegeben werden. Bei Windows XP liegt zum Beispiel der erforderliche Treiber nicht vor, dieser ist von der Intel-Webseite herunterzuladen: [Mic03]. Für die Installation von Ubuntu ist dies nicht erforderlich. Um RDP bei Windowsbetriebssystemen verwenden zu können, ist dieses über die Systemeinstellungen zu aktivieren. Soll das so erzeugte Image mehrfach auf einem Host laufen, beziehungsweise in veränderter Form, so erstellt man dafür am Besten einen neuen Snapshot (siehe 5.6 Weitere TFTP-Images erstellen auf Seite 19). Zur Verwendung von SPICE ist das Clientimage anzupassen, zu installieren ist das spiceprotocol [5411] und der vdagent [5411]. Weiterhin wird udev benötigt, die entsprechenden Regeln dazu werden automatisch generiert.

25 Setup Clientkongurationen Nachdem das Clientimage bereit ist, passt man die NBD-Konguration an, damit dieses auch per Netzwerk exportiert wird. Dazu bearbeitet man die Datei /etc/nbd-server/cong für den Export und die Datei /tftpboot/client64.rich01/etc/nbd-client für das Einbinden des Laufwerks. Zu jeder zu startenden virtuellen Instanz bedarf es noch der zugehörigen Kongurationsdateien, diese nden Sie unter: /tftpboot/client64.rich01/etc/init/. Für die erste Instanz handelt es sich dabei um die Dateien qemuinstance01.conf, xserver01.conf sowie viewer01.conf. Diese benden sich im Anhang ab: qemuinstance01.conf auf Seite 42. Weitere Instanzen konguriert man, indem man einen Symlink (symbolischer Link) auf diese Dateien erstellt mittels: # ln -s qemuinstance01.conf qemuinstance02.conf # ln -s xserver01.conf xserver02.conf # ln -s viewer01.conf viewer02.conf Zum Überschreiben der abweichenden Parameter, erstellt man entsprechende Dateien mit gleichem Namen, welche jedoch nicht auf.conf sondern auf.override enden. Die notwendigen Parameter benden sich jeweils am Anfang der betreffenden Dateien. Der Parameter num spielt dabei eine besondere Rolle, diesen gilt es mit jeder weiteren Instanz zu inkrementieren. Von diesem Parameter hängen etliche andere Parameter ab, er beeinflusst das Display sowie die Ports welche zum Betrieb der virtuellen Umgebung notwendig sind. Zur leichteren Kongurierbarkeit wurden für die möglichen Zugriffsprotokolle sämtliche notwendigen Einstellungen vorbereitet, so dass nur der Parameter graphic verändert werden muss. Diese beiden Parameter sind in jeder der drei zugehörigen Kongurationsdateien anzupassen: qemuinstance*.conf, viewer*.conf sowie xserver*.conf. 5.9 Auswahl möglicher Varianten während des Bootvorgangs Abbildung 5.4: Bootmanager(pxelinux)

26 Auswahl möglicher Varianten während des Bootvorgangs Um dem Benutzer beim Rechnerstart die Wahlmöglichkeit einzuräumen, welche Betriebssysteme geladen werden sollen, besteht die Möglichkeit, mehrere NFS-Images über den TFT- Server anzubieten. Zu diesem Zweck erstellt man Snapshots des vorhandenen NFS-Images und konguriert die gewünschten Instanzen wie unter 5.8 Clientkongurationen auf Seite 21 beschrieben. Zum Erstellen dieser Snapshots eignet sich das Vorgehen wie unter 5.6 Weitere TFTP-Images erstellen auf Seite 19. Diese Skripte erstellen einen neuen Snapshot und fügen diesen automatisch in der Konguration des NFS-Server ein. Damit diese Varianten innerhalb des Bootmanagers ausgewählt werden können, wie in Abbildung: 5.4 Bootmanager(pxelinux), fügt man in der Datei boot/pxelinux/default entsprechende Einträge zu den erstellten NFS-Images ein. Weiterhin besteht die Möglichkeit unterschiedlichen Rechnern nur bestimmte Kongurationen anzubieten. Dies lässt sich dadurch realisieren, dass basierend auf der MAC-Adresse des Rechners beziehungsweise genauer gesagt, dessen Netzwerkkarte eine eigene Konguration unter boot/pxelinux/ hinterlegt wird. Die in diesem Abschnitt beschriebenen relativen Pfade beziehen sich auf das Verzeichnis welches für den TFTP-Server verwendet wird, nach Vorgabe /var/lib/tftpboot/client64.rich01/.

27 6 Nutzung Nach erfolgreichem Bootvorgang gelangt der Benutzer automatisch zu einem graschen Betriebssystem. Wenn mehrere Betriebssysteme konguriert sind, kann der Benutzer zwischen diesen über Auswahl des jeweiligen virtuellen Terminals, mit der Tastenkombination: strg + Alt + VT umschalten, wobei VT durch die repräsentierende F-Taste zu ersetzen ist. Auf diese Weise kann zwischen maximal 24 unterschiedlichen Gastbetriebssystemen umgeschaltet werden (für VT13-VT24 ist statt der linken: strg die rechte strg zu verwenden), wenn man auf Zugriff auf den physischen Client per virtuellem Terminal verzichtet. Tastatureingaben und Maussteuerung werden direkt ins grasche System umgesetzt. Wird ein virtuelles Betriebssystem heruntergefahren, wird dieses automatisch erneut gestartet. Den physischen Rechner schaltet man durch kurzes Drücken des Ein-/Ausschalters aus, dieser wird dadurch mittels ACPI(Advanced Conguration and Power Interface)-Event heruntergefahren. Sollte der Rechner nicht korrekt herunterfahren, kann dieser durch längeres Drücken ( länger als 5 Sekunden), direkt ausgeschaltet werden. Datenverlust droht dadurch nicht, da das Dateisystem des minimalen Linux, welches als Plattform zur Emulation dient, rein lesend eingebunden wird. Die Images der virtuellen Betriebssysteme werden zwar beschreibbar eingebunden, jedoch existieren diese nur temporär bis zum Neustart des physische Rechners.

28

29 7 Empfehlungen 7.1 Filesystem Aufgrund der Größenbeschränkung der diff-dateien des NBD eigenen COW-Mechanismus, auf 4 GB pro Datei und der geringeren Schreibgeschwindigkeit, wird die Verwendung von BTRFS empfohlen. Beim gleichzeitigen Ausführen identischer Betriebssystemkongurationen auf einem Rechner kann mittels BTRFS-Snapshots efzienter mit der Speicherplatzbelegung umgegangen werden, gegenüber dem Vorbehalten identischer Kopien. Durch den Einsatz der Snapshotfunktion von BTRFS können durch die Nutzung veränderte Betriebssysteme auf Wunsch über Neustarts hinweg erhalten werden (Kongurationsanpassungen in der nbd-server.conf vorausgesetzt). 7.2 Graktreiber Bei Zugriff per VNC empehlt sich die Verwendung des VMware-Treibers. Bei Verwendung von SPICE kann der VMware-Treiber nicht verwendet werden, es sollte stattdessen der QXL- Treiber verwendet werden. Beide Treiber bieten vergleichbare Grakleistung und eine höhere Auflösung (größer 1024*768) als entsprechende VESA- beziehungsweise VGA-Treiber. 7.3 Grasche Zugriffsprotokolle Die Verwendung von VNC hat den Vorteil, dass es mit sämtlichen Betriebssystemen verwendet werden kann und direkt beim Starten des virtuellen Rechners Zugriff bietet. Nachteil von VNC ist jedoch, dass die Maussteuerung etwas unnatürlich wirkt. Zur Bedienung von Windowsbetriebssystemen empehlt sich die Nutzung von RDP, Nachteil von RDP ist jedoch, dass auf den Host erst zugegriffen werden kann, sobald das Betriebssystem vollständig geladen wurde. Bei Betriebssystemen basierend auf Linux bringt SPICE, in Verbindung mit dem QXL-Treiber, die besten Ergebnisse. Der Bildaufbau sowie die Maussteuerung wirken wie auf einem lokalen Rechner und der Zugriff ist direkt beim Starten des virtuellen Rechners möglich.

30

31 8 Resume 8.1 Empfohlene Einsatzzwecke AnyOS ist eine Lösung, welche es ermöglicht, ein/mehrere Betriebssystem/e in einem wohldenierten Zustand, auf einer Menge von Rechnern, gleichzeitig zu betreiben ohne große Anpassungen an den Betriebssystemen selbst vornehmen zu müssen. Vor dem Einspielen größerer Updates oder der Installation neuer Software, kann ein Snapshot vom bisherigen Image abgeleitet werden, so dass die Änderungen ohne Beeinträchtigung des aktuellen Images vorgenommen werden können. Nachdem die gewünschten Änderungen durchgeführt und ausgiebig getestet sind, können diese durch Zuweisung des neuen Images in den Livebetrieb geschaltet werden. Sollte es dennoch zu Problemen kommen, lässt sich dieses durch simples Rücksetzen auf das bisherige Image rückgängig machen. Mit Hilfe dieser Eigenschaften, lassen sich sämtliche Betriebssysteme zentral warten, mit der Möglichkeit, schnell und sicher, deren Konguration anzupassen ohne den Livebetrieb zu beeinträchtigen. Es bietet darüber hinaus die Möglichkeit, den Benutzern Administratorrechte einzuräumen, ohne dass diese das Betriebssystem über einen Reboot hinaus verändern können. Daher eignet es sich sehr gut um unternehmensweit Arbeitsplätze mit einem/mehrerer Betriebssystemkonguration/en zu versorgen. Der Einsatz mehrerer Versionen, des gleichen Betriebssystems bietet sich an, falls es bekannte Inkompatibilitäten zwischen einzusetzender Software gibt. Sehr gut eignet es sich auch um verschiedene Testumgebungen bereitzustellen, welche gleichzeitig betrieben werden können, ohne diese lokal installieren zu müssen. Zusammenfassend lässt sich sagen, dass die vorab gesetzten Erwartungen erfüllt werden und den Wartungsaufwand etlicher Rechner erheblich senken. 8.2 Einschränkungen Aufgrund der verwendeten Virtualisierungslösung, welche genauer gesagt eine Emulationslösung ist, eignet sich das beschriebene Setup nicht für Anwendungsbereiche, bei denen es auf eine hohe Grakleistung ankommt. Auch die Prozessorleistung ist wesentlich geringer gegenüber anderen Virtualisierungslösungen, speziell mit sogenannten Paravirtualisierern sowie dem nativem Betrieb.

32

33 9 Anhang 9.1 Skripte install server.sh #!/bin/bash if [ "$1"!= "amd64" ] && [ "$1"!= "i386" ]; then echo Parameter benutzen (ARCH: amd64 i386):./install_server.sh ARCH echo Um statt BTRFS AUFS zu verwenden ist folgender Aufruf notwendig: echo Parameter benutzen (ARCH: amd64 i386):./install_server.sh ARCH aufs exit else ARCH=$1 INSTALLERDIR= pwd echo Installing packages... apt-get -qy --force-yes update apt-get -qy --force-yes upgrade if [ "$2" == "aufs" ]; then apt-get -qy --force-yes install vim openssh-server debootstrap \ nfs-kernel-server schroot patch nbd-server make gcc subversion \ libglib2.0-dev qemu bzip2 aufs-tools else apt-get -qy --force-yes install vim openssh-server dnsmasq \ debootstrap nfs-kernel-server schroot patch nbd-server make \ gcc btrfs-tools subversion libglib2.0-dev qemu bzip2 cd /usr/src/ # only necessary for using nbd version #wget \ # #tar xfz nbd tar.gz #cd nbd #cp /home/installer/les/patch-nbd to-nbd /usr/src/ #patch -p1 <../patch-nbd to-nbd #./congure --enable-syslog #make && make install wget \

34 Skripte tar xjpf nbd tar.bz2 cd nbd /congure --enable-syslog make && make install ln -s /etc/nbd-server /usr/local/etc/nbd-server cd $INSTALLERDIR echo "Making helper" make -C helper/mkle cp -p helper/mkle/mkle /usr/bin/ sh congure_server.sh "$ARCH" "$2" congure server.sh #!/bin/bash if [ "$1"!= "amd64" ] && [ "$1"!= "i386" ]; then echo Parameter benutzen (ARCH: amd64 i386):./congure_server.sh ARCH echo Um statt BTRFS AUFS zu verwenden ist folgender Aufruf notwendig: echo Parameter benutzen (ARCH: amd64 i386):./congure_server.sh ARCH aufs exit else TFTPDIR="/var/lib/tftpboot" BTRFSPARTITION="/dev/sda6" arch=$1 # amd64 i386 SNAPSHOTNAME="client_$arch.rich01" ROOTFS="client_$arch.base01" #cd /home/installer/ sh populateservercongs.sh mkdir $TFTPDIR if [ "$2"!= "aufs" ]; then mkfs.btrfs $BTRFSPARTITION mount -t btrfs $BTRFSPARTITION $TFTPDIR echo "UUID= blkid -o value -s UUID $BTRFSPARTITION $TFTPDIR btrfs defaults 0 0" >> /etc/fstab #cd /home #svn co anyos #cd /home/anyos/trunk/server #cd /home/installer/./install.sh "-a" "$arch" "-c" "$2"./snapshot.sh "-c" "$2" "-r" "$ROOTFS" "$SNAPSHOTNAME"./prepare.sh "$SNAPSHOTNAME"./populate.sh "-r" "$SNAPSHOTNAME"

35 Anhang 31 #btrfs subvolume create $TFTPDIR/swap #btrfs subvolume create $TFTPDIR/qemu #btrfs subvolume create $TFTPDIR/qemu/ubuntu #btrfs subvolume create $TFTPDIR/qemu/windows #btrfs subvolume create $TFTPDIR/qemu/freebsd #btrfs subvolume create $TFTPDIR/qemu/freedos #qemu-img create /tftpboot/swap/swap.img 1G #mkswap /tftpboot/swap/swap.img #qemu-img create /tftpboot/qemu/ubuntu/ubuntu.img 5G #qemu-img create /tftpboot/qemu/windows/winxp.img 5G #qemu-img create /tftpboot/qemu/freebsd/freebsd.img 5G #qemu-img create /tftpboot/qemu/freedos/freedos.img 0.25G populateservercongs.sh #!/bin/bash # $Id$ rootfs="/" leslist="les/server/le.list" lesdir="./les/server" while getopts d: opt; do case "$opt" in r) rootfs="$optarg";; \?) echo "unknown option $opt" >$2; exit 1;; esac done shift expr $OPTIND - 1 if [! -d "$lesdir" ]; then echo "No $lesdir" exit 1 if [! -f "$leslist" ]; then echo "No $leslist" exit 1 grep ˆ[ \t]*[ˆ#] $leslist while read entry; do mode=$(echo $entry awk {print $1} ) own=$(echo $entry awk {print $2} ) le=$(echo $entry awk {print $3} ) if [! -f "$lesdir/$le" ]; then echo "No source le $lesdir/$le for $rootfs/$le" exit 1 echo "Copy $le" if [! -d "$(dirname $rootfs/$le)" ]; then mkdir -p "$(dirname $rootfs/$le)"

36 Skripte cp -p "$lesdir/$le" "$rootfs/$le" chmod "$mode" "$rootfs/$le" chown "$own" "$rootfs/$le" done install.sh #!/bin/bash # $Id$ # install a chroot export DEBIAN_FRONTEND=noninteractive export LANG="de_DE.UTF-8" force=false dist="natty" base="/var/lib/tftpboot" #rootfs="client_$arch.base01" while getopts b:t:d:a:c:f opt; do case "$opt" in b) rootfs="$optarg";; t) base="$optarg";; d) dist="$optarg";; a) arch="$optarg";; c) cow="$optarg";; f) force=true;; \?) echo "unknown option $opt" >&2; exit 1;; esac done shift expr $OPTIND - 1 rootfs="client_$arch.base01" if [ "$arch" == "amd64" ]; then KERNEL="linux-image-generic" else KERNEL="linux-image-generic-pae" if [ "$cow"!= "aufs" ]; then if [ -d "$base/$rootfs" ]; then if [ "$force" == true ]; then btrfs subvolume delete "$base/$rootfs" \ (echo "Exiting"; exit 1) else echo "chroot $base/$rootfs exists. remove rst or use option -f" exit 1 btrfs subvolume create "$base/$rootfs" (echo "Exiting"; exit 1)

37 Anhang 33 which schroot >/dev/null 2>&1 (echo "schroot not installed!"; exit 1) if [! -f "/etc/schroot/chroot.d/$rootfs" ]; then echo "No cong for $rootfs, creating..." cat<<eof > "/etc/schroot/chroot.d/$rootfs" [$rootfs] directory=$base/$rootfs description=$rootfs type=directory script-cong=$rootfs/cong EOF if [! -d "/etc/schroot/$rootfs" ]; then echo "no schroot cong for $rootfs, creating..." mkdir -p "/etc/schroot/$rootfs" cat <<EOF > "/etc/schroot/$rootfs/cong" FSTAB="/etc/schroot/$rootfs/fstab" COPYFILES="/etc/schroot/$rootfs/copyles" NSSDATABASES="/etc/schroot/$rootfs/nssdatabases" EOF cat <<EOF > "/etc/schroot/$rootfs/fstab" /proc /proc none rw,rbind 0 0 /sys /sys none rw,rbind 0 0 /dev /dev none rw,rbind 0 0 #/dev/pts /dev/pts none rw,rbind 0 0 EOF cat <<EOF > "/etc/schroot/$rootfs/copyles" /etc/resolv.conf /etc/hosts EOF cat <<EOF > "/etc/schroot/$rootfs/nssdatabases" EOF mkdir -p "$base/$rootfs/etc" cat <<EOF > "$base/$rootfs/etc/kernel-img.conf" do_symlinks = Yes link_in_boot = Yes image_dest = /boot do_bootloader = No EOF echo "Doing debootstrap of $dist in $rootfs" # extra packages (not with debootstrap) #extra_packages="lynx" extra_packages="lynx sudo" # dependencies for SPICE extra_packages="$extra_packages build-essential autoconf git-core" extra_packages="$extra_packages libtool liblog4cpp5-dev libavcodec-dev" extra_packages="$extra_packages libssl-dev xlibmesa-glu-dev libasound-dev" extra_packages="$extra_packages libpng12-dev libfreetype6-dev" extra_packages="$extra_packages libfontcong1-dev libogg-dev