Pflichtenheft - Nutzerverwaltung

[Hans-Dietrich Kirmse]

Stephan Beyer schrieb:
> 
> hallo,
> 
> hans-dietrich schrieb, dass nutzerverwaltung noch offen ist...
> ein paar kommentare zu ihr (das pflichtenheft ist gequotet):
> 
> > Es ergeben sich für die schulischen Anforderungen folgende Einteilung:
> > - Admin
> > - Lehrer mit besonderen Aufgaben        =>  spezielle Accounts
> 
> werden diese personen- oder aufgabengebunden angelegt? klingt ein
> bisschen wie aufgabengebunden, also dass es nicht einen user smeier
> gibt, der auch die haupthomepage bearbeiten darf, sondern dass es einen
> user homepage gibt ... (ich weiss die homepageverwaltung wird anders
> geregelt, ist nur ein beispiel) ... dessen passwort aber mehrere
> personen kriegen...

dann weißt du was falsch - hier könnte/müßte Rene sich äußern.

> hm diese variante halte ich aber nicht fuer gut, besser waere es
> natuerlich, ein account pro person (ausser admin) und smeier wird dann
> halt in die benoetigten gruppen eingetragen, also der "normale" weg...

der normale weg ist, das ein Linuxserver z.B. immer mindestens
2 Accounts hat - einen Anwender und root. Ist das nicht aufgaben-
gebunden. haben die da was falsch überlegt ? ;-)

Auf jeden Fall entspricht das dem "Prinzip des kleinsten Privilegs".
Es hat außerdem den Vorteil, wenn ein Lehrer/Schüler eine Aufgabe
nicht mehr wahrnehmen will, dann kann er diesen Account weitergeben.
Der nachfolger ändert das Passwort und alles ist erledigt. 

> hat die vorteile dass passwoerter nicht von einer breiten menge gekannt
> werden sondern jedernur seins hat, und dass halt jeder einzelne die
> verantwortung traegt fuer das was er tut - auch als lehrer :)

wo sollen Passwörter weitergegeben werden. An welcher Stelle
klingt das so. Es ist nicht gewollt und soll auch niemals so sein!


> 
> > jeder User erhält einen Account,
> > dieser kann erstellt werden über
> >
> > - die Eingabe in einem Menü mit folgenden Feldern:
> 
> die liste dazu sieht ganz vollstaendig aus, allerdings "auswahl ob
> lehrer oder schüler" ... wo sind die admins?

hm, kann ich inzwischen nachvollziehen.

> 
> > - das Einlesen der Daten aus einem File
> > - durch Datenübergabe eines weiteren Programms
> 
> wenn man die datenuebergabe vom gleichen format her ist, wie das file,
> dann waere das ein und dasselbe skript, was arbeiten muss, was von
> enormen vorteil ist... 

mag sein, aber dieser Standpunkt gefällt mir nicht.
Das Modul, welches die BW-lösung realisiert, wird (vermutlich) von
jemanden anders erstellt als das auf jeden Fall existente Modul,
was hier als Basis ansetzt. Auch wenn die Entwickler die gleichen
programmiersprachen verwenden sollten, lieber würde ich mit
2 gleichen programmen (Kopie) arbeiten lassen als das die Kapselung
dieser Module zerstört wird. - immer entflechten, es ist auch der
Festplatte für die paar Bytes auf jeden fall Platz.

allerdings kenn ich die erwaehnte
> bw-musterloesung nicht, was sie vorsieht... bzw kann man beide auch
> kombinieren -> einlesen aus einem file (was in einem programm realisiert
> wird, welches die aufbereiteten daten uebergibt)...

solche kunstgriffe um ein paar Bates zu sparen - einfach vergessen.


> 
> > Das Erstellen des Loginnamen soll ein separates Modul (Script)
> > übernehmen, deren Schnittstellen zum aufrufenden Programm gut
> > dokumentiert sind.
> 
> das ist sehr gut... somit ist keine schule an ein system gebunden.

schön das noch was bleibt ;-)

