L i n u x - S c h u l e Artikel bei Linux Enterprise
	Homepage | Server | Linux-Clients | Win9x-Clients | WinNT-Clients | Win3.11-Clients | Dos-Clients | Utilities

Arktur - Praktische Hinweise und tägliche Praxis von Thomas Litsch - Erschienen in Linux Enterprise 3/2001

Weitere Online Artikel bei Linux Enterprise:
Arktur - ein Kommunikationsserver für die Schule von Reiner Klaproth
Linux in der Schule von Karl Sarnow

Der c't ODS Kommunikationsserver Arktur ist einfach zu installieren und bietet neben den meisten Diensten, die man im Netz benötigt, auch einige schulspezifische Lösungen an. Er befreit aber nicht von grundlegenden Überlegungen bei der Planung der Benutzerstruktur und der Vorbereitung der Clients. Einige Ansätze dazu und einen besonderen Dienst für den Schulalltag stellt dieser Artikel vor.

Anbinden von Clients unter Windows

Die meisten Schulen setzen heute Windows 95 oder 98 ein, wobei die Anbindung von Win95 am einfachsten ist, weil hier (zumindest bei den frühen Versionen) noch nicht auf eine Passwortverschlüsselung geachtet werden muß. Bei allen neueren Windows Versionen muß zur Verwendung von Klartextpasswörtern ein Registry-Patch eingespielt werden, der auf der Installations-CD-ROM im Verzeichnis /software/regedit zu finden ist.

Wenn die Verkabelung steht, reicht auf den Clients (egal ob Windows oder Linux) die Angabe, dass eine IP Adresse per dhcp bezogen wird, um mit dem Server Kontakt aufnehmen zu können. Um bei Problemen jedoch eine bessere Kontrollmöglichkeit zu haben, sollten die IP-Adressen statisch vergeben werden. Dazu sind 19 Adressen aus dem Netz 192.168.0.x Städtenamen zugeordnet. In den weiteren Netzwerksträngen 1, 2 und 3 gibt es nur je 9 statische Adressen, durch einfache Änderungen der /etc/dhcpd.conf lassen sich aber mehr Namen der Form »client-b21« für die statische Vergabe vorsehen. Statische IP-Nummern sind besonders dann vorteilhaft, wenn man innerhalb des Windowsnetzes Drucker oder Verzeichnisse freigeben möchte. Um die Suche nach Computern im Windowsnetz zu beschleunigen, sollte Arktur auch als WINS Server eingetragen werden, was bei dynamischer Vergabe automatisch geschieht.

Arktur dient als Anmeldeserver in der Domäne »workgroup« (über das gleichnamige Schlüsselwort in /etc/samba/smb.conf änderbar), wenn der »Client für Microsoft Netzwerke« installiert ist und die Arbeitsgruppe dort eingetragen ist. Bei jeder Anmeldung wird dann das Script »/etc/samba/scripts/logon.bat« abgearbeitet, was zur Verteilung von Dateien oder weiteren Programmaufrufen genutzt werden kann. Hier ist auch der richtig Ort für eine »config.pol« Datei, die mit dem Policy Editor »poledit« erstellt wurde [1].

Zur Absicherung des Schulbetriebes setzen immer mehr Schulen sog. PC-Wächter Karten ein, die dem Anwender ein Schreiben auf die lokale Festplatte nur vorgaukeln, diese nach einem Neustart aber wieder im ursprünglichen Zustand zeigen. Weil Windows das Benutzerprofil auf der lokalen Platte ablegen möchte, erfolgt aber nach jedem Neustart eine Abfrage, ob die persönlichen Einstellungen gespeichert werden sollen. Um dieses lästige Verhalten zu vermeiden, kann über geeignete Gestaltung des Login-Scriptes die Registry beim Einloggen so gepatcht werden, dass diese Abfrage nicht mehr erfolgt (siehe Kasten »logon.bat«).

Anbinden von Clients unter Linux

