Administrative Überlegungen

UNIX-Rechte und CORBA

Die Corba-Server laufen als UNIX-Prozesse auf dem Gateway-Rechner und haben UNIX mäßig Rechte. Folgendes sollte unter root auf dem Gateway-Rechner laufen:

dialupmanager , da er auf die Devices zugreifen muß
queuemanager , da er das Mailspooldateien lesen möchte
fifo2ev , da es die Dateien in /var/log/ lesen möchte

Folgende CORBA-Dienste werden benötigt:

Interfacerepository
Nameservice
Eventservice

Letztere können unter einer gewöhnlichen uid laufen, sogar auf einem anderen Server.

Das Interfacerepository, der dialupmanager und fifo2ev werden direkt vom Betriebsystem aus gestartet.

Der queuemanager kann vom Implementationrepository aus gestartet werden, bei MICO der micod. Unter mehreren Uids könnte jeweils ein eigenes Implementationrepository laufen.

Die PORT-Adresse der Server von CORBA-MMIMS kann im Startscript eingetragen werden und es wird empfohlen, diese im Gatewayrechner zum Internet hin zu sperren.

Annahmen:

CORBAMMIMS ist für vertrauenswürdige Netze.
Der Gatewayrechner wird sowieso als unsicherer Rechner betrachtet.

Deswegen kann man es verantworten, aus Bequemlichkeitsgründen alle Dienste unter root laufen zu lassen.

Folgende Bedenken will ich aber nicht verschweigen:

Corba -IIOP hebelt die UNIX-Sicherheit in sofern aus, daß beliebige Nutzer aus dem Netz (lokal oder gar das Internet) Objektmethoden aufrufen können.
Der MICO-ORB und die CORBAMMIMS-Server sind neuer Code und Bufferoverflows und ähnliche Häßlichkeiten könnten darin enthalten sein.

Verteilung von CORBA-Objekten im (lokalen) Netz

Ohne weitere Maßnahmen kann bisher jeder Nutzer im Netz

Interfaces im Interfacerepository eintragen und löschen
Namen in den Nameserver verwalten.

Konzeptionell wollen wir ein Unternehmensweiten Nameserver vorsehen, wo die globalen Objektnamen verwaltet werden.

Bei unserem Corbammims z.B. der Dialmanagerkontext mit den Dialdevices und den Mailqueues und cti-Eventchannel.

Jeder Nutzer kann auf seiner Arbeitsstation einen lokalen Nameserver haben, wo seine GUI-Objekte eingetragen sind.

Die Nameserver der Nutzer können untereinander und mit dem globalen zusammenglinkt werden.

Andererseits ist anzunehmen, daß die CORBA-Interfaces der Objekte von allen Beteiligten im Unternehmen gebraucht werden, und deshalb sehen wir ein globales Interfacerepository vor.

Vorgeschlagene Verzeichnisstruktur und Softwareverteilung

MICO, CORBA-Script und tcltk/itcl,combat werden auf allen Rechnern benötigt.
Desgleichen die clients
Die CORBA-MMIMS-Server werden nur auf dem Gatewayrechnern benötigt.

Dazu empfehlen wir die Politik nach dem Paketkonzept.
Natürlich, Javaclients könnten als Applets über das HTTP verteilt verwerden...

Zentrales Logging

Mit dem Logger können Ereignisse verschiedener Dienste und Anwendungsprogramme zentral überwacht werden. Hier wäre eine Verbindung mit dem Netzwerkmanagement sinnvoll.

Startscript

Bislang wird Corbammims mit dem Shellscript corbammims gestartet und gestoppt, wie es dem UNIX-System V - Bootkonzept entspricht.
Server können natürlich, wie in UNIX üblich, eine Datei mit der Pid anlegen.
Mit unserer Kontroll-Schnittstelle ausgestattet, hinterlegen sie stattdessen die Objektreferenz in einer Datei (elementar) oder z.B.in einem speziellen Namingcontext (meist nicht mehr so elementar).
Mit einem kleinen CORBA-Script stopctrl.cs, das die Controllreferenzobjekt als file-URL als Parameter hat, wird die Pid ermittelt und ein UNIX-Terminierungssignal gesandt.

Damit liegt auch die Idee nahe, daß ganze Startscript in CORBA-Script zu schreiben.
Zusammen mit dem Gedanken, daß die UNIX-Philosophie Die Welt besteht aus Dateien im nachheinein gesehen schon immer bedenklich war, da die Welt bekanntlich aus Objekten besteht, und diese im verteilten System natürlich CORBA-Objekte sind, bedeutet dies, daß CORBA-Script die Rolle der traditionellen UNIX-Shells einnehmen wird (oder zumindest sollte).

Rudolf Weber Informatik- und Netzwerkverein Ravensburg e.V