> 
> >    Beispiel: Manfred Mustermann -> mmustermann
> > Sollten Logins nach diesem Muster schon vergeben sein, wird
> > automatisch variiert z.B. 2 Buchstaben vom Vornamen
> 
> auch wenn es nur ein vorschlag war, und darueber schon mehrfach
> diskutiert wuerde, ist er nicht wirklich sinnvoll ;)
> 
> einfacher waer es zu nummerieren, naemlich nur mal angenommen es gibt in
> vielen klassenstufen einen michael mueller (ueber die wahrscheinlichkeit
> moechten wir jetzt nicht diskutieren):
> mmueller       <- mit monika mueller vergeben
> mimueller      <- klasse 12
> micmueller     <- klasse 10
> michmueller    <- klasse 9
> michamueller   <- klasse 8
> michaemueller  <- klasse 7
> michaelmueller <- klasse 6
> 
> was tun wir nun mit dem armen hinzugekommenden michael mueller in klasse
> 5? da koennte man nun weiterprogrammieren, dass noch sonstewas mit dem
> namen gemacht wird, is aber nur unsinnigerweise mehr code...

dein Modell krankt daran, das bei uns die Accounts immer in der
5. Klasse angelegt werden. Beim ersten mal natürlich nicht.

 
> deswegen waere mmueller -> mmueller2 -> mmueller3 -> mmueller4
> sinnvoller, also einfach ein inkrementeller zaehler :)
> auch wenn es nicht mehr so "edel" aussieht wie zb ein michamueller :)

du sagst es. michamueller ist edler. warum soll ich auf was
schlechteres ausweichen ;-)
Außerdem ist mir das eh wurscht. nimmt man eben diesen Nummernsalat,
dann setze ich mich hin oder lasse es von dir machen, dieses 
angegebene System zu portieren.

 
> fuer das pflichtenheft wuerde ich als beispiel - rein formell - ein
> fast endlos skalierbares beispiel bevorzugen ;)

ich lieber ein edles ;-)

 
> > Beim Erstellen des Accounts wird gleichzeitig ein Mailaccount
> > generiert.
> 
> technisch gesehen ist das doch so standard (nicht nur) mit exim in debian
> und der entsprechenden vorkonfiguration...

nun, auch das stört mich nicht - hauptsache es ist da.
es steht im Pflichtenheft unabhänig vom Aufwand.

 
> > 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.
> 
> wahrscheinlich alle lehrer, die das kabinett betreten:

nein - niemals!
der Admin gibt das an den lehrer weiter, denen er die Verantwortung
auch übergeben kann. Ein Schüler ist von einem Lehrer ausgesperrt
(theoretisch) und beim anderen lehrer macht er sich liebkind
und erhält sein Passwort wieder. - nie. Verantwortung wird
delegiert nicht mit der Gieskanne verbreitet.

> englischklasse ist im kabinett, einer ruft: "mrs spasm, i've lost my
> password" ... damit nicht ein vielleicht beschaeftigter informatiklehrer
> geholt werden muss, und der schueler trotzdem arbeiten kann, der lehrer
> gleich das passwort neusetzen kann.

Strafe muß sein. Außerdem kann er ja von einem Mitschüler das
passwort "geborgt" bekommen. Der muß es halt dann ändern.
Wenns Ärger gibt, dann zwischen den beiden Schülern, denn der 
Lehrer krallt sich den mit dem Login.

> 
> > 1.2.3   Löschen der Accounts
> 
> das loeschen eines accounts bedeutet nicht gleich das loeschen seines
> persoenlichen verzeichnisses (homeverzeichnis)... sollte man dies
> einfach so machen? 

ja - sollte der Admin 2 mal löschen? erst den Account und
dann das homeverzeichnis?

> dies stellt wahrscheinlich kein problem dar, da kein
> schueler in der schule lebensnotwendige sachen ablegt, also denke ich,
> das dieses skript das auch erledigen sollte, aber in der letzten stunde
> am rechner sollte man zumindest alle darauf hinweisen, zu gucken, ob
> die schueler nicht noch etwas was sie vllt aufbewahren wollen, sichern
> moegen ... (in einigen langweiligen infostunden entstehen schon manchmal
			^^^^^^^^^^^^^^^^^^^^^^^^
                         aha ;-)

> interessante programme und spielereien, die man behalten mag :)


 
> > 1.2.5   Klausurumgebung
> 
> dabei ist etwas wichtiges nicht beachtet... digital spicken kann man nicht
> nur uebers netzwerk, sondern auch von daten, die man auf die lokale
> festplatte gelegt hat (bei windows clients kein problem, bei linux

es ging hier nur um den Server. Bei den Clients muß z.B. über ein 
neues image für saubere Festplatten gesorgt werden.
(Umsetzen hilft auch schon etwas ;-)




                                  /"\
Mit freundlichen Grüßen           \ / ASCII ribbon campaign
Hans-Dietrich                      X  against HTML mail 
                                  / \ and postings