Zur Anbindung von Linux Clients müssen NIS- und NFS-Server auf Arktur eingeschaltet werden. Die automatisch erzeugte NIS Domäne kann nach dem Aktivieren mit domainname angezeigt werden. Dieser Domänenname muß auch auf den Clientrechnern eingestellt werden, bei einer SuSE kann man das mit yast unter Administration des Systems, Netzwerkkonfiguration, YP-Client konfigurieren erledigen, die IP Adresse ist im ersten Netz die 192.168.0.1, im zweiten Netz die 192.168.1.1 usw. Dieselben Werte sind auch bei der Einrichtung des Nameservers zu verwenden.

Wenn die Einbindung der Homeverzeichnisse mit mount arktur:/home /home -t nfs -o nolock funktioniert, kann der Eintrag in /etc/fstab erfolgen: arktur:/home /home nfs auto,rw,nolock (die Option nolock ist wichtig für StarOffice, seine Javakomponente hängt sich sonst beim Starten auf).

Nach dem ersten Einloggen hält ein SuSE-Client noch eine Überraschung für den Anwender bereit: die Eingabe von ls wird mit einer Fehlermeldung quittiert, weil es für die Verwendung von ftp in jedem Homeverzeichnis ein Unterverzeichnis ~/bin mit einer statisch gelinkten Version von ls gibt und dieses Verzeichnis bei SuSE im Verzeichnispfad ganz vorne steht. Die Vertauschung der Variablen $DIR und $PATH in Zeile 33 (SuSE 6.4 und 7.0) von /etc/profile schafft das Problem aus der Welt.

Planung der Benutzerstruktur

Ein Netzwerk mit einem Kommunikationsserver läßt verschiedene Arten von Nutzung zu: 1.) jeder Benutzer wird als Anwender auf dem Server angelegt, 2.) die Benutzer sind bereits auf einem anderen Server angelegt oder 3.) es erfolgt keine individuelle, sondern eine maschinenbezogene, anonyme Anmeldung. In vielen Schulen, in denen es schon vor der Initiative Schulen ans Netz Netzwerke gab, war das so gelöst.

1.) Nur ein persönliches Login bietet den Zugriff auf alle Funktionen des Servers, insbesondere was Email und die Materialverteilung angeht (siehe unten). Soll Arktur nicht nur als Proxyserver zum Surfen, sondern auch als Mail- und Fileserver verwendet werden, so ist das die Möglichkeit der Wahl. Mit tab-getrennten Textdateien (sie sollten DOS CR-LF Zeilenenden haben) können die Anwender schnell klassenweise angelegt werden. Aus den Vor- und Nachnamen der Anwender geniert Arktur dann selbst eine Benutzerkennung: aus dem Schüler Heinz Ratlos wird rheinz, aus der Lehrerin Susi Klever klevers, wobei die Art und Weise der Namensvergabe durch Änderung der entsprechenden Datei geändert werden kann (siehe Kasten Anwendernamen und Passwörter). Es kann bei einer großen Schülerzahl sinnvoll sein, den Nachnamen nach vorne zu stellen und lang zu lassen, um in Verzeichnisbäumen oder Listen schneller suchen zu können. Die Länge der Benutzerkennung ist dabei auf acht Zeichen begrenzt, eine Beschränkung, die bei der Verwendung von Clients auf Basis von DOS oder Windows für Workgroups zur Verbindung mit den Samba-Homeshares notwendig ist.

2.) Eine häufig anzutreffende Situation ist die Koexistenz zwischen Arktur als reinem Kommunikationsserver und einem weiteren Anmelde- und Fileserver, meist unter Novell oder WindowsNT, der dann auch für die Verwaltung der Emails zuständig ist. Wird der Mail- und Newsverkehr über UUCP abgewickelt (was zu empfehlen ist), so kann bereits beim Einrichten der Verbindung der Server angegeben werden, an den die Mails weitergeleitet werden sollen. Der für Novell verfügbare Mailserver Mercury arbeitet auf diese Weise sauber mit Arktur zusammen. Bei der Verwendung von POP3/SMTP gibt es diesen Komfort leider nicht, hier muß man sich mit einer manuellen Änderung der /etc/sendmail.cf behelfen. Zuerst wird ein Pseudoanwender angelegt, aus dessen POP3 Postfach der andere Server dann seine Mails abholen kann. In sendmail.cf wird mit der Zeile DLlocal:pseudouser angegeben, an wen nicht zustellbare Mails geschickt werden sollen. Aber auch die Weiterleitung an einen anderen Server läßt sich durch Eintrag von DLsmtp:name.server.de manuell nachrüsten.

