Howto:Computerkabinett Goetheschule Ilsenburg
Inhaltsverzeichnis |
|
Einleitung
Das Projekt
Die Goethe Schule in Ilsenburg möchte ihr Computer-Kabinett 2 (technischer Stand 1999) mit 10 PC-Arbeitsplätzen erneuern. Hierzu gibt es bereits ein Angebot einer Firma, die diese Aufgabe mit einer Komplettlösung der Firma nComputing erledigen möchte. Die Kosten dafür sollen 5700€ betragen. Durch einen ehemaligen Schüler und den Vater eines aktuellen Schülers bei uns in der LUG bekamen wir Wind von der Sache. Nach näherer Betrachtung erklärten wir es kurzerhand zum LUG-Projekt und begannen nach Lösungen für ein geeignetes System zu suchen.
Wünsche der Schule
Wenn wir als LUG auch keinen finanziellen Gewinn haben möchten, so ist doch der Kunde König! In einem netten Gespräch mit dem zuständigen Informatiklehrer wurden die Wünsche und Vorgaben der Schule festgelegt.
Aufgaben des Computerkabinetts
- Informatikunterricht
- Im Rahmen des Lehrplanes sollen Textverabeitung, Tabellenkalkulation, Grundlagen des Internets vermittelt werden.
- Arbeitsgemeinschaften
- Die Arbeitsgemeinschaft "Webdesign" soll Ihr Projekt weiterentwickeln.
- Freie Nutzung
- Die Rechner sollen als Surf&Mail Station für Schüler und Lehrer nutzbar sein.
- Terminal-Server-Lösung
- Im bereits vorliegenden Angebot wird eine Terminal-Server-Lösung verwendet. Da der Informatiklehrer zu recht mehrfach gehört hat, dass das ein modernes, effektives System ist, soll eine solche Lösung favorisiert werden.
- Einhaltung des Budgets
- Die im Schulhaushalt bewilligte Summe von 5700€ kann und soll ausgegeben, jedoch nicht überschritten werden.
- Microsoft Software
- Wenn möglich, soll Micrssoft Software (Windows und Office) verwendet werden. Hierzu ist eine Analyse der vorhandenen Lizenzen und der zu veranschlagenden Lizenzkosten erforderlich. Begründet wurde der Wunsch mit der für die meisten Nutzer vertrauten Oberfläche. Microsoft-spezifische Funktionen jedoch spielen, nach unserer Nachfrage, keine Rolle.
- Kontrolle der Arbeitsplätze
- Der Informatiklehrer hatte früher bereits mit MasterEye gearbeitet und wünscht sich solch eine Lösung mit voller Kontrolle über jeden Arbeitsplatz. Gemeint ist eine Software, die es dem Lehrer ermöglicht, die einzelnen Terminals zu kontrollieren. Er kann damit jeden Bildschirm einsehen, schwarz schalten oder nach vorn auf einen großen Bildschirm legen.
- Berücksichtigung der 2. Ausbaustufe
- Es wurden Fördermittel in Höhe von 15000 € beantragt, die in etwa zwei Jahren zum Ausbau des grösseren Computerkabinetts 1 zur Verfügung stehen. Es soll die Möglichkeit geben, das die jetzt zu errichtende Anlage später mit der neuen zu einem noch leistungsfähigerem System verbunden werden kann.
Wünsche der LUG
- Einsatz von Open Source Software
- Auf 10 Rechnern Windows XP zu installieren und uns die nächsten Jahre jede Woche um die Reparatur zerstörter Installationen, Aktualisierung des Virenscanners und das Entfernen von Spyware zu kümmern, ist definitiv nicht unser Anspruch. Ein stabiles Linux-System mit Firefox, Openoffice und anderer freier Software sollte es schon sein.
- Benutzerverwaltung
- Es gibt für den Informatiklehrer die Möglichkeit, Benutzer anzulegen. Diese könen sich mit Passwort anmelden und bekommen so Zugriff auf erweiterte Funktionen des Systems. Die Möglichkeit des einloggens als Gast und die Nutzung eines Standard-Desktops mit festgelegten, eingeschränkten Funktionen besteht natürlich auch.
- Personalisierter Desktop
- Jeder angemeldete Benutzer darf den Standard Desktop nach seinen Wünschen verändern. Nach erneutem Anmelden an einem beliebigen Rechner findet er alles so vor, wie er es beim letzten Mal hinterlassen hat.
- Zentrale Verwaltung
- Das Betriebssystem sollte bei allen Rechnern identisch sein. Das reduziert den Aufwand für Veränderungen/Aktualisierungen immens. Die möglichen technischen Lösungen dafür stehen weiter unten.
- Fernwartung
- Die in einem Linux-System vorhandenen Funktionen wie beispielsweise ssh sollen mit sicheren Passwörtern, einer VPN-Verbindung etc. eingerichtet werden. So besteht für uns als LUG jederzeit die Möglichkeit, nach dem Rechten zu sehen ohne persönlich in der Schule vorstellig zu werden.
Planung
Nach reiflicher Überlegung kamen wir auf drei Möglichkeiten, die Schule bei Einhaltung des Kostenrahmens mit einer den meisten Vorgaben und Wünschen entsprechenden EDV-Anlage auszurüsten. Da es jeweils Lösungen mit kommerzieller als auch mit der von uns natürlich favorisierten freien Software gibt, gehen wir auf die genaue Bezeichnung der Betriebssysteme und Programme erstmal noch nicht ein.
Zwei Möglichkeiten
- 1. Ein Terminal-Server mit 10 Thinclients
Ein ThinClient ist ein minimaler Rechner auf dem sich ein minimales Betriebsystem befindet. Damit ist der Thinclient in der Lage, sich auf einen Terminal-Server aufzuschalten. Dieser empfängt vom Client die Eingaben von Tastatur und Maus und sendet im Gegenzug die entsprechenden Video- und Audiosignale zurück an den Client. Für den Benutzer ensteht der Eindruck, als würde direkt am Client gearbeitet werden. Tatsächlich geschieht aber alles auf dem Server. Die für die hohe Rechneleistung des Terminal-Servers notwendige Hardwareausstattung macht ihn sehr teuer. So muss etwa die Größe des RAM jener entsprechen, die alle Clients als Einzelplatzrechner zusammen benötigen würden. Ähnlich verhält es sich mit der Leistung der CPU und allen anderen Komponenten. In unserem Fall würden wir bei etwa 1500€ für den Server liegen, dabei wäre die Leistung allenfalls als ausreichend zu bezeichnen. Die Thin-Clients sind trotz ihrer geringen Leistung ebenfalls verhältnissmäßig teuer. 250-350€ ohne Tastatur, Maus und Monitor sind hier die Regel.
Vorteile | Nachteile |
---|---|
einfache Client-Hardware, keine Konfiguration notwendig | Thin-Client Hardware ist verhältnismäßig teuer |
energiesparend, ein Thin-Client verbraucht etwa nur 10W | teurer Terminal-Server (min. 4 Kerne und 4GB RAM, etwa 1500€) |
nur ein zentrales Betriebssystem, Zeitersparnis bei der Administration | hohe Lizenzkosten bei der Verwendung von MS-Betriebssystemen |
- 2. Ein Upgrade der vorhandenen Workstations
Die alte Struktur mit Einzelplatzrechnern bliebe erhalten, lediglich die Hardware würde ausgetauscht. Statt einer Festplatte würde ein Flash-Speicher verwendet. Der ist zum Einen leiser(0dB) und zum Anderen kann er mittels eines Schalters (physikalisch) schreibgeschützt werden. So können die Schüler nichts am installierten System verändern oder zerstören. Speichermöglichkeiten für Dateien o.ä. gäbe es nur auf USB-Sticks. Eine Kontrolle der Rechner vom Lehrer-PC aus ist auch bei dieser Konfiguration mittels einer speziellen Software über das lokale Netzwerk möglich. Der Lehrer kann damit auf seinem Rechner jeden anderen Bildschirm einsehen, sperren, etc.
Vorteile | Nachteile |
---|---|
Flashspeicher kann hardwareseititg schreibgeschützt werden | Speicher ist Begenzt im momen sind 4GB bis 8GB im bezahlbaren rahmen |
Die Rechner können von der Schule selbständig eingesetzt werden und benötigen nicht zwangsläufig einen Server oder Netzwerkanschluss | Die Anzahl der Schreib/lese-Operationen ist begrenzt danach ist der Flashspeicher defekt |
Bei einem Defekt muss nur schnell der Speicher ausgetauscht werden | soll ein update durchgeführt werden so muss in jedem Client der Speicher getauscht/überschrieben werden |
Eine dritte Lösung muss her
Die anspruchsvolle Terminal-Server Lösung liegt weit außerhalb des finanziellen Rahmens, das Upgrade der Einzelplatzrechner bietet zu wenig Benutzerkomfort und verursacht einen hohen administrativen Aufwand für uns.
Von den Kosten her kann man Thin-Clients problemlos durch vollwertige PCs ersetzen. Mini-ITX Boards im passenden Gehäuse sind nicht ganz so schick und verbrauchen geringfügig mehr Strom, können jedoch alle Anwendungen selbst berechnen. Dadurch werden Kosten beim Server eingespart. Damit nun nicht jeder Rechner ein eigenes Dateisystem hat, was bei Defekten,Upgrades usw. Arbeit verursacht, kann man ein Dateisystem zentral auf einen Boot-Server legen. Da die Rechner dann über das Netzwerk von da aus booten, brauchen sie keine eigene Festplatte mehr. Einen solchen Rechner nennt man auch Fat-Client. Da der Boot-Server nur das Dateisystem bereitstellt hat er deutlich niedrigere Hardwareanforderungen als ein Terminal-Server. Für unter 1000€ kann man ein System zusammenstellen, was auch in näherer Zukunft allen Anforderungen genügt.
Als Software wäre uns eine Art Live-Distribution sehr lieb, hier kann der Anwender nichts kaputtmachen-somit entsteht weniger Wartungsarbeit für uns. Also wird das komplette Dateisystem schreibgeschützt. Dadurch bleibt der Zustand nach der Installation immer erhalten. Erweitert wird das System durch die Möglichkeit Benutzer anzulegen, die dann innerhalb Ihres /home schreiben dürfen. Der nicht angemeldete Benutzer (Gast) darf das während der Sitzung auch, mit dem logout wird aber der Urzustand des /home wieder hergestellt. Beim nächsten login erwartet den Gast wieder ein leerer Standard Desktop, der also immer gleich aussieht. Da die Änderungen am Dateisystem nur im RAM des Clients passieren, können auch findige Schüler, die sich irgendwie einen root-account organisiert haben, nichts auf dem Server zerstören. Selbst 'ein rm -rf /' in der Konsole zerstört nur die aktuelle Sitzung, nach dem Neustart des Clients ist alles wieder da! Dieses Softwareseitig fast unzerstörbare System ist nun bezahlbar und erfüllt fast alle Wünsche und Anforderungen von beiden Seiten.
Etwas Überzeugungsarbeit
In den ersten Gesprächen mit der Schule erklärten wir zunächst unsere grundsätzliche Bereitschaft, der Schule auch bei einer Windows-Lösung zur Seite zu stehen. Als die Sache dann konkret wurde, konnten wir mit dem Kostenfaktor entscheidend punkten. Die Windows Terminal Server Lizenz kostet inklusive 5 Client-Lizenzen 600€ und die zusätzlich notwendigen 5 Client Lizenzen kosten jeweils 120€. Das sind zusammen etwa 1200€ und damit fast 20% des Gesamt-Budgets, da reicht der Rest des Geldes gerade mal für die Hardware des Terminal Servers und zwei Clients. Den Wunsch nach einer gewohnten Oberfläche, speziell für die Lehrerschaft, nahmen wir natürlich sehr ernst. Jedoch können auch wir nicht zaubern, und selbst eine Windows XP Oberfläche sieht nun mal deutlich anders aus als die von Windows 98. Um ein Umlernen kommen die Nutzer also nicht herum. Wertvolle Punkte sammeln konnten wir nun noch mit dem Argument, das der Standard Desktop auf allen Geräten gleich aussieht und nicht verändert werden kann. Auch der persönliche Desktop (nach Anmelden mit Benutzer/Passwort) sieht exakt so aus, wie er beim letzten mal verlassen wurde. Das ist erheblich mehr Komfort als bisher auf 10 unterschiedlichen Windows Installationen zur Verfügung steht. Aller Gegenargumente beraubt stimmte die Schule der Errichtung eines Systems mit Boot/Flie-Server und mindestens 10 Fat-Clients unter Verwendung von Linux zu.
Umsetzung
Die Hardware
Der Server
So ganz genau konnten wir die zu erwartende Belastung nicht berechnen. Mit einem Intel Quad Core und 8GB RAM wähnen wir uns aber mal auf der sicheren Seite. Ein Software-Raid-Verbund der 4 Festplatten soll für genügend Ausfallsicherheit sorgen.
Mainboard ASUS P5BV-C/4L | 190€ |
Intel® Core 2 Quad Q9550 | 210€ |
Gehäuse Midi Tower | 50 € |
2 Dimm-Modul Kingston ValueSelect 4096MB | 130€ |
Netzteil be quiet BQT L7-530W | 60€ |
4 Festplatten 250 GB 7/24 | 240€ |
Summe | 880 € |
Die Clients
Etwa 3000€ des Budgets stehen für die 10 Clients zur Verfügung. Nach einiger Suche stießen wir auf die Intel Atom-Serie. Ein mit 1,6 GHz getakteter Intel Atom 330 bietet mit 2 Kernen(+HT) mehr als genug Leistung uns passt mit 65€ für Mainboard mit Prozessor genau in den Kostenrahmen. Hier die gesamte Client-Hardware in der Übersicht:
Mainboard mit Prozessor | 65€ |
Gehäuse mit externem 75W Netzteil | 60 € |
2Gb DDR2 Speicher | |
Monitor (19" 1440x900 px) | |
Tastatur/Maus | |
Summe | 260 € |
Anmerkung: Ein ThinClient kostet ohne Monitor und Eingabegeräte das gleiche. Dafür ist er zwar kleiner und verbraucht noch weniger Strom, besitzt aber gar keine eigene Rechenleistung.
Die Software
Server
Server:
- Voraussetzung: Debian Minimal-Installation
- zusätzlich benötigte Pakete:
- tftp - dhcp-server - syslinux (pxelinux.0 und gPXE benötigt) - iscsitarget-modules-[kernelversion] - [kernelversion] => shell: "uname - r" - iSCSI-Server installieren - siehe http://www.lug-wr.de/wiki/index.php/Howto:iscsi - Kernelmodul für iSCSI installieren (s.o.) und laden ("modprobe iscsi-target") - Daemon aktivieren: in "/etc/default/iscsitarget" das "ISCSITARGET_ENABLE" auf "true" setzen
Ablauf:
PXE startet ("Boot from LAN" im BIOS) => BIOS sucht eine IP-Adresse über DHCP => Server übergibt neben IP-Adresse für den Client die Parameter "IP-Adresse des tftp-Servers" und "Dateiname des zu bootenden Images"
=> hier könnte komplettes Block-Device kommen und von diesem gebootet werden. Sehr Netzwerk- und RAM-lastig, tun wir nicht
=> wir liefern gPXE aus (Minilinux) => gPXE beherrscht iSCSI => zu bootendes Hauptsystem via iSCSI holen
Technisch als MultiStage-Bootloader: First Stage =========> Second Stage ==========> Third Stage PXE (Bios) -> tftp -> gPXE-Linux -> iSCSI -> Hauptsystem
Installation des Debian Grundsystems mit LVM
Einrichten des DHCP Servers
apt-get install dhcp3-server
in "/etc/dhcp3/dhcpd.conf" hinzufügen:
allow booting; allow bootp; allow unknown-clients; ... subnet 10.5.5.0 netmask 255.255.255.0 { range 10.5.5.10 10.5.5.30; option routers 10.5.5.1; filename "gpxelinux.0"; server-name "10.5.5.1"; }
Konfiguration von gPXE / sysLinux und TFTP
apt-get install syslinux tftpd-hpa
Datei "gpxelinux.0" und die Datei "sanboot.0" soll mit TFTP an den Client ausgeliefert werden, dazu mussen Sie von "/usr/lib/syslinux" nach "/var/lib/tftpboot" kopiert werden
cp /usr/lib/syslinux/.* /var/lib/tftpboot/
nun muss der TFTP-Server noch eingeschaltet werden, dazu in der Datei "/etc/default/tftpd-hpa" an der Stelle RUN_DEAMON="no" RUN_DAEMON="yes" eintragen
Ab jetzt sollte der Client schon in der Lage sein gPXE über das Netzwerk zu Laden, dazu einfach mal einen Rechner im BIOS auf Netzwerkboot (PXE) stellen und testen.
Einrichten des iSCSI Targets
apt-get install iscsi-tagret iscsitarget-modules-[kernelversion]
Die von installierte Kernelversion wird mit dem Befehl
uname - r
ausgegeben.
Einrichten des NFS-Servers
apt-get install nfs-kernel-server
Anpassen der /etc/exports
Einrichten des Samba-Servers
Saba LDAP-Tools
Saba Konfiguration
Konfiguration des LDAP Servers
apt-get install slapd ldapscripts
Client
Installation des Clientsystems (im Moment Kubuntu 10.04)
An dieser Stelle wäre auch ein Skole-Linux bzw. ein Edubuntu denkbar.
das Livesystem booten, und um iscsi erweitern
sudo aptitude update sudo aptitude install open-iscsi
nun das tagrent vom server holen und Lokal einbinden
iscsiadm -m discovery -t st -p 10.5.5.1 iscsiadm -m node -T iqn.2009-10.san:lvm.ubuntu-disk -l
dannach die installation starten und auf der nun neu existierenden Platte installieren.
Netzwerkboot über iSCSI ubuntu 9.10
Benötigte Programme
sudo aptitude install initramfs-tools open-iscsi sysv-rc-conf
Ändern des initiatorname
sudo echo "InitiatorName=iqn.2009-11.lan.san:01:22b2ed5d3ccc" > /etc/iscsi/initiatorname.iscsi
Anegen der Datei für das erstellen der initramfs
sudo touch /etc/iscsi/iscsi.initramfs
Kopieren der datei
sudo cp /usr/share/initramfs-tools/scripts/nfs-top/udev /usr/share/initramfs-tools/scripts/local-top/early_udev
Initramfs aufordern die iscsi module mit einzubauen
sudo echo "iscsi" >> /etc/initramfs-tools/modules
die neue Initramfs bauen
sudo update-initramfs -u
- GRUB 1 anpassen
title Ubuntu 9.10, iSCSI uuid f859db1e-39f8-4539-9f0e-8292f8f93cca kernel /vmlinuz ISCSI_TARGET_NAME=iqn.2009-11.lan.san:vg0.thinclient ISCSI_TARGET_IP=10.1.20.2 root=UUID=021ebcfc-188a-41ba-9864-ee18cbf7af9f ro initrd /initrd.img quiet
- GRUB 2 anpassen
dabei hilft diese anleitung http://etherboot.org/wiki/sanboot/ubuntu_iscsi
Das Overlay-Dateisystem AUFS Einrichten
https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
Automatisches einhängen der NFS Freigaben
in der /etc/fstab folgende Zeilen ergänzen ...
server:/srv/nfs/home /srv/nfs/home nfs defaults 0 0 server:/srv/nfs/opt /opt nfs ro,defaults 0 0
Anmeldung des Schülers mit Hilfe von LDAP
LDAP
pam-ldap
pam-mount
/etc/security/pam_mount.conf
<?xml version="1.0" encoding="UTF-8"?> <pam_mount> <volume user ="*" server ="SAMBASERVER" mountpoint ="/home/%(USER)" path ="%(USER)" fstype ="smbfs" /> </pam_mount>
datei /etc/pam.d/common-auth
auth required pam_mount.so
datei /etc/pam.d/common-session
session optional pam_mount.so