Pflichtenheft aktuell (2)
Hans-Dietrich Kirmse
hd.kirmse at gmx.de
Wed May 14 20:57:11 CEST 2003
Pflichtenheft
=============
1. Anforderungen aus Sicht des Administrators
1.1 Installation des Servers
1.2 Nutzerverwaltung
1.2.1 Anlegen der Accounts
1.2.2 Aktualisieren der Accounts
1.2.3 Löschen der Accounts
1.2.4 Synchronisation mit dem Schulverwaltungsprogramm
1.2.5 Klausurumgebung
1.3 Internetzugang
1.4 Datensicherung
1.5 Absicherung des Servers
2. Anforderungen an die bereitgestellten "Dienste"
2.1 die Standarddienste
2.1.1 Der Proxyserver
2.1.2 Der lokale Webserver
2.1.3 Der Mailserver
2.1.4 Der Fileserver
2.1.5 Der Printserver
2.1.6 Der CD-ROM-Server
2.2 mögliche Zusatzangebote
2.2.1 Der Listenserver
2.2.2 Der Newsserver
2.2.3 Die Homepageverwaltung
2.2.4 Der Datenbankserver
2.3 "Dienste" zur Unterstützung der Teamarbeit bzw. der
schulinternen Kommunikation
2.3.1 Das Wiki
2.3.2 Der CVS-Server
2.3.3 Das Schulportal
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.1 Installation des Servers
================================
lehrersichere Standardinstallation
----------------------------------
bedeutet, daß die Eingaben auf das wirklich notwendige reduziert
sind. Es wird davon ausgegangen, das für den Schuleinsatz dieses
System als einziges auf dem Server zum Einsatz kommt. Die Einrichtung
der Festplatte (Partitionierung, Formatierung, Installation,
Hardwareerkennung, ...) sollte weitestgehend automatisch ablaufen
Testinstallation
----------------
für Probeinstallation oder als Testumgebung sollte die Installation
als Zweitsystem (in eine Partition) trotzdem möglich sein. Das könnte
z.B. durch einen zusätzlichen Menüpunkt oder durch einen Parameter
beim Aufruf des Setups geschehen. Das muß aber für den Admin
dokumentiert sein.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.2 Nutzerverwaltung
========================
Um einen sicheren Server zu gewährleisten, wird versucht, konsequent
das "Prinzip des kleinsten Privilegs" einzuhalten. Es ergeben sich für
die schulischen Anforderungen folgende Einteilung:
- Admin
- Lehrer mit besonderen Aufgaben => spezielle Accounts
- Schüler (gewöhnlich aber nicht zwingend in Klassen bzw. Jahrgängen)
1.2.1 Anlegen der Accounts
----------------------------
jeder User erhält einen Account,
dieser kann erstellt werden über
- die Eingabe in ein Menü mit folgenden Feldern:
Name
Vorname
Login # wenn leer, dann sollte hier generiert werden
Auswahl ob Lehrer oder Schüler
Gruppe
Passwort # wenn leer, dann wird ein Passwort generiert
Kommentar
- das Einlesen der Daten aus einem File
Format des Textfiles: Nachname Vorname(n) # optionaler Kommentar
andere Daten werden über Menü abgefragt (ob Lehrer/Schüler, Gruppe)
Textfile sollte unter Linux, Win bzw. Mac erstellt werden können.
- durch Datenübergabe eines weiteren Programms
um z.B. die BW-Musterlösung realisieren können, soll die Routine
zum Erstellen des Accounts auch durch ein weiteres Programm
erfolgen können, von dem die benötigten Daten geliefert werden.
Das Erstellen des Loginnamen soll ein separates Modul (Script)
übernehmen, deren Schnittstellen zum aufrufenden Programm gut
dokumentiert sind. Dadurch könnte durch Austauschen dieses Moduls
gewährleistet werden, das die Loginnamen auch nach anderen Schemata
generiert werden.
Das Login könnte standardmäßig z.B. aus dem ersten Buchstaben des
Vornamens und aus dem Nachname gebildet werden. Dabei sind
max. 14 ASCII-Zeichen möglich, sonst wird entsprechend gekürzt.
Beispiel: Manfred Mustermann -> mmustermann
Sollten Logins nach diesem Muster schon vergeben sein, wird
automatisch variiert z.B. 2 Buchstaben vom Vornamen
Für Schulen, die für Lehrer und Schüler das Login auf verschiedene
Art und Weise generieren wollen, wird dem Admin ein Menü
bereitgestellt, sodaß er für Lehrer und Schüler die Vergabe des
Loginnamens getrennt nach den folgenden Schemata einstellen kann:
1. Buchstabe Vorname + Nachname (aus Peter Meier wird pmeier)
Nachname + 1. Buchstabe Vorname (aus Peter Meier wird meierp)
1. Buchstabe Nachname + Vorname (aus Peter Meier wird mpeter)
Vorname + 1. Buchstabe Nachname (aus Peter Meier wird peterm)
beim serienweisen Anlegen werden zufällige Passwörter generiert,
die Ausgabe erfolgt zwecks Weiterverarbeitung in eine csv-Datei,
mögliches Format: Name; Vorname(n); login; Passwort
Beim Erstellen des Accounts wird gleichzeitig ein Mailaccount
generiert. Die Mailadresse ergibt sich aus dem Login und der
Schuldomain.
Beispiel: Manfred Mustermann <mmustermann at schuldomain.de>
optional: es werden Konfigurationsdateien für verschiedene
Mail-Clients bereitgestellt (Netscape, Opera, Pegasus)
1.2.2 Aktualisieren der Accountdaten
--------------------------------------
falls mit den Gruppen die Klassen- bzw. Jahrgangsstrukturen
abgebildet werden, muß es für den Administrator über ein Menü möglich
sein, am Schuljahresende diese Strukturen zu ändern (6b -> 7b).
auch für einzelne Schüler muß für den Administrator das Ändern
der Gruppenzugehörigkeit über ein Menü möglich sein
(z.B. für Wiederholer).
Damit z.B. die BW-Lösung auch realisiert werden kann, soll das
Programm auch durch andere Programme aufgerufen werden können, wobei
die Schnittstellen zum aufrufenden Programm gut dokumentiert sind.
die Nutzer müssen ihre Passwörter jederzeit ändern können
(angedacht: Webinterface)
optional: die Schüler können die Qualität ihrer Passwörter testen.
Durch den Admin sollten verschiedene Restriktionen vorgegeben werden
können z.B. Mindestlänge, auch numerische Zeichen, max. Anzahl von
Anmeldeversuchen
Ausgewählte Lehrer (z.B. Informatiklehrer) sollen die Möglichkeit
erhalten können, über ein Webinterface die Passwörter von Schülern
neu zu setzen.
Im Unterricht sollte eine einfache Kontrolle der Verwendung des
richtigen Logins möglich sein. Denkbar wäre das Generieren einer
Webseite, bei der alle angemeldeten Nutzer und die betreffenden PCs
aufgelistet werden. Dieses sollte sich nur auf die Rechner des
betreffenden Raumes beziehen.
Es sollte weiterhin durch den Lehrer einfach möglich sein, für
jeden Arbeitsplatz die Anmeldungen nachzuvollziehen.
1.2.3 Löschen der Accounts
----------------------------
Für den Administrator wird über ein Menü ermöglicht, ganze Gruppen
am Schuljahresende zu löschen.
Auch einzelne Schüler kann der Administrator über ein Menü löschen.
(z.B. wegen Umzug)
Auch dieses Script(?) soll durch andere Programme aufgerufen werden
können, wobei die Schnittstellen zum aufrufenden Programm gut zu
dokumentierten sind.
1.2.4 Synchronisation mit dem Schulverwaltungsprogramm (BW-Lösung)
--------------------------------------------------------------------
# spezielle deutsche optionale Lösung:
Um die Nutzerverwaltung in der Art der BW-Lösung nachzugestalten,
wird ein Programm bereitgestellt, welches die vom Schulverwaltungs-
programm bereitgestellten Daten mit den Daten des Servers (LDAP)
abgleicht.
Wenn ein User auf der Diskette enthalten ist aber nicht auf den Server
wird dieser angelegt. Ist er auf den server aber nicht auf Diskette
wird der Account gelöscht. Andernfalls werden die Daten aktualisiert.
Dieses programm greift dazu auf die gerade angegebenen Scripte zum
Anlegen, Aktualisieren und zum Löschen der Accounts zurück.
In dieser Art sollten sich auch andere Schulverwaltungsprogramme
durch modifizierte Steuerprogramme zur Nutzerverwaltung einsetzen
lassen.
1.2.5 Klausurumgebung
-----------------------
Es geht darum, für eine bestimmte Anzahl/Gruppe von Computern und
einer bestimmten Anzahl von Accounts zeitweise in einen Zustand zu
versetzen, um einem Lehrer die sichere und komfortable Durchführung
von Prüfungen am Rechner zu ermöglichen.
Dazu müssen ALLE Kommunikationsmöglichkeiten abgeschalten werden,
ebenso der Zugriff auf ALLE Netzwerkressourcen wie Home-, Tausch-
und andere Netzlaufwerke. Ebenso muß der Zugriff auf ALLE Dienste
wie Webserver, Proxy, Datenbank, Wiki und dergleichen mehr.
Ausnahme sind die Dienste samba, dhcp, dns. Auf den Fileserver
wird der Zugriff auf ein readonly-Laufwerk zum Austeilen von Dateien
ermöglicht und ein spezielles Laufwerk zum Einsammeln. Jeder Schüler
kann dort seine Dateien dort ablegen, ohne das andere Schüler diese
zu sehen bekommen.
Durch die Klausurumgebung ist zu gewährleisten, daß kurz vor Beginn
der Klausur von einem Lehrer durch Start eines Skripts ein
spezieller Satz Klausur-Benutzer komplett neu initialisiert wird.
Bei dieser Initialisierung werden auch neue (Einmal-)Passwörter für
diese Accounts generiert, damit sich während der Prüfung nicht von
anderer Stelle des Netzes jemand mit dem evt. vorher schon einmal
bekannt gewordenen Standard-Klausur-Passwort eingeloggt werden kann
und damit auch Daten zuspielen kann.
Diese Einmal-Passwörter müssen in einer druckbaren Version bereit-
gestellt werden, um damit ein zügiges Austeilen der Passwörter zu
ermöglichen.
Zur Überwachung der laufende Klausur werden alle Domain-Logins/Logouts
während der Klausurzeit dem Lehrer auf seinem Arbeitsplatz angezeigt.
zusätzlich werden diese Daten auch in ein Protokollfile geschrieben.
Nach Beendigung der Klausur ist die Konfiguration ohne zusätzlichen
Aufwand in den Ausgangszustand zurück zu versetzen.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.3 Internetzugang
======================
Die Einrichtung des Internetzugangs sollte ebenso wie die
Installation so einfach wie möglich erfolgen (Menü).
# aus deutscher Sicht - also als optionales Modul:
da von den meisten Schulen der kostenlose T-Online-Zugang genutzt
wird, sollte ein spezielles Menü für diesen Zugang eingerichtet
werden. Dabei sollte die Menüführung auf dieses Formular Bezug
nehmen (die gleichen Begriffe, Angabe der Zeile, ...)
für Mail und News wird vom Winshuttle eine Maildomain kostenlos
zur Verfügung gestellt (empfohlen UUCP). Auch hier sollte mit einem
speziellen Menü die problemlose Einrichtung durch den Admin erfolgen
können.
für Schulen, die keinen kostenlosen Zugang nutzen können (VHS, Zweit-
und Drittzugänge) sollte ein Abrechnungssystem eingerichtet werden.
Dabei wird dem Lehrer, der den Internetzugang freischaltet
(Webinterface), die Dauer der Internetnutzung protokolliert. Für die
Abrechnung werden die lehrerbezogenen Verbindungsdaten dem Admin
aufbereitet zur Verfügung gestellt. Dem betreffenden Lehrer werden
seine Verbindungsdaten per E-Mail mitgeteilt.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.4 Datensicherung
======================
falls im Server eine (ausreichend große) zweite Festplatte zur
Verfügung steht, sollte optional ein automatisches Backup
eingerichtet werden. Das bedeutet insbesondere, daß OHNE tägliche
Betreuung (z.B. wegen Bandwechsel) ein aktuelles Backup zur Verfügung
gestellt wird.
Es sollte (alles unter Beachtung des Datenschutzes) das Backup
problemlos zurückgespielt werden können oder ein einfaches Zugreifen
auf die Daten ermöglicht werden.
# siehe http://linuxwiki.de/rsync_2fSnapshotBackups (deutsch)
# original: http://www.mikerubel.org/computers/rsync_snapshots/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.5 Absicherung
===================
Es sollte dem Admin eine einfache Einrichtung eine USV möglich sein
(menügeführt).
Es sollten eine lehrersichere Möglichkeit zur Kontrolle auf Root-Kits
etc. vorhanden sein z.B. Tripwire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.1 Der Proxyserver
=======================
Das Surfen darf nur über den Proxy erfolgen können. Damit die Schüler
das nicht nutzen, wenn im Unterricht nicht mit dem Internet
gearbeitet wird, sollte dieser Zugang zum Internet durch den Lehrer
gesperrt und wieder freigeschaltet werden können und zwar für jeden
Raum extra. Das betrifft auch Medienecken, also jede Medienecke
einzeln.
Um das Aufrufen unerwünschter Seiten zumindestens deutlich zu
erschweren, soll ein wirkungsvoller Filter integriert werden.
Die Pflege dieses Filters sollte entweder zentral erfolgen oder
durch Lehrer leicht möglich sein (Austausch und Ergänzung der
Filterlisten)
Da solche Filter niemals alles erfassen können, sollte eine effektive
Kontrolle der Seiten erfolgen. z.B. ein als Webseite aufbereitetes
Logfile mit den Links von den Schülern in dem betreffenden Raum,
d.h. alle anderen Schüler sind ausgeblendet. Damit die Links schnell
überprüft werden können, sollten diese Links als URL angegeben sein,
sodaß durch Anklicken die Seite (aus dem Cache) schnell auf dem
Monitor geholt werden kann.
Um im Unterricht das aktuelle Surfen beobachten zu können, damit
beim Aufsuchen von Seiten die nicht zum aktuellen Unterrichtsgeschehen
gehören vom Lehrer sofort reagiert werden kann, sollte in kurzen
Zeitabständen eine Auflistung der letzten aufgerufenen Seiten
auf einer Webseite angezeigt werden. Auch diese URLs sollten wie
beim Logfile als anklickbare Links angegeben werden. Links von anderen
Räumen sollten wieder ausgeblendet werden.
Damit ein aussagekräftiges Logfile vorliegt, muß (falls gewünscht)
das Login im Logfile gewährleistet werden können (z.B. durch
Anmeldezwang)
für Schüler, bei denen wegen Verletzung der Nutzerordnung eine
korrektes Arbeiten im Internet nicht erwartet werden kann, muß durch
den Admin die Möglichkeit bestehen, diesen vom Surfen auszuschließen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.2 Der lokale Webserver
============================
Durch den lok. Webserver werden über das cgi-bin-Verzeichnis
verschiedene Scripte (Passwortänderung, E-Mail-Weiterleitung,
Web-Mail-Client, ...) durch den Admin zur Verfügung gestellt.
Werden hier Passwörter übertragen, sollten diese Scripte
ausschließlich per SSL bereitgestellt werden.
Das lokale Webangebot soll durch den (lokalen) Webmaster
eigenverantwortlich betreut werden können.
Für jeden Nutzer wird ein html_public-Verzeichnis seines
Homeverzeichnisses in den Webserver eingebunden.
In diesem Verzeichnis wird PHP und SSI zur Verfügung gestellt.
Wird dieses an einer Schule nicht gebraucht, kann das durch den
Admin zur Erhöhung der Sicherheit einfach ausgeschaltet werden.
Zur Kontrolle der aufgerufenen Seiten (z.B. Nutzung als Spickzettel
bei Arbeiten, Verunglimpfung von anderen Schülern, ...) wird das
Logfile als aufbereitete Webseite für die Lehrer bereitgestellt.
Zur stichprobenhaften Kontrolle der abgelegten Webseiten auf Wörter
wie "porn", "sex" u.a.m. sollte eine lok. "Suchmaschine"
bereitgestellt werden.
für Schüler, bei denen wegen Verletzung der Nutzerordnung eine
ordnungsgemäße Nutzung des lok. Webservers nicht erwartet werden kann,
muß durch den Webmaster die Möglichkeit bestehen, diesen Schülern
das Bereitstellen von Webseiten zu unterbinden.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.3 Der MailServer
======================
Jeder Schüler hat einen Mailaccount (siehe Nutzerverwaltung, Account)
Um bei Absenderfälschung problemlos den richtigen Absender zu
erkennen, wird die korrekte Mail-Adresse als zusätzliche Headerzeile
ergänzt
es wird ein Mailvirenscanner bereitgestellt. die Aktualisierung der
Virensignaturen sollte möglichst automatisch erfolgen
Aufgrund der langen Nutzungsdauer der Mailadressen sollte (neben
Information, Schulung, etc.) ein wirksames technisches System zur
Spamverhinderung bereitgestellt werden.
zur Kontrolle auf Unregelmäßigkeiten wird dem Verantwortlichen für
Mail (Postmaster) ein aufbereitetes Logfile bereitgestellt
(sollte enthalten: Datum, von, an, Betreff, Größe)
Damit z.B. die Mailnutzung erst freigeben kann, wenn die Schüler die
entsprechende Reife (=> Alter) haben oder wenn die Einwilligung der
Eltern vorliegt, sollten die Mailaccounts durch den Postmaster
klassenweise bzw. einzeln freigeschalten bzw. gesperrt werden können.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.4 Der Fileserver
======================
Laufwerk p zum Bereitstellen von Daten und serverbasierten Programmen
---------------------------------------------------------------------
Auf diesem Laufwerk haben normalerweise alle Nutzer nur Leserechte
Der Verantwortliche für den Fileserver kann Lehrern
Schreibberechtigung auf diesem Laufwerk erteilen. Dazu sollte für
diesen Lehrer ein Verzeichnis angelegt werden (beispielsweise mit
seinem login als Namen), in welches nur dieser Lehrer schreiben kann.
Laufwerk t als Tauschverzeichnis
--------------------------------
Auf diesem Laufwerk hat normalerweise jeder User Schreibrecht.
Werden Dateien in der Wurzel dieses Laufwerks abgelegt (Lw t:\ )
dann haben auf diesen Dateien auch alle anderen Nutzer Schreibrecht.
Dadurch können Dateien von mehreren Usern bearbeitet (geändert)
werden.
Werden auf diesem Laufwerk Verzeichnisse angelegt, so kann in diese
Verzeichnisse nur derjenige schreiben, der dieses Verzeichnis
angelegt hat, so daß diese Dateien schreibgeschützt sind.
Um das Bereitstellen von Programmen im Netz (z.B. von Raubkopien)
verhindern zu können, sollen auf diesem Laufwerk keine ausführbaren
Dateien wie exe-, com-, bat-, pif- und reg-Dateien abgelegt werden
können.
Um das Vollmüllen dieses Laufwerks zu verhindern, soll der
Verantwortliche für den Fileserver ausgewählten Lehrern das volle
Schreibrecht auf diesem Laufwerk geben, um erforderlichenfalls
alte Dateien und Verzeichnisse löschen zu können.
Ebenso sollte für das automatische Säubern des Laufwerks ein Script
bereitgestellt werden, welches regelmäßig dieses Laufwerk komplett
löscht. Dem Verantwortlichen des Fileservers ist ein
leichtverständliches (Web-)Interface zum Einrichten des Zeitpunkts
dieses Löschvorgangs bereitzustellen.
Laufwerk u als Homeverzeichnis
------------------------------
Auf diesem Laufwerk hat nur der betreffende User Lese- und
Schreibrecht. (Ausnahme root, der Verantwortliche des Fileservers
und die Lehrer, denen Zugriff auf das Share "allhomes" eingerichtet
wurde)
Um den verbrauchten Plattenplatz nutzerbezogen kontrollieren zu
können, sollte durch ein Script die Größe des verbrauchten Platten-
platzes angezeigt werden. die Anzeige sollte nach der Größe des
verbrauchten Plattenplatzes erfolgen (größter Verbrauch zuerst),
bestimmte Nutzer können vom Admin ausgeblendet werden. Weiterhin
sollten alle User ausgeblendet werden, die ein bestimmtes Limit
noch nicht erreicht haben. User über einen weiteren Limit sollten
hervorgehoben werden (z.b. rot).
Beispiel: es soll jeder User 25 MByte an Plattenplatz bereitgestellt
werden. ausgeblendet werden der Betreuer des Fileservers und der
Admin. Alle User mit mehr als 25 MByte werden rot dargestellt, alle
die weniger als 20 Mbyte haben werden ausgeblendet, alle anderen
werden "normal" aufgelistet.
Beim Einrichten der Accounts wird der Plattenplatz limitiert (Quotas).
Um Probleme mit den Quotas auszuschließen, dürfen keine Seiteneffekte
auftreten. Quotas haben nur für die Homeverzeichnisse zu wirken.
(Das bedeutet insbesondere, das liegengebliebene Druckaufträge oder
nichtabgeholte Mails u.a.m. hier nicht relevant sind).
Es ist deutlich zu dokumentieren, ob auch der Platz beim
Verschiebelaufwerk bzw. in den Projektverzeichnissen erfaßt wird.
für Schüler, bei denen wegen Verletzung der Nutzerordnung eine
ordnungsgemäße Nutzung des Homeverzeichnisse nicht erwartet werden
kann, (zu viel benutzter Speicherplatz, Ablage unerwünschter Dateien
z.B Pornobilder, Viren) sollte durch den Verantwortlichen des File-
servers die Möglichkeit bestehen, diesen Schülern den Zugriff auf
ihr Homeverzeichnis zu unterbinden.
Laufwerk x (und y) zum Einsammeln von Schülerarbeiten
-----------------------------------------------------
Zum Einsammeln von Schülerarbeiten (Leistungskontrollen, Klausuren)
soll ein Laufwerk für die Schüler bereitgestellt werden. jeder
Schüler kann dort seine Dateien dort ablegen, ohne das andere Schüler
diese zu sehen bekommen.
Dem Lehrer wird zum Einsammeln ein Laufwerk y zur Verfügung gestellt,
wodurch er alle Arbeitsergebnisse seiner Schüler bequem auf einen
anderen Datenträger verschieben kann.
Share "allhomes"
-----------------
normalerweise NUR für Admin: er erhält bequemen Zugriff auf alle
Homeverzeichnisse ( /home). Für Schulen, bei deren Nutzungskonzept
weitere Lehrer Zugriff auf die Homeverzeichnisse erhalten sollen,
erhält der Verantwortliche für den Fileserver die Möglichkeit
(Webinterface), diesen Lehrern den Lese- und Schreibzugriff auf
allhomes zu ermöglichen.
Projektverzeichnisse
--------------------
zu jedem Projektverzeichnis gehört ein Projektverantwortlicher. Dieser
hat Lese- und _volles_ Schreibrecht. Er kann außerdem weiteren Nutzern
Schreib- und Leserecht erteilen ( = in das Projekt aufnehmen) und
natürlich auch wieder entziehen ( = Sanktionen).
Weiterhin kann er für dieses Verzeichnis festlegen, ob Schreibschutz
bestehen soll oder nicht (Stickybit).
Er hat die Möglichkeit, sich alle Projektmitglieder auflisten
zu lassen.
Die Verwaltung der Projektverzeichnisse durch den Verantwortlichen
für den Fileserver. Dieser kann:
1. Projekte anlegen (Zuordnung Verzeichnis + Lehrer)
2. eine Liste von Lehrern verwalten, die Projekte anlegen können
diese Lehrer in dieser unter 2. angegebenen Liste können aber nur
Projekte anlegen, wo sie selbst Projektverantwortlicher sind.
Das Anlegen der Projekte wird geloggt. Dieses Logfile wird nur dem
Verantwortlichen für den Fileserver und dem Admin bereitgestellt.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.5 Der Printserver
=======================
Einrichtung des Printservers
----------------------------
bedeutet, daß die Eingaben auf das wirklich notwendige reduziert
sind (Eingabe des Anmeldeservers). Es wird davon ausgegangen, das
für den Schuleinsatz dieses System als einziges auf dem Server zum
Einsatz kommt. Die Einrichtung der Festplatte (Partitionierung,
Formatierung, Installation, Hardwareerkennung, ...) sollte
weitestgehend automatisch ablaufen.
Der Server sollte verschiedene Möglichkeiten des Anschlusses der
Drucker (z.B. am Printserver, an Printboxen, an Win-Clients, ...)
ermöglichen.
Ebenso sollte ein einfaches Einrichten und Konfigurieren eines
Druckers geschehen können, für jeden Drucker sollte man festlegen
können, welcher Rechner auf diesen Drucker zugreifen kann
für Win-Clients sollte ein einfaches Bereitstellen der Druckertreiber
möglich sein.
Anforderungen an die Bedienung
------------------------------
durch die Lehrer sollten die Drucker gestoppt und wieder freigegeben
werden können.
alle Lehrer erhalten das Recht zum Löschen von Druckaufträgen, alle
anderen User können nur ihre Druckaufträge löschen
von jedem Druckvorgang werden folgende Daten in einer Datenbank
erfaßt: Datum, Zeit, Login, PC, Drucker, Dateiname, Seitenzahl.
der Zugriff auf die Datenbank so, daß
- jeder Nutzer seine Daten einsehen kann,
- jeder Lehrer ... (müßte noch geklärt werden),
- der Verantwortliche für den Printserver alle Daten einsehen kann
(bezahlte Druckaufträge müssen als solche markiert werden können,
dürfen
aber nicht gelöscht werden wegen einer Druckerstatistik)
die Ausgabe (per Webinterface) hat auch in "druckerfreundlichen"
Versionen (z.B. mit Hilfe von CSS) möglich zu sein.
wünschenswert: wenn die Schüler einen Druckauftrag absenden, dann
sollte eine Meldung kommen mit User, Login, PC und Drucker, das eben
dieser Druckauftrag anliegt. Dieser Nutzer sollte erst bestätigen,
daß er diesen Druckauftrag auch wirklich absenden will (-> Kosten).
für Schüler, bei denen wegen Verletzung der Nutzerordnung eine
ordnungsgemäße Nutzung der Drucker nicht erwartet werden kann,
sollte durch den Verantwortlichen des Printservers die Möglichkeit
bestehen, diesem Schülern den Zugriff auf die Drucker zu unterbinden.
wünschenswert: einfaches Einbinden von Wasserzeichen, Kopf- bzw.
Fußzeile. Es ist zu erwarten, das private Druckergebnisse mit einem
Schullogo als Wasserzeichen die unerwünschte Druckernutzung reduziert
wird.
wünschenswert: Druckserver erstellt PDF-File z.B. für
Veröffentlichung im Intranet oder Internet.
wünschenswert: Druckkontingente (im Voraus werden Druckkontingente
erworben, die auf dem Account gelistet werden. Pro gedruckter Seite
wird dann ein Betrag abgezogen. Ist der Account leer, kann nicht
mehr gedruckt werden)
dazu ein System, um das Geld einzuzahlen:
es geht ein Formular auf, dort kann man auswählen:
- den Account für das Druckkontingent
- aus einer Liste den zum Einzahlen berechtigten Lehrer
- ein Feld zum Eingeben des Geldwertes
- die Bestätigung mit den beiden zugehörigen Passwörtern
dann kommt eine Bestätigungsmeldung, damit man nochmal den Wert
vergleicht, dann wird der Vorgang mit "Ok" abgeschlossen.
es geht jeweils eine signierte Mail an den
- Einzahler
- den einsammelnden Lehrer
- den verantwortlichen Lehrer
diese Mails können durch den Admin abgeschaltet werden
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1.6 Der CD-ROM-Server
=========================
Da es eine völlig unsinnige Belastung für die Lehrer ist, eine
CD-Sammlung zu verwalten und es nicht gewährleistet werden kann, daß
CDs beschädigt werden können (zerkratzt), geschweige denn der
Verursacher ermittelt werden kann, sollten CDs generell nur über
einen CD-ROM-Server bereitgestellt werden.
Dem Verantwortlichen für diesen CD-ROM-Server sollte es einfach
möglich sein, für eine bereitgestellte CD ein Image zu erstellen und
dieses in den CD-ROM-Server einzuspielen.
Das einzige Problem welches sich dabei ergibt und abgefangen werden
muß ist, das beim Erstellen bzw. Einspielen der Images der zur
Verfügung stehende Plattenplatz nicht ausreicht.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.2.1 Der Listenserver
========================
Listenserver könnten für die Schule in folgender Hinsicht interessant
sein: zur internen Kommunikation der verschiedensten Gruppen, für
E-Mail-Projekte und als Newsletter von Seiten der Elternsprecher,
Schülersprecher, Schulleitung, Arbeitsgemeinschaften und Projekte.
Der Verwalter des Listenserver richtet (automatisiert) die Listen
ein und gibt die Verantwortung an den Betreuer der betreffenden Liste
ab. Dieser konfiguriert die Liste möglichst über ein Webinterface
entsprechend seinen Vorstellungen (Archiv, Teilnehmerliste, offene
bzw. geschlossene Liste, Betreffzeile, Footer, Begrüßungsmail)
Die Liste sollte so konfiguriert werden, daß die Lehrer weitest-
gehend unterstützt werden. Das bedeutet, das im Gegensatz zur
üblichen Konfiguration die Antworten an die Liste und nicht an
den Autor der Ursprungsmail gehen. !!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.2.2 Der Newsserver
======================
Das Abonnieren der betreffenden Newsgroups sollte durch den Verwalter
des Listenservers möglichst problemlos erfolgen können (GUP-System)
Dem Lehrer, der eine betreffende Newsgroup angefordert hat
(also verantwortlich dafür ist) sollte über ein Webinterface diese
Newsgroup zu konfigurieren (moderiert, readonly, ...).
in jedem Posting sollte die korrekte Mailadresse als zusätzliche
Headerzeile eingetragen sein.
jedes Posting von diesem Server sollte automatisch archiviert werden.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.2.3 Die Homepageverwaltung
==============================
Die Verantwortung für die Homepage der Schule hat einzig und allein
der Webmaster. Das bedeutet insbesondere, daß er das Passwort nicht
weitergeben darf/muß.
Andererseits ist es durchaus erwünscht, das verschiedene Gruppen
in der Schule eigene Seiten betreuen wollen, z.B. Förderverein,
Schülerzeitung, Sportgruppen, Fachschaften etc. Somit besteht durchaus
der Wunsch, einen direkten (besser ungehinderten) Zugriff auf die
Homepage zu bekommen.
Es geht also darum, dieser Gruppe für einen Bereich auf der Homepage
den Zugriff zu ermöglichen und dabei die Verantwortung für diesen
Bereich vom Webmaster zum Verantwortlichen dieser Gruppe zu
delegieren.
Die Betreuung/Steuerung sollte über ein Webinterface erfolgen.
Der Webmaster kann
- neue Gruppen einrichten
- den Gruppenverantwortlichen ändern
(löschen bedeutet, der Webmaster wird selbst verantwortlich)
Die Gruppenverantwortlichen können
- Schreibrechte in das Verzeichnis weitergeben und zurücknehmen
- sich die jeweiligen Gruppenmitglieder auflisten lassen
Beim Abgleich der Version auf dem Schulserver mit der Homepage werden
die Änderungen getrennt nach den einzelnen Gruppen erfaßt und
Berichte an den Gruppenverantwortlichen, den Webmaster und den
Schulleiter per E-Mail versandt.
Um Manipulationen an der eigentlichen Homepage festzustellen, testet
das Programm, ob Änderungen an diesem Programm vorbei erfolgt sind.
Solche Manipulationen werden per Mail an den Webmaster gemeldet.
Das Layout der Formulare sollte durch den Admin leicht an die
schulischen Forderungen angepaßt werden können (mindestens
Hintergrund, Kopf- und Fußzeile).
wünschenswert: das Programm überprüft, ob alle Links auf der Homepage
funktionieren. (betrifft insbesondere Linkssammlungen)
wünschenswert: es wird automatisch für die Homepage
- eine "News"-Seite
- eine Sitemap
bereitgestellt.
More information about the SAN
mailing list