Tagung2005:Ergebnisse

Aus AGSS

Erste übergreifende Schulserver-Entwickler-Tagung (16./17.12.2005)

Topics

1)  Wer ist ASQF
2)  Vorstellungsrunde
3)  Einheitliches LDAP Schema
4)  Vereinheitlichung der Ordner-Struktur unterhalb von /home
5)  Diskussion: zentrale Plattform (CVS, Bugtracking, Mailinglisten?)
6)  Diskussion: Jugendschutzfilter "freie" Lösungsmöglichkeiten
7)  Diskussion: Basisplattform für Webinterface
8)  Imaging / Autoinstallation / Restore
9)  Terminalserverlösungen
10) Bildschirmkontrolle
11) Webbasierte Tests
12) Konfiguration von Clients

Wer is ASQF

Der ASQF e.V. ist ein gemeinnütziger Verein und dient dem Austausch von Erfahrungen, Kenntnissen und Ideen auf den Gebieten Software-Entwicklung und Qualitätsmanagement. => http://www.isqi.org/asqf/deu/

Über die Firma Extis, den Hauptsponsor des Treffens, wurden die Räume beim ASQF in Tennenlohe reserviert - hier konnte dann in ruhiger Atmosphäre "getagt" werden.

Vorstellungsrunde / Einleitung

Die Anwesenden stellten sich und ihre bisherige Tätigkeit im Bereich Schulserver vor.

Lars begrüßte als Hauptinitiator die Teilnehmer und freute sich über den großen Teilnehmerkreis. Vertreter von der Musterlösung Linux aus Baden Württemberg waren zwar Eingeladen worden - aber anscheinend bestand hier kein großes Interesse an einem Treffen.

Lars begründete die "Auswahl" der eingeladenen Teilnehmer: so käme es bei diesem Treffen hauptsächlich darauf an, an "realen Lösungsansätzen" zu arbeiten und auch zu prüfen, ob man überhaupt zusammenarbeiten möchte und nicht wie bei ähnlichen Treffen über Nebensächlichkeiten zu streiten.

"[...]Ziel dieser Tagung sollte sein, dass wir die Entwicklung von Schulservern in Zukunft zusammen angehen und nicht mehr nur jeder sein eigenes Süppchen kocht. Nur so kann endlich gemeinsam am Erfolg von Linux in der Schule gearbeitet werden."

Die Diskussionen über die Vor- und Nachteile von Distributionen sind bei Schulservern mit ihrem klar umrissenen Einsatzgebiet und Aufgabenspektrum fehl am Platz. Hier kommt es vielmehr darauf an, eine solide, stabile und genormte Plattform zu etablieren, die dann von allen Anbietern (hier sind auch Schul-Softwarehersteller gemeint) genutzt werden kann. Mein Wunsch wäre ein 'Schulserver-Paket', welches später auf einer beliebigen Distribution installiert werden kann. Wenn das mit Paketen für Samba oder Apache möglich ist, dann sollte es auch mit einem "Konfigurationstool für Schulen" möglich sein. Sicher wird jeder das System auf seiner späteren Lieblingsplattform noch anpassen - aber wenn wir eine gemeinsame Basis verwenden, dann haben wir mit einem Schlag als einzelner Entwickler weniger Arbeit und mehr Akzeptanz.

Jeder der eingeladenen Teilnehmer hat -- sei es durch die Entwicklung eines eigenen Schulservers, durch den Support oder durch die "reine Anwendung" eines solchen -- seine eigenen Erfahrungen gesammelt, die wir uns alle zunutze machen sollten.

Auch kommerzielle Interessen sollten nicht "verteufelt" werden: Schulen brauchen Anpassungen an lokale Gegebenheiten, Schulen brauchen Support, eine Firma als Ansprechpartner ist juristisch greifbar, ... - außerdem steigert eine gesunde Konkurrenz durchaus die angebotene Leistung. ...und dem widerspricht auch eine GPL nicht ;-) [...]"