3) Die dritte Lösung sollte man wirklich nur im Notfall in Betracht ziehen, weil hier keinerlei Kontrolle der Netzaktivitäten mit Hilfe der Logdateien möglich ist. Man kann solche anonymen Anwender mit Hilfe der Systemverwaltung einrichten, indem man die Namen der Anwender entsprechend wählt:

Datei»plaetze«
a 1
a 2
a 3

In solchen Umgebungen sollte es den Anwendern auch verboten sein, Veränderungen am Aussehen des Desktops vorzunehmen, um eine einheitliche Arbeitsumgebung für alle sicherzustellen. Unter Windows bietet sich hier wieder poledit an.

Arbeiten vor dem Anlegen von Anwendern

Beim Anlegen von Anwendern werden Dateien, die in /etc/skel abgelegt sind, automatisch in das Homeverzeichnis der Anwender kopiert. Dadurch ist es sehr einfach möglich, den Anwendern einen vorkonfigurierten Desktop mit den wichtigsten, zur Arbeit notwendigen Verknüpfungen zur Verfügung zu stellen. Arbeitet man mit Windows (9x, NT oder 2000) als Clientbetriebssystem, so sollte man auch den benutzerspezifischen Teil der Registry, die Datei user.dat, vorkonfigurieren. Dazu legt man einen Anwender als Musteruser an und installiert einen Clientrechner mit der gesamten im Schulalltag benötigten Software. Diese Software und die persönliche Arbeitsumgebung richtet man dann nach Wunsch ein. Dazu zählen z.B. der Standardpfad für die Dateiablage, der auf das nach U:\ verbundene Homeverzeichnis des Anwenders zeigen sollte.

Auch unter Linux sollte ein Musteruser den KDE Desktop und die Menüs im Hinblick auf Sprachauswahl und spezielle Software anpassen und nach /etc/skel kopieren. Die persönlichen Einstellungen für Mails und News können dann über die beiden Variablen %user% und %username% leicht angepasst werden. Wer hierbei nicht selbst zur Tat schreiten möchte, der findet beim Bildungsserver Schleswig-Holstein im Projekt kmlinux eine Linux-Distribution, die auf SuSE beruht und speziell auf die Bedürfnisse von Schulen abgestimmt ist [3].

Arbeitserleichterungen I - Materialverteilung

Ein Server in der Schule sollte noch etwas mehr können, als nur Netzdienste zur Verfügung stellen: er sollte Lehrer und Schüler bei ihrer Arbeit unterstützen. Zur Unterstützung der Lehrer gibt es bei Arktur die Fachlehrer-Shell. Sie wird über Telnet bedient und bietet Funktionen an, die den Umgang mit Schülerdokumenten erheblich vereinfachen. Um diese Shell benutzen zu können, muß sie dem Lehrer mit der Menüoberfläche zur Anwenderverwaltung explizit zugewiesen werden (als Vorgabe haben alle Lehrer und Schüler /usr/bin/passwd als Shell). Nach dem Aktivieren der Änderungen ist der Lehrer dann auch Mitglied der Gruppe fachl, die in allen Schülerhomeverzeichnissen Schreib- und Leserechte hat. Beim nächsten Einloggen wird der Lehrer mit einer Meldung zur aktuellen Größe seines Emailpostfaches begrüßt und könnte dann im nächsten Menüpunkt gleich mit pine seine Mails lesen (oder sich die Hilfe anschauen, die in allen Menüs der Systemadministrationsoberfläche verfügbar ist). Er kann sich aber auch den Menüpunkt Arbeit aufrufen und sieht das Menü in Abbildung 1.

Abbildung 1: Fachlehrermenü

