Pflichtenheft aktuell (2)
Hans-Dietrich Kirmse
hd.kirmse at gmx.de
Thu May 15 10:00:02 CEST 2003
Hallo,
Alexander Dubielczyk schrieb:
>
> Am Mit, 2003-05-14 um 20.49 schrieb Hans-Dietrich Kirmse:
>
> Hallo Hans-Dietrich,
>
> mir sind da beim Durchlesen noch ein paar Ideen gekommen, die zwar z.T.
> wieder eher technischer Natur sind, die ich aber trotzdem mal an dieser
> Stelle anbringe, damit sie zumindest schon mal archiviert werden.
>
> > 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).
>
> Wie wäre es, wenn man einfach einer Benutzergruppe als "Eigenschaft" die
> zeitlich folgende Gruppe zuordnet? Z.B. könnte man vermerken, dass immer
> wenn die Operation "versetzen" auf eine Gruppe angewendet wird, alle
> Gruppenmitglieder in die vorgemerkte nächste Gruppe versetzt werden. Bei
> LDAP könnte das wahrscheinlich recht einfach über ein weiteres Attribut
> der Benutzergruppe erledigt werden.
ich sehe den Vorteil nicht, eher nur den Nachteil eines höheren
(technischen?) Verwaltungsaufwandes.
>
> Das ganze hätte den Vorteil, dass man neben Klassen auch Kurse von einem
> Schuljahr ins nächste versetzen könnte, wenn entsprechende Folgekurse
> definiert wären. Man würde außerdem flexibler bleiben was die Bennenung
> der Klassengruppen angeht, über die man wohl sonst die Versetzungslogik
> aufbauen würde (z.B. Gruppe "Klasse-(n)A" wird versetzt in
> Klassen-(n+1)A" etc.).
auch das sehe ich (noch) nicht.
ich muß weiter dazu bemerken, das die Problematik der Klassen, Kurse
bzw. Jahrgänge aus meiner Sicht sich immernoch nicht erschließt.
Nach diesem Modell können quasi beliebig viele Gruppen angelegt werden
(auch ohne Aufwand für den Admin), die deswegen trotzdem jeweils einen
Verantwortlichen haben und diese Gruppen sind völlig unabhängig von
irgendwelchen vorhandenen Strukturen. damit wäre auch klassen-
übergreifend etc. kein Problem. Und einen anderen Grund für
Gruppenbildung kann ich nicht endecken. Die Klausurumgebung ist m.E.
auch unabhängig von den Gruppen, weil es da spezielle Nutzer gibt.
Nach "Modell Arktur" haben die ja noch den Sinn, das man dann das
Löschen ganzer Klassen/Jahrgänge noch recht effektiv durchführen
kann, ohne die betreffenden Schüler zusammenzusuchen.
Bei der Variante BW-Lösung, die ja nach diesem neuen Konzept auch
möglich wäre entfällt sogar diese Vorteil.
> Evt. wäre es auch günstig die Vorgängergruppe zu vermerken, um die
> Anforderung zu erfüllen, möglichst einfach Leute mit Ehrenrunde
> "zurückzuversetzen".
viel Aufwand für fast nichts. außerdem muß eine Ehrenrunde nicht
automatisch in der organisatorisch zughörigen Klasse sein.
z.B. ist bei uns die Klassenstärke ein gewichtiges Argument.
>
> Es sollte außerdem weiter definiert werden, wie bei dem
> Versetzungsvorgang mit denen zur Gruppe gehörigen Dateien verfahren
> wird. Ich benutze dafür z.B. die Lösung die Daten des alten Schuljahres
> zusammenpacken und als ZIP-Archiv mit in das Verzeichnis der Gruppe des
> nächsten Jahres zu legen, bevor das alte Gruppenverzeichnis gelöscht
> wird. Gut möglich, dass es da noch bessere Lösungen gibt.
auch das sehe ich (noch) nicht. persönliche Daten sollten nicht
angegriffen werden (es ist ja nur die Änderung einer Gruppe) und
Projektverzeichnisse sind momentan völlig unabhängig von irgendwelchen
Gruppenstrukturen. Also wird hier auch nichts beeinflußt.
ich sehe es einfach nicht :-(
Allerdings, wenn bei der BW-lösung automatisch gelöscht wird, wenn
ein Schüler nicht mehr in der Schülerdatenbank des Sekretariats ist,
dann sehe ich Probleme wegen Schülern, die mal ein Jahr pausieren
(z.B. Ausland). Ich hätte denen ihre Daten gerne gelassen.
>
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > 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
>
> Zum Thema Absicherung fällt mir noch ein, dass irgendwo vermerkt werden
> sollte, dass alle Verbindungen die eine Passwortauthentifikation nötig
> ist (z.B. Admin-Interface, Webmail-Client etc.) durch SSL gegen Sniffing
> geschützt werden sollte.
richtig. Diese generelle Forderung werde ich vermerken.
Bei Webinterface steht es schon aber bei allen anderen nicht. Samba
wird vermutlich sowieso verschlüsselt genutzt, aber die übliche
Schwachstelle sehe ich bei POP. Also mal E-Mail mit Netscape/Outlook
geholt und schon läuft das Passwort im Klartext übers Netz.
>
> > Laufwerk t als Tauschverzeichnis
> > --------------------------------
>
> [...]
>
> > 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.
>
> Vielleicht wäre es besser hier eine Art Verfallsdatum für die Dateien
> auf dem Tauschlaufwerk zu definieren. Z.B. Alles was älter als x Tage
> ist wird gelöscht?!
ja, das geht. Es macht aber "Probleme" bei Verzeichnissen. Wenn
innerhalb von Verzeichnissen Daten aktualisiert werden, dann können
Verzeichnisse sehr alt werden. Andererseits sollen auch nicht
Verzeichnisse als "Dateileichen" rumliegen. Es wären mir dann zu viele
Fälle zu betrachten, also fehleranfällig und schlecht nachvollziehbar.
> Ansonsten ist mir noch in den Sinn gekommen, dass es Sinn machen würde
> die Möglichkeit vorzusehen, Rechner zu logischen Gruppen (=>
> Kabinette/Medienecken etc) zusammenschließen zu können. Das wäre dafür
> sinnvoll, um z.B. Einschränkungen für bestimmte Dienste nur auf eine
> Rechnergruppe (aktuellen Rechnerraum) anwenden zu können. Das wäre auch
> nützlich um den Lehrer z.B. über den Webserver über die Aktivitäten an
> den Rechnern in seinem aktuellen Raum zu informieren.
Solche logischen Gruppen sind schon bei der Klausurumgebung bzw. beim
Sperren und Freischalten bzgl. surfen angegeben. Es stellt sich die
Frage, ob man das für jeden Dienst machen sollte oder ob man diesen
PC-Gruppen quasi das "Primat" gibt. (letzteres wäre bei unserer
Arkturlösung derzeit so, denn wir arbeiten mit Teilnetzen, ist aber
sehr unflexibel - und kein Arktur-Standard)
> Rein technisch müßte das wohl irgendwie mit an die Stelle, wo Rechner
> für den DHCP-Server eingetragen werden. Dort könnte man ihnen einfach
> eine vorher an anderer Stelle definierte Gruppe zuweisen.
ja, das wäre auch aus meiner Sicht eine geeignete Stelle.
/"\
Mit freundlichen Grüßen \ / ASCII ribbon campaign
Hans-Dietrich X against HTML mail
/ \ and postings
More information about the SAN
mailing list