Addons (Bemerkungen)

Phillip:

Man sollte auch einen angepassten Schulserver anbieten, so dass Schulen vorhandene Strukturen weiter nutzen können. Beispiel: Schulen möchten nicht umsteigen, weil dann alle Nutzer & Gruppenrichtlinien vom W2k-Server nicht übernommen werden können => Schulserver "nur" als Kommunikationsplattform, der sich in ein vorhandenes Netzwerk integriert

Jürgen:

Problem: Support-Plattform. Diese sollte immer erreichbar sein und möglichst schnell helfen können. Das ist aber nur über eine entsprechende Finanzierung zu erreichen.

Stephan:

SLIXS verfolgt andere Ziele als die anderen Schulserver aufgrund der österreichischen Struktur. "Klein, aber fein" ist hier das Motto. Da in Österreich Lehrer für die Aufgabe der Netzwerkadministration komplett vom eigentlichen Unterricht freigestellt werden können, ist hier das

"Bastelpotential" höher als in Deutschland, wo die Administration "nebenbei" erledigt werden muss und noch dazu meist überhaupt nicht honoriert wird.

Einheitliches LDAP Schema

PG:

Das "Extis-Schema" wird ggf. erweitert und allen Schulservern (unter "GPL") zur Verfügung gestellt.

Reiner:

Arktur kommt bislang ohne spezielle Schema-Dateien aus. Hier werden nur die bislang bekannten genutzt.

Wichtig für die zukünftige Entwicklung: alle Daten sollen ins LDAP! Hierüber herrscht allgemeine Einigkeit.