Dieses Menü bietet eine einfache Oberfläche zum Verteilen, Einsammeln und Löschen von Unterrichtsmaterial. Das vom Lehrer verteilte Material bleibt allerdings weiterhin im Besitz des Lehrers, die Schüler müssen es unter einem anderen Namen abspeichern, unter dem es der Lehrer später wieder einsammeln kann. Es kann nicht nur an Klassen verteilt werden, sondern auch an Projektgruppen (z.B. die Schülerzeitungsredaktion), die vorher durch den Systemverwalter angelegt wurden. Eine andere Möglichkeit der Materialverteilung ist die Ablage der Daten in einem temporären Verzeichnis /home/tmp (unter Windows das Verzeichnis T:\), von wo aus die Schüler sie dann in ihr Verzeichnis U:\ kopieren. Durch den Kopiervorgang werden die Besitzrechte auf den Schüler übertragen. Sammelt der Lehrer die Datei ein, so entsteht in seinem Homeverzeichnis für jeden Schüler ein Unterverzeichnis, in dem die Datei dann liegt. Bei einer Projektgruppe ist das etwas einfacher, hier gibt es eine Samba Freigabe mit dem Namen des Projektes, in die die Daten abgelegt werden können. Im Gegensatz zu einem normalen temporären Verzeichnis können diese Dateien aber von allen Projektmitgliedern (sie gehören einer Unix-Gruppe an) geändert werden.

Leider hat die Fachlehrershell einen Nachteil: sie kann unter Linux auf dem Client nicht verwendet werden, weil Gruppen- und Benutzernamen in /etc/passwd gesucht werden, die auf den Clients aber so nicht vorhanden sind. Hier muß also die normale bash als Shell eingetragen werden und mit dem Kommando gpasswd -a anwendername fachl ein Eintrag in die Gruppe der Fachlehrer erfolgen. Nach einer Telnet-Verbindung zum Server kann die Fachlehrershell mit dem Kommando /usr/lib/ods-server/shells/shell.fach aufgerufen werden.

Arbeitserleichterungen II - das Webinterface

Ein häufiges Ärgernis in Schulen sind vergessene Passwörter. Normalerweise ist es nur als root oder bei Verwendung der Systemverwaltungsoberfläche möglich, das Passwort eines anderen Anwenders zu ändern. In der Webadministration, die von jedem Client-Rechner unter http://www/admin2 zu erreichen ist (der Artikel von Reiner Klaproth zeigt eine Abbildung), ist dies auch für einen »normalen« Lehrer möglich. Der Zugang zu diesen Seiten ist durch ein vom Login-Passwort unabhängiges Passwort geschützt, von dort aus ist neben dem Anstoßen der Internetverbindung auch der Zugang zu browserbasierten Verwaltungstools für Samba (SWAT) und Mysql (phpMyAdmin) möglich. Nicht geschützt ist die Seite http://www/online, das Web-Interface für »normale« Anwender (siehe Abbildung 2). Es bietet einen Webmail Client, einen Dialog zur Änderung des eigenen Passwortes, eine Nutzerübersicht mit Links zu den Homepages der Anwender und die Möglichkeit, eine Weiterleitungsadresse für eigene Emails einzustellen.

Abbildung 2: Das Online Interface

Schlußakkord

Arktur bringt daneben auch einen Mysql-Server, einen IRC-Server und einen BSCW-Server [4] mit, die allerdings erst auf leistungsfähiger Hardware sinnvoll einsetzbar sind. Der BSCW Server ist wegen der abweichenden Lizenz nicht vorkonfiguriert, sondern muß mit einem make erst eingerichtet werden (weitere Hinweise zur Konfiguration gibt [5]). Als Open Source Produkt ist Arktur für individuelle Erweiterungen offen. Am wichtigsten ist aber sicher die Unterstützung, die er mitbringt: die Heise Redaktion für die ersten Schritte und eine Mailingliste für alle weiteren Probleme [6]. Dort gibt es engagierte Lehrerkollegen, die mit Rat und Tat zur Seite stehen.

Benutzernamen und Passwörter

Eine praktische Funktion an Arktur ist das automatische Anlegen der Anwender aus eine Liste. Wenn einem die automatisch generierten Anwendernamen nicht gefallen, so kann man den Mechanismus in der Datei /usr/lib/ods-server/bin/user ab Zeile 345 ändern. Hier sind die möglichen Kombinationen aufgeführt:

# Zuerst kommen die Lehrer:
#1) Peter Lustig -> lustigp (das Original)
   nl=`genuser -n "$nachname" "$vorname"`
#2) Peter Lustig -> plustig
#   nl=`genuser -v "$nachname" "$vorname"`
#3)Peter Lustig -> lpeter
#   nl=`genuser -v "$vorname" "$nachname"`
#4)Peter Lustig -> peterl
#   nl=`genuser -n "$vorname" "$nachname"`

