================================================================= Pflichtenheft für einen Schulserver Hier sollen die Anforderungen an einem Schulserver beschrieben werden. Diese Anforderungen wurden in der Liste zum Skolelinux- server (www.skolelinux.de) zusammengetragen. Um die Gründe für verschiedene Punkte nachzuvollziehen verweise ich auf das Archiv dieser Liste. http://lug-owl.de/cgi-bin/mailman/listinfo/san -> SAN@lug-owl.de ================================================================= 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 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 Administrator 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 einem Menü mit folgenden Feldern: Name Vorname Login # wenn leer, dann sollte hier generiert werden Auswahl ob Lehrer, Schüler oder (Co-)Admin 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. Eine Möglichkeit für das Bilden des Login könnte so aussehen: der erste Buchstaben des Vornamen und der Nachname. 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 Eine zweite Möglichkeit wäre die Bereitstellung eines Moduls, welches für Lehrer und Schüler das Login auf verschiedene Art und Weise generiert. Denkbar wäre, das beim Einrichten des Moduls der Admin angeben kann, nach welchem der folgenden 4 Schemata das Login der Lehrer bzw. Schüler gebildet werden soll: 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 Alternativ sollten die Passwörter auch nach dem Muster Passwort = Loginname generiert werden können (z.B. Grundschulen) Beim Erstellen des Accounts wird gleichzeitig ein Mailaccount generiert. Die Mailadresse ergibt sich aus dem Login und der Schuldomain. Beispiel: Manfred Mustermann 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. Damit die Nutzer ihre Passwörter jederzeit ändern können, sollte ein einfaches Interface bereitgestellt werden (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. Dadurch wäre das Problem der vergessenen Passwörter gelöst. 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 ---------------------------- Löschen bedeutet hier, das der Account gelöscht wird, die Daten (Inhalt des Homeverzeichnisses) werden gesichert (archiviert). Für den Administrator wird über ein Menü ermöglicht, ganze Gruppen am Schuljahresende zu löschen. Das Gleiche gilt auch für die Archive. Auch einzelne Schüler kann der Administrator über ein Menü löschen. (z.B. wegen Umzug). Das Gleiche gilt auch für das zugehörige Archive. Auch dieses Script (hier nur auf die Accounts bezogen) 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 vorhanden, aber nicht auf der 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 unterbunden werden. Ausnahme sind die Dienste samba, dhcp und 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 eventuell vorher schon einmal bekannt gewordenen Standard-Klausur-Passwort eingeloggt werden 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ü). 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 mit einem Webinterface Freischaltet, 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. # 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Um das Ausspähen der Passwörter zu unterbinden ist es nötig, ALLE Verbindungen, für die eine Passwortauthentifikation nötig ist (z.B. Admin-Interface, Webmail-Client etc.) durch SSL gegen Sniffing zu schützen. Zur Fernwartung sollte den Schulen der Zugang per SSH möglich sein. Dabei ist durch den Admin auf einfache Art und Weise auf Anforderung Durch andere User diesen dieser Zugang individuell bereitzustellen. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 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, Ergänzung bzw. Abgleich 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 am Proxy) 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 anderen 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 Scripte bereitgestellt werden, welches regelmäßig dieses Laufwerk säubern. Dabei sollte ein Script zur Verfügung stehen, welches dieses Laufwerk komplett löscht. Ein weiteres Script sollte alle Dateien löschen, die ein bestimmtes Alter erreicht haben. z.B. alle Dateien die älter sind als 14 Tage Werden gelöscht. Bei Verzeichnissen gilt weiter, daß diese nur gelöscht werden, wenn diese auch leer sind. Dem Verantwortlichen des Fileservers ist ein leichtverständliches (Web-)Interface zum Einrichten des ausgewählten Scripts bereit- zustellen. 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 (per Webinterface), diesen Lehrern den Lese- und Schreibzugriff auf dieses Share 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). Es besteht die Möglichkeit, ganze Gruppen (Klassen) aufzunehmen. 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. Er kann das Projekt wieder löschen. 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. Um die Anzahl verwaister (also nicht betreuter) Projektverzeichnisse zur reduzieren, sind die Projektverantwortlichen angehalten, die Projektverzeichnisse nach Abschluß des Projekts zu löschen. Außerdem kann der Verantwortlich für den Fileserver sich eine Aufstellung der existierenden Projekte erstellen lassen (auch in ausdruckbarer Form). Am Schuljahresende können die Gruppenverantwortlichen über ein Webformular bestätigen, daß die Projektverzeichnisse weiter bestehen bleiben sollen. Andernfalls werden diese automatisch gelöscht. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 nicht 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.3.1 Das Wiki ================ Ein Wiki kann z.B. eine gemeinsame Plattform für Hausaufgaben und Gruppenarbeiten sein. Dabei kommt auch der Vorteil zum Tragen, daß die Arbeitsergebnisse immer zur Verfügung stehen. Außerdem sind die Arbeitsergebnisse sowie die Arbeitsfortschritte für andere sichtbar (Mitschüler, andere Lehrer). Da Lehrer die gleiche Rechte haben wie Schüler, werden die Lehrer zu Coachs. Anforderungen: - Versionenverwaltung: es können Arbeitsschritte aufgezeigt werden. - Userverwaltung: bei Änderungen wird registriert, wer diese gemacht hat. Zusätzlich sollte festgelegt werden können, welche Nutzer Zugriff auf die Seiten haben (insbesondere bzgl. Schreibrecht) - Sperrmechanismus: wenn ein zweiter Benutzer eine Seite bearbeiten will, welche bereits durch einen ersten Benutzer in Bearbeitung ist, muß der zweite gewarnt werden. - Unter-Wikis (Wiki-Farm): es sollten mehrere getrennte Wikis verwaltet werden können, welche aber die gleiche Benutzerverwaltung verwenden. Da Schüler bei möglichen Präsentationen ihrer Ergebnisse auch Wert auf Attraktivität legen (müssen), sollten weiterhin folgende Forderungen erfüllt werden: - Es lassen sich Bilder bequem einfügen. - Es lassen Schriften auch farbig darstellen - Das Wiki sollte ein attraktives Layout haben. Dieses sollte möglichst leicht an die Anforderungen der betreffenden Schule angepaßt werden können. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.3.3 Das Schulportal ======================= Das Schulportal dient zum schulinternen Bereitstellen aktueller Informationen, Terminen ebenso wie dem Bereitstellen von Vertretungs- und Raumplänen. Sollte das Portal auch über das Internet erreichbar sein (z.B. Standleitung), dann ist der Zugriff (SSL) nur mit Login und Passwort möglich und wird natürlich auch geloggt. Dieses Portal sollte beinhalten: - ein Terminplan (Kalender) - ein Plan mit der Zuordnung Lehrer - Klasse - ein Plan mit der Zuordnung Lehrer - Raum - ein Plan mit der Zuordnung Klasse - Raum - einen Bereich für aktuelle Informationen (News) - ein Photoalbum Es sollten vorkonfigurierte Bereiche bereitgestellt werden für - die Schulleitung - die Schülersprecher - den Förderverein - Klassen (Musterklasse) - Fachschaften - Arbeitsgemeinschaften und Sportgruppen Der Betreuer des Schulportals sollte die Bereiche weiter über ein Webinterface an jeweils einen Verantwortlichen für diesen Bereich freigeben können. Dieser Verantwortliche kann für seinen Bereich die Schreibrechte weiter vergeben und wieder entziehen.