Pflichtenheft aktuell (2)

Alexander Dubielczyk Alexander.Dubielczyk at gmx.de
Fri May 16 13:29:03 CEST 2003


Am Fre, 2003-05-16 um 11.05 schrieb Hans-Dietrich Kirmse:

Hallo Hans-Dietrich,

> > >
> > > 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)
> 
> war von mir schlecht formuliert bzw. schlecht durchdacht
> 
> > Also die Gruppen dürfen imo nichts mit der Netzsegmentierung zu tun
> > haben (nicht jede Medienecke kriegt ein eigenes Subnetz). 
> 
> so etwas steht m.E. auf den Webseiten von Skolelinux. Wenn ich das 
> richtig verstanden habe, sind die ja deshalb in ein 10er Netz und
> nicht in einem 192er Netz. Ich hatte deshalb wirklich angenommen,
> das jede Medienecke ebenfalls ihr eigenes Subnetz bekommt.

Wie gesagt: Das sollte unabhängig von Subnetzen geschehen können. Es
könnten also (bei einem Class-C Netz) durchaus die Rechner 192.168.0.1
und 192.168.100.1 in einer logischen Gruppe auftauchen (obwohl das in
der Praxis wahrscheinlich kaum vorkommt).

> > Ich finde es
> > aber sinnvoll die Gruppierung von Rechnern "global" zu definieren
und
> > andere Funktionen des Systems auf diese Gruppierung zurückgreifen zu
> > lassen. Ich sehe im Moment eher Nachteile darin, diese
Funktionalität
> > für jeden Dienst einzeln zu implementieren und dann auch zu pflegen.
> > Warum sollte man Rechner für verschiedene Dienste in verschiedene
> > Gruppen einteilen? Fällt mir so spontan kein Szenario für ein.
> 
> Bei mir war mehr der Gedanke, das zumindest der Rechner von dem aus
> kontrolliert wird (also der Lehrerrechner) sinnvollerweise im gleichen
> Raum steht, und damit auch in der gleichen Gruppe ist. 
> 
> Ursache ist, das aus jeder Schutzsoftware (im weitesten Sinne) auf 
> einmal eine Waffe wird, wenn diese in die falschen Händen kommt.
> Mal ein typisches Windowsbeispiel: Wenn man Master-Eye, also eine
> kommerzielle Lösung um die Bildschirme auf den Lehrer-Rechner zu
> holen und Monitore und Tastaturen sperren zu können auf einmal auf
> den Schülerrechner zur Verfügung hätte, dann könnte das den
> Unterricht sofort lahm legen können ohne die Chance zu wissen wo es
> herkommt. Ist es im gleichen Raum, dann hat der Lehrer die chance,
> wenigstens zu Fuß alle plätze zu inspizieren oder an den Verhalten
> der schüler etwas zu merken oder einen Klassenkameraden fällt was
> auf. Aber ferngesteuert würde ich richtig problematisch sehen.
> 
> Aus meiner Sicht sollte der im gleichen Raum sein. Andererseits
> könnte der u.U. mehr Rechte brauchen, z.B. die Schülerrechner haben
> nur Zugriff auf den Fileserver, aber der Lehrerrechner hat auch
> Zugriff auf den Webserver und die Logfiles etc. zu kontrollieren.
> 
> ist mir jetzt richtig unklar :-(

An diese Unterteilung in Lehrer-/Master-Platz und normalen
Schülerarbeitsplatz hatte ich auch schon gedacht. Aber das könnte man ja
machen, indem man Rechnern mit zusätzlichen "Freiheiten" einfach ein
"Master"-Flag verpasst.

Beispiel:

2 Kabinette mit je einem Lehrerarbeitsplatz und 2 Schülerarbeitsplätzen

Rechner         Gruppe          Master
--------------------------------------------
Kab1-01         Kabinett1       X
Kab1-02         Kabinett1       
Kab1-03         Kabinett1       
Kab2-01         Kabinett2       
Kab2-02         Kabinett2       X
Kab2-03         Kabinett2       

Hierbei wären dann Kab1-01/Kab2-02 die Lehrer-Arbeistplätze bzw.
Arbeitsplätze mit höherer Berechtigung im Netz. Das könnte z.B. dann
Einfluss auf die Klausurumgebung haben oder auf das Trennen des Raums
vom Internet oder ähnlichen Dingen.

Was hinter dem Rechnernamen nun wirklich für eine IP bzw. welches
Subnetz steht ist imo egal.

Gruß,
                Alex




-- 

Alexander Dubielczyk <Alexander.Dubielczyk at gmx.de>

Public PGP/GPG Key: http://www.rep-intern.de/keys/alexdu.gpg
Key fingerprint = 61BA 2C78 3503 B7ED 9B00 61DA D8D8 6C8F 3F2B 1302





More information about the SAN mailing list