# Das sind die Schueler
#1) Susi Sorglos -> ssusi (das Original)
   nl=`genuser -v "$vorname" "$nachname"`
#2) Susi Sorglos -> susis
#   nl=`genuser -n "$vorname" "$nachname"`
#3) Susi Sorglos -> ssorglos
#   nl=`genuser -v "$nachname" "$vorname"`
#4) Susi Sorglos -> sorgloss
#   nl=`genuser -n "$nachname" "$vorname"`

Bis zur Version q der Serie 3.0 und bei der Version 3.1 des Heise Verlages wurde dem neuangelegten Anwender sein Anwendername als Passwort gegeben. Aus Bequemlichkeit und mangelndem Sicherheitsbewußtsein ist es oft vorgekommen, dass nicht nur Schüler, sondern auch Lehrer ihr Passwort nicht geändert haben. So konnten fremde Emails oder Dateien gelesen oder, noch schlimmer, unter fremdem Namen Email verschickt werden. Ab Version 3.0r und auch in der Version 3.2, die demnächst erscheinen wird, wird für jeden Anwender ein eigenes geheimes Passwort generiert. Beim einzelnen Anlegen von Anwendern erscheint dieses Passwort nur einmal auf dem Bildschirm und muß dort abgeschrieben werden, beim Anlegen von Anwendergruppen wird eine tab-getrennte Textdatei mit Anwendernamen und Passwörtern erzeugt, die dann beliebig weiterverarbeitet werden kann. Diese Datei trägt den gleichen Namen wie die Datei, aus der die Anwender ausgelesen wurden, jedoch mit der Dateiendung out. Wer dennoch zum alten Mechanismus zurückkehren möchte, kann auch dazu die Datei /usr/lib/ods-server/bin/user editieren. Die Zeile 386 npass=`pwgen --numeral 8` muß dazu durch die Zeile npass=$name ersetzt werden.

Die Datei logon.bat

Zum Patches der Registry benötigt man den Namen des angemeldeten Anwenders, der erst ab Windows NT in der Variablen %username% verfügbar ist, unter Win9x hilft hier das Programm putinenv.exe. Das modifizierte Login Script kann dann so aussehen (Download von Script und putinenv.exe unter [2]):

@echo off
net use u: \\arktur\homes /yes
net use p: \\arktur\pub /yes
net use t: \\arktur\tmp /yes
net time \\arktur /set /yes

REM Batch zum Anlegen von Usern in der Win9x Registry beim Einloggen
REM Alle HKEY Schlüssel bestehen nur aus einer Zeile!
REM Der Name des Anwenders wird ausgelesen und in der Variable %username% abgelegt.

\\arktur\netlogon\putinenv.exe L

REM Ein neuer Registry Eintrag wird generiert
set regfile=c:\windows\temp\profreg.reg
echo REGEDIT4> %regfile%
echo.>> %regfile%
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProfileList]>> %regfile%
echo.>> %regfile%

REM Der Pfad in der naechsten Zeile muss an die Konfiguration der
REM Arbeitsstationen angepasst werden!!!
REM Hier bleibt die User.dat in u:\profile liegen und wird nicht
REM nach c:\windows\profiles kopiert
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\ProfileList\%username%]>> %regfile%
echo "ProfileImagePath"="U:\\profile">> %regfile%

REM Damit nicht nach dem Passwort gefragt wird, schalten wir das ab
echo. >> %regfile%
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network]>> %regfile%
echo "DisablePwdCaching"=dword:00000001>> %regfile%

REM Der erzeugt Registy Eintrag wird eingetragen: /s fuer silent!
regedit /s %regfile%

[1] http://www.ping.de/sites/afu/poledit.htm

[2] http://www.linux-schule.de

[3] http://www.lernnetz-sh.de/kmlinux

[4] Linuxenterprise 1/2001, S. 36 und http://bscw.gmd.de

[5] http://home.nexgo.de/thomas.litsch/s-bscw.htm

[6] http://www.heise.de/ct/schan/support.shtml

Nach oben

© Thomas Litsch, zuletzt aktualisiert 09.05.2001, Email: thomas.litsch@linux-schule.de