Vorschlag für einen Anforderungskatalog (1. Etappe)

Sam a-cappella at gmx.de
Sat Apr 12 12:57:02 CEST 2003


Lieber Hans-Dietrich, 

dein Anforderungskatalog klingt recht spannend :) Allerdings habe ich zu
ein paar Punkten noch Fragen, vielleicht kannst du mir das
verdeutlichen? 

(Ansonsten vorab in die Techniker-Runde: Wie weit arbeitet der Server
mit ACLs zusammen? Grad, wenn hier User aus der Windows-Welt kommen,
koennte das nicht uninteressant sein ...) 

Am Sam, 2003-04-12 um 07.05 schrieb Hans-Dietrich Kirmse: 
> Nutzerverwaltung
> ================
> 
>  - Anlegen der Nutzer (Festlegungen UID, GID, ...)
GID versteh ich - nur warum man dem Nutzer explizit eine UID zuweisen
will, geht mir noch nicht ganz auf? Die laesst sich doch prima
automatisch vergeben und gut? (Auszer, man legt explizit Wert darauf,
dass die UID beispielsweise die Immatrikulationsnummer ist (mal auf eine
Uni bezogen), um die Zuordnung zu erleichtern ...) 

>  - Änderung der Klassen (neues Schuljahr)			  [2]
Du hast dazu unten eine interessante Problematik beschrieben, die man
ziemlich einfach umgehen kann, spaetestens, wenn der Schulserver auch im
Abiturbereich mit Wahlfaechern und reinen Jahrgangsstufen eingesetzt
wird, wuerde das reine Klassenprinzip in die Knie gehen. Dann gibt es
eben keine 6a mehr, sondern nur noch den Jahrgang X. 

Insofern wuerde es sich hier IMO anbieten, von vornherein die Klassen
beispielsweise mit <Einschulungsjahr>.<Klassenkuerzel> (bsp: 2003.a) zu
kennzeichnen. Damit wird es nur noch notwendig, der Stufe (oder
Einzelklasse) bestimmte Rechte zuzuweisen oder zu entziehen. Keine
laestige zusaetzliche Umschreibung aller Klassen in den Sommerferien
mehr :) Und zusaetzlich verringert sich die Fehlerquote bei Eingaben,
wie von dir geschildert wurden. 

>  - alle Schüler und Lehrer sind Mitglied der Gruppe "tausch"      [3]
>  - Gruppe tauschadmin (Lehrer werden durch admin aufgenommen)     [4]
>  - Gruppe programmadmin (Lehrer werden durch admin aufgenommen)   [5]

Mir ist trotz Lektuere des Wiki noch nicht so ganz klar, was du mit
diesen Gruppen machen willst, bist du so lieb und hilfst mir auf die
Spruenge?

> FileServer 
> ==========
> 
>  Laufwerk p: (Bereitstellen von Daten und serverbasierten Programmen)

sieht unter Linux ein bisschen anders aus, da das Prinzip "wir haben
nur maximal 26 Moeglichkeiten, wo Dateien abgelegt werden koennen" so 
nicht existiert. Aber das sind Feinheiten :)
 
>  Share  "allhomes"
> 
>  - NUR für Admin für bequemen Zugriff auf alle Homeverzeichnisse [11]

Kleiner Blick auf den Datenschutz, so ohne weiteres ist das nicht erlaubt.

> WebServer 
> =========
> 
>  - stellt verschiedene Scripte per SSL zur Verfügung		 [12]

Warum soll so etwas ueber eine Web-Oberflaeche ablaufen? nur mal als 
rein interessierte Frage ...

>  - für das lok. Webangebot wird der Nutzer "intranet" vorgesehen

? wofuer? (Ich befuerchte, ich denke hier einfach zu sehr als Techniker,
insofern waere eine Erklaerung des Zwecks dieser Regelung fuer mich
ganz sinnvoll, mag sein, ich habe ob des schoenen Wetters drauszen
einfach grad ein Brett vor dem Kopf ;)

> [3]  Begründung siehe im Wiki 
> 
> [4]  Begründung siehe im Wiki 
> 
> [5]  Begründung siehe im Wiki 

Bitte, koennen wir uns ob des staendig wachsenden Wiki-Umfangs
darauf einigen, bei Verweisen auf dasselbe die entsprechende 
Seite mit anzugeben? Bsp: siehe im Wiki RollenBeiDerBedienung - 
dann weisz jeder sofort, worauf genau sich gerade bezogen wird :)
 
> [6]  es ist zu überlegen, ob eine Alternative zu <login>@schuldomain
>      sinnvoll ist. (praktisch ist mit dem Login auch die Mailadresse
>      bekannt bzw. leicht zu erraten - da machen manche ein 
>      Datenschutzproblem daraus)

vorname.nachname at schuldomain.de - das ist relativ offen und klar. Es ist
ja sowieso offenkundig, wer unter welchem Account Mails verschickt,
insofern ...Aber natuerlich sollten die Schueler genauso wie die Lehrer
ihre Passworte schuetzen und nicht offen ans Schwarze Brett pinnen,
uebertragen gesagt.

Btw, Passwoerter kann man ja prinzipiell so angeben lassen, dass sie 
mindestens x Stellen haben und mindestens je einen Grosz- und Kleinbuchstaben
sowie ein Sonderzeichen und/oder eine Ziffer enthalten. Und nebenbei 
in der Wortanalyse keinen woerterbuchbekannten Begriff bilden. Da ist dann
zwar ein gut Stueck Fantasie gefragt, aber das ist durchaus machbar.

Automatische Passwortrotation nach x Tagen gehoert ja sowieso dazu.

> [13] es sollte PHP und SSI zur Verfügung gestellt werden, schon weil
>      es Arktur auch kann ;-)
>      vielleicht abschaltbar, falls es nicht gebraucht wird

Ahm ... so rein vom technischen: PHP sauber und sicher zu installieren, 
ist das eine. Aber noch SSI dazu zu nehmen, grenzt an Selbstmord.
Die Chance, so etwas sicher gegen Angriffe zu machen, ist in einem 
lehrerverwalteten System zu gering. (Nichts gegen die mitlesenden und
bestimmt hochmotivierten LehrerInnen, aber selbst Techniker brauchen
einiges an Know-How, um so eine Kombination abzusichern. Die meisten
verzichten daher auf SSI, auch wenn es nette Spielereien erzeugen
kann :) Ich glaube daher, dass es ein bisschen viel von einem Lehrer
verlangt waere, muesste er sich in einem so flexibel zu haltenden 
System wie dem Schulserver auch noch mit der fuer exakt seinen Fall
richtigen Konfiguration fuer SSI befassen. Sollte ich mich an dieser
Stelle irren, habe ich nichts gegen den Widerspruch einzuwenden :)
 

So viel fuer heute :)

Viele Gruesze
Carola Kummert


PS: Deine Vita im Wiki liest sich gut :)




More information about the SAN mailing list