next up previous contents index
Next: 2.5.3 Beispiel Up: 2.5 Dienst-Management Previous: 2.5.1 Allgemeines

2.5.2 Umsetzungs-Idee

In einem komplexen Umfeld fallen naturgemäß eine große Anzahl von Einträgen und Konfigurationen an. Diese betreffen oft nicht nur einzelne Dienste, sondern das gesamte System, mit all seinen Diensten.

Damit dieses einfach zu warten ist, benötigt man eine Möglichkeit schnell und menschenlesbar größere Mengen an Regeln und sonstigen Angaben niederschreiben zu können.

Solche Regeln umfassen die Eintragung neuer Nutzer des Systems (Nomadische Systeme) genauso, wie Dienste und deren Teilkomponenten, den Proxy für den Dienst Web (HTTP) und den Server, der Emails mit dem Protokoll POP3 ausliefert.

Will man diese Idee praktisch umsetzen, werden eine Reihe von Fragen aufgeworfen.

Einem Nutzer muß mindestens eine IP-Adresse zugewiesen werden können. Soll diese statisch (also immer die gleiche Adresse) sein oder soll sie dynamisch bei jedem Anmelden im Netz aus einem größeren Adresspool zugewiesen werden?

Ein Service muß erfragen können, welche Nutzer seine Dienste nutzen dürfen. Hat ein spezieller Nutzer besondere Vorrechte?

Wer einen Service nutzt, verursacht zwangsläufig Kosten, welche abgerechnet werden müssen. Soll diese Abrechnung nach jeder Nutzung erfolgen? Was, wenn der Nutzer schon so viel von diesem Dienst genutzt hat, daß er ihn jetzt nicht mehr nutzen darf? Soll vor jeder Erbringung des Services abgerechnet werden, sobald die zu erwartenden Kosten bekannt sind oder nach der Nutzung? Wie sieht eine zu berechnende Einheit aus: Pro angefangenen Meter Papier? Pro benötigte Zeit? Pro Auftrag?

Was passiert, wenn im System ein Sicherheitsproblem auftaucht oder ein Ereignis, welches einen weiteren reibungslosen Ablauf verhindert?

[GUI zum Erfassen eines neuen Nutzers]GUI zum Erfassen eines neuen Nutzers 

Lösungen zu all diesen Fragen muß man individuell dem Managementsystem vermitteln können. Dazu benötigt man eine einfach zu handhabende Beschreibungsmöglichkeit.

Wie eine solche Eingabemöglichkeit aussehen kann, ist in Abbildung 2.8 zu sehen.

Diese Art der Eingabemöglichkeit über ein fertiges grafisches Formular, sieht sehr gut aus und ist für einen Ungeübten leicht bedienbar. Leider ist diese Form der Datenerfassung sehr behindernd, wenn eine größere Menge Nutzer auf einmal erfasst werden müssen, wie zum Beispiel die Teilnehmer eines Kongresses, die

Hinderlich an dieser Art Formular ist die Tatsache, daß man nicht mit wenigen Handgriffen einen bereits konfigurierten Nutzer duplizieren kann. Häufig pendelt man zwischen Tastatur und Maus hin und her. Dabei verliert man wertvolle Zeit und die Eintragung der Daten dauert unnötig lange.

[ASCII-File zum Erfassen eines neuen Nutzers]ASCII-File zum Erfassen eines neuen Nutzers 

Abbildung 2.9 zeigt einen anderen, rein ASCII-basierten Ansatz für genau die gleiche Problemstellung. Dabei wird ein normaler Editor zum Erfassen der Daten verwendet. Vorteil dieser Vorgehensweise ist, daß man die Techniken, die ein Editor zur Verfügung stellt (cut and paste) leichter nutzen kann, als in einem GUI-basierten Interface.

Wenn man zusätzlich eine Eingabesprache wählt, die vom Konzept her bereits bekannt und einfach verständlich ist, kann auch ein Ungeübter sich in diese Technik schnell einarbeiten.


next up previous contents index
Next: 2.5.3 Beispiel Up: 2.5 Dienst-Management Previous: 2.5.1 Allgemeines
Copyright Munich Network Management Team