========================================================== Virtuelles Unix Labor - Deployment der Übungsrechner- Hubert Feyrer ========================================================== Dieser Text beschreibt das Deployments der Uebungsrechner des Virtuellen Unix Labors. Beim Buchen der Übungen wird via at(1) ein Job "setup Aufgabenname" hinterlegt, der dann mit Hilfe der Datenbank die fuer die jeweilige Aufgabe benötigten Rechner ermittelt, und diese installert. Der Vorgang der vollautomatisierten Installation via Image Deployment ist hier beschrieben. Randbedingungen sind, dass die Rechner zu jedem Zeitpunkt moeglichst wenig Schaden auf dem Deployment-Rechner anrichten koennen. Ein minimaler Schreibzugriff wird fuer die Rueckmeldung eines erfolgreichen Deployments benutzt. Die aufzusetzenden Rechner (Sun SS4) verfügen über die Möglichkeit eines (optionalen) Netboots, welches fuer die Installation benutzt wird. Per Default booten die Rechner von Platte. 1. Verzeichnisstruktur /vulab /vulab/sparc-root /vulab/sparc-root/install-stuff 2. Setup und Konfiguration Netboot-Environment - im EEPROM: boot-device=disk - Sets in /vulab/sparc-root entpacken: base, etc - cd .../dev; sh MAKEDEV all - Nachinstallation/config (rc.conf, ...) XXX 3. Netboot der Clients siehe netboot-doku.txt (Ettle) 4. Image Erzeugung - Schreibzugriff auf NFS - Vor dem Image-ziehen leere Bloecke mit 0-Bytes fuellen: dd if=/dev/zero of=null bs=1000000 ; rm null - Script /vulab/sparc-root/install-stuff/disk2img (gekuerzt): dd progress=1 if=/dev/r${disk}c bs=1m | gzip >$file 5. Ablauf Deployment (manuell) - Nach netboot: gzip -wd $file | dd of=r${disk}c bs=1m progress=1 6. Konzept Ablauf Deployment (automatisiertes) - Aus at-Job: deploy buchungs-nr - Image fuer Zielrechner vorbereiten: img-$machine - Zielrechner netbooten (remote): # rsh maschine reboot -- net - maschine: Image wird nach netboot via NFS geholt und auf Platte geschrieben # file=/vulab/sparc-root/install-stuff/img-$machine # gzip -wd $file | dd of=r${disk}c bs=1m progress=1 Logfile in .../install-stuff/logs ablegen - machine: nach Deployment Ende im Logfile anzeigen: "Fertig!" - Rueckmeldung an Server, dass image fertig deployed. Poll Logfile (Jeder cronjob pollt 1 File) auf "Fertig!" Write in 777-Dir sollte auch als root ohne -maproot=0 gehen. 7. Detailierter Ablauf des automatisierten Deployments: - at(1) Job: + Install-Image fuer Zielmaschine bereitstellen: file=/vulab/sparc-root/install-stuff/img-$machine ln -sf image-filename $file + Client zum Netbooten bringen: ssh client-hostname reboot "boot net" (Pfad zu reboot ist unter NetBSD und Solaris verschieden! XXX) + Warten, bis Client fertig ist: auf Fertig-Cookie in /vulab/sparc-root/logs/client-hostname warten (Poll-Intervall?) - Client Netboot: (aus /etc/rc, via rc.g4u) + Image auf Platte schreiben: img2disk client-hostname sd0 + "Fertig!"-Cookie in /vulab/sparc-root/install-stuff/logs/client-hostname hinterlegen + reboot (und von Platte booten) 8. Zugang Master->Client aufsetzen: vulab-inetd Nachdem ssh zwischen zwei Maschinen mit ca. 75MHz viel zu langsam ist muss hier nach einer schnelleren Loesung gesucht werden, zumindest fuer Steuerung und Deployment. Fuer den Benutzerzugang kann SSH durchaus angeboten werden. Patch fuer NetBSD's rsh Kommando um "-p port" zu verstehen (erwartet rshd auf dem angegebenen port): siehe rsh+rlogin-p.patch Anschliessend am Server: "rsh -p 9999 befehl" XXX Problem: aus unerklaerlichen Gruenden kann die Option "-p 9999" nur als Root verwendet werden. Moegliche Loesung: setuid root rshrwapper. 8.1 System-Setup für NetBSD - Auf dem jeweiligen Client laeuft ein inetd mit eigener Config-Datei /root/vulab/inetd.conf mit folgendem Inhalt: 9999 stream tcp nowait root /usr/libexec/rshd rshd -L - In /etc/rc.local: echo -n " vulab-inetd" inetd /root/vulab/vulab-inetd - In /root/.rhosts: 10.0.0.250 root - Sicherstellen dass /root/vulab/perl existiert. Kopieren des Binaries von laufender Instalation oder Symlink zu /usr/pkg/bin/perl. 8.2 System-Setup für Solaris - Auf dem jeweiligen Client laeuft ein inetd mit eigener Config-Datei /root/vulab/inetd.conf mit folgendem Inhalt: vshell stream tcp nowait root /usr/sbin/in.rsh in.rsh - in /etc/services anfuegen: vshell 9999/tcp (Solaris' inetd kann keine Port_NUMMERN_ in inetd.conf verwenden :/) - In /etc/rc2.d/S88vulab-inetd: #!/bin/sh case "$1" in 'start') echo vulab-inetd started. inetd -s /root/vulab/inetd.conf ;; 'stop') /usr/bin/pkill -u 0 -f 'inetd.*vulab' ;; *) echo "Usage: $0 { start | stop }" exit 1 ;; esac exit 0 - echo "10.0.0.250 root" >/.rhosts - chmod kann entfallen, arbeitet eh jeder als root :) - /root/vulab/perl zugaenglich machen: ln -s /usr/bin/perl /root/vulab (oder Binary kopieren) - Solaris Pakete installieren: * SUNWcpp (cpp), SUNWsprot (/usr/ccs/bin/make), fuer NIS * SUNWypr, fuer NIS * SUNWypu, fuer NIS * SUNWtoo, fuer truss, ... * SUNWlibC, SUNWdoc, SUNWman, fuer Manpages * SUNWssh*, SUNWzlib, fuer sshd 9. Sonstige Nachinstallion auf den Uebungsrechnern Die Uebungsrechner sind ueberlicherweise (abhaengig von der Aufgabe) mit einer Standard-Installation eines Betriebssystems (Solaris, NetBSD, ...) ausgestattet. Die folgenden Aenderungen wurden fuer den Betrieb im Virtuellen Unix-Labor gemacht: * Root Passwort: vulab * User vulab, Passwort: vulab * telnet, ftp in inetd.conf anschalten * sshd starten * User vulab in group wheel aufnehmen (NetBSD, fuer su) 10. Dauertest Deployment Um die Stabilitaet des Deployment-Systems zu testen wurde ein Benchmark mit zwei Zielen gefahren: 1. Lasttest, um eventuelle Probleme nach wiederholtem Deployment festzustellen 2. Ermitteln der Deployment-Zeiten fuer die Vorbereitung der Übungen In einer Schleife wurde dabei abwechselnd zwei Images auf einen Rechner geschrieben (siehe benchmark-1-host): ./deploy1 netbsd16.img.gz $host cat logs/$host.log >>logs/benchmark-log-$host ./deploy1 solaris29.img.gz $host cat logs/$host.log >>logs/benchmark-log-$host Die Images waren wie folgt: -rw-r--r-- 1 root wheel 415853485 Apr 8 11:30 netbsd16.img.gz -rw-r--r-- 1 root wheel 116936676 Apr 19 02:29 solaris29.img.gz Die Logfiles jedes Laufs wurden archiviert. Das Script wurde parallel fuer die beiden Uebungsrechner gestartet. Insgesamt lief der Dauertest von Fri Apr 25 00:24:09 UTC 2003 bis Mon Apr 28 16:32:12 UTC 2003, jedes der beiden Images wurde dabei 163 mal auf jeden Rechner installiert. Die Betrachtung der Zeiten ergeben ca. folgendes Bild (siehe benchmark-calc-time): yui# perl benchmark-calc-time < logs/benchmark-log-vulab2 19:49 -> 20:23: 34 min (netbsd) 20:25 -> 20:51: 26 min (solaris) 20:54 -> 21:28: 34 min (netbsd) 21:31 -> 21:56: 25 min (solaris) 22:00 -> 22:34: 34 min (netbsd) 22:37 -> 23:02: 25 min (solaris) ... Die durchschnittliche Deployment-Zeit muss abhaengig vom Image genommen werden, da die Image-Groesse hier eine Rolle spielt: Average time solaris: 25.22 Average time netbsd: 34.00 Aus diesen zeitlichen Werten und dem Image-Größen läst sich sehen, das nicht die Groesse des Images allein fuer die Dauer des Deployments verantwortlich ist. Auch ist zu vermuten, dass die Faktoren CPU-Geschwindigkeit (-> Entpacken des Images auf dem Client) von untergeordneter Bedeutung ist. Vielmehr sind relativ konstante Faktoren wie Netzwerk-Bandbreite/Durchsatz und Platten-Durchsatz sowohl auf dem NFS-Server sowie auf dem zu installierenden Client die begrenzenden Faktoren, die nur durch Image-Groesse und indirekt dadurch durch CPU-Geschwindigkeit beeinflusst werden. A Zeiten Deployment - netbsd152-vulab1.img.gz (185MB): ~38 min - netbsd16-vulab2.img.gz (415MB): 33 min - solaris29-vulab2.img.gz (115MB): 25 min -- $Id: deployment,v 1.24 2012-12-21 23:32:17 feyrer Exp $