Pflichtenheft aktuell (1)
Hans-Dietrich Kirmse
hd.kirmse at gmx.de
Wed May 21 23:55:41 CEST 2003
Alexander Dubielczyk schrieb:
>
> Am Mit, 2003-05-21 um 21.12 schrieb Hans-Dietrich Kirmse:
>
> Hallo Hans-Dietrich,
>
:
>
> Die Frage ist: Kannst Du die Problemstellung angemessen und sicher
> lösen, indem Du ein gutes _Serverkonzept_ hast? Meiner Meinung nach
> nicht: Du brauchst dazu ein passendes _Netzwerkkonzept_, welches
Hm, wenn ich das so recht bedenke, dann wird mit dem Skolelinuxserver
trotzdem auch ein (wenn auch sehr primitives) netzwerkkonzept
geliefert, nämlich
internet -- router -- Skoleserver --- clients ...
oder
internet -- router -- Skoleserver
|
Terminalserver --- clients ...
|
Terminalserver --- clients ...
|
Terminalserver --- clients ...
> Bereiche unterschiedlicher Sicherheitsstufen vorsieht (Stichwort:
> Demilitarisierte Zone). Kann/sollte es Aufgabe einer
> "Schulserver-Distribution" sein, solch ein Konzept zu entwerfen und
> vorzuschreiben?
nun, eigentlich geht es nur um den Server. Derjenige der den Server
einsetzt sollte natürlich das Wissen für seine Nutzung haben.
Werden höhere anspüche gestellt, dann muß er da durch. Bedeutet nicht,
das die Bedienung deswegen kryptischer werden muß.
Auch wenn hier immer mehr Möglichkeiten bereitgestellt werden,
bedeutet das noch lange nicht, das die auch sinnvoll eingesetzt
werden. Er muß sich mit den technischen und pädagogischen Konzepten
vertraut machen.
Für den admin analog, er muß sich mit den technischen UND den
Netzkonzepten vertraut machen. Es kann hier nur darum gehen, das die
technische Seite (also Bedienung und Sicherheit) optimal gestaltet
wird.
Das andere kann durch Anleitungen etc. geliefert werden. wie gesagt
nicht als pflicht, sondern als Kür.
Auf für die Nutzung (von Arktur) gibt es dokumentatitonen im Netz.
Warum nicht für die Einbindung in Netzkonzept (für die die es
brauchen)
>
> > Ich denke, die zeiten werden sich ändern. vor 3 jahren waren die
> > meisten Schulen noch gar nicht am Netz, denn kostenlos T-Online
> > gibt es noch nicht solange (denke ich jetzt mal).
> > In 3 Jahren, warum sollen denn da nicht Standleitungen möglich sein.
> > Die Frage wird zumindest häufiger gestellt.
> >
> > Wenn eine saubere Lösung mit guter Dokumentation (einschließlich
> > der deutlichen Warnungen!) als skalierbare Lösung existieren würde,
> > dann wäre mehr gekonnt.
>
> Wie bereits an anderer Stelle gesagt: Der Wunsch nach solchen
> Funktionalitäten ist mehr als verständlich. Mit der Idee einer Anleitung
> statt einer out-of-the-box Lösung könnte ich mich durchaus anfreunden,
> wenn diese ein gewisses Verständnis für die Problematik vorausetzt.
wie gesagt, das muß vorausgesetzt werden können, ansonsten ist es
sowieso die falsche Person am falschen Platz.
>
> > > - Sicherheitsaspekt: Wie die Erfahrung zeigt muss ein Server im Internetz
> > > viel besser abgesichert werden.
> >
> > richtig. Aber auch Universitäten, Krankenhäuser etc. haben serienweise
> > die Rechner am Netz. Die Brisanz der Daten ist dort ungleich höher.
>
> Und es wird z.T. geschlampt was das Zeug hält, wenn da nicht
> irgendwelche Profis am Werk sind :-/
das ändert aber auch ein guter Server nicht.
>
> > > Man koennte ueberlegen, ob diese Funktionalitaet durch ein Zusatzmodul gewaehrleistet
> > > werden kann, aber zur Basisaustattung sollte es nicht gehoeren.
> >
> > richtig, es sollte eben mit fli4l oder für die Smoothwall eine
> > detaillierte Anleitung erstellt werden - quasi als Addon.
> >
> > > (Ich weiss aber nicht, ob dies so sinnvoll ist. Wahrscheinlich ist dann
> > > ein grundlegend
> > > anderes Konzept, d.h. ein Server fuers Schul-Intranet und davon getrennt
> > > ein
> > > Server fuer den Zugang von Aussen, oder aehnliches, viel besser geeignet.)
> >
> > Prinzipiell kann man 2 Server anders strukturieren, aber wenn der
> > eine Server nunmal so da ist, dann wird eben ein kleiner Rechner
> > als Firewall davor gesetzt.
> >
> > wie gesagt - nicht als Empfehlung, aber für eine skalierbare lösung
> > gehört es (irgendwann) dazu.
>
> Hier noch mal ein Verweis auf meine letzte Mail zu dem Thema. Es ist
> meiner Ansicht nach nicht damit getan bestimmte Dienste zu dem Server
> durch einen Paketfilter reinzulassen oder eben nicht. Bestimmte Dienste,
> die extern verfügbar sein sollen, müssen auf einem separaten Server
> laufen. Das ist ein wichtiger Unterschied.
und wenn das ein vserver wäre?
> > Dabei zieht das sicher weitere Kreise. Wenn man an sowas denkt, dann
> > kann man auch an Fernwartung denken. - es gab bis jetzt keinen
> > Gedanke dazu.
>
> Da sehe ich keine großen Gefahren. Ein ssh-Zugang läßt sich auf recht
> einfache Weise wasserdicht machen. Da kann nicht viel schiefgehen, wenn
> das Programm selber keine Sicherheitslöcher aufweist (->regelmäßige
> Updates)
dann sollte man das irgendwie ins Pflichtenheft mit aufnehmen.
>
> > Wenn man immer online wäre, dann könnte es vielleicht auch probleme
> > geben, das der Admin nicht mehr weiter weiß (wer weiß schon alles).
> >
> > einen Account, das man von außen inspizieren kann, ohne etwas zu
> > verändern zu können wäre sicher hilfreich. (zumindest Lesezugriff
> > auf alle logfiles und auf Konfigurationsdateien)
> > Arktur hat dazu meines Wissens einen User "service". natürlich nicht
> > dokumentiert und schon ist das ganze in der Versenkung verschwunden.
> >
> > warum nicht soetwas überlegen/abgucken? könnte sogar sinn machen
> > ohne das man im Netz etwas freigibt.
>
> Mmhh... über diesen Wartungsuser muss ich mir erst noch mal Gedanken
> machen... das klingt gefährlich....
ich meine das so: es gibt einen speziellen Account, der zwar nicht
existent ist, aber schnell bereitgestellt (generiert) werden kann.
Falls also Hilfe gebraucht wird, dann könnte mit diesem account ein
anderer, dem dazu das Login (also "service") und das Passwort
übermittelt wird, sich per ssh einklinken und hat aber nur lesenden
zugriff auf die Dateien, die sinnvoll erscheinen. m.E. logdateien
und Konfigurationsdateien. Nach dieser Arbeit - hoffentlich
erfolgreich wird der Account "service" wieder gelöscht.
Hilfe bekommen heißt immer, das jemand anderes informationen erhält.
durch den "vorbereiteten" user dürften aber weniger Fehler passieren
als wenn man keine Hilfe erhält oder gibt ihm letztendlich gar noch
root-Rechte.
/"\
Mit freundlichen Grüßen \ / ASCII ribbon campaign
Hans-Dietrich X against HTML mail
/ \ and postings
More information about the SAN
mailing list