=> D.h. z.B. für ein Backup: slapcat; /var/lib/* (Mails); /home/*; => mehr Daten sind nicht nötig. Allerdings ist dies noch nicht bei allen angebotenen Diensten möglich - deshalb muss hier mittelfristig noch mit Workarounds gearbeitet werden. Vorstellbar ist z.B. die Datenhaltung im LDAP und ein DUMP der entsprechenden Daten in das Filesystem, damit die Dienste diese Files dann einlesen können.

PV => Präsentation des OSS-LDAP Schemas

Hinweise von Andreas:

ou=ldapconfig (und Struktur) mehr in die Öffentlichkeit pushen! Das ist gut, aber zu wenig bekannt!
über Kerberos sind auch bei NFS mehr als 16 Gruppen möglich - allerdings nur mit einigem Aufwand

=> Netgroups anstelle von objectClass

=> Jede primary Gruppe bekommt einen Template-Benutzer (für [Desktop-]Profile)

Problem: Lehrer unterrichtet in mehreren Klassen und ist Klassenlehrer in einer bestimmten Klasse. In dieser einen Klasse soll er mehr Rechte haben als ein normaler Lehrer - aber nicht in anderen Klassen.

=> zusätzliches Attribut an schoolAccount hängen:

User = primary group
Role => evtl. sogar auf Gruppen und auf Benutzerbasis

Ein User in der group "teachers" könnte so zusätzliche "roles" haben - etwa "Proxy-Admin". In der Gruppe 10A könnte eine "role" auf den "class teacher" verweisen.

Für "Proxy-Admin", etc. sollten hier Posix-Gruppen genommen werden um auch auf Filesystem-Ebene entsprechend zugreifen zu können.

writeDN sowohl für Gruppen als auch für Benutzer

=> ein Benutzer mit writeDN für Gruppe kann nicht die Benutzer ändern

objectClass = schoolGroup
Type =

LDAP-Struktur unterhalb eines Nutzers – Addon für Schulbuchverlage und Softwareanbieter:

uid=...
addr=...
cn=<vendorname>
+--- objectClass=schoolVendorObject
-----vendorParameter_R=(case intensive, read only)
-----vendorParameter_RW=(case intensive, read/write)
-----vendorParameter_W=(case intensive, writeable)
-----vendorParameter_0=(case intensive, )

==> gesteuert über ACI – Teile unterhalb der jeweiligen objectClass sollen nur von einem bestimmten Programm geschrieben werden können – andere Teile nur von Lehrern.

=> die ldapconfig sollte ggf. von den Herstellern benutzt werden, um (auch im laufenden Betrieb) den LDAP-Server über neue Konfigurationen zu informieren.

ACLs und Upgradebarkeit => zu diskutieren

capability= beschreibt die aktuellen Fähigkeiten des LDAP-Baums

=> Aufnehmen in ou=ldapconfig als Objekt mit eigener objektClass. Damit ist ein Update später leichter.

InternetFreischaltung => wer schaltet wann was mit welchen "Rechten"?

=> Lösung über iptables bzw. ipchains kann bis auf Benutzerebene. Problem: Nutzer bekommt keine Rückmeldung --> schlechteste Lösung

=> Lösung über Proxy => hier gibt es auch mehrere Möglichkeiten:

über LDAP-Attribut pro Schüler (siehe auth_param basic program)
über Raumweises Sperren (mittels ACL oder SquidGuard)

==> (derzeit?) zwei verschiedene Lösungen nötig - anzustreben wäre eine Schaltung pro Schüler. Probleme:

Schüler wurden gesperrt und kommen später nicht rein. (Zeitschaltung)
Schüler, die aus bestimmten Gründen nicht dürfen, kommen plötzlich rein (Lösung: zwei Attribute defaultInternet + internetEnabled im LDAP)

Nutzen einer Gruppe Internet? Nur Nutzer in dieser bestimmten Gruppe kommen rein.

==> zu diskutieren!

Wir brauchen "sysconfig-Variablen", die bestimmte Preferenzen der Schule abbilden. Z.B. Thema Internet:

=> Internet ist immer frei / nicht frei

=> Zeitsteuerung

=> böse Buben dürfen auf Lehrer-Anforderung trotzdem ins Netz (zeitlich begrenzt)? Ebenso z.B. bei Quota-Einstellungen, Email, etc.

Für diese Variablen sollten default-Werte während der Installation gesetzt werden, die aber verändert werden können. Damit können Schulen den Server schnell aufsetzen - ihn aber später noch leicht an ihre Bedürfnisse anpassen.

(Das würde z.B. für den OSS bedeuten:

ou=ldapconfig,c=schoolserver

==> hier kommen die derzeitigen Werte von /etc/sysconfig/schoolserver rein)

---

Vortrag Malte:

Hardwaredatenbank für Support => derzeit in MySQL implementiert

Damit die Schule eine Inventarisierung ihrer Hardware vornehmen kann, wäre es nützlich, die Hardwaredaten eines Rechners gleich bei der Aufnahme dieses Rechners ins Schulnetz (Anmelden an der Domäne, Eintragen in dhcp) auf dem Server zu speichern.

Hier können in erster Linie Linux-Tools gute Dienste leisten. Ein einfaches "hwinfo" ist schon nicht schlecht. SUSE bietet hier mit dem Tool "sitar" (System InformaTion At Runtime) schon seit längerer Zeit ein noch ausgefeilteres Tool an, welches alle benötigten Informationen für den Support sammelt.

Malte => Inventarisierungsstruktur evtl. openSource (?)

IMPORT VON SCHÜLERN => SCHULVERWALTUNGSPROGRAMM

Benötigt wird eine Schnittstelle auf allen Schulservern, wie man automatisiert Schüler anlegt. Da sollten aber evtl. schon bestimmte Informationen drin sein. (Datenschutz?)

Da es für jedes Bundesland und teilweise sogar bei jeder Schule andere Schulverwaltungslösungen gibt, muss die angestrebte Lösung möglichst flexibel sein.

Lösung: Scripte konvertieren den Originalexport in ein XML-Format (XML soll in dt. Verwaltungen bald stark forciert werden). Dieses XML-Format wiederum wird dann vom Schulserver eingelesen.

=> es sollte eine Definition für ein XML-Format geben. => Auch wenn CVS-Export, dann in XML-konvertieren und einlesen.

(Hintergrund: damit lassen sich u.a. Kodierungsfehler (UTF-8 vs. ISO-8859) vermeiden.)

Für die Identifizierung der Benutzer sollte ein Hash als unique-ID dienen, der nicht mit Datenschutzproblemen belastet ist.

=> Beispiel: Die Benutzer-ID des Schulverwaltungsprogramm hashen (md5) (Warum hashen? Die ist doch sowieso nur im entsprechenden Programm drin

- evtl. ist die ID aber auch anderswoher übernommen (bei Lehrern z.B. von der Dienststelle)).

Vereinheitlichung der Ordner-Struktur unterhalb von /home

aufgrund von Internationalisierung sollten die Namen zunächst englisch sein (also "students" anstelle von "Schüler")

alle für den Schulbetrieb relevanten Daten sollten unterhalb von /home verfügbar sein.

Übersichtlichkeit sollte gewahrt bleiben (wohl wissend, dass hier international teilweise flachere Strukturen bevorzugt werden)

in den Homeverzeichnissen gibt es Symlinks auf die Ordner, welche die Nutzer brauchen:

==> /home/students/<user>/+all ist ein Symlink auf /home/all
==> /home/students/<user>/+groups ist ein Symlink auf /home/groups/

ACLs müssen aktiviert sein => feinere Rechtevergabe

eine Kopplung von päd. und Verwaltungsnetz ist nicht vorgesehen

==> KEINE MÖGLICHKEIT ZUR ABLAGE VON PERSÖNLICHEN DATEN DER NUTZER!

jede primary Gruppe sollte ein eigenes Verzeichnis haben

++ Schüler unter /home/students/* (plain)

==> Wenn Lehrer Zugriffsrechte auf die Schülerverzeichnisse haben sollen, dann gibt es ein zusätzlich ein Verzeichnis:

+++ /home/classes/*

==> dort drin gibt es Symlinks in die Homeverzeichnisse der Schüler einer Klasse das erleichtert erfahrungsgemäß die Übersicht

++ Lehrer unter /home/teachers/* (plain) Rechte werden so gesetzt, dass Schüler hier nicht hinein dürfen

++ /home/groups/*

==> jede Gruppe/ Klasse hat dort ein eigenes Verzeichnis (d.h. hier liegt z.B. auch das Lehrer-Tauschverzeichnis oder Verzeichnisse für Arbeitsgruppen (Homepage, Theater-AG, etc.)

==> eigene Partition - diese wird mit GruppenQuotas gemountet und nicht mit UserQuotas (damit entfällt die Suche nach Dateien, die die Nutzerquota sprengen)

==> Die Klassenverzeichnisse werden nach einem Schuljahr aufgeräumt (archiviert), nur "Projektverzeichnisse" bleiben erhalten

++ /home/archiv/

==> Daten eines gelöschten Nutzers werden dort gespeichert (Lehrer haben dort Leserechte - zu klären: Datenschutz)

==> Wenn man einen Lehrer löscht, wer hat dann Leserecht? Evtl. Unterverzeichnis für gelöschte Lehrerdaten:

+++ /home/archiv/teachers

++ /home/all/ (Tauschverzeichnis)

==> normalerweise kommmt keiner rein - über ACLs freigegeben

==> Klausurnutzer (und anonymous) kommen da NICHT rein!

++ /home/profile/* (plain)

==> Windows-Profile für die einzelnen Nutzer

==> d.h. es kann auch auf auf eine eigene Partition (inkl. oder ohne Quota) ausgelagert werden. Nutzer können nicht mehr so leicht ihre eigenen Profile manipulieren (security by obscurity - die Dateien werden nicht so leicht gefunden), zusätzlich lassen sich die Profile leicht neu schreiben (siehe Template weiter oben).

++ /home/software/

==> Lehrer (oder Fachadministratoren ?) haben hier Lese- und Schreibrecht um Software zu installieren

==> Netzwerktaugliche Software wird hier liegen

==> CD-Images als eigener Unterordner /home/software/CDs

==> evtl. eigene Partition, damit UserQuotas hier bei Fachlehrern nicht zum Zuge kommen

++ /home/install/ (für unattended Installation)

==> Sollte eigentlich auf einem anderen Rechner liegen (Performance) - aber hier sollten sonst jegliche Rechte entzogen sein. Problem: Damit kann man schlecht Einstellungen über das Netzwerk zurücksichern...

++ /home/sysadmins/

==> normalerweise nur Zugriff für "admin"

==> Dateien für die Sysadmins

++ /home/administration/* (plain)

==> Dateien/ Homeverzeichnisse für die Verwaltungsleute (Sekretariat, Hausmeister, Putzfrauen), die auch im Schulnetz verwendet werden dürfen

==> damit auch Verwaltungsangestellte, die weder Lehrer noch Schüler sind ein "Home-Verzeichnis" haben (ihres liegt dann unterhalb dieses Verzeichnisses)

Zentrale Plattform

Hier erklärt sich Schul-Netz für das Hosting bereit. Um es Entwicklern angenehmer zu machen: "One Identity" ist anzustreben, d.h. für alle Dienste sollte nur ein einziger Account nötig sein.

As soon as possible benötigt:

=> Wiki für Entwicklung der Standards (schreibgeschützt für anonymous)

=> Subversion

=> Mailingliste

Später:

=> Bugtracking

=> CMS

Diskussion: Jugendschutzfilter "freie" Lösungsmöglichkeiten

Problem: derzeit werden kommerzielle Listen angeboten, die mit mehr oder weniger hohem Aufwand gepflegt werden. Zusätzlich gibt es freie Listen, die jeder mit Wissen über die Download-URLs beziehen kann. Die kommerziellen Listen kosten Geld, die kostenlosen sind nicht immer "up-to-date".

So pflegt jeder Schulserver (bzw. jede Schule) oft eigene Listen. Hier sollte eine Zusammenarbeit möglich sein.

Lösungsansatz:

1) Eine Schule schickt Brief an eine bestimmte Stelle und wird damit authentifiziert

2) Die Schule "aktiviert" einen Konfigurationseintrag auf ihrem Schulserver und läd automatisch ihre "custom" Einträge auf einen Server im Internet. Hier bräuchten wir einen entsprechenden Server.

3) mdsumme über Schulname, etc. dient für die Authentifizierung der Schule

==> Ergo könnte jede Schule später die während des Unterrichts von den Lehrern eingetragenen "Black-" und "Whitelists" automatisch auf einen Server hochladen. Damit wir später einen Überblick behalten, welche Schule wann was hochgeladen hat, brauchen wir da eine entsprechende Lösung: Über den Schulnamen und eine "Registrierungsnummer" o.ä. (von SaN o.a. nach Authentifizierung vergeben) wird eine eindeutige md5sum gebildet.

Dann wird per Skript die "Black-" und "Whitelist" eingepackt und die md5summe dient als Name des resultierenden "tar.bz2". Das wird dann (über FTP?) in ein incoming-Verzeichnis auf den Server im Internet hochgeladen (evtl. mit eingestelltem "Schulname + md5sum" in einer config-datei als zusätzlichen Schutz?).

Auf dem Server werden dann in einem Subverzeichnis:

 blacklists/<md5sum>/date+time/

die Daten ausgepackt. Dazu gleich ein Symlink gelegt von obigem auf:

 blacklists/<md5sum>/latest/

Damit könnten wir später per Skript die Dateien einsammeln lassen und in entsprechende Listen kopieren. Zudem hätten wir immer den Nachweis, was welche Schule wann geschickt hat.

Das würde derzeit reichen. Später kommt dann noch der entsprechende Download dazu:

=> md5summe wird später beim Download von der Schule aus an die URL angehängt (oder auch wieder Zugang mit Schulname + md5sum) => Validierung, dann Download freischalten

Wo wird die Liste eingebunden?

Reihenfolge: good !bad sngood !blacklist !snbad all

good, bad:     eigene Listen der Schulen
sngood, snbad: heruntergeladene Listen
blacklist:     andere Listen (sonstwo her)

Damit haben die "persönlichen" Einstellungen der Schule immer Vorrang vor den heruntergeladenen Listen. Je mehr Schulen an der Aktion mitmachen, desto besser werden aber sngood und snbad - so dass evtl. später sogar ein "whitelisting" möglich wäre, d.h. nur noch die URLs, die von der Schule und von unserem Server freigegeben sind dürfen angesurft werden.

Aus diesem Grund sollte es auch wenig Probleme mit "Diskussionswürdigen Seiten" geben. Die Schule vor Ort nimmt diese in ihre persönliche Liste auf und überschreibt damit die heruntergeladenen Seiten. Auf dem Internetserver muss dann irgendwann aber eine "Kommission", die aus interessierten Nutzern bestehen kann, über die "strittigen" Sachen entscheiden.

Diskussion: Basisplattform für Webinterface

Da die zentralen Anforderungen für alle Schulserver identisch sind, bietet sich eine Kooperation auf Basis-Ebene für die Entwickler geradezu an.

Hierzu evtl. interessant:

SAGA => kommender EU-Standard, der XML auf API-Ebene preferiert (siehe u.a.: http://www.bundesingenieurkammer.de/2429.htm http://www.bva.bund.de/aufgaben/win/beitraege/00281/ )

OSGI => development of new and exciting services and applications for the latest generation of networked devices. Wird u.a. auf von der Eclipse Foundation unterstützt. (siehe u.a.: http://www.osgi.org/ http://osgi.org/osgi_technology/download_specs.asp )

Andreas: suad sollte nicht "aufgeblasen" werden, sondern eher modularisiert werden.

API: gemeinsam definieren => let's create a new Schoolserver Standard

==> Präsentation von PG über die mögliche Struktur.

Hintergründe:

Skalierung soll möglich sein

=> wenn die Konfiguration auf dem zentralen LDAP-Server geändert wird, muss diese Änderung an die Server weitergeleitet werden, die davon betroffen sind

Frontend - unabhängig

=> Das Frontend soll nur über die API mit dem System kommunizieren. Damit wären später verschiedenste Frontends zur Administration des Schulservers möglich. Das reicht von reinen Webfrontends bis hin zum angepassten "Sysadmin-Menü" von Arktur oder reinen QT-Applikationen, die nativ auf dem Client laufen. Das Frontend sollte eine gewisse eigenintelligenz besitzen, um Daten zu validieren und den Nutzer zu führen. Die eigentliche Logik wird aber vom "Core-System" übernommen, das über die API angesteuert wird.

Sicherheit

=> Durch die Trennung von Core und Frontend ist schon einmal nicht alles erreichbar. Während die Fronends einfach die API bemühen, stellt das Core-System die Berechtigungen und die Validierung sicher.

Erweiterbarkeit/ Flexibilität

=> über Plugins sollte es möglich sein, das Core-System mit bestimmten Features zu erweitern. Diese Plugins sollten aber auf bestimmte Core-Funktionen wie z.B. die Authentifizierung, Lesen/ Schreiben von Dateien, (Neu)Starten und Stoppen von Diensten, etc. zurückgreifen könnnen. Damit sollte es später leicht sein, ein "eigenes" Plugin zu schreiben welches bestimmte Aufgaben übernimmt. Beispiele: Webmin, YaST.

Ob die Frontends mit der API über XML kommunizieren wäre zu diskutieren. Ebenso, ob die Plugins mit dem Core-System über XML kommunizieren. Hier klang ein wenig "Angst" vor einer neuen Unbekannten

durch. Allerdings würde XML hier nur zur Kapselung der Daten und Befehle dienen, was auf lange Sicht Vorteile bringen kann.

Beispiel:

Version 1:

 my $obj = NEW user (Name, Vorname, Klasse, ID);

==> dies geht in der "bisherigen" Version als Datenstring übers Netz:

 create - Name - Vorname - Klasse - ID

==> in XML gekapselt:

<command>create</command>
<name>Name</name>
<surname>Vorname</surname>
<class>Klasse</class>
<uid>ID</uid>

Auf den ersten Blick sieht das nur nach einem größeren Datenwulst aus - aber selbst hier sollte schon erkennbar sein, dass "Sonderzeichen", größere Arrays, etc. hier keine Probleme bereiten, weil die API klar erkennen kann, wann ein Objekt anfängt und endet.

Noch interessanter wird es, wenn plötzlich das Core-System oder das Frontend aktualisiert wird und neue Objekte beherrscht: create - Name - Vorname - Klasse - defaultRights - ID

=> Damit gibt es Probleme, weil Frontend und Core-System nicht mehr zueinander kompatibel sind. Mit der XML-Übermittlung ist es jedoch Problemlos:

<command>create</command>
<name>Name</name>
<surname>Vorname</surname>
<class>Klasse</class>
<defaultRights>defaultRights</defaultRights>
<uid>ID</uid>

==> Das Frontend (oder das Core-System - je nachdem was "älter ist") interessieren die neuen Objekte nicht - Sie werden einfach ignoriert. Um Problemen vorzubeugen muss hier eine DTD (http://de.wikipedia.org/wiki/DTD) definiert werden und die Tools übermitteln dann zusätzlich zu den obigen Settings die DTD-Version, nach der Sie die Daten übermitteln. Gibt es einmal inkompatible Änderungen in der DTD, kann so rechtzeitig gehandelt werden.

Nachteil: Die Frontends benötigen für die "Kapselung der Daten in XML" zwar ein weiteres Modul, welches dann aus obigem "NEW user(Name, Vorname, Klasse, ID)" ein entsprechendes XML-Konstrukt erzeugt und an die API übermittelt - die Vorteile dieses Verfahrens sollten aber diesen Nachteil überwiegen.

Weiterer Vorteil: Dank genormter DTD (API) könnten Schulbuchverlage und Softwareanbieter ihre Software so anpassen, dass diese "Schulserver-Konformität" bietet. Dank Datenhaltung im LDAP und genormter Schnittstellen um an diese Daten heran zu kommen fällt es sicherlich manchem Softwareanbieter leichter, entsprechende Schnittstellen in seine Software zu integrieren. Immerhin könnten seine Applikationen so auf einfach Art und Weise "Webtauglich" bzw. "Mutliplatform"-Tauglich werden.

Imaging / Autoinstallation / Restore

Zum Thema Images recht interessant:

CiPUX => Imaging einer Linux-Installation Entwickler: Christian http://www.cipux.org/

Unattended ist gerade vom OSS-Team getestet worden und wird dort evtl. als "Windows-Installationslösung" eingesetzt werden: http://unattended.sourceforge.net/ http://www.linux-schulserver.de/Sections-article39-p1.phtml

Diese beiden Sachen sollten (da GPL) weiter evaluiert werden, damit sie ggf. als "Musterlösung" dienen können.

Terminalserverlösungen, Bildschirmkontrolle, Webbasierte Tests, Konfiguration von Clients

=> Wie schon im Vorfeld erwartet, war hier leider die Zeit zu knapp.

Aber die Themen sollten trotzdem weiter vertieft werden.

Anhang

Unzusammenhängend notiert:

Ziel der nächsten Schulserver: Kerberos + AFS

PGINA (http://rulink.rutgers.edu/pgina.html) sollte evaluiert werden. Weitere Infos: Jürgen

Nächstes Treffen: noch unklar. Vorschlag: Linuxtag 2006

Hauptseite