1/96 pdf

1/96
Table of Contents
In aller Kürze
Welches Mail−Programm?
Flieg,Pferdchen, flieg... Der Mail Client Pegasus
MIME − Multipurpose Internet Mail Extension
Sicherheit bei Kommunikations−Anwendungen, insbesondere bei E/Mail
E−Mail im Unix−Workstationpool
VBN in BelWü 1988 − 1995
ATM − RUS, urbi et orbi
The University of Stuttgart − A Future−Oriented Place of Research and
Teaching:
· Belwü Coordination
· Information Services
· High−Performance Computing
· Server & Networks
· Basic Services
· Projects of RUS
Fachhochschule Isny der Naturwissenschaftlich−Technischen Akademie Prof.
Dr. Grübler, gemeinnützige GmbH
Der Südwestdeutsche Bibliotheksverbund
FTP−, WWW−, Info−Server, Netzinfos
BelWü−Beauftragte
Inhaltsverzeichnisse aller BelWü−Spots
1
März 1996
Contents
1/ 96
+++ in aller Kürze +++
+++ Im Dezember 95 unterschrieben das Land (MWF) und eine Tochter der
baden−württembergischen Energieversorger (CNS) eine Vereinbarung hinsichtlich der
Versorgung der BelWü−Teilnehmer mit Hochgeschwindigkeitsverbindungen. Zu Beginn
werden die Anschlüsse zwischen den neun Landesuniversitäten vom DFN im Rahmen
des Breitband−(ATM) Wissenschaftsnetzes erbracht − ab spätestens April 96 mit 34
MBit/s, später dann mit 155 MBit/s. Parallel dazu wird ein ebenfalls auf ATM
basierendes Hochgeschwindigkeitsnetz auf Leitungen der Energieversorger aufgebaut,
über die neben den Universitäten (mit 155 MBit/s) ab 1998 zusätzlich einige
Fachhochschulen mit 34 MBit/s eingebunden werden sollen. Im Vorgriff darauf sind seit
Ende 1995 zehn Fachhochschulen mit 2 MBit/s Telekom−Standleitungen an das BelWü
angebunden. +++
+++ Der unbefriedigende transatlantische Zugang soll durch Erhöhung der
Leitungskapazität durch den DFN verbessert werden. Gerüchteweise hört man hier
sowohl 34 MBit/s nach Europa als auch USA. +++
+++ Die Dynamik des Internets läßt sich auch im BelWü nachvollziehen: So
verzwanzigfachte sich das Verkehrsvolumen der BelWü−Teilnehmer von Ende 91 von 80
GByte/Monat auf über 1600 GByte/Monat Ende 95. +++
+++ Ende 95 verband das BelWü über 45 000 Rechner von über 70 Teilnehmern: Den
Universitäten Freiburg, Heidelberg, Hohenheim, Karlsruhe, Konstanz, Mannheim,
Stuttgart, Tübingen und Ulm; den Fachhochschulen Aalen, Albstadt−Sigmaringen,
Biberach, Esslingen, Furtwangen, Heilbronn, Isny, Karlsruhe (FHT und HfG),
Konstanz, Ludwigsburg, Mannheim (FHT und FHS), Nürtingen, Offenburg, Pforzheim,
Reutlingen, Rottenburg, Schwäbisch Gmünd, Stuttgart (FHB, FHD, FHT), Ulm und
Weingarten; den Berufsakademien Heidenheim, Karlsruhe, Lörrach, Mannheim,
Mosbach, Ravensburg und Stuttgart, den Pädagogischen Hochschulen Heidelberg,
Ludwigsburg und Schwäbisch Gmünd, der Musikhochschule Stuttgart, der Akademie
für Datenverarbeitung Böblingen, der Badischen Landesbibliothek Karlsruhe, dem
Institut für Deutsche Sprache Mannheim, dem Zen−trum für europäische
Wirtschaftsforschung Mannheim, dem Zentralinstitut für Seelische Gesundheit
Mannheim, dem Deutschen Literaturarchiv Marbach, der University of Maryland
(Außenstelle Schwäbisch Gmünd), dem Mathematischen Forschungsinstitut
Oberwolfach, der Akademie für Technikfolgenabschätzung Stuttgart, der evangelischen
Landeskirche Stuttgart, der Landesbildstelle Stuttgart, dem Landesinstitut für
Erziehung und Unterricht Stuttgart, dem Ministerium für Wissenschaft und Forschung
Stuttgart, dem Psychotherapeutischen Zentrum Stuttgart, der Württembergischen
Landesbibliothek Stuttgart sowie mehreren nicht−öffentlichen Teilnehmer. +++
2
IMG
Welches Mail−Programm?
Hartmuth Heldt
Auswahlkriterien bei der Wahl
eines Mail−Programms für Einsteiger
Die Kommunikation über Electronic Mail ist eine der ersten und wichtigsten
Anwendungen, mit der man im Internet konfrontiert wird. Für den Anfänger stellt sich
dann allerdings die Frage, welches Programm für ihn sinnvoll ist. In diesem Artikel
werden die verschiedenen Kriterien für die Auswahl eines Programmes erläutert. Dabei
werden die diversen Rechnerplattformen und Verbindungsarten, wie Modem oder
Arbeitsplatzrechner, am Uni−Netz berücksichtigt.
Ein bestimmtes Programm zu empfehlen, ist zu−dem schwieriger als es auf den ersten
Blick er−scheint. Dies liegt nicht an den technischen De−tails, sondern an deren
Beurteilung.
Während der Anfänger, um schnell mit dem Programm zurechtzukommen, leicht
verständliche Funktionen benötigt, möchte der erfahrene An−wender die bequemen
Funktionen nicht vermissen. Daß er am Anfang kaum einsehen konnte, warum er diese
Funktionen so aufrufen muß, in−teressiert ihn nun nicht mehr. Wer am Tag hundert(e)
von Mails bearbeiten muß oder will, der benötigt schnelle Funktionen, ganz egal wie
einsichtig oder bequem sie sind.
In diesem Artikel wird die Sicht eines Anfängers berücksichtigt, der keine Erfahrungen
mit E−Mail oder einer bestimmten Rechnerplattform hat.
Um zu entscheiden, welches E−Mail−Programm man wählen sollte sind die folgenden
Kriterien wichtig:
· Die Rechnerplattform/das Betriebssystem
· Die Funktionen, die das Programm bietet
· Die Bedienung des Programms
· Der Ort, von dem die E−Mail verschickt oder empfangen werden soll.
Dabei ist es oft Ansichtssache, welches Kriteri−um einem am wichtigsten erscheint.
Insbesondere bei der Bedienung des Programmes gerät man in heftigste Diskussionen
darüber, ob beispielsweise die Bedienung einer grafischen Oberfläche mit der Maus
3
einfacher, schneller oder leichter ist, als einen Befehl mittels Tastatur einzugeben.
Angenommen, die Bedienung eines Programms mit der Maus ist einfacher, aber nicht
schneller als die Eingabe von Befehlen − was ist dann besser? Konkret wird auf die
folgenden (alphabetisch aufgelisteten) Programme eingegangen:
· elm
· emacs
· Eudora
· mail
· Netscape
· pine
· Pmail (Pegasus Mail).
Es gibt natürlich noch viele andere E−Mail−Programme. Sollte eines häufig in Ihrer
Umgebung benutzt werden, ist es zu empfehlen dieses auch zu benutzen, da Sie dann
die Möglichkeit haben, daß Andere Ihnen bei Problemen helfen können.
Als Infrastruktur setze ich die normale Umgebung an einer Universität voraus: Ein vom
Re−chenzentrum oder einer DV−Abteilung betriebener Pool von Unix−Rechnern. Den
Benutzern stehen Unix−Terminals (X−Terminals), PCs oder Macintosh−Rechner, die via
Uni−Netz (Ethernet, Tokenring, FDDI, ...) mit dem Rechenzentrum verbunden sind, zur
Verfügung. Weiterhin können Modemanschlüsse von zu Hause benutzt werden.
Auswahlkriterium:
Das Betriebssystem
Alle o.a. Programme, außer emacs, können mit PCs und Macintoshs benutzt werden. Die
Programme elm und mail sind reine Unix−Program−me und lassen sich deshalb von
PCs und Macs nur mit Hilfe des Programms Telnet (siehe un−ten) einsetzen. pine ist
sowohl unter Unix, als auch unter DOS (PC−Pine) verfügbar, die Nutzung durch Macs
ist wiederum nur mit Telnet möglich.
Mit Unix−Rechnern bzw. X−Terminals können Eudora und Pmail nicht verwendet
werden.
Auswahlkriterium:
Die Funktionen des Programms
4
Die wesentlichen Funktionen eines E−Mail−Programmes sind:
· Editor zum Schreiben einer E−Mail
· E−Mail verschicken/empfangen
· Speichern von abgeschickter und empfangener E−Mail
· E−Mail in verschiedenen Ordnern nach Inhalt sortieren
· Ein Adressbuch
· Nicknames, also Kurznamen für Adressaten
· Signatur
· Die Funktionen cc, bcc, forward und reply.
Jedes der genannten Programme hat alle diese wesentlichen Funktionen. Deshalb
scheidet bei der Wahl des Programms keines aufgrund einer fehlenden, wichtigen
Funktion aus.
Auswahlkriterium:
Die Bedienung des Programms
Bei der Bedienung sind zwei Extreme zu unterscheiden:
Das Programm läßt sich entweder mittels Mausklick und entsprechenden Menüs
bedienen oder es hat eine Kommandozeile, in der auswendig gelernte Befehle eingetippt
werden müssen. Es gibt auch Zwischenlösungen, z.B. Menüs, die über die Tastatur
bedient werden
Für Anfänger halte ich die menügesteuerten Programme für deutlich sinnvoller. Die
möglichen Befehle werden nach Themen sortiert angezeigt und sind durch einen
Mausklick auszuführen. Syntaxfehler können nicht vorkommen.
Der Hinweis, daß Kommandos schneller sind, ist sicher richtig, aber zum einen ist die
Ge−schwindigkeit am Anfang nicht das Problem, zum anderen können die meisten
menügeführten Programme auch über Kommandos oder Tastenkombinationen bedient
werden.
Zum Bedienungskomfort eines Mailprogramms gehört auch der Editor. Er dient zum
Schreiben und Korrigieren einer Mail.
Gerade bei Anfängern halte ich es für wichtig, daß ein Editor einfach zu bedienen ist
und folgende Funktionen erfüllt:
5
· Durch Drücken der Entertaste beginnt eine neue Zeile
· Drückt man die Entertaste in einer Zeile, wird dort ein Zeilenende−Zeichen eingefügt
· Mit den Cursortasten kann man sich im Text bewegen
· Tippt man im Textbereich Buchstaben, werden diese in den Text geschrieben.
Die Programme elm und mail erfüllen diese Be−dingungen nicht. Jedenfalls dann nicht,
wenn der mitgelieferte Editor verwendet wird. (Näheres weiter unten bei der
Beschreibung der Programme.)
Ohne an dieser Stelle auf die Programme konkret einzugehen, hier eine Reihenfolge
nach Be−dienbarkeit. Je weiter oben die Programme stehen, desto stärker sind sie
maus− und menügesteuert:
· Eudora
· Netscape
· Pmail (Pegasus Mail)
· emacs
· pine
· elm
· mail.
Auswahlkriterium:
Der Ort,
an dem das Programm benutzt wird
E−Mail wird im wesentlichen an drei verschiedenen Orten verwendet:
1. Am Arbeitsplatz an einem vernetzen Rechner
2. Zu Hause an einem Rechner mit Modemanschluß oder
3. an irgendeinem Ort an einem Rechner mit Internetanschluß.
Wer im Büro einen Arbeitsplatzrechner benutzt, zeitweise zu Hause seine E−Mail liest
und/oder oft auf Reisen von anderen Systemen aus seine Mail lesen muß, der benötigt
ein Programm oder eine Kombination von Programmen, die es ihm ermöglichen jederzeit
Zugriff auf seine E−Mail zu haben. In diesem Fall ist es nicht immer möglich, daß das
6
bevorzugte E−Mail−Programm zur Verfügung steht.
Im allgemeinen ist eine E−Mail−Adresse ein Ac−count auf einem Unix−Rechner im
Rechenzentrum. Dort kommt die E−Mail an und wird gespeichert, unabhängig davon,
wo sie gelesen wird. Betrachen wir die drei verschiedenen Orte:
1. Am vernetzten Arbeitsplatz an der Uni, mit einem Unix−Terminal (X−Terminal):
Die E−Mail wird nun über das Unix−Terminal (X−Terminal) auch an dem gleichen
Rechner gelesen und bleibt dort auch gespeichert. Mögliche Programme (ohne Wertung)
wären pine, elm, mail, emacs oder Netscape.
2. An einen PC oder Macintosh am Arbeitsplatz oder auch zu Hause, sofern eine
Modemanbindung existiert:
Soll die E−Mail auf einem PC oder Macintosh gelesen werden, wird dies im allgemeinen
mit Hilfe eines POP−Mail−Pro−grammes getan. Es nimmt Verbindung mit dem
Unix−Rechner auf und transportiert dann die Mail auf den PC (oder Macintosh, im
weiteren erwähne ich den Mac−intosh nicht mehr extra). Natürlich muß auf dem
Unix−Rechner ein POP−Server laufen. Wahlweise zeigt der PC nun die E−Mail nur an
und läßt sie auf dem UnixRechner gespeichert oder die E−Mail wird auf den PC
übertragen und dort gespeichert; gleichzeitig wird sie dann auf dem Unix−Rechner
gelöscht. Dies ist insbesondere bei Modemverbindungen von Vorteil, da nach der
Übertragung nun die Telefonverbindung abgebrochen werden kann. Beachten Sie aber,
ob Sie die Mail noch auf dem Unix−Rechner benötigen, z.B. um von einem anderen
Rechner noch einmal darauf zugreifen zu können. Die Berechtigung am Unix−Rechner
die E−Mail abzuholen ist natürlich mit UserID und Password gesichert. Geeignete
Programme sind (wieder ohne Wertung): Eudora, Pmail oder Netscape. Statt eines
POP−Mail−Programms können Sie auch mit Telnet eine Verbindung zum Unix−Rechner
aufbauen und dann mit pine, elm oder mail direkt auf dem Unix−Rechner arbeiten, wie
unter 3. beschrieben. Bei Modemverbindungen müssen Sie al−lerdings die Gebühren
beachten, da Sie die gesamte Zeit über die Verbindung halten müssen.
3. Zugang von irgendwo auf der Welt:
Sie benötigen einen Rechner mit Internet−Anschluß und Telnet−Programm.
Es spielt keine Rolle, was dies für ein Rechner und wie er angebunden ist; auch ein PC
mit Modemanschluß ist möglich. Via Telnet wählen Sie nun Ihren Unix−Rechner am
Rechenzentrum an. Sie erhalten dann ein Fenster oder Bildschirm, in dem Sie genauso
arbeiten, wie auf einem Unix−Terminal am Rechenzentrum, allerdings ohne Grafik. Das
E−Mail−Programm rufen Sie nun auf dem Unix−Rechner auf. Zu beachten sind die
unterschiedlichen Tastaturen der verschiedenen Rechner. Daher eignen sich nur
Programme, die mit den Tasten zu bedienen sind, die jeder Rechner zur Verfügung hat.
Dies sind im Prinzip die Buchstaben, die Shift− und Crtl−Taste (auf deutsch die
Umschalt− und Strg−Taste). Mit diesen Tasten lassen sich alle Befehle eingeben und es
funktioniert immer und überall. Geeignete Programme sind pine, elm und mail, da sie
ohne Grafik arbeiten und wie oben beschrieben zu bedienen sind. E−Mail, die Sie schon
mit einem POP−Mail−Programm, wie unter 2. be−schrieben, auf einem PC
abgespeichert haben, können Sie nun natürlich nicht mehr lesen!
Nachfolgend noch einige Kommentare zu den einzelnen Programmen.
7
Eudora
Eudora ist ein POP−Mail−Programm für PCs mit Windows oder Macintoshs. Eine
Verbindung über Modem ist möglich. Das Programm hat ei−ne grafische Oberfläche, die
mittels Maus zu be−dienen ist, es können aber auch Tastenkombinationen verwendet
werden; es ist daher leicht zu bedienen und außerdem gibt es (zumindest in der
Mac−Version) ein ausführliches Handbuch (MS−Word−Dokument).
Pmail
Pmail ist ebenfalls ein POP−Mail−Programm für PCs unter DOS, MS−Windows
(Winpmail) oder Macintosh. Im DOS werden die Menüs durch Buchstabentasten oder
Cursortasten bedient. Es gibt eine ausführliche Hilfe, aber das Programm ist (soweit ich
weiß) nur in Englisch erhältlich.
Netscape
Eigentlich ist Netscape ein WWW−Browser, der sich zur Eierlegenden Wollmilchsau
entwickelt hat. Das Programm gibt es auf allen Plattformen (Unix, PC, Macintosh).
Benutzt werden kann es als normales Mail− oder POP−Mail−Programm. Die
Mailfunktionen gibt es eventuell erst in der nächsten Version, je nach Plattform. Es hat
eine grafische (3D−) Oberfläche und ist mit der Maus zu bedienen. Dieses Programm
hätte den Vorteil alles abzudecken: WWW, News, Telnet, ftp und Mail.
emacs
emacs ist eigentlich ein Unix Editor (auf PC oder Macintosh ist er mir nicht bekannt).
Inzwischen gibt es ihn mit Menüsteuerung (Maus) − er kann aber auch noch mit den
praktischen Tastenkombinationen benutzt werden; z.B. Ctrl+x Ctrl+s zum Speichern −
es sind also nur vier Tasten zu drücken! Na gut drei, Ctrl kann man festhalten. Der
Editor ist sehr mächtig und bestens für be−stimmte Anwendungen, wie z.B.
Programmiersprachen, geeignet. Für E−Mail ist dies eigentlich nicht nötig, wenn man
ihn aber sowieso be−nutzt, erhält man sich die gewohnte Umgebung.
pine, elm, mail
Alle drei sind bekannte E−Mail−Programme auf Unix−Rechnern. Spätestens wenn man
via Telnet ein E−Mail−Programm benutzen muß, kommt man an einem der Drei (leider)
nicht vorbei. Die Programme sind textorientiert und haben keinerlei Grafik. Befehle
werden mit den Buchstabentasten ausgelöst. Wesentliche Unterschiede zwi−schen
diesen Programmen sind die Anzeige der möglichen Befehle und der verwendete Editor.
1. Unterschied:
Welche Buchstaben für welchen Befehl?
1.1. pine:
Bei pine stehen die Tasten−Befehl−Kombinationen unten auf dem Bildschirm. Wenn der
Platz nicht ausreicht, gibt es für Other Cmds den Befehl O. Man muß wissen, daß ^C die
8
Tastenkombination Ctrl+C bzw. Strg+C bedeutet
1.2. elm:
elm verrät auf ähnlicher Weise ei−nige Befehle, abhängig vom User Mode. Anfänger
bekommen nur wenige Befehle mit mehr Kommentar angezeigt, Experten alle Befeh−le,
aber mit sehr knappen Bezeichnungen. Immerhin steht dort der Hinweis "? = help"
1.3. mail:
Das Programm mail zeigt die eingegangene E−Mail an oder meldet: no mail for ...
E−Mail verschicken können Sie nur, wenn Sie die Adresse gleich beim Programmaufruf
mit angeben. Hilfe erhalten Sie mit "~?" Verlassen wird das Programm, ohne Schaden
anzurichten, mit "~q"
2. Unterschied:
Der Editor
2.1. pine:
pine hat den Editor pico. Er hat nicht viele Funktionen, aber genügend, um E−Mail
schreiben zu können. Die Enter−Taste beginnt eine neue Zeile und wenn man
Buchstabentasten drückt, tippt man diese als Text, genau das funktioniert bei den
beiden anderen Programmen nicht!
2.2. elm:
elm arbeitet mit dem Editor vi. Falls Sie in diesen (für Systemprogramierer
unverzichtbaren, mächtigen und genialen) Editor geraten, können Sie ihn ohne Schaden
anzurichten verlassen, indem Sie die Escape−Taste (Esc) drücken und dann ":q!"
eingeben. Sie können nicht einfach Text eintippen. Zum Üben laden Sie eine unwichtige
Textdatei in den Editor vi (gibt es auf jedem Unix−Recher). Versuchen Sie ein Wort
einzufügen oder eine Leerzeile. Viel Spaß! elm kann aber jeden beliebigen Editor
anbieten, die beiden anderen Programme können das vielleicht auch. Leider habe ich
noch nirgendwo eine Installation mit einem anderen Editor vorgefunden. Ob Anfänger
sich allerdings trauen, das Mailprogramm zuerst einmal umzukonfigurieren? Für die
Mutigen: Kommando: o (für Options). Im dann auftauchenden Menü bei "E)ditor" und
"V)isual Editor" den gewünschten Editor eintragen, pico −t zum Beispiel. Mit dem Befehl
">" speichern. Tippen Sie einfach "e" oder "v" und gehen Sie nicht mit dem Cursor in die
Zeilen!
mail
Das Programm mail hat den Editor ex, der noch mehr Spaß (?) und Frust bereitet als der
Editor vi. Er ist für Anfänger indiskutabel. Wer dennoch an diesen Editor gerät, kann
sich mit folgenden Befehlen helfen:
· ~? für Hilfe
· ~q zum Verlassen ohne Speichern/Senden
· . (soll heißen am Zeilenanfang Punkt und Enter) verläßt den Editor und versendet die
9
Mail!
Konkrete Empfehlung
Wer als Arbeitsplatz einen PC oder Macintosh hat, dem würde ich zu Eudora raten. Es
läuft auf dem PC unter Windows, aber das ist ja inzwischen schon Standard.
Auf Unix−Rechnern oder bei Telnet−Verbindungen ist pine wegen seines Editors pico zu
empfehlen. Wenn elm auf einen anderen Editor, z.B. pico, umgestellt wird, ist es
genauso zu empfehlen. Vielleicht hilft jemand beim Konfigurieren?
Kleine Tips
für die Anfänge mit E−Mail
1. Falls Sie noch keine Erfahrung mit E−Mail haben, beginnen Sie einfach damit sich
selbst eine E−Mail zu schicken. So können Sie alle Funktionen in Ruhe ausprobieren
und sehen sofort das Ergebnis.
2. Die Umlaute, ß und einige Sonderzeichen sollten Sie vermeiden. Es gibt Verfahren
diese Zeichen problemlos zu übertragen. Leider muß der Empfänger sich auch an dieses
Verfahren halten. Oft ist das aber nicht der Fall und dann wird "für" zu f}r, fr oder
anderen Verstümmelungen. Falls Ihre Partner die Umlaute richtig erhalten, kann man
sie natürlich auch benutzen.
Hinweise
auf Dokumentationen
Neben vielen Büchern gibt es auch einige Stellen im WWW, an denen Sie bestimmte
Informationen finden. An den Universitäten sind diese oft auf die spezielle Situation an
der jeweiligen Hochschule abgestimmt. An jeder Universität gibt es eine Reihe von
Hinweisen, die sich oft ergänzen.
Hier einige Beispiele aus Heidelberg:
http://www.urz.uni−heidelberg.de/anleitung:
Hier finden Sie einige Hinweise, unter anderem:
· Eine Anleitung für pine:
http://www.urz.uni−heidelberg.de/anleitung/pine.html
· Die Netiquette, also die Benimmregeln.
Sie sind ursprünglich für News geschrieben worden, treffen aber auch im wesentlichen
für E−Mail zu:
http://www.urz.uni−heidelberg.de/zentral/urz/netz/Netiquette.html
Weitere Informationen unter:
http://www.urz.uni−heidelberg.de/internet
10
· Häufig gestellte Fragen zu Electronic Mail:
gopher://gopher.urz.uni−heidelberg.de/00/zentral/urz/netz/mailfaq
· FAQ "How to find people’s E−Mail addresses":
http://www.boku.ac.at:1080/Ch.mail−adr
Hartmuth Heldt
Rechenzentrum Universität Heidelberg
[email protected]−heidelberg.de
Flieg, Pferdchen, flieg...
Der Mail Client Pegasus
Roland Hofmann
"Wir befinden uns im Jahre 50 v. Chr., ganz Gallien ist von den Römern besetzt...
Ganz Gallien? Nein! Ein von unbeugsamen Galliern bevölkertes Dorf hört nicht auf, dem
Eindringling Widerstand zu leisten. Und das Leben ist nicht leicht für die römischen
Le−gionäre, die als Besatzung in den befestigten Lagern Babaorum, Aquarium,
Laudanum und Kleinbonum liegen..."
In Abwandlung dieser bekannten Präambel soll in diesem Artikel ein vielseitig
verwendbarer Mail Client vorgestellt werden, der wohl ähnlich seinen gallischen
Vorfahren dank seines Zaubers den Großen der (Software−) Welt erfolgreichreich die
Stirn bietet.
Die Rede ist von Pegasus Mail des Neuseeländers David Harris. Er gehört der alten
Riege von (Internet−) Idealisten an, die sich für wenig Geld und vielleicht etwas mehr
Ehre dem Dienst an der Allgemeinheit verpflichtet fühlen. Pegasus ist ebenfalls ein
Paradebeispiel für internationale Zusammenarbeit: Das rege Betatester−Team verteilt
sich über den ganzen Globus, die weltweite Anwendergemeinde kann zu diesem und
zum Autor in direkten Kontakt treten, was sich durchweg positiv auf die Qualität des
Programms auswirkt: Keine überladenen Feature Lists, aber viele kleine Schönheiten
machen es trotz einiger Schwächen zu einem kleinen Juwel.
Pegasus ist für die Plattformen DOS, Windows−16bit und Macintosh verfügbar, eine
Windows−32bit−Version ist in Vorbereitung. In diesem Artikel wird vorwiegend auf die
Windows−16bit−Version (WinPMail), die neben der DOS am weites−ten entwickelte,
Bezug genommen. Einige der Möglichkeiten sind auf den anderen Plattformen nur
eingeschränkt bzw. überhaupt nicht gegeben. Als Transportsysteme werden Novells
NetWare (bindery−basierend), MHS sowie SMTP/POP3 unterstützt. Eine NDS−fähige
Version (NetWare 4.x) ist im Betatest.
Einem geschenkten Gaul
schaut man wohl ins Maul...
Welche Möglichkeiten bietet Pegasus? Die folgende Aufzählung beschreibt die unseres
11
Erachtens wichtigsten Funktionen und erhebt keinen Anspruch auf Objektivität oder
Vollständigkeit:
· Übersichtliche und einfach zu
bedienende Oberfläche (mehrsprachig):
Nach unserer Erfahrung kommen auch Windows−Neulinge sofort mit den wichtigsten
Funktionen zurecht. Dinge wie ENCODING/DECODING, MIME usw. werden
normalerweise vollständig von Pegasus kontrolliert und erfordern keinerlei
Benutzereingriff. Gleichwohl kann der erfahrenere Anwender durchaus viele
Einstellungen seinen Wünschen gemäß anpassen. Pegasus ist mit vielen Sprachmodulen
erhältlich. Die Sprach−auswahl kann über DOS Environment−Variablen oder
Kommandozeilenparameter ge−steuert werden. Zumindest bei der deutschen
Übersetzung hat ein bundesweites Betatest−Team (meine Wenigkeit war ebenfalls
beteiligt) die Güte geprüft und durch Vorschläge verbessert. Der Philosophie des
Entwicklers folgend beruht die Internationalisierung ebenfalls auf der Arbeit einiger
engagierter Mitarbeiter, die mit dem Autor in enger Kooperation die Lokalisierung
vornehmen.
· Hierarchisches,
funktionelles Ordnerkonzept:
Pegasus kann Ordner (Folder) bzw. Schubladen (Trays) in beliebiger Tiefe benutzen.
Drag & Drop zwischen Ordnern wird unterstützt, ebenso eine einfache Umsortierung
durch Klicken auf die Ordnerspaltenleiste. Pflegefunktionen (Komprimierung,
Reindizierung, Konsistenzprüfung) laufen automatisch ab bzw. sind durch Auswahl in
der Menüleiste leicht durchführbar.
· Definition von Filterregeln:
Sowohl neue Mail als auch Copy−to−Self Mails können nach verschiedenen Kriterien
gefiltert werden und damit mehrere Aktionen auslösen (Löschen, Verschieben, Drucken,
externer Programmaufruf, Mail senden und noch viele weitere). Filterregeln lassen sich
ebenfalls nachträglich auf ganze Ordner anwenden und unterstützen so die
Neuorganisation der Ab−lage. Die Definition der Regeln erfolgt per Mausklick,
notwendige Angaben werden in Eingabefeldern abgefragt.
· MIME−fähig, Automatisierung
der Attachment−Behandlung:
Wie bereits erwähnt, bietet Pegasus eine sehr benutzerfreundliche Handhabung von
Attachments und Multipurpose Internet Mail Extensions. Neben
UUENCODE/DECODE wird BIN−HEX 4.0, Basic MIME und diverse weitere
MIME−Standards angeboten. Die Dekodierung empfangener Mail startet beim Öffnen
automatisch bzw. es kann entschieden werden, welche Aktion erfolgen soll. Dies kann
soweit getrieben werden, daß z.B. ein WordPerfect−Dokument als Attachment oder
MIME Mail automatisch den Aufruf der Applikation mit dem Laden des decodierten
Textes herbeiführt. Sicher sollte hier mit Bedacht vorgegangen werden −
Virusinfektionen über Word−Dokumente oder gar durch den Start von ausführbaren
Binaries könnten sonst die Folge sein.
· Schnittstelle für Erweiterungen:
12
Seit Version 2.1 von WinPMail wird ebenfalls eine Schnittstelle für eigene
Erweiterungen zur Verfügung gestellt, die über 80 Pegasus−spezifische Aufrufe enthält.
Dadurch sind be−liebige Erweiterungen in der Funktionalität er−möglicht. Die
Serienbrief−Funktion ist damit vom Autor selbst realisiert worden, weiterhin gibt es ein
Open Encryptor Interface for PGP von John Navas, das zwar, bedingt durch die
Funktionsweise der Pegasus−Schnittstelle, noch einige Security−Probleme aufweist,
aber das Prinzip und die Flexibilität dieses Mechanismus aufzeigt.
· Ausführliche und verständliche
Online−Hilfe:
Der Mail−Einsteiger wird wohl schnell an der kontextsensitiven Online−Hilfe Gefallen
finden. Neben einer detaillierten Beschreibung zu wichtigen Vorgehensweisen finden
sich ausführliche und gut verständliche Hintergrundinformationen rund um das Thema
E−Mail. Hier wurde bei der Übersetzung mit be−sonderer Sorgfalt gearbeitet und einige
Er−gänzungen und Verbesserungen gegenüber dem englischen Original eingefügt.
· Adreßbücher, Verteilerlisten, Glossar, Rechtschreibprüfung:
Nichts außergewöhnliches für einen Mail Client, wären da nicht die eingangs erwähnten
kleinen Schönheiten. So genügen z.B. einige Mausklicks oder eine Filterregel, um den
Ab−sender einer Mail einer Verteilerliste hinzuzufügen. Praktisch: Ein Doppelklick auf
einen Adreßbucheintrag/Verteilerliste erzeugt ein leeres, fertig adressiertes
Mail−Fenster (na ja, das können andere sicher auch). Oft verwendete Begriffe oder
Floskeln können als Abkürzungen definiert werden und stehen nach Tastendruck
(STRG+W) als expandierter Text im Editorfenster (mfg mutiert zu Mit freundlichen
Grüßen). Die enthaltene Rechtschreibprüfung ist nur in englischer Sprache, aber wer
braucht das bei Mail schon...
· Notizbrett−Funktionen:
In LAN−Umgebungen lassen sich Pegasus−spezifische, öffentliche Notice Boards
einrichten, die News−ähnliche Funktionalität im LAN gewähren − für LAN−basierende
Arbeitsgruppen ein nettes Merkmal.
Einsatzgebiete
NetWare
NetWare Server stellen die historische Plattform für Pegasus Mail dar. David Harris
entwickelte damit eines der ersten Mail−Programme, die in der Lage waren, die
Bindery−Information (NetWare−Verwaltungsdatenbank) für ihre Zwecke direkt zu
verwenden. Der verwendete File Sharing−Mechanismus auf dem Server ist in den Net−
Ware−Versionen 3.x vorbereitet, da jeder Be−nutzer ein Mail−Verzeichnis
(SYS:MAIL\<ID−#>) mit Referenzierung in eben dieser Bindery be−sitzt. Damit
erfreute sich Pegasus zuerst bei den Novell−Administratoren einer ungemeinen
Be−liebtheit, fielen doch alle mühseligen Konfigurationspielchen a’ la CC:mail und
MS−Mail zuerst einmal weg. Darüber hinaus ist das Verhalten durch
NetWare−GROUP−Zuweisungen einfach steuerbar. Mit der Freigabe der
NetWare−Version 4.x wurde die serverorientierte Bindery durch die NetWare Directory
Services (NDS), ei−ne im Netz verteilte, hierarchische Verwaltungsdatenbank, abgelöst.
13
Auch in dieser Umgebung bleibt David Harris dem Prinzip der leichten
Ad−ministierbarkeit treu und entwicklt mit der NDS−fähigen Variante ein sehr gut
eingepaßtes Mail−Programm. Sämtliche wichtigen Parameter werden ebenfalls in der
NDS abgelegt und sind da−her leicht zu verwalten.
Durch Virtualisierung der Pegasus−Funktionen gelang es die Schnittstelle zum
jeweiligen LAN flexibel zu gestalten. Die als NICA (Network In−dependant Calls
Architecture) getauften DLLs sind inzwischen für NetWare 3.x (Bindery) und demnächst
für 4.x (NDS) verfügbar. Weitere sind in Planung bzw. in Entwicklung. Nicht unerwähnt
bleiben darf in diesem Kontext ein weiteres Produkt aus gleichem Hause, das im
Zu−sammenspiel mit Pegasus NetWare−Umgebungen den Anschluß an die
IP−Mail−Welt sichert: Gemeint ist Mercury, ein SMTP/POP3 Gateway, welches als
NLM (NetWare Loadable Modul) zentral auf einem NetWare Server abläuft und Mail
aus dem LAN an einen Smart Mailer (Mail Relay) weitergibt bzw. diese von einem
beliebigen Host empfängt. Mercury kann, wie Pegasus, direkt auf die Bindery bzw. NDS
zugreifen und erfordert daher nur geringen Pflegeaufwand. Voraussetzung ist ein
TCP/IP Stack auf dem NetWare Server (Software im Lieferumfang enthalten) und ein
Relay Host für die Mail−Weiterleitung. Letztere Einschränkung ist in erster Linie nicht
durch Mercury, sondern durch den i.d. R. fehlenden DNS−Mechanismus bei
NetWare−IP gegeben. Mercury entspricht dem RFC 1425 und bietet daher ESMTP
Support (s.a. Technische Details, S. 13).
Standalone
Für zahlreiche BelWü−Anwender dürfte ein weiteres Einsatzgebiet bedeutender sein.
Pegasus läßt sich im Standalone−Modus betreiben und nutzt dann die bekannten
TCP/IP−Protokolle POP3 (Post Office Protocol) und SMTP (Simple Mail Transfer
Protocol) zum Mail−Austausch.
Folgende Voraussetzungen müssen erfüllt sein:
· TCP/IP−Transportschnittstelle:
Die von WinPMail unterstützte Schnittstelle sind die sogenannte Windows Sockets oder
kurz WinSock. In diesem Fall benötigen Sie eine Laufzeitbibliothek namens WINSOCK.
DLL auf Ihrem System. Produkte der Firma FTP oder Shareware (z.B. Trumpet
Winsock) bieten beispielsweise diese Funktionalität an.
· Ein per SMTP/POP3
ansprechbarer Mail Host:
Die POP3−Dienste erlauben Ihnen, sich neue Post von einem Server abzuholen
(üblicherweise von einem Unix/NetWare Server). Via SMTP können Sie Nachrichten in
das Internet (oder in ein Novell−Netz mit SMTP Gateway) verschicken. WinPMail
verwendet dazu ei−nen Relais Service − es übergibt die Nachrichten zum Versand an
einen Server, der über eine vollständige SMTP−Implementierung verfügt.
Alle weiteren Einstellungen sind wahlfrei und dienen nur der Anpassung an die
persönlichen Bedürfnisse des jeweiligen Benutzers.
Einige Bonbons sind nachfolgend aufgeführt:
14
· Option Nur ungelesene Mail abholen:
Sie können diese Option verwenden, um neue Nachrichten von außen über POP3 zu
lesen, sie aber gleichzeitig auf dem Server zu belassen. Pegasus Mail verwaltet die
zuletzt abgeholten Nachrichten in Ihrem Mail−Verzeichnis in der Datei MEMORY. PM;
die dort eingetragenen Daten werden mit den am Server anliegenden Nachrichten
verglichen und anschließend werden nur die Nachrichten abgeholt, die noch nicht in
dieser Datei vermerkt sind. Sie können durch Aktivierung dieser Option Ihre neuen
Nachrichten jederzeit von außerhalb über POP3 lesen und trotzdem noch am Server
angezeigt bekommen, um Sie anschließend dort in Ihre Ordner einzusortieren. Wenn der
Server ein NetWare Server mit SMTP Gateway Mercury ist, werden diese neuen
Nachrichten im Netz ein Häkch−en tragen, um zu zeigen, daß sie bereits über POP3
gelesen wurden.
· Offline−Modus:
Wenn Sie den Offline−Modus aktivieren, wird Pegasus Mail alle
POP3/SMTP−Verbindungen abbrechen und keine weiteren Verbindungen mehr öffnen.
Während Sie sich im Offline−Modus befinden, können Sie beliebig viele Nachrichten
editieren und in die Warteschlange einreihen − die einzigen jetzt deaktivierten
Funktionen sind die eigentlichen Ver−bindungen zu den Servern. Der Offline−Mo−dus
ist dann sinnvoll, wenn Sie keine Netzwerkverbindung haben (z.B. während Sie
un−terwegs sind), aber trotzdem mit Ihrer Mail ar−beiten wollen. Wenn Sie dann den
Offline−Mo−dus verlassen, wird die normale Netzwerkaktivität wieder aufgenommen.
Sie können Pegasus Mail zwingen, immer im Offline−Modus zu starten, indem Sie den
Befehlszeilenparameter −O (ein "oh", keine Null) als Befehlszeilenparameter eintragen.
Standalone mit verschiedenen Benutzern
Kurz sei noch darauf hingewiesen, daß WinP− Mail auf einem PC nicht nur für einen,
sondern für beliebig viele verschiedene Benutzer konfiguriert werden kann. Teilen sich
also mehrere Anwender einen Rechner, können sie trotzdem Ihre Mails in völlig
getrennten Verzeichnissen ablegen und natürlich unterschiedliche Einstellungen
vornehmen. Schutz vor der Neugierde anderer Mitmenschen ist in so einer Umgebung
nicht gegeben − das DOS−Filesystem öffnet hier Tür und Tor für eigentlich jedermann.
Nimmt mensch diese Einschränkung aber bewußt in Kauf, erschließen sich doch
sinnvolle Möglichkeiten für Einrichtungen, die nicht mit üppiger
Hardware−Ausstattung gesegnet sind. Findige Leser werden an dieser Stelle bemerken,
daß diese Konfiguration die Anpassung an LANs wie Windows NT oder
Peer−to−Peer−Netze ermöglicht, solange dafür noch kein NICA−Modul existiert: Die
Verlegung des Mail−Verzeichnisses in das eines nur dem entsprechenden Benutzer
zugänglichen auf einem Server bietet wiederum den erforderlichen Zugriffsschutz, der
auf DOS−Ebene fehlt.
Landung
Diese gestaltet sich nach unseren Erfahrungen recht sanft. Im Novell−Umfeld wird
mensch wohl kein einfacher zu administrierenderes Produkt finden, vor allem unter der
Prämisse, daß Mail das sein soll, was es bisher immer gewesen ist: Ein einfaches
Hilfsmittel, um schnell und unkonventionell zu kommunizieren. Natürlich hat Pe−gasus
15
auch Schwachpunkte: Es verfügt über keine der vielgelobten Mechanismen wie OLE,
unterstützt bisher kein MAPI und die Editorfunktionen sind etwas simpel. Mehrmals
wurde einiges davon an David Harris herangetragen, aber auch da bleibt er was er
hoffentlich noch länger ist − unabhängig und idealistisch, ein richtiger unbeugsamer
Gallier...
Technische Details
WinPMail Version 2.23 vom 22.11.95
Extension Manager Version 1.02,
Deutsches Sprachmodul von Henning Stams, 02.12.95
Alle Implementationen erfordern mindestens:
· 286 PC, 386 PC empfohlen (s.u.)
· Microsoft Windows 3.1
· 4MB RAM empfohlen
(WinPMail benötigt normalerweise ca. 700K).
· VGA (640x480) 16−color Grafikkarte, Mono−VGA/EGA/Hercules werden nicht
unterstützt
Für Benutzung
unter Novell NetWare:
· Alle Versionen von NetWare höher als 2.12 NetWare Client−Version höher als 3.26
· NetWare Windows−Unterstützung
properly installed :−)
Empfehlung aus der Praxis:
· Windows 3.1
Enhanced Mode (386−Modus)
· VLM Requester 1.20 für DOS
NETWARE. DRV 3.03 für Windows
· NICA Module−Version 1.02, 14.06.95 (deutsch)
Für Benutzung
mit Windows Sockets−Implementationen:
· TCP/IP stack
16
properly installed :−)
· WINSOCK.DLL
entsprechend Spezifikation WinSock v1.1
Empfehlung aus der Praxis:
· Windows 3.1
Enhanced Mode (386−Modus)
· Getestete WinSock−Implementationen:
− Novell LAN Workplace, Trumpet,
Microsoft (3.1/95), OS/2 Warp 3.0,
FTP (ab PC/TCP 3.1)
Bei Pegasus verwendete RFCs:
· RFC822: Message Format
· RFC1522: Header Encoding
· RFC1725: Newest POP3 Revision
with UIDL Command
SMTP Gateway Mercury Version 1.21
vom 09.02.95
Erfordert mindestens:
· NetWare 3.11
mit NetWare TCP/IP Transport
· ca. 70KB RAM im Server
bei durchschnittlichem Betrieb
· 2 BSD Sockets
· Should not significantly slow
the Performance of the Server
· unter NetWare 4.x:
Bindery Emulation Mode
· Bei Mercury verwendete RFCs:
· RFC821:
17
"received" Headers for Loop Detection
· RFC822: Message Format
· RFC1425: EHLO Command
· RFC1426: 8BITMIME Keyword
· RFC1427: SMTP SIZE Extension
· RFC1725:
newest POP3 Revision with UIDL Command
Quellen
· BelWü
ftp.rz.uni−hohenheim.de in
/ftp/pub/novell/pegasus bzw. mercury
· Offizielle Pegasus Sides
− North America:
risc.ua.edu in /pub/network/pegasus
− Europe:
ftp.let.rug.nl in /pub/pmail
Informationen
· [email protected]
· Phone (+64) 3 453 6880
but PLEASE remember
New Zealand is GMT+1200...
· Fax (+64) 3 453 6612
· Pegasus Mail
c/o David Harris
P.O. Box 5451
Dunedin
New Zealand
· Mailing Lists
(behandeln auch Mercury−Themen):
18
− [email protected]
SUBSCRIBE PMAIL
firstname lastname
− [email protected]
SUBSCRIBE PM−NEWS
firstname lastname
− [email protected]−mannheim.de
SUBSCRIBE PMAIL−DE
(deutschsprachig)
· News (mirror der PMAIL−DE)
de.comm.software.pmail
Roland Hofmann
Rechenzentrum Universität Hohenheim
hofmann@uni−hohenheim.de
MIME
Multipurpose Internet Mail Extension
Edith Petermann
Die Motivation
Internet Mail, definiert im RFC822 (SMTP), er−laubt nur US−ASCII−Text als Mail
Body. Wünschenswert ist, daß auch andere Arten der Da−ten mit dem vorhandenen
Mailprogramm versendet und empfangen werden können.
Zum Beispiel:
· Texte mit Umlauten oder strukturierte Texte (EDI−Dokumente)
· Binaries, Bilder, Grafiken, Audio, Video
· Zusammengesetzte Dokumente mit unterschiedlichen Elementen.
Außerdem wäre es schön, wenn zukünftige Entwicklungen, ohne daß dafür wiederum
neue Standards entwickelt werden müßten, ebenfalls eingebunden werden könnten. Der
OSI Mail−Standard X.400 sieht solche multimedialen In−halte von Anfang an vor und
sie sind teilweise auch schon in den Implementierungen realisiert. Dadurch entstehen
natürlich Probleme beim Übergang zur Internet−Mail; denn solange hier keine adäquate
Entsprechung existiert, kann auch in den Gateways die jeweilige Umsetzung nicht
durchgeführt werden.
Das Resultat dieser Anforderungen ist der MIME−Standard (RFC 1521), der kompatibel
19
zu RFC 822 ist. Die Erweiterungen betreffen lediglich den Mail Body:
· Es sind mehrere Teile unterschiedlichen Typs möglich
· es gibt keine Längenbeschränkung bei
Zeilen/Gesamt−Mail und
· der Zeichensatz ist nicht mehr auf US−ASCII beschränkt.
MIME erlaubt eine große Anzahl unterschiedlicher Datentypen. Alle registrierten
Datentypen sind auf einem ftp−Server niedergelegt (siehe S. 10 Weitere Informationen
zu MIME).
Nachfolgend eine kleine Auswahl der gebräuchlichsten Typen mit Angabe von möglichen
Untertypen in Klammern:
· Text mit verschiedenen Character Sets (plain, richtext)
· multipart: Der Body ist aus mehreren Teilen zusammengesetzt (mixed, alternative,
digest, parallel, appledouble, header−set)
· message: Der Body enthält wiederum eine vollständige Mail (rfc822, partial, external,
news)
· audio: Für Sprache, Musik und Geräusche (basic)
· video: Bewegte Bilder (mpeg, quicktime)
· application: Zeigt an, daß der Inhalt erst von einem Programm bearbeitet werden muß,
be−vor der Empfänger es ansehen oder weiterverarbeiten kann. Hier gibt es die meisten
Sub−types (octet−stream, postscript, oda, msword, wordperfect 5.1 usw.)
· experimental: Ist vorgesehen für private
Typdefinitionen; die Typangabe beginnt mit
X− und ist auch für Subtypes und eventuelle
Parameter möglich. Inzwischen gibt es schon
eine stattliche Anzahl solcher privater Typen.
Aus diesem vielfältigen Angebot von Datentypen folgen Erweiterungen im Mail Header,
die angeben, was jeweils im Mail Body enthalten ist.
Zusätzlich zu den bekannten RFC822 Header−Feldern kommen hinzu:
· Der MIME Versions−Header
· Der Content Type Header, der den Typ und eventuell Subtyp des Mail Bodies angibt
20
· Der Content Transfer Encoding Header, der die Kodierungsart angibt, die verwendet
wurde, um die Kompatibilität zu RFC822 zu gewährleisten. Denn Binärdaten oder
8−bit−Character oder Sätze länger als 1000 Zeichen werden für den Transport
automatisch umkodiert mit z.B. base64 oder quoted printable
· Der Content ID Header, der eine Bezugnahme zwischen verschiedenen Bodies
ermöglicht
· Der Content Description Header, der eine Be−schreibung des Inhalts enthält, analog
dem bekannten Subject Header.
Bei dieser großen Anzahl von Datentypen war es notwendig, ähnlich wie man auch beim
OSI−Standard X.400 vorgegangen ist, ein Minimal−Set zu definieren, das User Agents
erfüllen müssen, um als MIME−konform zu gelten.
Die MIME−Datentypen finden nicht nur Anwendung bei E−Mail, sondern haben sich
ebenso nützlich erwiesen für Gopher, WWW und News Reader.
Um die Datentypen auf dem Rechner darstellen zu können, müssen natürlich
systemspezifische Angaben gemacht werden, welches Tool/Programm die Darstellung
durchführt. Das kann entweder im Client integriert sein oder über eine spezielle Datei
"mailcap" organisiert werden. Die mailcap enthält Informationen, welche Viewer,
Audiotools oder Text− und Dokumentverarbeitungsprogramme bei den jeweiligen
Datentypen aufgerufen werden sollen. Die mailcap hat sich als Quasi−Standard
etabliert und weite Verbreitung gefunden.
Eine mailcap als Beispiel:
audio/*; audiotool %s image/*; imagetool %s application/postscript; ghostview %s
Die Einträge besagen, daß alles vom Typ audio vom audiotool bearbeitet werden soll
(das in diesem Fall in der Lage ist, alle Subtypes abhandeln zu können), entsprechendes
gilt beim Datentyp image. Der Datentyp application und dann speziell der Subtyp
postscript kann vom Programm ghostview dargestellt werden. Im Normalfall wird eine
mailcap natürlich mehr Informationen als in diesem Beispiel beinhalten, je nach
Kapazität und Software des jeweiligen Rechners.
Weitere Informationen
zu MIME
· Vollständige Beschreibung des Standards im RFC1521:
ftp://ftp.nic.de/pub/doc/rfc (Karlsruhe)
http://www.cis.ohio−state.edu/hypertext/information/rfc.html
· Aufzählung aller registrierten Datentypen:
ftp://ftp.isi.edu/in−notes/iana/assignments/media−types/media−types
· News−Gruppe: comp.mail.mime
21
· FAQs: Regelmäßig in der angegebenen News−Gruppe oder:
http://www.cs.ruu.nl/wais/html/na−dir/mail/mime−faq/.html
ftp://ftp.uu.net/usenet/news.answers/mail/mime−faq
· MIME−Produkte werden umfassend in den FAQs Part2 angegeben. Ebenso
Literaturhinweise in FAQs Part1.
Ausblick
Im Forschungs− und Wissenschaftsbereich ist MIME schon relativ weit verbreitet,
allerdings noch längst nicht in dem Ausmaß, in dem es wünschenswert wäre.
Kommerzielle Anwender bevorzugen X.400.
Es gibt einige Internet Drafts zum Problem MIME und Security, die zum Datentyp
Application Subtypes vorschlagen, so daß PGP und PEM erkannt und entsprechend
bearbeitet werden kann.
Edith Petermann
Rechenzentrum Universität Mannheim
[email protected]−mannheim.de
Sicherheit bei Kommunikations−
Anwendungen, insbesondere bei E−Mail
Edith Petermann
Kontext und Allgemeines
Bei der Mail−Anwendung im Internet (SMTP/RfC822) gibt es einige bekannte Lücken
bezüglich der Anforderungen an die Sicherheit. Es ist relativ einfach, Absender und
Inhalt einer Mail zu fälschen, denn die Mail ist während des Transportes über Netz und
Relays kaum geschützt vor neugierigen Blicken. Das gilt nicht nur für Mail, sondern für
alle Kommunikationsanwendungen über das Internet. Beispiele für die offensichtliche
Notwendigkeit von mehr Sicherheit sind:
· Elektronische Zahlungsvorgänge und elektronisches Shopping
· Austausch von Dokumenten in Verwaltung und Kommerz
· Austausch von Forschungsunterlagen
· Vertraulicher Informationsaustausch
· Sicherung von Datenbeständen vor Veränderung und fremder Einsichtnahme
22
· Und last not least ein generelles Bedürfnis nach Schutz der persönlichen Sphäre bei
der elektronischen Kommunikation.
Daraus ergeben sich folgende Anforderungen an die Sicherheit bei Anwendungen zum
Datenaustausch, insbesondere bei E−Mail:
− Der Absender muß authentisch sein, d.h. es muß Sicherheit geben, daß der Absender
nicht gefälscht ist
− Der Mail−Inhalt muß unverfälscht übertragen werden
− Die Mail darf nur von Befugten lesbar sein (Vertraulichkeit)
− Der Absender kann von ihm versendete Mail weder vom Inhalt her verleugnen noch
seine Urheberschaft (Unleugbarkeit des Ursprungs).
Eine Lösung dieses Problemfeldes bieten asymmetrische
Verschlüsselungsmechanismen. Die besten Verfahren sind so mächtig, daß es mit den
zur Zeit verfügbaren Rechnerkapazitäten Jahrzehnte dauern würde, solche
verschlüsselten Daten zu entziffern. Man sollte allerdings immer im Kopf behalten:
Neue Entwicklungen im Rechnerbereich oder die Entdeckung effizienter Algorithmen
zum Knacken von Verschlüsselungen, könnten schlagartig heute sichere Verfahren
wirkungslos werden lassen. Andererseits, sichere Verschlüsselungen schützen nicht nur
den Bürger mit seinem legalen Bedürfnis nach Privatsphäre sondern auch Kriminelle
oder Verfassungsfeinde bei illegalen Machenschaften. In manchen Ländern ist deshalb
Verschlüsseln ge−nerell verboten (z.B. Frankreich), andere Länder versuchen, ihren
entsprechenden Instanzen Zu−gang zu den Schlüsseln zu gewähren, vielleicht unter
vergleichbaren Bedingungen wie bei ei−nem Durchsuchungsbefehl. In der BRD ist bis
jetzt noch kein einschlägiger Beschluß gefaßt worden, allerdings wird darüber
diskutiert.
Verschlüsselungen
Verschlüsselungen sind Transformationen von Texten (allgemeinen Daten) in eine
Form, die ohne die entsprechende Rücktransformation nicht lesbar (verarbeitbar) ist. Im
Spionagebereich gibt es dafür schon eine lange Tradition. Mit der fortschreitenden
Durchdringung von DV in allen Be−reichen (Forschung, Wirtschaft, Verwaltung,
Privatbereich s.o.) ergibt sich der Bedarf für Verschlüsselungsmöglichkeiten auch hier.
Im wesentlichen gibt es zwei Arten:
1. Die konventionelle bzw. symmetrische Verschlüsselung (Secret Key). Es wird ein
einziger Schlüssel zum Ver− und Entschlüsseln verwendet. Das heißt, mindestens zwei
Leute kennen diesen Schlüs−sel. Zum Verschlüsseln werden zwei Komponenten
eingesetzt, der eigentliche Schlüssel (eine geheime Zeichenfolge) und der Algorithmus
der i.a. bekannt ist und aus Substitutionen und Permutationen besteht. Bekannte
Verfahren sind DES (Data Encryption Standard), IDEA (International Data Encryption
Algorithm) und SKIPJACK, dieser Algorithmus ist geheim, verwendet wird er im
Clipper−Chip. Diese Verfahren gelten als sicher.
23
2. Die asymmetrische Verschlüsselung (Public Key). Hier wird ein Schlüsselpaar
(privater und öffentlicher Schlüssel) eingesetzt. 1976 gab es das erste Verfahren dieser
Art von Diffie und Hellmann. Der öffentlicher Schlüssel wird bekanntgegeben und zum
Verschlüsseln verwendet, der private bleibt nur dem Eigentümer bekannt, und dient
dem Entschlüsseln. Der Algorithmus ist wieder i.a. bekannt.
RSA ist wohl der bekannteste Algorithmus; er wurde 1977 von Rivest, Shamir und
Adleman vom MIT entwickelt, das auch das Patent dafür hält. Seine Schlüssellänge ist
unterschiedlich wählbar. Der Algorithmus erlaubt Verschlüsselungen sowohl mit dem
Private, wie auch dem Public Key. Mit dieser Eigenschaft können Da−ten nicht nur
verschlüsselt werden, also vor un−befugter Einsicht geschützt werden, sondern es ist
auch möglich, digitale Unterschriften zu er−zeugen und die Anforderungen nach
Authentizität und Unleugbarkeit des Ursprungs, und die Unveränderbarkeit der Daten
zu erfüllen. Einzelheiten dazu bei der Beschreibung von PGP und PEM weiter unten.
Zur Sicherheit diese Verfahrens: Zwar läßt sich theoretisch der private aus dem public
Schlüssel ermitteln, entweder durch Ausprobieren aller möglichen Schlüssel oder durch
Faktorisierungsverfahren um die Komponenten, mit denen sich der private Schlüssel
berechnen ließe, zu ermitteln. Beide Ansätze sind bei den bis jetzt vorhandenen
Rechnerkapazitäten so zeitaufwendig, daß man sagen kann, praktisch sind die
Verfahren sicher. Allerdings: Vor etwa einem Jahr wurde ein Schlüssel mit 512 bit mit
1600 Rechnern in−nerhalb von acht Monaten geknackt. Als sicher gilt zur Zeit eine
Schlüssellänge mit 1024 bit (ca. 300 Dezimalstellen). Wo liegen nun die wesentlichen
Unterschiede zwischen symmetrischen und asymmetrischen Verschlüsselungen?
· Der Vorteile beim symmetrischen Schlüssel:
− Schnellere Verschlüsselungsvorgänge.
· Die Vorteile beim asymmetrischen Schlüssel:
− Er ermöglicht digitale Unterschriften
− Durch die digitale Unterschrift ist die An−forderung nach Unleugbarkeit von
Do−kumenten erfüllbar
− Der Austausch des öffentlichen Schlüssels ist etwas sicherer (allerdings nur, solange
der Kreis der Kommunikationspartner begrenzt ist).
Bei PGP und PEM werden deshalb beide Verfahren kombiniert, um optimale
Verschlüsselungsvorgänge zu erhalten.
PGP −
Pretty Good Privacy
PGP ist ein Programm, das Sicherheit in erster Linie für E−Mail bietet, aber auch für
weitere An−wendungen. PGP wurde von Phil Zimmermann entwickelt (erstes Release
24
1991), verwendet die zur Zeit als beste Verschlüsselungsalgorithmen beurteilten
Verfahren RSA und IDEA, bietet eine einfache Nutzerschnittstelle auf fast allen
Rechnerplattformen und hat inzwischen eine beachtlich wachsende Verbreitung im
Internet. Es ist sowohl als Public Domain−Programm für die private Nutzung, als auch
als kommerzielle Version erhältlich.
Die Entwicklungsgeschichte von PGP ist sehr bewegt. So gab es Lizenzprobleme und bei
der Verbreitung im Internet ist gegen herrschende Ausfuhrbeschränkungen für
Verschlüsselungsverfahren, die in den USA unter die Waffengesetze fallen, verstoßen
worden.
Der aktuelle Stand ist:
· PGP Version 2.6 ist legal in den USA und Kanada, darf aber nicht exportiert werden
· PGP Version 2.6.ui entspricht der Version 2.6 und ist außerhalb der USA und Kanada
legal. Beide Versionen sind nicht kompatibel zu Vorgängerversionen
· PGP Version 2.6.i verstößt gegen Lizenzgesetze innerhalb der USA, aber es ist
kompatibel zu Vorgängerversionen.
P
>PEM −
Privacy Enhancement
for Internet Electronic Mail
Dabei handelt es sich im Gegensatz zu PGP nicht um ein Programm, sondern einen
Internet−Standard, beschrieben in den RFCs 1421, 1422, 1423 und 1424. Programme
nach diesem Standard sind bisher im wesentlichen nur in Projekten, z.B. SecuDE bei
GMD Darmstadt im Auftrag von DFN, realisiert worden. DES und RSA werden als
Verschlüsselungsalgorithmen eingesetzt. Sie sind längst nicht so verbreitet wie PGP.
Ein Grund dafür ist die Art der Schlüsselvergabe und −verwaltung, die Bestandteil des
Standards ist. Dazu müssen Zertifizierungsinstanzen aufgebaut werden, denen dann
vertraut wird. SecuDE hat sich auch dieser Problematik angenommen.
Gemeinsamkeiten
von PGP und PEM
1. PGP und PEM betreffen bei der Anwendung durch E−Mail nur die Nutzerschnittstelle
und sind kompatibel zu den be−stehenden Mailsystemen.
2. Die Verschlüsselung von E−Mail, die die Vertraulichkeit sichert, läuft im Prinzip
gleich ab: Zuerst wird ein Session Key er−zeugt und damit per IDEA oder DES der Text
verschlüsselt. Dieser Session Key wird dann mit dem Public Key des Empfängers
verschlüsselt und zusammen mit dem verschlüsselten Text versendet. Dadurch wird die
schnellere symmetrische mit der sicheren asymmetrischen Verschlüsselung kombiniert.
25
Der Partner entschlüsselt zuerst mit seinem Private Key den Session Key und dann
damit den Text.
3. Die digitale Unterschrift (Signatur) erfolgt in drei Schritten:
− Aus dem Text wird ein Digest−Wert er−zeugt, der eindeutig ist. Sollte der Text
verändert werden, hat das einen anderen Digest−Wert zur Folge
− Dieser Digest wird mit dem Private Key des Senders verschlüsselt
− Das Ergebnis wird unten an den Text ge−fügt und bildet die digitale Unterschrift. Sie
ist eindeutig, weil nur dem Sender der Pivate Key bekannt ist, und da der Digest−Wert
eindeutig ist, ist der Text auch vor unbemerkten Veränderungen geschützt.
Beim Verifizieren der Signatur sind wieder drei Schritte erforderlich:
1. Wieder wird der Digest aus dem Text erzeugt
2. Die digitale Unterschrift wird mit dem Public Key des Senders entschlüsselt
3. Das Ergebnis wird mit dem erzeugten Digest verglichen.
Die Verfahren können nun noch kombiniert werden. Das heißt sowohl PGP als auch
PEM erfüllen die anfänglich aufgestellten Anforderungen an sichere E−Mail. PGP ist in
der Kombination der einzelnen Schritte etwas variabler als PEM, hat die
Schlüsselverwaltung in das Programm integriert. NutzerInnen erzeugen ihre
Schlüsselpaare selbst und verwalten sie in Dateien.
Sie haben die Auswahl zwischen verschiedenen Schlüssellängen, gebräuchlich und
ausreichend ist zur Zeit 1024 bit, aber auch 2048 ist möglich.
Die Schlüssel werden in Dateien gespeichert:
· Der secring enthält private(n) Schlüssel, die ihrerseits wieder durch symmetrische
Verschlüsselung geschützt sind
· Der pubring enthält dann die Sammlung der öffentlichen Schlüssel von
KommunikationspartnerInnen. Mit weiteren Kommando−Parametern kann man die
Schlüssel ansehen, neue hinzufügen, vorhandene herauskopieren, sie löschen und
editieren.
Sehr wichtig beim Hinzufügen eines neuen Schlüssels ist, daß der Schlüssel mittels der
digitalen Unterschrift zertifiziert werden kann. Damit versichert man, daß dies wirklich
der Schlüssel des angegebenen Nutzers ist. Hier ist also ganz be−sondere Sorgfalt
notwendig! Darüber hinaus gibt man unmittelbar nach Schritt A an, wie weit man
selber den Schlüsselzertifizierungen des jeweiligen Partners vertraut. Dabei sind vier
Stufen möglich: Von null bis zu absolutem Vertrauen. Mittels dieser
Zertifizierungsverfahren entsteht das sogenannte Web of Trust, das auf persönlichem
26
Vertrauen beruht, im Gegensatz zum Ansatz bei PEM, der Vertrauen in Instanzen
voraussetzt.
Weitere Informationen
· News−Gruppen:
alt.security.pgp, alt.security, alt.privacy, comp.security.misc, info.pem−dev,
alt.security.ripem
· FAQs:
In Abständen in der News−Gruppe
alt.security.pgp
· User Guide:
von Phil Zimmermann, ist beim Programmpaket PGP dabei
· Buch:
Simson Garfinkel, PGP, O’Reilly & Associates, Inc.
· ftp−Server, die das Programm PGP bereitstellen (in Deutschland):
ftp://ftp.informatik.tu−muenchen.de/pub/comp/os/os2/crypt
ftp://ftp.informatik.uni−hamburg.de/pub/virus/crypt/pgp
ftp://ftp.tu−clausthal.de/pub/atari/misc/pgp
ftp://ftp.uni−paderborn.de/pub/aminet/util/crypt
Meist stehen auf den Servern auch Scripte für die Einbindung in gängige Mail−Produkte
bereit (Es gibt noch viele weitere Quellen, die teilweise auch in den FAQs aufgelistet
sind). Der ftp−Server der Universität Hamburg stellt auch Informationen zu PEM
bereit.
Ausblick
Verschlüsselungsverfahren werden in Zukunft noch verstärkt eingesetzt werden.
Welche Verfahren/Produkte sich auf dem Markt durchsetzen werden, ist zum einen
abhängig von politischen Entscheidungen, zum anderen auch von der Art, wie
komfortabel sie für den Endnutzer sind. PGP hat zur Zeit zumindest in der
nichtkommerziellen DV−Welt die größte Verbreitung. Großen Anteil daran hat die
unkonventionelle Propagierung von Phil Zimmermann.
Edith Petermann
Rechenzentrum Universität Mannheim
[email protected]−mannheim.de
Contents [IMAGE]
27
E−Mail im Unix−Workstationpool
Jürgen Georgi
Electronic Mail hat einen festen Platz in der Pa−lette der modernen rechnergestützten
Kommunkationsformen eingenommen. Als eine der ersten Nutzungsmöglichkeiten des
einstigen ARPANnet gehört E−Mail gewissermaßen zur Großvatergeneration der
Netzdienste. Seitdem die University of Berkeley das Unix−Betriebssystem mit
TCP/IP−Netzwerkfähigkeit ausrüstete, ist E−Mail−Software Bestandteil von nahezu
jedem Unix−Betriebsystem. Sie gehört ebenso selbstverständlich zu Unix wie der
legendäre Editor vi.
Im Verlauf der kurzen Geschichte des Internets haben sich viele revolutionäre
technische Veränderungen ereignet. War früher ein Unix−Rechner ein teurer und von
vielen Personen gemeinsam genutzter Computer, so haben heute nicht ge−rade Wenige
eine eigene Workstation auf ihrem Schreibtisch stehen. Vernetzte Workstationpools
ersetzen die einstigen Multi User−Rechner, sie stellen den Benutzern volle
Rechnerleistung und arbeitsplatzunabhängigen Datenzugriff zur Verfügung.
Workstationpools stellen an E−Mail Software besondere Anforderungen, die oftmals die
Standardsoftware heutiger Unix−Betriebssysteme überfordert. In diesem Artikel sollen
die Probleme des E−Mail−Managements in Workstationpools genauer untersucht und
einige Lösungsvorschläge präsentiert werden.
E−Mail−Agenten
Über den Aufbau und die Funktionsweise des weltweiten E−Mail−Verbundes soll hier
nicht näher eingegangen werden. Nur kurz wird daran erinnert, daß die wesentlichen
Elemente der E−Mail−Verarbeitung sogenannte Mail Transport Agents (MTA) und Mail
User Agents (MUA) sind. Im In−ternet geschieht der Austausch von Nachrichten
zwischen den MTAs nach den Regeln des Simple Mail Transport Protocol [1] (SMTP).
Ein Benutzer selbst hat jedoch mit einem MTA keinen direkten Kontakt. Sie/er benutzt
einen User Agent, um eine E−Mail zu verfassen bzw. um empfangene Nachrichten zu
lesen.
Es gibt allerdings nur wenige Funktionsmerkmale des SMTP, die ein Nutzer wissen
sollte. Nachdem sie/er die Nachricht verfaßt und mit einer Zieladresse versehen hat,
übergibt sie das MUA−Programm an das Mailtransportprogramm, das für die
anschließende Auslieferung verantwortlich ist. Von nun an hat ein Benutzer keinen
Einfluß mehr auf das weitere Schicksal seiner Nachricht. Der lokale Transport Agent
wird zunächst einmal versuchen, eine Netzverbindung zum Transport Agent des
Zielsystems aufzubauen. Ist dieser empfangsbereit, wird die Nachricht sofort
übertragen. Der Zielrechner legt die Nachricht in einer strukturierten Mailboxdatei ab,
die der Adressat mit einem Mail User Agent lesen kann. Ist jedoch der Ziel−MTA nicht
empfangsbereit oder ist die Netzwerkverbindung gestört, wird der lokale MTA die
Nachricht zwischenspeichern (Queueing) und nach einer Zeitspanne − in der Regel
spätestens nach 30 Minuten − den Verbindungsaufbau er−neut versuchen. MTAs sind
sehr geduldig und wiederholen diesen Vorgang, bis der Zielrechner endlich erreichbar
ist. Alle Geduld hat aber auch ein Ende: Im Internet ist es üblich, daß nach etwa drei bis
28
fünf Tagen die Auslieferungsversuche abgebrochen werden, und der Absender
entsprechend benachrichtigt wird. Es muß zudem eingeräumt werden, daß der
Mailtransportvorgang hier sehr vereinfacht dargestellt wurde. In manchen Fällen liegen
zwischen dem sendenden MTA und dem Ziel−MTA weitere Zwischen−MTAs, die
ihrerseits ein Queueing durchführen können.
Das digitale Postamt
Der Leser wird sich vielleicht schon gefragt ha−ben, wie ein Mailtransportprogramm
funktioniert. Man kann einen MTA wohl am ehesten mit einem Postamt vergleichen:
Aus mehreren Orten können Briefe eintreffen, die anhand der Zieladresse sortiert und
eventuell weitertransportiert werden. Hat ein Brief mit dem Eingang den eigentlichen
Bestimmungsort erreicht, wird er entweder in ei−nem Kundenpostfach abgelegt, oder
einem Briefträger übergeben, der ihn am nächsten Morgen in den Hausbriefkasten des
Adressaten steckt, so−fern ihn nicht ein bissiger Hund davon abhält...
Der Vergleich mit einem Postamt hinkt ein we−nig. Vor allem die Funktion des
Briefträgers ist bei den meisten Mailtransportsystemen nicht zu−friedenstellend
ausgefüllt. Man kann sogar sa−gen, daß die Rolle des elektronische Briefträgers − der
Transport der Briefe vom Postamt zum persönlichen Briefkasten des Kunden − bei den
gängigen MTAs einfach nicht vorhanden ist: Der Kun−de muß zum Postamt gehen, um
die Post aus seinem Postfach zu holen. Die erfahrenen E−Mail−Nutzer unter uns werden
jetzt sicherlich entgegnen, daß bei ihnen die Sache schon richtig organisiert sei: Auf
ihrer Workstation läuft der MTA sendmail, und um ihre E−Mail zu lesen und
abzuschicken, benutzen sie einen User Agent wie z.B. elm oder mailx und vom Fehlen
eines Briefträgerprogrammes kann schon garnicht die Rede sein. Stimmt. In diesem Fall
gibt es tatsächlich ein Briefträgerprogramm. sendmail ruft beim Empfangen einer
Nachricht einen Delivery Agenten (DA), in der Regel /bin/mail, kurz binmail ge−nannt,
auf, der die Nachricht in eine Mailboxdatei ablegt, auf die Programme wie elm oder
mailx direkt zugreifen können. Dies ist der einfachste Fall: Das Postamt, um bei
unserem Bild zu bleiben, ist gleich im Haus. Das Kundenpostfach ist gleichzeitig der
Hausbriefkasten.
Nun sind wir beim Kernpunkt dieses Artikels an−gekommen. Wir stellten nämlich die
Behauptung auf, daß das Konzept \xe3 In jedem Haus ein Postamt" bzw. \xe3 Auf
jedem Rechner ein vollwertiger MTA" ein Anachronismus ist. Es stammt aus den alten
Zeiten, als Unix−Rechner in der Regel Dutzende von Benutzern über Terminals
bedienten. Für einen zentral organisierten Computer genügt das primitive
Briefträgerprogramm binmail vollauf.
Unsere heutigen Workstations dagegen sind de−zentral organisiert. Sie sind mit
schnellen LANs vernetzt, die Nutzerdaten werden in verteilten Filesystemen gehalten.
Datenspeicherung, Programmverarbeitung und Bildschirm−Ein/Ausgabe sind nicht auf
einen einzigen Rechner bezogen: Ich sitze vor der Workstation X und benutze ein
Programm, das auf der CPU des Rechners Y läuft, das die Daten verarbeitet, die auf der
Festplatte des Rechners Z gespeichert werden. Da−bei fällt es mir überhaupt nicht auf,
daß hier drei Workstations am Werk sind, ja oftmals weiß ich überhaupt nicht einmal,
auf welchem Rechner was passiert. Die Grenzen zwischen den Rechnern sind
29
verschwunden, sind transparent ge−worden: The Network is the Computer.
Netzwerktransparenz für E−Mail
Mit einem vollständigen Unix−Betriebssystem ist eine Workstation von heute mit einen
vollfunktionalen SMTP Transport Agent ausgerüstet, hat also stets das \xe3 Postamt im
eigenen Haus". In ei−nem Workstationpool gibt es deshalb ebenso vie−le Postämter wie
es Workstations gibt, ein Benutzer hat folglich ebenso viele unterschiedliche Briefkästen
und damit E−Mail−Adressen, wie es Workstations gibt. Die Bindung einer
Mailbox/E−Mail−Adresse an einen ganz bestimmten Rechner im Workstationpool
verletzt das Prinzip der Netzwerktransparenz, welches hinsichtlich der
Datenspeicherung im Workstationpool sonst selbstverständlich ist.
Ein wirklich netzwerktransparentes E−Mail−Man−agement dagegen verlangt, daß die
folgenden Merkmale und Funktionen unabhängig vom ge−wählten Arbeitsplatz
innerhalb eines Workstationpools sind:
· Eindeutige und feste E−Mail−Adressierung
· Verschicken, Empfang und Bearbeitung von elektronischer Post
· Verwaltung des Mailarchivs
· Benachrichtigung über neu eingetroffene Nachrichten
· Benutzerbestimmte Umleitung von Mail, Nutzung von Filterprogrammen.
Mit anderen Worten: In einem Workstationpool muß gleichgültig sein, mit welchem
Rechner ge−rade gearbeitet wird, es steht einem überall die gleiche E−Mail−Umgebung
zur Verfügung.
Mit etwas zusätzlichem Aufwand läßt sich für ei−nen Workstationpool eine
netzwerktransparente E−Mail−Konfiguration herstellen. In diesem Artikel werden
einige Installationskonzepte vorgestellt. Es gibt hierbei kein bestes Konzept, die
Entscheidung darüber hängt von den Anforderungen der Nutzer ab − und von dem
Aufwand, den ein Netzwerk−Administrator leisten möchte.
Zentraler Mailserver
Das Rezept ist ganz einfach: Das Abschicken von Briefen wird nur auf einem einzigen
Rechner zugelassen, der als zentraler Mailserver für alle Nutzer des Workstationpools
dient. Damit ist die E−Mail−Adresse eines Benutzers festgelegt. Alle Nachrichten
kommen nur auf diesem Rechner an. Muß auf einer anderen Workstation gearbeitet
werden, ist eine telnet/rlogin−Sitzung zum Mailserver notwendig. In unserer
Postamt−Analogie betreibt der Mailserver das Hauptpostamt, es gibt weder
Nebenpostämter, noch einen Briefträger. Wer Post erwartet, muß sich zum
30
Hauptpostamt begeben, um sein Postfach zu leeren. Ein Brief kann auch nur beim
Hauptpostamt aufgegeben werden, es werden keine Briefe automatisch vom
Kundenstandort zum Postamt transportiert − ausgenommen vom Kunden selbst.
Dieses Konzept erfüllt fast alle obigen Anforderungen, mutet den Benutzern jedoch
einige Ab−striche im Bedienungskomfort zu.
Die einsetzbaren Mail User Agents sind durch die Darstellungsmöglichkeiten der
telnet−Terminal−emulation eingeschränkt. Viele der derzeit populären Mail User
Agents können ohne Einschrän−kung an Komfort über eine telnet−Terminalverbindung
betrieben werden. Wer jedoch ohne Point−&−Click und Multimedia−Mail nicht leben
kann, wird an X−Windows MUAs nicht vorbeikommen. Diese können auf dem
Mailserver betrieben werden und auf dem X−Window Display der gerade genutzten
Workstation dargestellt werden. Leider bietet das X−Windows−Protokoll noch keine
Netzwerktransparenz hinsichtlich der Ausgabe von Audiodaten. Wenn der kalifornische
Freund in seiner E−Mail eine Kostprobe seines Mitschnitts des letzten Grateful
Dead−Konzerts als Audio Attatchment schickt, wird die integrierte Wiedergabefunktion
des X−Windows MUAs höchstens den Operator vor der Konsole des Mailservers
erfreuen. Zur Wiedergabe auf der eigenen Workstation muß die Audiodatei erst einmal
übertragen und mit einem Player abgespielt werden, der auf der Workstation selbst
gestartet wird.
Eine weitere Komforteinbuße: Die Einbindung von Dateien in einen elektronischen Brief
erfordert einen expliziten Dateitransfer von der Workstation zum Mailserver. Auch
hiergegen gibt es ein Hilfsmittel: Mailserver und Workstation können zu−sammen in ein
netzwerktransparentes Filesystem wie z.B. NFS eingebunden werden. Es empfiehlt sich,
die Funktion des Mail− mit der des NFS−Fileservers auf einem Rechner zu vereinigen,
sodaß das $HOME des Benutzers auf einem lokalen Speicherbereich des Mailservers
residiert.
Das Konzept Zentraler Mailserver besticht durch seine Einfachheit, es ist zudem ohne
zusätzliche Softwareinstallation realisierbar. Die beschriebenen Mängel im
Benutzerkomfort lassen sich aber durch andere Netzwerktechnologien (NFS,
X−Windows) weitgehend ausgleichen. Ein Schön−heitsfehler bleibt: Der Mailserver wird
bei Versorgung vieler Nutzer − besonders bei Anwendung von speicherhungrigen
X−Windows MUAs − stark belastet und muß hinsichtlich seiner Rechenleistung und
RAM−Ausstattung entsprechend di−mensioniert werden. Es findet gewissermaßen
ei−ne Konzentration von CPU/RAM−Ressourcen auf dem Mailserver statt, der verteilt
im Workstationverbund eigentlich ausreichend vorhanden wäre.
NFS−Shared Mailbox
Der Gedanke liegt nahe: Wenn schon der Mailserver als NFS−Fileserver die
Workstations be−dient, kann er doch allen anderen Workstations im Pool den
Festplattenbereich /var/spool/mail bzw. /var/mail mit den Eingangsmailboxen aller
Benutzer über NFS zur Verfügung stellen. Wir wollen ihn in dieser Funktion auch als
Mailboxserver bezeichnen. Auf diese Weise wird jedem Workstation−MTA vorgegaukelt,
die Eingangsmailboxen der Benutzer seien lokal vorhanden. Die Benutzer sind folglich
31
frei in der Wahl ihrer Mail User Agents, deren Betrieb auch nicht den Mailboxserver
belastet. Ein Mailboxserver wird durch den Mailverkehr nicht sonderlich beansprucht,
er muß nur ausreichend Festplattenkapazität für die Speicherung der Mailboxen
auf−weisen. Eine rechnerunabhängige Archivierung der E−Mail−Korrespondenz
geschieht im $HOME der Benutzer, auf das von allen Rechnern im Verbund über NFS
zugegriffen werden kann.
NFS ermöglicht elegant den netzwerktransparenten Zugriff auf die Eingangsmailbox.
Die Realisierung einer einheitlichen Mailadresse erfordert eine besondere Konfiguration
der beteiligten MTAs, es muß eine Umschreibung der Absenderadresse in eine
rechnerunabhängige Form vorgenommen werden. Im Gegensatz zu dem oben
beschriebenen zentralen Mailserver werden Briefe von den einzelnen Workstations aus
verschickt. Der ausgehende Mailtransport erfolgt jedoch stets über den Mailboxserver,
der die weitere Auslieferung übernimmt. Er ist allein zuständig für den Empfang von
E−Mail, die MTAs der Workstations sind nicht für die Ablage von Briefen in die
Eingangsmailbox eingerichtet.
Das Konzept NFS−Shared Mailbox funktioniert in der Tat in den meisten Fällen. Es hat
jedoch seine dunklen Seiten. Man muß sich im Klaren sein, daß eine Eingangsmailbox in
bestimmten Situationen von verschiedenen Programmen zu gleichen Zeit mit
Schreibzugriff geöffnet wird: Der Delivery Agent des Mailboxservers legt neu
eingetroffene Mail in der Eingangsmailbox ab, während der Benutzer gerade in seiner
Mailbox mit einem UA einige schon gelesene Nachrichten löscht. Die Synchronisation
von Prozessen, die gemeinsam schreibend auf eine Datei zugreifen wollen, funktioniert
bei Unix−Betriebsystemen durch verschiedene Arten von Sperrmechanismen (File
Locking) sehr sicher, wenn die Datei auf einem lokalen Dateisystem liegt. Wenn die
Prozesse auf die Datei über NFS zugreifen, funktioniert sie meist nicht mehr
zuverlässigt. Besonders anfällig gegen Locking−Probleme sind Workstationpools, in
denen Rechner unterschiedlicher Hersteller betrieben werden. Die Probleme zeigen sich
oftmals darin, daß Briefe auf mysteriöse Weise verloren gehen, User Agenten ihren
Dienst ganz verweigern, oder der sendmail−Prozeß regelrecht hängenbleibt.
Doch zurück zum Briefträger. Die beiden gezeigten Techniken, um innerhalb eines
vernetzten Workstationpools eine einheitliche Mailadresse und netzwerktransparenten
Mailboxzugriff für die Benutzer bereitzustellen, sind nichts anderes als ungenügende
Substitute für das oben geforderte Briefträgerprogramm. Im ersten Fall kann der
Briefträger binmail das Postamt nicht verlassen, der Kunde begibt sich selbst auf das
Postamt. Im weiten Fall ist der Briefträger ebenso beschränkt, dafür übernimmt das
verteilte Dateisystem den Transport der Briefe zum Kunden.
Nicht nur für PCs: POP und IMAP
Es lohnt sich, einmal über den Zaun zu schauen und Softwarelösungen für Internet Mail
aus der bunten Welt der Personal Computer zu betrachten. PCs haben sehr schlechte
Voraussetzungen für den Betrieb eines SMTP MTAs, da sich ers−tens die übliche
Systemsoftware nicht gut für den Betrieb von SMTP−Serverprogrammen eignet und sie
zweitens − im Gegensatz zu Workstations − bei Nichtbenutzung häufig ausgeschaltet
werden. Was liegt hier näher, als auf einen MTA ganz zu verzichten und einen User
32
Agent mit eingebauter Briefträgerfunktion zu betreiben. Ganz ohne einen MTA kommen
PCs natürlich nicht aus, so sind sie auf einen Mailboxserver mit MTA angewiesen, mit
dem sie über das Netz kommunizieren können. Üblicherweise übernimmt ein
Unix−Rechner diese Rolle. Dieser empfängt alle E−Mail für den PC−Benutzer und
speichert sie in seiner Unix−Eingangsmailbox ab. Der Mailboxserver muß
darüberhinaus ein Programm betreiben, das vom PC User−Agenten aus über das Netz
ferngesteuert werden kann und die üblichen Mailboxoperationen wie Lesen, Löschen
einer Nachricht etc. durchführt und bei Bedarf Nachrichten an den PC zur lokalen
Speicherung überträgt. Man beachte, daß hierbei kein verteiltes Filesystem im Spiel ist.
Für die beschriebene Briefträgerfunktionalität von Mail User Agents wurden zwei
Verfahren für TCP/IP−Protokollwelt standardisiert und in eigenen Request for
Comments beschrieben.
Das Post Office Protocol [2] (POP) ist das ältere und deshalb auch am weitest verbreitete
der beiden Protokolle.
Die wichtigsten POP−Funktionen sind:
· Anmeldung beim Mailboxserver mit Paßwort−Überprüfung
· Erstellung und Übertragung einer Inhalts−liste der Eingangsmailbox
· Vollständige/partielle Übertragung von Nachrichten aus der Eingangsmailbox
· Löschen einer Nachricht aus der Eingangsmailbox
· Abmeldung beim Mailboxserver.
Das Internet Message Access Protocol [4], [5] (IMAP) hingegen erweitert die
Mailbox−Operationen in der Weise, daß auf dem Mailboxserver nicht nur eine einzige
Mailbox − die Eingangsmailbox − gespeichert und vom User Agent manipuliert werden
kann, sondern derer beliebig viele. Die Eingangsmailbox nimmt insofern eine
Sonderrolle ein, da nur in ihr neu eintreffende Mail abgelegt wird. Man kann die
zusätzlichen Mailboxen als Archivmailboxen ansehen, in denen eingegangene
Nachrichten nach beliebigem Ord−nungsprinzip zur weiteren Speicherung abgelegt
werden können. IMAP erlaubt es zudem, daß in einer Mailbox gezielt nach Textmustern
gesucht werden kann, ohne daß der ganze Mailboxinhalt zum Klienten−Rechner
übertragen werden muß.
Sowohl POP als auch IMAP legen nicht fest, auf welche Weise E−Mail vom User
Agenten abgeschickt wird. Fast alle POP/IMAP User Agents verfügen deshalb über eine
minimale SMTP−Sendefunktion, die ausgehende Mail an einen SMTP−MTA überträgt −
meist ist dies der Mailboxserver.
Was für PCs gut ist, kann auch für Workstations ganz nützlich sein. POP oder IMAP
würden auf elegante Weise ein verteiltes E−Mail−System er−möglichen, bei dem es
prinzipiell egal ist, von welchem Rechner man gerade auf seine Mailbox(en) zugreifen
33
möchte. Während mit IMAP ei−ne vollständige Rechnerunabhängigkeit der
Mailboxverwaltung erreicht wird − es findet garkeine Speicherung von Nachrichten auf
der Workstation statt − muß bei POP der netzwerktransparente Zugriff auf
Archivmailboxen über den NFS−Zugriff auf $HOME realisiert werden.
Leider führen POP und IMAP auf Unix−Rechnern ein regelrechtes Schattendasein. Die
Mehrzahl aller Hersteller rüsten ihre Workstations mit Mail User Agents aus, die direkt
auf die Eingangsmailboxdatei zugreifen. POP− oder IMAP−Server sind in der Regel
nicht Bestandteil der Systemsoftware. Auch die Palette POP/IMAP−fähiger
3rd−Partysoftware läßt sich an einer Hand abzählen. Eine Alternative zu
POP/IMAP−fähigen Mail User Agents stellt Carl Harris‘ popclient dar: Ein POP
Transport Agent, der den Inhalt der Eingangsmailbox auf dem Mailboxserver zur
Workstation transportiert und dann dort in eine lokale Mailbox ablegt. Das Lesen der
Nachrichten erfolgt auf der Workstation mit Hilfe eines beliebigen herkömmlichen User
Agent. popclient ist also eine Implementation des eingangs geforderten Briefträgers, der
vom Kunden zum Postamt geschickt wird, dort aus dem Postfach die Post abholt und sie
zu Hause in den normalen Hausbriefkasten steckt.
Mit popclient wird der Benutzer sogar über eingetroffene Mail benachrichtigt, da die
Ablage der Briefe mit dem Delivery Agent binmail auf der Workstation gemacht wird,
welcher den biff/comsat−Mechanismus verwendet. Sogar die Einbindung von
Filterprogrammen ist mit popclient möglich, z.B. über den Aufruf popclient | filterprog,
wobei filterprog die Filterfunktionen ausübt.
Der Mailboxzugriff mit popclient hat auch seine Schönheitsfehler. Da die Zustellung der
Briefe von der Workstation aus angestoßen wird, und nicht von einem lokalen MTA,
bekommt ein Be−nutzer seine Post nicht unmittelbar nach Eintreffen, sondern erst beim
Aufruf von popclient. Falls keine sofortige Benachrichtigung über neu eingekommende
Mail stattfindet, werden neugierige oder ungeduldige Zeitgenossen die Spanne zwischen
den Aufrufen von popclient sehr kurz wählen. Das wiederum kann bei einer großen
Anzahl vom Benutzern den Mailboxserver stark bean−spruchen − eine Zeitspanne von
mindestens 10 Minuten zwischen den Aufrufen sollte deshalb eingehalten werden.
Hiermit haben wir bei POP und IMAP eine empfindlichen Stelle berührt: Sie verlangen
nämlich, daß sich Benutzer beim Mailboxserver über ein Paßwort ausweisen. Dieses
Paßwort geht im einfachsten Fall im Klartext über das Netz. Wird in einem LAN der
Kontakt zum Mailboxserver periodisch mit kurzen Check−Intervallen hergestellt, erhöht
sich die Wahrscheinlichkeit, daß das Paßwort mit geeigneter Schnüf−felsoftware
abgehört werden kann. Ausreichenden Schutz vor solchen Attacken bieten
Authentisierungsverfahren wie beispielsweise Kerberos oder Authenticated POP [3]
(APOP), bei denen Paßworte nur verschlüsselt auf dem Netz er−scheinen. popclient
unterstützt optional die APOP−Authentisierung, bei der POP−Server/−Client ein
Geheimnis kennen, das bei einer Transaktion zusammen mit einem vom Server
generierten Zeitstempel verschlüsselt übertragen wird.
E−Mail unter Unix − Plug and Play?
So vielseitig und leistungsfähig Unix−Workstations auch sind − der Aufbau einer
komfortablen und robusten netzwerktransparenten Mail−Konfiguration für einen
34
Workstationpool ist alles an−dere als trivial. Die E−Mail−Softwareausstattung heutiger
Workstations stellt die geforderte Funkti−onalität meist nur ansatzweise zur Verfügung.
Die standardisierten netzwerkbasierten Mailboxzugriffsverfahren wie POP und IMAP
haben leider bisher nur wenig Unterstützung in den Unix−Softwareschmieden erfahren.
Die Techniken für netzwerktransparentes E−Mail−Management sind be−kannt, ja es ist
Software frei verfügbar, mittels der dies realisierbar ist. Die Software muß
allerdingsnachträglich installiert werden, das Zusammenspiel der Komponenten unter
erheblichen Zeitauf−wand getestet werden. Auf Plug and Play werden wir wohl noch
einige Jahre warten müssen.
Anhang
Im folgenden werden Musterkonfigurationen für zwei der oben vorgestellten
netzwerktransparenten Mailkonzepte genauer beschrieben: Mailboxserver/NFS−Shared
Mailbox und Mailboxserver/POP. In beiden Fällen soll der Mailboxserver den
Phantasienamen donald.disneyland.com tragen, die beteiligten Workstations
tick.disneyland.com, trick.disneyland.com und track.disneyland.com heißen. Die
rechnerunabhängige E−Mailadresse soll lauten <loginname>@disneyland.com. In al−len
Fällen wird vorausgesetzt, daß der Login−Na−me eines Benutzers auf allen
Workstations einschließlich Mailboxserver der gleiche ist. Auf al−len Rechnern wird der
zum Lieferumfang des Betriebssystems − in den Beispielen durchweg SunOS 4.1 −
gehörende sendmail MTA durch die frei verfügbare UCB sendmail Version 8 − derzeit
aktuelles Release 8.7.3 − ersetzt. UCB sendmail−V8 vereinfacht die
sendmail−Konfiguration − d.h. die Erzeugung einer sendmail.cf−Datei − erheblich. Es
erfüllt darüberhinaus, im Vergleich zu dem meist veralteten sendmail des
Rechnerherstellers, sehr hohe Anforderungen an die Unix−Systemsicherheit.
Szenario A: NFS−Shared Mailbox
donald.disneyland.com exportiert /var/spool/mail per NFS an tick, trick und track.
Außerdem ist er Fileserver für die Homedirectories der Benutzer und exportiert /home
per NFS an tick, trick und track. Da aus der Sicht von donald alle Dateisysteme lokal
sind, wird einer Faustregel Rechnung getragen, der zufolge der sendmail−Dämonprozeß
und sein Delivery Agent binmail nie auf NFS−Dateisysteme zugreifen sollten. Dies gilt
sowohl für die Mailablage in /var/spool/mail/$USER als auch für den Zugriff auf
$HOME/.forward.
A.1 Domain Name System
Der Mailboxserver ist exklusiv für den Mailempfang zuständig. Folgende MX−Einträge
sind hierfür in der DNS−Zone disneyland.com erforderlich:
$ORIGIN disneyland.com.
@ MX 10 donald
donald MX 10 donald
tick MX 10 donald
trick MX 10 donald
track MX 10 donald
35
Obwohl für die Benutzeradressierung des Disneyland−Pools die generische Adresse
<loginname>@disneyland.com verwendet wird, ist da−mit auch für den Fall Sorge
getragen, daß aus Versehen eine Nachricht an eine rechnerbezogene Adresse verschickt
wird.
A.2 Mailboxserver − sendmail−Konfiguration
Die Konfigurationsdatei sendmail.cf wird mit Hilfe der Unix M4−Makrosprache
generiert. Näheres hierzu ist in der Datei cf/README der sendmail−V8 Source
Distribution zu entnehmen.
Hier die M4−Makrodefinitionen für die sendmail− Konfiguration des Mailboxservers:
OSTYPE(sunos4.1)
MAILER(local)
MAILER(smtp)
MASQUERADE_AS(disneyland.com)
FEATURE(masquerade_envelope)
FEATURE(use_cw_file)
In der Datei /etc/sendmail.cw (\xe3 use_cw_file") werden alle Domainnamen genannt,
für die do−nald Mail akzeptiert und ausliefert, d.h.
disneyland.com
tick.disneyland.com
trick.disneyland.com
track.disneyland.com
Die Rechnernamen in /etc/sendmail.cw werden bei ausgehender Mail durch den
generischen Namen disneyland.com in der Absenderadresse maskiert.
A.3 Mailboxserver − DA−Konfiguration
Für die Ablage von neuen Nachrichten in /var/spool/mail ruft sendmail den Delivery
Agent binmail. Dem Delivery Agenten kommt die Aufgabe zu, die Eingangsmailbox
während des schreibenden Zugriffs gegenüber anderen Prozessen, z.B. MUAs, zu
sperren. Bei einem Workstationpool mit NFS−Zugriff auf Mailboxen empfiehlt sich die
Installation des Delivery Agent procmail von Stephen van den Berg. Seine
herausragenden Ei−genschaften: procmail respektiert sämtliche auf der verwendeten
Plattform verfügbaren Kernel Locking−Verfahren und implementiert den Um−gang mit
Lock−Dateien (dot locking) in einer für NFS angemesse Weise. Als Beigabe stellt
procmail den Benutzern sehr mächtige Filterfunktionen zur Verfügung, die in der Datei
$HOME/.procmailrc spezifiziert werden. Beim Einsatz von procmail muß bei der
M4−Generierung von sendmail.cf FEATURE (local_procmail) hinzugefügt werden.
A.4 Workstations − sendmail−Konfiguration
Der Funktionsumfang des sendmail−MTAs der Workstations beschränkt sich darauf,
36
alle auszuliefernde Mail sofort an den Mailboxserver zu schicken. Es gibt keine lokale
Alias−Unterstützung. Die M4−Makrodefinitionen für eine so reduzierte
sendmail−Konfiguration (nullclient) lauten:
OSTYPE(sunos4.1)
FEATURE(nullclient, donald.disneyland.com)
FEATURE(nocanonify)
A.5 New Mail Notification
Für New Mail Notification gibt es zwei Ansätze:
A.5.1 Notification über biff/comsat
Beim Eingang einer neuen Mail schickt der Delivery Agent des Mailboxservers ein
Datagramm an den im Hintergrund laufenden comsat−Dä−mon, der seinerseits eine
Meldung New mail for... und den Mail−Anfangsteilauf dem Terminal des Benutzers
anzeigt, falls diese/r vorher mit dem biff−Programm vom comsat−Dämon eine
Benachrichtigung angefordert hat (biff y). Da die Benutzer der Workstations in der
Regel nicht auf dem Mailboxserver eingeloggt sind, haben Sie keinen Nutzen von der
Meldung des comsat−Dämons. Die biff/comsat−Implementation von Steve Grimm (rbiff)
ermöglicht die New Mail−Benachrichtigung auch über Rechnergrenzen hinweg, indem
beim biff−Aufruf von den Workstations aus als zusätzlicher Parameter der
Mailboxserver angegeben wird, z.B. mit dem Befehl
biff a @donald.disneyland.com
Natürlich erfordert dieser Komfort den Austausch der biff− und comsat−Binaries auf
allen beteiligten Rechnern.
A.5.2 Mailbox−Monitore bei MUAs und Shells oder als Stand Alone−Programme
Viele MUAs schauen periodisch in der Eingangsmailbox nach, ob neue Nachrichten
eingetroffen sind und verkünden dies durch visuelle oder akustische Signale. Die
Funktion steht natürlich nur dann zur Verfügung, wenn der MUA in Betrieb ist. Die
gleiche Funktionalität wird auch von einigen Unix Shells angeboten, wobei über eine
Shell−Variable der Name der zu überwachenden Eingangsmailbox angegeben wird.
Mailbox−Mo−nitore sind aber auch als eigenständige Applikationen verfügbar und
werden vorwiegend unter X−Windows eingesetzt, wo sie als geduldige Helferlein ihr
ständiges Plätzchen auf dem Desktop zugewiesen bekommen, beliebt sind hierfür Xbiff
bzw. Xmultibiff.
A.6 Workstations − MUA−Konfiguration
Durch den netzwerkweiten Zugriff der Mail User Agents auf die Eingangsmailbox
besteht die Ge−fahr, daß ein Benutzer von mehreren Workstati−ons aus gleichzeitig
seine Post bearbeitet. Dies sollte natürlich vermieden werden, ist aber prinzipiell nicht
zu verhindern. MUAs, die temporäre Dateien anlegen, sollten dies, falls konfigurierbar,
in Filesystemen tun, die netzwerkweit verfügbar sind, z.B. /var/spool/mail oder
37
$HOME/tmp. Ein MUA kann durch die Existenz von Temporärdateien erkennen, ob die
Mailbox von anderer Seite aus schon geöffnet wurde.
A.7 NFS−Konfiguration des Mailboxservers
Der Mailboxserver exportiert das Mailboxverzeichnis /var/spool/mail via NFS an die
Workstations tick, trick und track mit Zugriffsmodus Read−Write (rw).
A.8 NFS−Konfiguration der Workstations
Die Workstations tick, trick und track importieren das Mailboxverzeichnis von donald
via NFS. Ob−ligatorische Parameter für den mount−Befehl sind rw und hard, optional
intr, bg und noac (no attribute caching). noac erhöht die Zuverlässigkeit des Zugriff auf
Lockdateien über NFS.
Szenario B: POP Mailbox Access
donald.disneyland.com betreibt als Mailboxserver einen POP−Dämon, der die
Workstations tick, trick und track bedient. Die Homedirectories der Benutzer auf tick,
trick und track stehen dann wie in Szenario A per NFS zur Verfügung an. Es ist jedoch
nicht erforderlich, daß donald auch NFS−Fileserver für $HOME ist.
B.1 Domain Name System
Wie in A.1.
B.2 Mailboxserver − sendmail−Konfiguration
Die sendmail−Konfiguration unterscheidet sich nur unwesentlich von der aus A.2: Der
Austausch von binmail durch procmail ist nicht notwendig, das M4−Makro
FEATURE(local_procmail) entfällt deshalb. Falls der Mailboxserver $HOME der
Be−nutzer via NFS importiert, sollte sendmail davon abgehalten werden, auf Per User
Forward−Datei−en (.forward) unter $HOME zuzugreifen, da bei Ausfall des
NFS−Servers die Auslieferung verzögert oder gar gestört werden könnte. sendmail− V8
erlaubt über die sendmail.cf−Option J die An−gabe eines zentralen, lokalen
Verzeichnisses für Per User Forward−Dateien. In der Musterkonfiguration wurde
hierfür /var/forward gewählt, die Forward−Dateien heißen /var/forward/$USER. Aus
Sicherheitsgründen schreiben die Benutzer nicht selbst in das Forward Directory, ein
Shell Script kopiert dafür einmal in der Nacht für jeden Benutzer $HOME/.forward nach
/var/forward/$USER.
Die M4−Makrodefinitionen für die sendmail−Konfiguration des
Mailboxservers/POP−Servers lauten:
OSTYPE(sunos4.1)
MAILER(local)
MAILER(smtp)
MASQUERADE_AS(disneyland.com)
38
FEATURE(masquerade_envelope)
FEATURE(use_cw_file)
define(‘confFORWARD_PATH‘, /var/forward/$u)
Alles weitere wie in A.2.
B.3 Mailboxserver − DA−Konfiguration
Entfällt.
B.4 Workstations − SMTP−Konfiguration
Wie in A4.
B.5 New Mail Notification
Für Ungeduldige, die ohne sofortige Benachrichtigung über neue Mail nicht leben
können, empfiehlt sich die Konfiguration aus A.5.1. Wem die Installation von rbiff zu
aufwendig ist, der kann sich auch mit dem herkömmlichen lokalen
biff/comsat−Mechanismus oder mit einer der Methoden aus A.5.2 begnügen. Die
Ankunft neuer Nachrichten wird dann aber erst nach dem Aufruf des POP−Client
signalisiert.
B.6 Workstations − MUA−Konfiguration
Falls der Mail User Agent selbst das POP−Protokoll beherrscht, muß dem MUA der
Name bzw. die IP−Adresse des POP−Servers, in diesem Fall donald.disneyland.com,
mitgeteilt werden, aus−serdem das Paßwort für die Mailbox−Zugriffsberechtigung.
In unserer Musterkonfiguration gehen wir davon aus, daß die verwendeten MUAs nicht
POP−fähig sind und deshalb als Eingangsmailbox eine Datei in /var/spool/mail
erwarten. Den Transfer der Eingangsmailbox vom Mailboxserver zur Workstation
bewerkstelligt der POP Transport Agent pop−client (Version 3). popclient muß also vor
dem Aufruf des MUAs seine Arbeit schon getan ha−ben. Diese Arbeitsteilung könnte
durch die Verwendung eines Wrapper Scripts realisiert werden, z.B. mit
#!/bin/sh
donald.disneyland.com popclient && exec elm
Andere, raffiniertere Methoden sind denkbar, z.B. der periodische Aufruf von popclient
durch cron, dies jedoch abhängig von der Existenz einer vom MUA beim Aufruf
angelegten Temporärdatei. Da popclient für die Mailablage in das lokale /var/spool/mail
den gleichen DA wie sendmail verwendet, ist die Synchronisation des schreibenden
Zugriffs von popclient und MUA auf die Ein−gangsmailbox gewährleistet. popclient
kann also auch nach dem Start des MUAs Post abholen, der MUA wird die Ankunft
neuer Nachrichten auf die übliche Art und Weise erkennen.
39
B.7 Mailboxserver − POP Server−Konfiguration
Auf dem Mailboxserver muß ein POP−Serverprozess betrieben werden. Die gängigen
Implementationen von POP−Servern unterscheiden sich im Wesentlichen nur in der
Methode der Benutzerauthorisierung. Eine Gruppe greift auf das Unix Password File zu,
die andere verwendet eine ei−gene Tabelle für die Authorisierung. Der Betrieb eines
POP−Servers mit eigener Paßwortdatei ermöglicht den POP−Service für Nutzer ohne
ei−ne Login−Berechtigung auf dem Mailboxserver, erfordert jedoch eine besondere
sendmail−Konfiguration mit einem speziellen Delivery Agent für POP−Mailboxen. Um
die netzwerktransparente New Mail Notification mit rbiff nutzen zu können, wurde für
die Musterkonfiguration mit qpopper 2.1.4 ein Server aus der ersten Gruppe gewählt.
qpopper unterstützt die APOP−Authentisierung, die − falls bei Clients verfügbar − in
einen Workstationpool mit regelmäßigen POP−Transaktionen aus bekannten Gründen
bevorzugt einge−setzt werden sollte. Bei APOP−Authentisierung muß eine Unix−dbm−
bzw. db−Datenbank mit den APOP Secrets der POP−Benutzer angelegt werden. Die
APOP−Datenbank wird mit dem mitgelieferten Programm popauth auf dem
POP−Server verwaltet.
Falls APOP nicht möglich ist, z.B. weil auf den Workstations ein POP−fähiger MUA
ohne APOP−Unterstützung eingesetzt wird, empfiehlt sich folgende
Sicherheitsvorkehrung:
· Keine Login Shell im Paßworteintrag auf dem Mailboxserver
· Kein ftp−Zugang auf dem Mailbox−Server, d.h. ein Eintrag des POP Users in
/etc/ftpusers
· Das POP−Paßwort muß sich vom Login−Paßwort auf den Workstations unterscheiden.
Kommt ein POP−Paßwort durch das Abhören des LAN−Datenverkehrs in falsche
Hände, ist nur der Zugriff auf die Mailbox des Benutzers davon be−troffen, nicht aber
seine anderen Daten.
B.8 Workstations − POP Client−Konfiguration
Wie bereits in B.5 erwähnt, greifen die Benutzer der Workstations mit Hilfe des
Programms popclient auf ihre Eingangsmailboxen zu. In der Konfigurationsdatei
$HOME/.poprc werden die not−wendigen Betriebsparameter abgelegt. Der Be−nutzer
jsmith in unserem Workstationpool hat in seinem .poprc folgendes eingetragen:
server donald.disneyland.com \
protocol apop \
username jsmith \
password dontellya
Natürlich muß die Datei .poprc mit Modus 600 vor unbefugter Einsicht geschützt
werden, da sie das APOP−Geheimnis im Klartext enthält.
40
B.9 Workstations − DA−Konfiguration
Prinzipiell erfordert der Delivery Agent, den popclient verwendet, keine besondere
Aufmerksamkeit. Der übliche binmail−DA reicht für die reine Ablage völlig aus. Falls
die Benutzer jedoch ge−wöhnt sind, mit Hilfe des Per User Forward File Mail Filter zu
verwenden, bietet sich wiederum procmail als Delivery Agent auf den Workstations an.
Die gewünschten Filterfunktionen werden dann im $HOME/.procmail angegeben.
Literatur
[1] J. Postel, Simple Mail Transport Protocol, RFC 821, 1982
[2] J. Myers, M. Rose, Post Office Protocol, Version 3, RFC 1725, 1994
[3] J. Myers, POP3 AUTHentication command, RFC 1734, 1994
[4] M. Crispin, Interactive Mail Access Protocol, Version 2, RFC 1176, 1990
[5] M. Crispin, Internet Message Access Protocol, Version 4, RFC 1730, 1994
[6] J. Wobus, LAN Mail Protocols, 1995,
http://web.syr.edu/~jmwobus/comfaqs/
lan−mail−protocols.
Quellen
Die im Text erwähnten Programme sendmail, popclient, qpopper, procmail und rbiff sind
in der Quellform zu finden unter
ftp://ftp.belwue.de/pub/unix/
Jürgen Georgi
BelWü−Koordination
[email protected]
Contents [IMAGE]
VBN in BelWü 1988 − 1995
Paul Christ
Nach mehr als sieben Jahren Produktion wurde am 18. Juli 1995 die
FDDI/VBN−Strecke Karlsru−he−Stuttgart als letzte BelWü−VBN−Verbindungen(1)
außer Betrieb genommen: Feierlich eingeweiht von Minister Schwarz−Schilling,
Minister−präsident Späth und Wissenschaftsprominenz am 22. Februar 1988, war das
Ende eher still:
From:Joseph Michl <[email protected]>
41
To: <belwue−[email protected]>
Subject:VBN tatsaechlich abgeschaltet
Liebe Kolleginnen und Kollegen,
offensichtlich wurde die VBN Strecke Stuttgart − Karlsruhe heute um 14:05 Uhr von der
Telekom tatsaechlich ab−geschaltet.
Gruss,
Joseph Michl
B−ISDN, VBN und ATM
Das VBN − das Akronym zunächst zu Vorläufer Breitbandnetz, später zu Vermittelndes
Breitbandnetz expandiert − repräsentierte das historische Credo(2) Vieler in der Welt
des Breitband−, des B−ISDN, daß dieses nichts sei als ein − etwa 140 Mbit/s − schnelles
Schmalband−ISDN: Der Nutzer sieht eine feste, kleine Anzahl von Kanälen für Sprache,
Video, Daten plus einen Signalisierungskanal − das Ganze leitungsvermittelt [1].
Die Telekom hatte entsprechend seit Mitte der 80er Jahre verschiedene Pilotvorhaben
etabliert: In Berlin BERKOM, in der Fläche zunächst BIGFON und danach das VBN.
Für BERKOM lieferten SEL und Philips
Leitungsvermittlungskno−ten,Teilnehmer−Anschluß−Einrichtungen (TAE) und
Systemsoftware − für das VBN entsprechend ANT und Nixdorf. Im selben Monat
Februar 1988, in dem in Stuttgart die Minister feierlich eröffneten, akzeptierte der
CCITT in Seoul ATM als Basistechnologie für B−ISDN. Siemens lieferte zeitgemäß
einen experimentellen ATM−Switch an BERKOM.
HORNET, VBN und BelWü
Wohl 1986 hatten Ministerpräsident Späth und die Spitze der auch im Lande
ansässigen vormaligen DFVLR − jetzt DLR − vereinbart, in Kooperation mit der
Telekom auf VBN−Basis ein Netz für Wissenschaft und Forschung zunächst im Lande
zu errichten. Angesiedelt beim Wirtschaftsministerium wurde unter der Leitung der
DLR eine Ar−beitsgemeinschaft aus Industrievertretern und den Universitäten
Karlsruhe und Stuttgart gebildet. Der Arbeitstitel für das Vorhaben war HORNET:
High−speed Open Research Network. Die−sem Vorhaben war kein Erfolg beschieden. Im
Ergebnis hat das Wissenschaftsministerium die−se Aktivität übernommen: Vor der
Sommerpause 1987 wurde in einer Presseerklärung das heute als BelWü bekannte
Vorhaben angekündigt; die Nutzung von VBN−Strecken war dabei eines der
Anfangsziele. Das Institut für Nachrichtenübertragung der Universität Stuttgart (INÜ),
Prof. Kaiser, und das RUS haben in Kooperation mit der Firma Hirschmann zur oben
genannten Eröffnungsdemonstration jene VBN−Elemente fertiggestellt, die eigentlich
einen Teil von HORNET hätten bilden sollen/können: Einen Multiplexer Ethernet−VBN
(E−MUX) und eine Ethernet Remote Bridge.
42
Weitere VBN−Vorhaben
In der Folge wurden von verschiedenen Projektträgern in Einzelabkommen mit der
Telekom weitere VBN−Vorhaben vereinbart. Das INÜ hat dem E−MUX einen F−MUX
folgen lassen: VBN konnte damit zur Übertragung von FDDI−, TAXI−artigen
Datenströmen verwendet werden − also etwa für FDDI selbst, UltraNet Links und
TAXI−basiertes ATM. Alle drei Einsatzarten wurden demonstriert. Die schon 1990
vorgeführte UltraNet−Verbindung zwischen der CeBIT und dem RUS mit 95 Mbit/s auf
Benutzerebene dürfte damals ein Weltrekord für ein \xe3 irdisches" Produkt
Bandbreite*Entfernung gewesen und noch heute in Deutschland unübertroffen sein.
Was gelernt, erreicht wurde
Die VBN−Projekte waren zweifelsohne ein Teil der weltweiten Bewegung \xe3 Nicht
alles geht mit 2Mbit/s oder gar mit n*64 Kbit/s, für \xb2 30"; SuperJANET, das vBNS,
das neue ESnet, die europäischen ATM−Piloten, die DFN RTBs und absehbar B−WIN
und vielleicht BelWü selbst belegen den Erfolg dieser Bewegung.
Die BelWü−VBN−Projekte haben deutlich die Notwendigkeit einer engen Verknüpfung
teurer Netzwerk−Ressourcen mit konkreten Anwendungs−projekten aufgezeigt, wie sie
etwa in den EU−Vorhaben des RUS PAGEIN, ADONNIS oder MICE erreicht wurde: Die
VBN−Projektberichte an die Telekom hatten teilweise Schwierigkeiten Auslastung und
Notwendigkeit der Verbindungen darzutun. Andere \xe3 Schulen" haben hier z.T.
weniger allgemeine oder effiziente Datenvorhaben über das VBN abgewickelt − gingen
aber von spezifizierten Anwendungen aus. Zu nennen sind etwa die Remote
Publishing−Vorhaben der DeTeBerkom und die Telemedizin−Vorhaben ULKOM und
ZELLKOM.
Das RUS selbst hat auf die VBN−Arbeiten bei der Akquisition von
EU−Anwendungs/Netzprojekten erfolgreich verweisen können (z.B. RACE 2031
PAGEIN); im Lande wurde die Ethernet− zu einer Multiport−Brücke mit
ATM−Übergang ausgebaut (Projekt HiATM); das Vorhaben USPS ist ein Versuch, die
VBN−Arbeiten in den ATM−HIPPI−Gigabit−Bereich zu transferieren.
Danksagung
Professor Kaiser, Institut für Nachrichtenübertragung der Universität Stuttgart (INÜ),
ist der politische und auch technische Vater der geschilder−ten VBN−Vorhaben.
Die 1. Generation der VBN−Multiplexer wurde von den Herrn Riede und Widmann des
INÜ entworfen und erstellt. Das o.a. Redesign der Multiplexer wurde von den Herren
Hofbauer und Milow, RUS, und der Firma Hirschmann durchgeführt.
Ethernet−Brückenarchitektur, Schaltungsdesign, Systemsoftware wurden von den
Herrn Haas und Copplestone, RUS, in Zusammenarbeit mit der Firma Hirschmann
designed und implementiert.
43
Die Herren Feil und Fahner, RUS, haben mit den Projektpartnern die
VBN−(Pilot−)Betriebsszenarien realisiert.
Herr Michl, BelWü−RUS, Herr Bannas, Frau Gol−ka, RUS, Herr Lortz, Karlsruhe, Herr
Hipp,Tübingen, u.a. haben mit den Schwächen der Geräte managementmäßig leben
müssen.
Das Wissenschaftsministerium hat die Vorhaben politisch und finanziell unterstützt,
der DFN−Verein dieselben aus Mitteln des BMFT unter den Kennzeichen TK 558 −
HD001 (DFN CXLX) und TK 558 HD 010 (DFN CXLXplus) gefördert. Das
MUX−Redesign wurde teilweise durch das Vorhaben RACE 2031 PAGEIN getragen.
Wir danken unseren Projektpartnern in Berlin, Bremerhaven, Freiburg, Hamburg,
Kaiserslautern, Karlsruhe, München, Tübingen und andernorts.
Besonderer Dank gilt der Deutschen Telekom AG hier speziell den Herren Wabbels und
Kercher von der Projektgruppe IKAT bei der Direktion Stuttgart.
Literatur
[1] G. Doman, A. Engel, H.−J. Matt, R. Stannard, B−ISDN Field Trial Concept, ISDN
Europe 86, November 5 − 7, 1986, Basel
Paul Christ
BelWü−Entwicklung
[email protected]−stuttgart.de
ATM − RUS, urbi et orbi
Paul Christ
Der Artikel − ursprünglich im Herbst 1995 verfaßt − gibt einen gleitenden
ATM−Statusbericht aus der Sicht des RUS. Nach einer kurzen historischen Übersicht
wird der Titel von rechts nach links jeweils unter den Aspekten Produktion und
Pilotierung/F&E behandelt.
Zur ATM−Technologie
ATM zwischen den Kulturen
ATM − Asynchroner Transfer Mode − wurde im Februar 1988 in Seoul vom damaligen
CCITT als Basis−Technologie für das kommende Breitband−ISDN akzeptiert: Auf der
Basis kleiner, Adressen tragender Datenpakete(1) fester Länge − eventually cells of 48
plus 5 bytes − soll es möglich sein, von hier nach Australien zu telefonieren,
Bewegtbilder zu übertragen, LANs miteinander zu verbinden und schließlich auch
44
Fernsehprogramme zu verteilen.
Der Grund zur damit erfolgten Abkehr vom Leitungsvermittlungsprinzip á la Telefon
oder ISDN war die Forderung nach Flexibilität: Ein fester Ka−nalmix beim Teilnehmer
erschien bei unbekanntem Zukunftsbedarf zu rigide; die festen Kanäle wurden durch
virtuelle − gebildet aus Zellströmen mit verhandelbarer Quality of Service − ersetzt.
Mit dieser Entscheidung ist der CCITT − jetzt ITU T − bis heute weder bei den
Videobroadcastern noch den Internet−Freaks sonderlich beliebt: Viele \xe3
Leitungsvermittlungs− oder Verteil−Leute" glauben heute noch nicht, daß bei den
Zeitanforderungen von Sprache und Video ein nennenswerter Multiplex−Gewinn − die
Summe der Teilkanalraten kann statistisch größer sein als die physikalische
Ge−samtrate der Übertragungsstrecke − zu erzielen sei. Den Datenleuten erscheinen die
ATM−Zellen ge−messen an den eigenen Riesendatenpaketen − z.B. 64 KBytes − doch
sehr klein; Internetter lieben zu−dem das Prinzip der virtuellen Kanäle/Verbindungen
beim ATM nicht.
Internet über ATM
Für das Internet erscheinen die ATM−Netze zu−nächst nur als weitere Infrastruktur,
über die das universelle IP plus TCP etc. transportiert werden kann; die Aufgabe heißt
dann IP on top of ATM. Probleme, die sich hierbei für das heutige TCP/IP ergeben, sind
etwa:
· Erhalt typischer LAN−zu−LAN−Eigenschaft: Ein typischer LAN− und
Internet−Nutzer er−wartet beispielsweise von einem Ethernet−Anschluß, daß er
möglichst einen hohen Prozentsatz der Medienbandbreite von 10 Mbit/s erreicht. Er ist
es nicht gewohnt zu − und könnte es auch üblicherweise gar nicht vor einem
Sendevorgang sagen: \xe3 Meine Workstation sendet jetzt mit 6 Mbit/s Daten"
· Schutz von TCP vor Cell−Verlusten:
Das moderne TCP − etwa mit Slow Start und Congestion Avoidance−Mechanismen −
reagiert empfindlich auf Cell− und damit Paketverluste − und Wiederholungen
· Management von virtuellen Kanälen
und Bandbreitenmanagement:
Virtuelle Kanäle, VCs, können in heutigen ATM−Netzen nicht dynamisch bei Bedarf
er−zeugt werden − das ergibt dann bei großen Netzen einen entsprechenden
Management− Aufwand; entsprechend muß ggf. auch die Bandbreite der
Übertragungsstrecke, z.Z. noch meist statisch, verteilt werden. Ließen sich VCs durch
Signalisierung dynamisch etablieren, hätte man ein neues Problem: Wofür lebten sie
wielange?
· Architektur−Modell −
Routing und/versus Switching:
Da bis auf weiteres die übergroße Mehrzahl der Rechner keinen direkten
ATM−Anschluß besitzt, und da für so gebildete Netze Router die Strukturen bestimmen,
45
ergibt sich die Fra−ge: Wie verhalten sich Internet Router zu ATM−Switchen?
· Security:
Von grundlegender Bedeutung sind desweiteren die heute in Routern auf IP− und
höherer Ebene implementierten Sicherheitsmechanismen, die z. Z. keine Entsprechung
in ATM−Switchen haben.
Nimmt man künftig die Bereitstellung von integrierten Diensten − Sprache und
Bewegtbilder − auch im Internet im großen Stil an, ergeben sich auch hier Fragen der
Garantien von Qualität durch Ressource−Reservierung. Dies soll künftig auf der Basis
von IPv6−Paketen(2) mit QoS−Feld zu lösen sein, die über ATM−Wege geführt werden,
die in einem integrierten Routing−Be−triebsmittel−Reservierungs−Vorgang auf
Cell−Ba−sis etabliert wurden. Dadurch erhält man eine
· Verdoppelte QoS Architektur:
ATM−Produktionsnetze
ATM in den USA und Europa
In den USA sind seit Anfang 1995 mindestens zwei für den deutschen
Wissenschaftsbereich wichtige Netze in ATM−Technologie in Betrieb genommen
worden: ESnet, das Netz des Department of Energy, hat nach mehrjähriger Verzögerung
− verursacht durch Klagen nicht zum Zuge gekommener Anbieter − endlich seinen
Betrieb als 155 Mbit/s ATM−Netz aufnehmen können. Das Netz umfaßt u.a. alle großen
Labs des DoE. ESnet ist langjähriger Partner des DFN−Vereins und nimmt in Princeton
deutschen Verkehr auf.
Das zweite im Kontext wesentliche Netz in den USA ist das vBNS, der very high speed
Backbone Network Service. Es ist in der Funktion \xe3 Verbindung der National
Supercomputer Centers"(3) Nachfolger des NSFnet Backbones; neben Cornell, NCSA,
San Diego, Pittsburgh umfaßt es auch NCAR, Boulder Colorado, das National Center für
Atmospheric Research. Es ist noch relativ stark forschungsorientiert und hat als
konstituierenden Bestandteil ein Programm von netzgestützten Projekten. Die
derzeitige Übertragungsrate im Netz beträgt 155 Mbit/s. Betrachtet man einen
typischen Teilnehmeranschluß, er−scheint der Plan, 1996 auf 622 Mbit/s zu gehen,
plausibel.(4)
In Europa sind derzeit z.B. die Forschungsnetze in Großbritannien − SuperJANET −
und in Frankreich − RENATER − im Kern oder weitgehend ATM−Infrastrukturen. Die
Verbindung der nationalen Forschungsnetze durch ein europäisches ATM−Back−bone
ist Gegenstand des TEN34−Proposals der in TERENA vereinigten entsprechenden
nationalen Institute (s. u.).
46
ATM in der Republik und im Land
In der Bundesrepublik hat der DFN−Verein den Aufbau von
Hochgeschwindigkeitsnetzen − nicht zuletzt aus Kostengründen − zunächst auf
regionaler Basis im Rahmen der sogenannten RTBs, der Regionalen Testbeds, verfolgt.
Im Rahmen des DFN−NOC am Rechenzentrum der Universität Stuttgart wurden seit
Februar 1995 die beiden Regionalen Testbeds NORD (AWI Bremerhaven, DKRZ
Hamburg, Universität Hannover, Universität Braunschweig) und NRW (DLR Köln,
GMD Birlinghoven, KFA Jülich, Universität Aachen, Universität Bonn und Universität
Köln) hinsichtlich des IP−Managements betrieben.
versitäten beim DFN−Verein Anschlüsse an das kommende B−WiN beantragt.
Parallel dazu hat die mit dem Aufbau des BelWü−ATM−Netzes beauftragte Firma CNS
und die Universität Karlsruhe am 12. März diesen Jahres − testweise und als erste − die
Strecke Karlsruhe − Stuttgart in 155 Mbit/s ATM− Technologie in Betrieb nehmen
können.
ATM an der Universität Stuttgart
ATM−Produktionsnetze werden an der Universität Stuttgart evolutionär erscheinen −
etwa mit neuen Gebäudeverkabelungen oder der Verstärkung zu schwacher
Netzelemente − d.h. i.A. unsichtbar für den typischen derzeitigen Netznutzer. In dieser
Absicht wurde inzwischen eine 622 Mbit/s ATM− Verbindung zwischen dem Campus
Pfaffenwald und Untertürkheim(5) getestet.
Inzwischen hat der DFN−Verein die Aufbauplanung für ein flächendeckendes
Breitbandnetz, das dann auch die derzeitigen RTBs umfassen wird, erfolgreich
weitergeführt, und auf der CeBIT ‘96 konnte bekanntlich das Breitband−WiN feierlich
eröffnet werden. IP über ATM ist dabei der erste wesentliche B−WiN Dienst. Auch er
wird von Stuttgart aus gemanaged.
Seit Frühjahr 1993 betreibt das Land Baden−Württemberg ein Vorhaben zur
Aufrüstung des BelWü−Kernnetzes auf ATM. Die anlaufenden
Liberalisierungsbewegungen haben dieses Vorhaben sowohl befördert als auch
erschwert. Das Ministerium für Wissenschaft und Forschung hat nun kürzlich als
Eingangsstufe für die Landesuni
ATM bis zum Endteilnehmer wird wegen der eingangs genannten Problematik im
Management− und Sicherheitsbereich wohl lange Zeit vorwiegend in experimentellen
oder projektorientierten Infrastrukturen vertreten sein.
ATM−Pilot−Infrastrukturen
für nationale & internationale Projekte
47
SMDS über ATM im 3. Rahmenprogramm der EU−RACE
und ESPRIT
Wir verweisen hier zunächst auf das Angebot aus unserer Benutzer Information BI. 2
95, S. 7, allen potentiellen Projektplanern bei der Herstellung von \xe3
Pilot−Netzverbindungen jeglicher Art" − insbesondere aber solchen in ATM−Technologie
− beratend zur Verfügung zu stehen.
ATM im 4. Rahmenprogramm der EU−ACTS, ESPRIT,
Telematics und das G7−Thema
Der europäische ATM−Pilot endete formal am 31. Dezember 1995. Derzeit gibt es unter
den Na−men JAMES, NICE und TEN34 drei Projektvorschläge der jeweiligen
natürlichen Klientel von DG IIIF (ESPRIT IT), DG XIIIB (RACE/ACTS) und DG XIIIF
(Telematics), die auf die Aufrechterhaltung einer ATM−Pilot− und Test−Infrastruktur,
auf ein Produktionsnetz (Verbindung der nationalen Forschungsnetze) oder auf eine
Kombination von beidem zielen. TEN34 wurde inzwischen un−terschrieben. Das RUS
arbeitet in einer entsprechenden TERENA Arbeitsgruppe zu Service−Tests im TEN34
Rahmen mit.
Schon zur Frühjahrskonferenz der G7(6) 1995 in Brüssel wurde als Thema II von XI−en
die Global Interoperability for Broadband Networks als Aufgabe formuliert und gleich
praktisch vorgeführt.(7) Von Berlin über Hamburg−Helgoland−usw. de−monstrierte
Kanada mit der Deutschen Telekom/DeTeBerkom über den 155 Mbit/s−ATM−Link der
Firma TELEGLOBE Videoanwendungen und Te−lemedizin.
Diese Verbindung wird innerhalb der ACTS−Vorhaben AC039, CASHMAN und AC089,
DVP u.a. zwischen Deutschland (u.a. GMD), Kanada und den USA (NCSA, UCB)
verwendet werden. Deutscher Kontaktmann für das Thema II ist Herr Ullmann vom
DFN−Verein. Aus der Sicht von ACTS sind dabei alle Infrastrukturen unter dem
Stichwort Nationaler Host zu betrachten.
Das RUS hat den TELEGLOBE Link am 29. Feb−ruar bei der Einweihung des Bremer
Landesnetzes zusammen mit der Daimler−Benz Aerospace Airbus und dem kanadischen
BADLAB in Ottawa zu einer Demonstration in Collaborativer Simulation und
Visualisierung (System COVISE) ge−nutzt.
Das RUS ist in einem der drei deutschen und zwei US−amerikanischen (PSC, Sandia)
GIBN−Demonstrationsproposals vertreten. Diese werden z.Z. auf der laufenden
G7−Conference in Süd−Afrika verhandelt.
ATM in der Republik
Auch in der Republik endete die Pilotphase des Telekom−ATM−Netzes am 31. Dezember
1995. Es wird davon ausgegangen, daß das Netz ab 1996 zu kommerziellen Bedingungen
zur Verfügung stehen wird. Diese werden voraussichtlich stark dadurch beeinflußt
48
werden, daß nach der jetzt erfolgten Genehmigung der deutsch−französischen
Telekom−Kooperation ATLAS durch die EU, Deutschland verpflichtet wurde, schon ab
dem 1. Juli 1996 anderen Netzanbietern (Bahn, Energieversorger etc.) Netzlizenzen zu
verleihen. Neben der Telekom und dem DFN−Verein, für den die Verleihung praktisch
erfolgt ist, werden also voraussichtlich bald weitere Anbieter auf dem Netzmarkt
auftreten.
Schließlich wird auch der DFN−Verein nach einer Eingangsphase im B−WIN neben dem
Produktions−IP/ATM−Netz schrittweise reine ATM−Verbindungen − vorzugsweise für
Projektvorhaben − an−bieten.
An das Telekom−ATM unterhält das RUS seit September letzten Jahres einen 155
Mbit/s−Pilot−Anschluß. Er wird/wurde in den an− und auslaufenden RACE, Telematics,
ACTS und ESPRIT−Vorhaben sowie zur RACE/ACTS National Host− Konferenz in Wien
in der zweiten Novemberwoche 1995 und der TELEGLOBE−Demonstration eingesetzt.
Mit der gebotenen Vorsicht wiederholen wir hier unser Angebot bezüglich der
Etablierung von Pilot−Netzverbindungen.
ATM im Land
Das ATM−basierte Landesforschungsnetz BelWü als Teil des o.a. B−WIN wird in erster
Linie ein Produktionsnetz sein − gleichwohl sollte es u.E. für Projekte möglich sein,
dieses Netz nach ge−eigneter Absprache auch als Projektinfrastruktur zu nutzen −
vielfach wird das ohnehin kein Widerspruch sein.
ATM an der Universität
Seit Ende 1992 betreibt das Rechenzentrum ein lokales ATM−Pilotnetz, das schon zur
CeBIT ‘93 im Rahmen der RACE−Vorhaben CIO und PAGEIN über das VBN
demonstriert wurde.
Dieses Netz wurde im Februar 1995 mit dem des IPVR verknüpft. Im September war
dieser Komplex dann über die o.a. 155 Mbit/s−Verbindung zum Feuerbacher
ATM−Knoten der Telekom mit Partnern des RACE CIO−Projektes in Darmstadt, Berlin
und Zürich verbunden. Gegen Ende 1995 fanden weitere Einsätze in EU−Vorhaben
statt. Für gemeinsame Vorhaben mit Universität und RUS in
Sonderforschungsbereichen und EU−Projekten wird als nächstes das ausgedehnte
ATM−Netz verschiedener Institute der Fraunhofer Ge−sellschaft in Stuttgart in die
Pilot−ATM−Infrastruktur einbezogen werden.
Für das Remote−Microscopy−Vorhaben ZELLKOM des Instituts für Physikalische
Elektronik, IPE, wird derzeit nach dem Aufbau eines ein zu−nächst lokalen
ATM−Testbeds eine Wide Area−ATM−Verbindung zum Projektpartner in
Karlsruhe−Rüppur realisiert. Diese Arbeit wird auf der Karlsruher Seite auch vom
dortigen Rechenzentrum unterstützt.
49
Innerhalb des Umweltinformationssystems Ba−den−Württemberg (Umweltministerium,
Institut für Kernenergie und Energiesysteme) soll in Absprache mit der Stabsstelle I &
K des Innenministeriums eine schnelle Verbindung zur Universität ebenfalls in
ATM−Technologie realisiert werden. Entsprechend wird die Stuttgarter mit der Zürcher
Architektur über das internationale ATM kooperieren.
Insgesamt werden in diesem Jahr für bereits be−willigte oder neu zu beantragende
EU−Vorhaben ATM−(Pilot−)Verbindungen für Partner in fünf bis zehn internationalen
Projekten benötigt werden.
ATM F&E
Das RUS hat sich in Fortsetzung seiner seit 1984 bestehenden Kooperation mit der
Firma Hirschmann(8) an der Entwicklung einer Ethernet−zu−ATM−Box beteiligt,
HiATM. Die Hardware des ATM−Subsystems − eine Shared Memory−Konstruktion − ist
fertiggestellt. Derzeit wird das Sys−tem mit Software ausgestattet: Betriebssystem,
Signalisierung (Dritthersteller) etc. Im Landes−Forschungsschwerpunkt−Programm
wurde im Rahmen des Vorhabens USPS der Übergang von Gigabit−LANs zu ATM
untersucht (IND, INÜ, IPVR, IMS, RUS). Über das IND ist das RUS Mitglied im
ATM−Forum. Für den DFN−Verein hat das RUS eine Eingangskonfiguration erarbeitet.
Ausblick
Nach vielen Jahren direkter und vielfach indirekter Vorarbeit des Forschungsbereiches,
globalen Entwicklungen wie der Deregulierung und Liberalisierung der
Telekommunikationsmärkte verspricht 1996 wirklich den Beginn globaler
Breit−bandkommunikation − auf der Basis von ATM.
Literatur
[1] Anthony Alles: ATM Internetworking,
May 1995.
http://cio.cisco.com/warp/public/614/12.html
Informationen zu
· B−WiN: Peter Merdian
· Campus−ATM: Horst Bannas
· HiATM: Chris Copplestone
· USPS: Peter Haas
· Internationales/Telekom ATM: Peter Feil
50
· ATM Traffic Management etc.: Robert Stoy
Paul Christ
Kommunikationssysteme &
BelWü−Entwicklung
[email protected]−stuttgart.de
The University of Stuttgart −−
A Future−Oriented Place of
Research and Teaching
Compared with Germany’s traditional univer−sities, the University of Stuttgart is
rather young: founded in 1829, the former Technical College has integrated the social
sciences and the humanities and has developed to become an internationally renowned
future−oriented place of research. The close interconnection of re−search and teaching
makes it possible both to provide a very good education for students who aim for
positions in business, government and science, and to hold a top position in basic and
applied research. Furthermore, the university with its 140 institutes distributed over 14
faculties, 5,000 employees (about 1,700 of them paid by external sponsors), and about
21,000 students −− among them 2,900 young men and women from all over the world −−
is an important influence in Baden−Württemberg, Germany’s traditional high−tech
region.
Every year about 1,800 students graduate from the University of Stuttgart. Apart from
that, some 150 apprentices in 30 trades are trained in the workshops, laboratories and
the computer centre of the university.
The annual budget of the university in 1994 amounts to DM 513 million −− not counting
construction costs. DM 200 million of this amount are provided by public and private
sponsors for research projects. 40 per cent are provided by industry, about 20 per cent by
the Ministry of Research and Technology, 12 per cent by the "Deutsche
Forschungsgemeinschaft", and special research projects take up 10 per cent. The
remaining funds are brought in through the European Union, the Government of
Baden−Württemberg, the Federal Government, and others. In terms of contract−based
research, the University of Stuttgart holds a top position among German universities −−
a consequence of efficient research and management of science.
The University of Stuttgart is divided into two campuses linked by a speedy
underground train: Stadtmitte (downtown) and Stuttgart−Vaihingen. In the vicinity
there are also a number of Institutes of the Max−Planck− and Fraunhofer−Societies, and
the German Research Institute of Aerospace Engineering. The university’s openness and
interest in cooperation can also be seen in the close interrelation with about 20
additional institutes. Many companies take advantage of the facilities of the university
as clients: examples are the wind tunnel for the testing of automobiles in which the
aerodynamics of new models is tested 1:1 at velocities of 255 km/h, or the super
computers of the regional computing centre (RUS) for the simulation of crash tests,
51
meteorological data or the spread−ing of toxic materials in the atmosphere.
An important feature of the University of Stuttgart is its combination of a primarily
applied and theoretical−experimental orientation. Excellent conditions exist for both
areas of activity. The foremost aim in research and teaching lies in the fields of
engineering and the natural sciences. Personalities like the philosopher Friedrich
Theodor Vischer, literary scholar Fritz Martini, philosopher of science Max Bense or
literary scholar Käte Hamburger were responsi−ble for the formation of the social
sciences and the humanities at Stuttgart.
There are many interconnections with the city of Stuttgart and the surrounding area:
the university is an important economic factor, since it employs 5,000 men and women
and provides innovative impulses to research and technology. In addition, graduates of
the university contribute to the economy and industry of the middle−Neckar−region.
The following pages will give you an overview of the different areas and services at RUS,
which are:
· Belwü Coordination
· Information Services
· High−Performance Computing
· Server & Networks
· Basic Services
· Projects of RUS
BelWü Coordination
In the context of the BelWü Coordination the following services are provided through
TCP/IP: the wide area network access to the University of Stuttgart, the wide area
network access of more than 70 members of the regional network BelWü
(Baden−Württembergs extended LAN), and the wide area network access of german
members of DFN−IP by order of DFN through the DFN NOC.
The following lines are currently used at the University of Stuttgart for WAN access:
· 34MBit/s BWiN (ATM) to reach the german and international IP networks
· several 2 MBit/s and 64 KBit/s leased lines to directly connected BelWü members in
Stuttgart region.
Currently over 70 members are connected via BelWü to each other. The switched IP
traffic amounts to more than 1700 GByte per month (see figure). The BelWü backbone
52
consists of about 70 Cisco routers (see figure) which are managed centrally from
Stuttgart but in close cooperation with the local BelWü contact of each member.
This implies that fault and performance status of the network is monitored all the time,
respon−sible people for the management at the network are available, and network
services are centrally offered and coordinated. Besides the man−agement of the IP level
the second crucial point of networking is the support of the BelWü mem−bers with
essential network services. This in−cludes the operation and control of primary and
secondary name−servers for about 900 domains of more than 40 BelWü members as well
as the X.500 DSA for the University of Stuttgart, the operation of a mail−host (with
about 4 GByte mail traffic per month), and a SMTP/X.400 mail gate−way, the operation
of a stratum 1 time−server, the operation of a gateway into the civil service net−work
(Landesverwaltungsnetz LVN), the oper−ation of a telnet/X.29 gateway, the operation of
a news−server as well as the distribution of news feeds in BelWü, the provision of a
WWW and ftp server, the provision of teaching software, hand−books and a user
magazine, the provision of lectures for end−user, the guidance of network administrators
of new BelWü members, and the assignment of IP network addresses.
Since late 1993 the DFN NOC is located at the BelWü Coordination. The DFN NOC
provides basic IP services for the german scientific and research community.
For more information please contact:
Peter Merdian
Tel. 0711/685−5804
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Tab.\x11 1:\x14
Belwü Traffic Matrix December 1994 (IP
Traffic in MByte)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Freiburg Heidelberg Hohenheim Karlsruhe Konstanz Mannheim Stuttgart Tübingen
Freiburg
875
72
2177
3201
133
66273
896
Heidelberg
875
180
14591
487
5503
16550
1203
Hohenheim
72
180
472
206
17
16086
100
Karlsruhe
2177
14591
472
738
12204
49093
1331
Konstanz
3201
487
206
738
365
15070
1026
Mannheim
133
5503
17
12204
365
22941
137
Stuttgart
66273
16550
16086
49093
15070
22941
32849
Tübingen
896
1203
100
1331
1026
137
32849
Ulm
226
710
51
15167
176
168
30327
321
FH/BA/etc.
582
1866
265
17284
1041
15771
64034
2745
Kaiserslautern 375
1012
137
10444
210
432
5132
153
Rest BRD
15227
75209
3193
131475
5753
20599
349617
23988
Europa
1710
8495
727
4470
848
1465
71133
1332
Oversea
30074
47594
7959
56969
9640
16282
171052
25310
Total
121841
174849
29486
316758
38795
106555
912220
91616
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
53
Information Services
The complexity of computing environment and the network as well as the variety of
services require appropriate information management.
Main Tasks
The information services of the RUS cover four main areas
· Systematic distribution of information and know how
· Support the users to exploit the information resources in the net
· Distribution of software
· Costumer feedback and evaluation of critics.
Due to the number of users, massive electronic support is necessary to deal with the
need for information.
Beside electronic information traditional channels are maintained and further
developed.
Information Channels
From the needs of our users result three differ−ent information channels:
· Training and consulting
− Courses (40/year − 1200 part.)
− Mini courses(120/year − 2500 part.)
− Helpdesk (40 hours per week)
− Online helpdesk (project)
− Support and develop communication between RUS and costumers
− Learning systems
· Print media
− BI. − User magazine (10 issues)
54
− Posters
− Publications (handouts, etc.)
· Computer based information
− Information and software server
WWW (25.000 users/M)
gopher, telnet
aftp (120000 Acc./M, 130 GB transfer)
− News, mailing lists.
The various information channels are coordinat−ed to bring best results.
Software Distribution
Beside the distribution of public domain software via aftp we took over in 1993 the
distribution and of licensed software at large scale.
Fig.\x11 1:\x14 WWW−Page: BI.
A student’s project for distribution of ready to use installed software became the base for
the software installation concept of RUS. In meantime this project was funded by the
Ministry of Research to make available software at large scale in the country of
Baden−Württemberg. The project will be funded from DFN−Verein for two years.
Multimedia Services
Multimedia services as e.g. learning systems or multimedia labs are provided or
planned.
Marketing
One of our biggest challenges is to inform our costumers about the existence and quality
of our services.
In this context it is necessary to treat information as a product. The evaluation of
costumer needs and the adaptation of our services to the needs a highly important point
as well as the public relations for our products.
Projects and Research
Projects and research help us to reach the objective to support costumers a our best.
55
Two PHD thesises with the following subjects will be finished in 1994/95:
· Feature structures for unification based generation of navigation structures in
document space
· Multimedia learning in an object oriented simulation environment.
The following proposals are accepted by DFN−Verein:
· /sw − Software installation concept
(1 MY + 1 MY for University of Tübingen)
· Distributed scientific network publishing (2 MY + 2 MY for Library University of
Stuttgart)
· Online helpdesk (2 MY + 1 MY for Universities of Mannheim and Konstanz).
Access
· http://www.uni−stuttgart.de
· ftp.uni−stuttgart.de
· gopher.uni−stuttgart.de
· news.uni−stuttgart.de
· Modem connection: ++49−711−685−7712
· Win Datex−P: NUA 0262 45050 966911
· EuropaNet: NUA 0204 3623 966911
For more information please contact:
Barbara Burr
Tel. 0711/1319−111
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
HIGH−PERFORMANCE COMPUTING
Numerical Mathematics
56
Development
of Algebraic Multigrid Techniques
Uwe Küster, Manuela Zürn
Algebraic Multigrid techniques are useful if there exist not enough information on the
underlying problem. They also give insight in the problems arising in conventional
multigrid approaches in sense of construction of restriction, prolongation and coarse grid
operator.
The techniques used by Stüben and Ruge in calculation of these operators make the
assumption that the given matrix is a M−Matrix. We replace this by analysing SPD
matrices which are a sum of some smaller SPD matrices like element matrices for the
stiffness matrix in the Finite Element context. Based on this we formulate a theory for
the two grid algorithm which covers also shell elements stiffness matrices.
Coding these algorithms is a difficult task caus−ed by the dynamic behaviour of the
generated data objects. Our Fortran 90 object oriented implementation allows handling
objects like sparse sum of matrices, dense matrices, partial sums of matrices, sparse
matrices with methods like *, +, Schur Complements. LAPACK routines can be called
via operators.
In distributed interactive graphical interface based on Tcl/Tk shows matrix properties of
se−lectable parts of stiffness matrices.
Numerical Simulation
of Blood Flow on Supercomputers
Michael Resch
Simulation of blood flow in large arteries is a tool for risk assessment in atherosclerosis
and for assessment of flow behaviour in artificial vessels or an artificial heart. So far it
was based on simple Navier−Stokes models assuming a constant viscosity. More
sophisticated models have taken into account a shear−rate dependent viscosity, which
only slightly changed the Navier−Stokes model.
The project under development is based on models and data gathered from rheological
measurements. Such investigations show that blood exhibits more complex properties
(like shear−thinning and elasticity). To take into ac−count such effects a model from
theory of viscoelastic fluids (modified Maxwell model) is chosen. Such models are
characterised by the Weissenberg number which describes the in−fluence of elasticity.
So far classical methods fail to work for increasing Weissenberg numbers. The challenge
of the project is to partially overcome this problem and solve for increasing Weissenberg
numbers.
This requires more complex solution methods as used in aerodynamics and increases the
number of Ps per gridpoint by a factor of 2 for 2D−problems and 2.5 for 3D cases.
57
Nu−merical simulation of blood flow thus requires supercomputing performance both in
terms of MFLOPs and in terms of main memory.
Solution of Conservative Equations on Unstructured
Grids with Arbitrarly Complex Cells
Clemens Helf
Today, the bottleneck of industrial flow simulation for complex technical geometries is
grid generation and grid adaption. In the same time flow solvers require high quality
grids to compute accurate solutions.
The project CEQ (Conservative EQuation solver) gives a new approach by completely
gener−ating the grid during the flow calculation on the base of a single multiply
connected cell. The description of the problem geometry serves as an initial grid.
Self−adaptive refinement divides arbitrary cells along arbitrary hyper−planes. Special
techniques fit existing nodes and limit the complexity of resulting cells. Multiple flow
features are captured by controlling refinement by location and direction. The numerical
technique is a second order ENO like explicit Finite Volume scheme and is capable of
producing accurate solutions on these complex grids. Formulas for computation of
volume, centroid and all others moments of arbitrary polyhedra are implemented.
The object oriented implementation allows handling of 2D as well as 3D problems. The
code is written in C++. The grid database part can be used for other time dependent
conservative equations. The data structures allow vec−torization of the computationally
intensive parts in principle. The complete code including refinement is parallelized on
base of DDD. Automatic dynamic load balancing will be provided. Visualization will be
done by a special project.
The program is now working in 2D. 3D refinement is in progress. Navier Stokes
equations will be implemented in the near future. Parallelized multi grid techniques will
be implemented.
Dynamic Distributed Data:
An Efficient Programming Model for Parallel and
Adaptive Algorithms
Klaus Birken
Parallelizing computational intensive algorithms based on dynamic data structures (e.g.
adaptive PDE solvers) will often be doomed to failure if one does heavily rely on pure
message−passing layers as the basic access point to the parallel hardware.
Various problems as for data redundancy, con−sistency and load balancing can only be
tackled using an appropriate level of abstraction. With Dynamic Distributed Data (DDD)
this abstraction is available on a fine−grain object level. DDD provides a dynamic
58
representation of data graphs, transfer operations of any set of objects and abstract
interfaces across local−memory borders.
Usage of DDD will result in parallel applications, which are efficient and portable. The
changes of the sequential code are minimal; complex real−world examples could be
parallelized within a few days.
Distributed Visualization
of Arbitrary Unstructured Grids
Thomas Schmidt
Computational simulations for complex geometries nowadays often deal with
unstructured grids. That’s why scientific visualization must also be extended to these
grid types. A visualization system is presented which works with any type of
unstructured grids, i.e. arbitrary polygonal and polyhedral grids. Results from finite
volume (cell centered) and finite element methods can be visualized. Additionally
time−dependent data can be processed and interpolation between timesteps is possible.
This data may be transferred directly from a simulation program and therefore on−line
visual−ized. To integrate this task into a computational simulation an object−oriented
interface is presented which allows easy connection from simulation to visualization.
This interface also provi−des a connection to the technical database sys−tem RSYST.
Therefore it is possible to read grids and initial data from the database and write results
back to it. Preprocessing, CAD and other moduls can be accessed on this way.
Esprit Project
Parallel Aero of Europort 1
Uwe Küster, Manuela Zürn
In this Esprit project a Multi Block Navier Stokes Solver has to be parallelized and
tested on differ−ent platforms. CERFACS/France, KTH/Sweden, Cira/Italy,
EPFL/Switzerland, SAAB/Sweden, Aerospatiale/France, and RUS/Germany are the
partners.
For more information please contact:
Uwe Küster
Tel. 0711/685−5984
Fax 0711/6788363
E−Mail: [email protected]−stuttgart.de
59
Parallel Computing
Although RUS started not before 1992 in offer−ing MPP services, activities in this area
go back into the mid−80s, mainly based on workstation−clusters. The reason for a start
at that time was, that earlier there were no systems available, which had the flexibility
to serve a large user−community with very heterogeneous interests. As a first platform,
a workstation−cluster (PARIS) dedicated to parallel computing was offered to a
restricted user−group in aero−thermodynamics. This was followed soon by an intel
Paragon XP/S−5 as representative of a new generation of MPPs with a very flexible
model of operation and usage. In 1994 a Cray T3D joined the other two platforms,
expanding the services especially in the area of novel programming−paradigms and of
more fine−grain parallelism. Already from the beginning it was obvious, that
user−support in the area of parallel computing must by far exceed the classical services
of a computing centre and must in most cases have the form of a project−partnership. In
consequence the in−stalled systems up to now were also acquired in the framework of
cooperation between several institutions:
· intel Paragon: RUS, ICA II, IPVR
72 Compute−nodes
Peak−Performance 5 GFLOP/s
Memory 2GB
− Software:
NX, PVM, MPI, PARMACS, APR−HPF, PGI−HPF, ProSolver, Paragraph
· PARIS: RUS, SFB 259, DLR, IBM
Cluster of 6 RS/6000−550
Peak−Performance 0.5GFLOP/s
Interconnected via SOCC, FDDI, Ethernet
− Software:
PVM, PVM/6000, NXlib, MPI, FORGE90, Paragraph
· Cray T3D: RUS, ICA III, Cray Research
32 PEs DEC 21064
Peak−Performance 5GFLOP/s
Memory 2GB
− Software:
PVM, CRAYPVM, CRAFT, TotalView, Apprentice.
An additional step for the embedding of projects was the foundation of the Stuttgart
competence centre for high−performance computing which was established in 1993. All
central−institutes of Stuttgart University in the field of supercomput−ing are
participating in this organisation.
The parallel−computing activities in the beginn−ing primarily dealt with
code−development. This means first of all the development of new meth−ods for parallel
60
computers and second porting of existing sequential codes. Today we are one step
further. First production−codes are running on MPPs. With one relevant commercial
code, LS DYNA3D, we had already a reasonable initial success, as well concerning pure
power, but also the economical solution of problems. The following diagram illustrates
for a car crash example, which additional efforts between system−manufacturer,
software−provider and end−user is still needed for the successful use of parallel systems.
Over a timeframe of half a year the diagram explains which actions led to which gain in
performance and cost−effective−ness. As can obviously be seen, the initial parallel code
was neither efficient from the pure calculation times, nor from the economic perspective.
Especially it was not at all competitive with the Cray C90 as representative of the
classical vector−supercomputers. Through optimization and further development on the
system − as well as on the application − code side however a much more cost−effective
solution (factor 3) than on the vector−machine could be achieved.
As consequence of the results of the last years, the next step will be the establishment of
a powerful MPP−service for production. The de−partment for parallel computing consists
actually of 2.5 scientists (1 staff, 1.5 paid from projects) and 5 students. Apart from the
projects, which are all coming from the field of computational fluid dynamics, the main
task is user−support and, together with onsite engineers from intel and Cray, keeping
the machines running.
For more information please contact:
Dr. Alfred Geiger
Tel. 0711/685−5391
Fax 0711/6788363
E−Mail: [email protected]−stuttgart.de
Visualization
The Visualization Department of RUS provides services to convert and visualize results
of simulations and experiments for the understanding of scientific models and content.
These services cover the operation of high end graphics workstations, video equipment,
plotters, printers, slide recorders, etc.. Currently a visualization and a video lab are
maintained, which comprise centralized equipment that is too expensive or specialized to
be established at an institute.
A broad variety of software packages is support−ed and used by the visualization
department.
Fixed staff members are involved in these services, 3 for video production, 2 for
plot/print equipment operation and graphics software. 1 for coordination of the
visualization based support tasks, handled by student support workers, as well as the
operation of the visualization equipment.
61
Video
Fig.\x11 1:\x14 Video Lab
For video production purposes Wavefront Advanced Visualizer, Wavefront Composer,
Xaos nTitle, Utah Raster Toolkit, SDSC tools, etc. are used.
The video group operates a Broadcast Quality Studio based on Betacam devices to
produce video animations with story board production planning, titling, narration and
sound. An important service is consulting in video production ranging from timing of
scenes, attribute se−lections (e.g. font type/size, line thickness, etc.), colour selection and
balancing, scene propor−tions, usage of edit suite capabilities (cut, fad−ing, zoom,
overlay, colour/chroma key usage, etc.). Video cameras and lighting are used to record
live experiment at institute or industrial partner sites. These scenes are typically
com−bined with computer generated visualization to compare simulation and
experiment.
Visualization
Fig.\x11 2:\x14 Visualization Lab
For high end visualization purposes supported packages are IBM Data Explorer, SGI
Iris Explorer, Application Visualization System AVS, Ensight (previously Cray MPGS),
and Wavefront Data Visualizer). For plot oriented output generation Uniras, Tecplot and
IDL are used.
Support based on these packages ranges from the conduction of courses, individual
consulting and support in the usage of visualization pack−ages to the establishment of
small projects to−gether with users to help them handle their tasks. Typical cooperation
with users range from days to months. In longer projects user algorithms are embedded
in specialized modules which are included in module networks also produced in
cooperation with the user. Part of such projects are the production of sequences of single
video frames for video production.
In addition Users can bring their graphics orient−ed software on the workstations of the
visualization lab either to make use of graphics hardware for better interactivity or for
online video record−ing of workstation sessions.
Additional support is provided via the relocation of a member of the State Material
Testing Institute into the visualization department. He pro−vides expertise and support
in the usage of AVS. The support for AVS based on a state wide licence agreement will
be done by the RUS visualization department for all Baden−Württemberg Universities.
62
Projects
To introduce new developments from scientific visualization research and development a
close cooperation with the Institute for Computer Applications Department of Computer
Simu−lation and Visualization (ICA/CVS) has been established. One staff member of
ICA/CSV is permanently allocated to the RUS visualization department.
Research covers the development and implementation of algorithms and visualization
meth−ods with a special aim to make optimal use of the available parallel/vectorizing
hardware together with the high speed network infrastructure.
Publication of papers, participation to conferences and teaching of visualization lectures
as well as the cooperation with other partners in projects adds to the effort to bring the
leading visualization developments into RUS. Via these efforts additional stuff members
are sponsored from different project frameworks. The projects and their research and
development efforts are:
· Participation to the RACE project PAGEIN. RUS has the leading role in the
development of COVISE (Collaborative Visual Simulation Environment). Currently
PAGEIN developments are introduced at industrial partner−sites (Dassault/France,
Alenia/Italy, CASA/Spain)
· Participation to ESPRIT’s project ADONNIS. Cooperation on a European scale using
high speed network infrastructures. Our part of experiments consists of a cooperation
with Daimler Benz Aerospace Airbus to integrate their CFD code MELINA into COVISE
to perform collaborative simulation and visualization
· Participation in a collaborative research project of the Universities of Stuttgart and
Tübingen "Methods and Algorithms for the Simulation of physical Processes on High
Performance Computers". RUS−VIS is in−volved in 2 subprojects "Interactive
Visualization of 3D−Data on adaptive Grids using Parallel Computers" and
"Visualization of four dimensional bended Space Time"
· Participation in a collaborative research project of the University of Stuttgart "Rapid
Prototyping in new Product Developments" with a project on "Development and Test of
innovative Products − Rapid Prototyping". RUS−VIS is involved in 2 sub−projects
"Visualization and Simulation of physical and technical Processes"
· One PHD student on a research grant work−ing on "Design and Implementation of a
parallel Volume and Surface oriented Renderer"
· One PHD student on a research grant work−ing on "Multimedia Functionalities for the
Comparison of experimental Data and Simulation Visualizations".
The German Research Network Organization (DFN−Verein) sponsors regional testbed
activities. In this framework 2 projects will start in April with a 2 years duration. These
are:
63
· "Distributed Virtual Reality Laboratory Ba−den−Württemberg". A cooperation with the
Max−Planck−Institute for biological Cybernetics and the Institute for Theoretical
Astrophysics both in Tübingen
· "Distributed Numerics Lab Baden−Württemberg". A cooperation with the Institute for
Nu−merical Mathematics of the University of Freiburg.
Thus, based on external funding the Visualization department currently has 6 additional
staff members.
The involvement in education leads to semester and diploma works done by students.
These works are supervised by staff members.
The participation to steering committees, conference programme committees, etc. is part
of the activity to establish close relationships and co−operations with scientists and
developers in the fields relevant to scientific visualization.
For more information please contact:
Dr. Ulrich Lang
Tel. 0711/685−5995
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Communication Systems
BelWü Development
The Department CS−BD
Communication Systems and BelWü Development of RUS is a project oriented group
pursu−ing − in close cooperation with the LAN−department and the BelWü−operations −
the following three major tasks:
LAN − WAN
Acquiring and running communication oriented leading edge projects − especially at the
border between public wide area and local area network infrastructures.
Since 1984 LAN−WAN does co−operate with the Hirschmann company and has
participated in the development of the first electro−optical Ethernet worldwide providing
then for the early campus backbone.
Local high−speed network infrastructures have been pioneered in Europe such as
HYPER−channel, UltraNet and real FDDI.
64
At present a medium−size HiPPI production network is researched.
An experimental ATM−LAN was established.
Since 1987 Remote Ethernet Bridges and Mappers 140Mbit/s PDH−to−Ethernet/FDDI
data streams have been developed − used in nu−merous demonstrations and pilot
productions: An FDDI−ring Stuttgart−Karlsruhe is still based upon these developments.
At present, HiPPI−to−ATM and Ethernet−to−ATM systems are under development.
In 1991 one of the two Metropolitan Area Network trials of DBP Telekom was brought to
Stutt−gart − together with the Porsche AG and Daimler−Benz AG. 1993 wide area ATM
was demonstrated between Stuttgart and the CeBIT in Hannover. Since 1994
international ATM connections have been established and used within European
projects − in co−operation with DBP Telekom and international PNOs.
BelWü − Development
This function subsidizes the operation groups of the State Science Network BelWü −
Baden−Württemberg’s extended LAN.
Ethernet Bridges and PDH−to−Ethernet/FDDI mappers developed by LAN−WAN have
been used from the very beginning in BelWü.
New application types have been pioneered for future use in BelWü − examples are the
ESPRIT MICE project (Multimedia Integrated Conferencing for Researchers in Europe)
making intensive use of the multicast overlay of the Internet (MBONE) and RACE CIO
(Co−ordination, Implementation and Operation of Multimedia Teleservices.
At present, a technical framework document for the upgrade of BelWü to 155 Mbit/s
ATM is under development.
Projects
This function deals with project creation and coordination in general − both externally
and internally.
Projects maintains close relations to all relevant funding bodies − within the University,
the State, the Federation and the European Union. Special treatment is also given to
DBP Telekom.
RUS projects are typically vertically integrated ones − technology is always sold by
end−user applications. Typical of this approach is the co−operation between networkers
and visualization people in RUS projects − exemplified within the ongoing RACE
PAGEIN and ESPRIT ADONNIS (collaborative distributed simulation/visualization).
65
It was within these projects, that for the first time a European border was crossed by a
more than 2 Mbit/s link!
At present − January 1995 − the next European and German DFN projects are under
preparation. Within this context, Projects has success−fully urged other State
infrastructure projects − a Video−on−Demand and a Digital Audio Broadcast project −
jointly to become part of the German National Host for ACTS within the 4th Framework
Programme of the European Union.
For more information please contact:
Tel. 0711/685−2515
Fax 0711/6787626
Web: http://www.uni−stuttgart.de
Application Support
Dr. Heinz W. Pöhlmann
Scientific computing has a long history at the University of Stuttgart. Since 1986, RUS
is providing extensive application support to its academic and commercial customers.
A team of specialists provides subject−specific consulting, licensing, installing and
maintaining software packages on various hardware plat−forms, with a focus on
supercomputers.
RUS consulting staff consists of scientists all having a university degree. Related to their
subject, they understand the research problems of the users and are also skilled in the
right selection and effective usage of the appropriate software and hardware platforms.
The scientific staff also provides efficient support in perform−ing scientific and technical
computer simula−tions. Furtheron, they support users from differ−ent application areas
to adapt their own programs to vector and parallel machines, to find right numerical
algorithms, to make use of par−allel architectures and to visualize their simulation
results.
Fig.\x11 1:\x14 Model based Analyses of Dispersion over complex Terrain, Institut für
Kernenergetik
This work often leads to close cooperation and common research projects with academic
and commercial customers. License contracts with commercial software vendors
normally include free access to those packages for academic users, but often charge
license fees for commercial customers using the software.
Major support areas include:
· Computer Aided Engineering
66
· Computational chemistry
· Integration of data, methods and models for scientific computing
· Computational Fluid Dynamics
· Graphics
· Mathematical libraries
· Numerical methods
· Optimization, vectorization, parallelization
· Structure mechanics
· Distributed applications using
DFN−Remote Procedure Call
· Visualization.
Fig.\x11 2:\x14 Velocity Distribution over the Surface of a Helicopter‘s Rotor Blades,
Institut für Aero− und Gasdynamik
Please find out more about these areas on special leaflets.
Computational Chemistry
The use of supercomputers in the area of computational chemistry has a long tradition
at the University of Stuttgart. Since 1986, one of the major application support areas of
RUS is computational chemistry.
Our Ph.D. chemist supports research chemists from university institutes and from
industry, understanding their specific research problems and their needs in scientific
computing. Often this leads to close cooperation and common research projects with the
partners.
Computational chemistry has very high demands in computer power, especially in the
number of cpu cycles, memory size and IO bandwidth. Currently, this can be provided
only to a several degree even with todays fastest supercom−puters. Since the
computational effort needed to do exact calculations out of theory scales to about N times
4, while N is the problem size, being direct proportional to the number of atoms in the
system under review, so called ab initio calculations are limited to relatively small
mole−cular systems with up to about 100 atoms.
Fig.\x11 3:\x14 Buckminsterfullerene
67
To overcome this situation, scientists early de−veloped algorithms which incorporate
more or less simplifications. Semiempirical molecular orbital and force field methods
normally lead to good approximative results, depending on the system under review.
With these methods, calculations on bigger molecular systems can be done. Force field
calculations only scale to about N squared, so that even huge biomolecules, like peptides,
proteins and enzymes can be simulated together with their dynamical behaviour.
All those areas are covered by computational chemistry codes supported directly by RUS
on the existing supercomputer platforms:
· CHARMm
· DISCOVER
· GAMESS
· GAUSSIAN 92
· GAUSSIAN 94
· MOLPRO
· MOPAC
· PATSEE
· SHELXS−86
· UNICHEM, including CADPAC, DGauss
and MNDO93
· X−PLOR
· XRAY−76.
For more information please contact:
Dr. Heinz W. Pöhlmann
Tel. 0711/685−5992
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Computer Aided Engineering
Norbert Ibold
68
Computer Aided Engineering (CAE) is the application of computerized methods during
the de−sign process of technical systems. The problem areas are diverse and demand the
use of com−prehensive and high−priced software packages that, depending upon their
hardware requirements, are either installed on the CRAY C94 or on workstations.
Typical supercomputer CAE applications are identified with the difficult areas of
accuracy, stability and convergence that characterize a solution to a multidimensional
and complex system.
Accuracy:
Even in studying the linear behav−iour of materials with small geometrical
deformations, the desired solution often appears with local high gradients. This requires
a fine−mesh network with many computational points to fully capture.
Convergence:
With existing nonlinearities e.g., elastic behaviour of materials, creep effects,
progressive crack damage, large geometric deformations or contact with frictional
processes, the desired answer is usually found with iterative and incremental
mathematical meth−ods. Convergence often only appears by using small load increments
and therefore requires much more computation power.
Stability:
Following a static analysis, there is often the wish to determine how a system’s
be−haviour will react under time−dependent loads. In order to arrive at numerically
stable solutions, in which the computational inaccu−racies must be diminished with
time, a small integration−time−step resulting in higher processing effort can be decisive.
Complexity:
The coupling of systems e.g., the interaction of a structure with its surrounding field, can
be described by the introduction of extra system matrices and/or an increase in the
dimensionality of the computational task.
Our commitments to the CAE supercomputing area embrace the provision and
maintenance of software, advice and execution of test computations for the planned
computation projects to be run on the CRAY. Access to the CAE packages for all our
users including the commercial users only requires a simple application to RUS.
Fig.\x11 4:\x14 Postprocessing of a Pump Body under internal Pressure, KSB AG
The following software packages are available on the CRAY C94 for mechanical CAE:
· ABAQUS: FEM package for mainly non−linear computations
69
· ANSYS: FEM package for universal problem areas
· LS−DYNA3D: FEM package for non−linear short−time dynamics (crash testing, metal
forming, airbags)
· MARC: FEM package for mainly non−linear computations.
Electromagnetic CAE computations can show many aspects of the field behaviour within
the limits set by the software’s ability to model the initial and boundary conditions,
within the limits given by the difficult areas indicated above and the available computer
performance.
Typical practical application domains are the design of electric motors, transformers and
micro−wave devices as well as computations relating to EMI, EMC and antenna
analysis.
Computations involving electromagnetic fields use the package:
· MSC/EMAS: FEM package for solutions to time−dependent 3D−Maxwell equations.
The generation of the input data for the pack−ages on the C94 as well as the display of
the resultant output data is carried out on workstations located at the users’ desks’.
They are fitted with powerful graphics hardware and are linked to the CRAY
supercomputer over a high performance network.
CAE Pre/Postprocessing is done using the following software packages:
· PATRAN: Pre/postprocessing for ABAQUS, ANSYS and MARC installed on the C94
· I−DEAS: Pre/postprocessing, analysis of linear static and dynamics
· CATIA: CAD/CAE/CAM package with many modules (e.g., robotics)
· MSC/ARIES: Pre/postprocessing for
MSC/EMAS on the C94.
The interface between the different Pre/postprocessing programs on the workstations
and the analysis tools on the supercomputer is currently realized via file translators.
Since the CAE workstation software is very ex−pensive, the Computer Centre tries to
obtain campus licenses in order to keep the costs down for the numerous academic users.
The software packages are procured and administered by the Computer Centre and only
made available to university institutions to which the RUS offers a central supporting
role.
In the postprocessing area there is comprehensive video equipment, in our visualization
de−partment, available. It can be used by all our commercial customers also, to provide
70
animations from the output data of the CRAY.
For more information please contact:
Norbert Ibold
Tel. 0711/685−5803
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Computational Fluid Dynamics
Martin F. Winter
The numerical fluid dynamics is one of the most computer−bound disciplines. Using the
funda−mental set of partial differential equations (the Navier−Stokes−Equations often
supplemented by turbulence models and the energy equation) general problems of fluid
flow are solved.
The solvable problem size is until these days really small with respect to the requests.
Never−theless the program development is pushed in an intense manner. The programs
are expanded in the direction of chemical reaction, combus−tion, interface problems
between fluid and solid, and more. The advantages of the numerical simulation
compared with the experiment are evident. For example, difficult or impossible
measurements can be replaced by computation.
Fig.\x11 5:\x14 Fluid Flow Simulation with FIDAP:
Vortex Pairing in free Shear Layer
For the solution of numerical simulation prob−lems in fluid dynamics together with their
various border regions, the computer centre offers different commercial simulation
programs.
The institutes of the university develop adapted simulation programs for special
purposes, as long as no commercial program is able to solve the problem. Some of these
developments are based on commercial programs.
While applying the simulation programs the computer centre offers intensive user
support. This support includes:
· Analysis of the physical problem
· Development of the mathematical model
· Description of the material properties
· Development of the mesh
71
· Adaption of the program
· Handling of the program
· Postprocessing
· Interpretation of the results.
Fig.\x11 6:\x14 Combustion in a Gas Motor/Flame Propagation, AVL GmbH
Moreover projects and tight cooperations with industry and institutes of the university
are carried out in numerical simulation.
The following commercial programs for fluid flow simulations are available:
Finite Volume Method:
· CFDS−Flow3D
· FIRE.
Finite Element Method:
· FIDAP
· FluxExpert.
For more information please contact:
Martin F. Winter
Tel. 0711/685−5532
Fax 0711/6788363
E−Mail: [email protected]−stuttgart.de
SERVER & NETWORKS
Workstation Concepts
The data processing concept of the University of Stuttgart is committed to a
heterogeneous open systems environment for scientific and educa−tional applications
based on Unix, in which certain well−known Unix workstation vendors should be
represented and hopefully also be supported.
Within this frame, the department for workstation concepts has the job to find, work on
and test computer− and operating systems, additional necessary and helpful software
subsystems or products as well as methods in distributed processing, networking, etc..
Interoperability is an important point herein. The gained knowledge will surely enable
72
RUS, to give campuswide information and support in selecting, installing, configuring,
operating and managing Unix workstations and subsystems for various vendors. An
important topic is the interaction between high performance computers and user
workstations in a highly distributed processing environment; one goal is here to achieve
an optimal working with supercomputers by client/server concepts.
This knowledge on different Unix workstations should lead to a standardization of
general and wide−spread Unix software, products, methods and services in the campus
and will allow an uniform, lean and economical management and maintenance of
workstations, which can be used at RUS and can be offered to other users. In this
context RUS operates reference/server systems on various workstation platforms as for
example DEC, HP, IBM (in SERVus cluster), SGI and SUN. Therefore RUS should be
able to give basic system support and other informations concerning those Unix
workstation platforms.
The reference systems are typical workstations as used in an university environment
and will users help to test and compare different hard− and software in general, to make
special user−de−pendent functional tests, to check performance on user programs, to get
a feeling with a certain Unix system and its components. These refer−ence systems
should enable users to test and evaluate a workstation, check for their own needs and
try to compile, link and (performance−) test their own software for making an optimal
selec−tion and investment.
The department also operates some heteroge−neous compute server systems, based on
typic−al Unix−workstation architectures. Within the open systems concept, users on
campus should have the possibility, to get access and make use of sys−tem platforms of
well−known Unix vendors usually not available in their own working environment.
Reasons for using such system platforms may be:
· Having binary programs and data which are not suitable for the own environment
· Using special bounded software products (licensed/available on a certain platform)
· Project cooperations needing other platforms
· Porting of software on other vendor platforms.
The security of Unix workstations is another task, but only in a more technical sense.
This means having a general look on security features of the hard/software components
of Unix workstations and to pay attention to security problems in these fields, especially
in networking subsystems.
Staff
The department consists of about 4 1/2 co−work−ers, whereof one person is full−time
concerned with the support, evaluation and checking of proposals for computer
investments of the institutes.
73
Equipment
There are reference systems for the following vendors: DEC (Ultrix: VAX, RISC; OSF/1:
AXP), HP (UX: PA730), SGI (IRIX: Indy) and SUN (Solaris: Sparcstation20), IBM is on
SERVus. There are universal compute server systems for SUN: Sparcstation 1000 (6
cpus, 256 MB memory) and DEC: DEC AXP 2100 Server (2 cpus, 256 me−mory), IBM is
on SERVus. Other vendor systems have to be added.
For more information please contact:
Dr.Lothar Ehnis
Tel. 0711/685−5985
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
SERVER & NETWORKS
Workstation Concepts
Systems
The Systems Department plans, installs, maintains, supports and develops Unix−based
operat−ing systems and their components. Maintenance and support for the production
backbone includ−ing its servers is a key focus. We are striving for a single−system image
and also for mainframe quality of services.
Responsibilities
· Unicos system maintenance
· SERVus−cluster operation and development
· AIX support for users on and off campus
· Operation and maintenance of a campuswide AFS−cells
· Support and development of campuswide distributed batch systems
· Maintenance and operation of the in−house backbone network
· DCE project−leadership
74
Cooperations
· IBM: Several betatests
· CRAY: Unicos and OSI beta−tests
· CRAY & PSC: AFS on Cray
· IBM & CRAY: DCE prototypes and betatests
· BULL: Betatest SMP−system
History
· 1968 CD6600, scope, NOS/BE
· 1975 Cyber 174, first inter−active usage
· 1983 CRAY−1M, COS
· 1983 IBM 3083, VM/CMS
· 1984 EARN Network
· 1986 CRAY−2, first UNIX− system in production
· 1991 CRAY Y−MP, fileserver
· 1991 first timeserver
· 1991 first AFS−cell in Germany
· 1992 SERVus servicecluster
· 1992 prototype DCE
· 1994 CRAY−C94 replaces CRAY−2
· 1994 CRAY T3D.
Since the introduction of the CRAY−1 in 1983, computing at RUS has two major
components:
· vector− and more recently parallel−supercomputing for numerically intensive
applications,
75
· interactive systems for post− and preprocess−ing of application−runs as well as scalar
batch processing. Necessary technologies of distributed computing evolved from
prototype to production in the service environment.
Conception
Today’s system environment consists of a number of servers interconnected and
accessible via a hierarchical network topology. Increasing compute power of the
workstations on campus led to a decrease in usage of the traditional general−purpose
services. At the same time the demand of the workstation users for better system− and
software−support in their decentralized environment has increased constantly.
The answer appears to be a centralized and consistent management of users, data,
networks and systems in a heterogeneous environment.
The idea of a RISC−based server cluster at RUS (aka SERVus) as the technology−carrier
and base for the streamlined offer of numerous dif−ferent centralized services, was
supported financially and conceptually by the advisory commission of the DFG
(Deutsche Forschungsgemeinschaft, German Research Foundation). The cluster were to
replace a COMPAREX mainframe (IBM compatible) which had provid−ed general
services to the user community for many years.
Integration into the Environment
After the migration of all RUS−services onto Unix−based platforms, the RISC−cluster
SERVus is integrated homogeneously into the surrounding Unix environment. It
constitutes a transparent front−end interface between user−machines or terminals on
campus and the high−performance servers of the Computer Centre. The homo−genous
integration directly and transparently supplies the following services:
· High−performance vector−computeserver CRAY−C94 (including a T3D MPP system)
via direct NQS−queues
· High−performance fileserver CRAY−Y/MP as a mass storage system for large amounts
of data. Storage into StorageTek tapesilos through automatic DataMigration of NFS
mounted filesystems
· Other services like print, plot, info, news etc.
RUS−Services for Cluster and Workstations on Campus
The SERVus−cluster in its current conception not only replaces the former mainframe
functionality, but also serves as a reference platform for the development and test of
support−methods for external systems on campus. Today we offer the following services
to our outside customers:
76
· Operating system installation and mainten−ance (AIX)
· Readily standardized operating−system images to install or upgrade workstations over
the net
· Administration of distributed resources (i.e. AFS−cells)
· Distribution and maintenance of AIX−software under campus licenses
· Distribution of centrally maintained software via AFS
· User management.
Filesystem
In building a Single System Image, the file−system is of greatest importance. The view
onto user’s data shall be completely transparent and independent of the location. The
state−of−the−art distributed Andrew−File−System is very success−fully used, not only
in the cluster but also in the campus community.
ACLs are administered by the owners them−selves. For the users the pathnames to their
directories on all machines in the AFS−cell are identical! All homedirectories as well as
application packages, compilers and other software reside in AFS, resulting in
centralized installation and maintenance capabilities. A huge software offering (i.e.
public domain software etc.) is available on all machines in and outside the cell.
For more information please contact:
Walter Wehinger
Tel. 0711/685−2513
Fax 0711/682357
E−Mail: [email protected]−stuttgart.de
Data Management
In the context of growing computer power and a fast emerging distributed computing
environment, data storage becomes more and more a focal point.
Networked computer systems are to be considered as being only a tool for the users to
pursue their profession. Data should be processed on the most appropriate servers,
whether they are PVPs, MPPs, graphic workstations or simp−le PCs. The tasks to locate
and store the data, sometimes up to several gigabytes in size, and, if required, to
transfer this data are not of any primary concern. Those actions should be carried out by
the computer systems, in order that the user can work more effectively.
The scope of the Data Management Section includes:
77
· local file systems for permanent and tempo−rary data storage on the Centre’s compute
servers,
· distributed file systems,
· a mass storage system,
· a backup service,
· and support for user data exchange.
Responsibilities cover the areas of planning, configuration, maintenance, software
customization and tools development, resource usage collection, and problem tracking.
The mass storage file service runs on a dedicat−ed CRAY Y−MP M92. UNICOS Data
Migration Facility (DMF) is used for hierarchical storage management on 50 GB disk
space and about seven terabyte of tape capacity housed in a StorageTek Automated
Cartridge System.
Data access is either explicit − ftp, rcp − or implicit via NFS. The mass storage file
system has some 1.85 million files and a data volume of 1.45 TB.
The backup service, in its current state, is a distinct file system on the CRAY Y−MP
M92, where the user targets his backups to disk files and the movement of those copies
onto tapes is up to DMF. This "backup" file system contains a data volume of 1.2 TB in
52 500 files. Scheduled to be available this year is a RISC computer based backup
service, sharing the back−end storage with the mass storage system. It will provide more
end−user functionality, such as a GUI−based user interface for user−initiated backups
and selective file restores as well as more man−agement capabilities for the Centre as
the service provider.
For the local file systems special attention is to provide highly reliable, properly
managed data storage for effective use on the high perform−ance computers with many
users, varying their workload over time. The temporary, more accu−rate
semi−permanent working space is subject to similar rules on all the compute servers,
providing data availability across system restarts and beyond job or session termination.
On all the central servers a directory tree struc−ture has been defined and implemented,
which establishes a global uniform name space, wheth−er access is via NFS or AFS. In
conformance with the DCE project at RUS, provisions are made to achieve a smooth
integration of the Distributed File Service (DFS).
For more information please contact:
Uwe Fischer
Tel. 0711/685−5800
Fax 0711/682357
E−Mail: [email protected]−stuttgart.de
78
Workstation Maintenance
The Workstation Maintenance group offers services for workstation (WS) users in the
campus and maintains WS− and PC−pools, offered by RUS for students.
This group has been established in 1993 within a cooperate project between RUS and
Staatliche Materialprüfungsanstalt (MPA). The project’s intend is a turning away from a
local maintenance approach and strives for setting up a RUS service, to achieve a more
cost−efficient workstation maintenance by increasing synergy. This service will be
offered by costs to other institutions. Therefore, MPA’s computer maintenance staff (6
persons) has been integrated within the RUS, still paid by MPA and primarily engaged
in supporting the MPA.
In accordance with the project’s goals, these concepts and techniques for workstation
main−tenance (WS−M) at MPA should be considered as typical for WS support in the
campus. In principal, the WS−M group is endeavoured to apply concepts, which are
evaluated by the RUS department Workstation Concepts.
For all supported WS platforms (DEC, HP, IBM, SGI, SUN) the following services will
be offered:
· Installation of the hardware
· Installation and update of operating systems
· User and resource management
· Supervision of system integrity.
All kinds of advisory support is free of charge.
Fields of Activities: Workstation Pool
Students have free access to a WS pool maintained by RUS. For their accounts a full
range of UIDs is separately maintained by a specific kerberos server. Filespace is located
within an own AFS−cell. Both services are offered to other pools in the campus.
To simplify the pool management, each client is replicated from a reference system
image. All services are server based, e.g. mail is available via POP−mail from the central
studbox.
Each day the pool is used by about 400 users.
79
PC−Pool
The PC−Pool for students is DOS based and available without an user account. This pool
will be renewed to offer additional services like: DOS/Windows, OS/2, Linux, which will
be user selectable during startup. For a reliable pool availability it is necessary, that
each user starts with a well defined environment, downloaded from a server.
For all PC platforms software will be installed to enable users with an Unix account to
use all Unix services offered by RUS.
DECathena
Advanced WS management concepts are stud−ied in a common project (DEC, RUS,
MPA).
MIT−Athena and DEC−Athena are evaluated for their suitability for future cluster
management.
PC Support
Support for PCs in the campus is done by a group of students. They evaluate software
solutions to integrate PCs into Internet. Though RUS services can be used by all PC
user, e.g. back−up, archiving. Support is given by courses, publications and a mailbox
helpline.
MPA / RUS Project
MPA is a representative of a big institute (about 280 empl.), working mainly on
experimental and numerical analyses in the area of material science and testing. Its
computer equipment is heavily heterogeneous, data processing pre−dominantly
applications oriented.
Support for MPA is based on RUS concepts and covers the management of:
· Unix−WS (25 systems)
· Server (4 systems)
· VAX/VMS (11 systems)
· Peripherals (25 X−terminals,
120 VT−terminals, 30 printers, etc.)
· Network infrastructure (Ethernet, FDDI)
80
· Internet services for Personal Computers (about 110 systems). This includes a full site
support of planning, purchasing, hardware/ software installation, maintenance and
oper−ation of those systems with application
orientated user support.
Server and workstation management as well as all aspects of service offering is strictly
orientated to the conceptional framework of RUS:
· RUS services are used wherever possible:
− User and account management
− Compute services (CRAY, SERVus)
− AFS and CRAY−YMP mass storage
− Software distribution via RUS’s software
− Installation concept (/sw)
− Visualisation services
− Communication and information services
· Client/Server computing is based mainly on RUS services and assisted by local servers.
They improve central service availability and efficiency by local service replication (/sw)
or local subservers (AFS)
· Workstations are organized in clusters and each WS is treated as a client with the
same software configurations. System images are replications of a site specific reference
system. Services are generally realized by servers. In case of local requirements,
filesystems for spe−cific software are always implemented on a separate disk to
minimize interferences with system management. MPA uses the following Unix systems:
− AIX
− IRIX
− ULTRIX
− OSF/1e.
The workstation maintenance group is formed by 3 scientific and 3 technical employees
with up to 20 years experience in data processing and system maintenance.
For more information please contact:
81
Dietmar Kießling
Tel. 0711/685−4519
Fax 0711/6854519
E−Mail: [email protected]−stuttgart.de
BASIC SERVICES
Operations
The Computer Centre of the University of Stuttgart affords its users various modern
supercomputing platforms with numerous application packages. It provides services in
all the im−portant areas of computing and supports its users by offering solutions to
their technical and scientific problems.
In the areas of education and research, the Computing Centre users include not only the
vast majority of the disciplines within the University, but other universities and colleges
within the state of Baden−Württemberg.
Further users include a number of public, state and national institutions as well as
medium to large industrial companies.
Networking, both within the Computer Centre and to the University, use modern
technologies to allow flexible machine access. Basically, all the services offered by the
Computing Centre are charged.
The Operations Department of the Computing Centre provides an important interface to
the user community. It is responsible for the management of the users, including the
central UID server for the University. It also organizes the resources and issues the
invoices for all pro−cessing performed on any of the available ma−chines. Users are
offered advice on the use of a machine and those users requiring larger re−sources are
especially catered for. The database knowledge, existing within the department, led to
the establishment of a service to provide and maintain database software systems.
The department is also responsible for the trouble−free running of the machines and to
ensure their high availability. Any problems including interruptions outside normal
working hours are solved using the cooperation of other departments where necessary.
Additional tasks involve controlling and maintaining the ancillary equipment such as
power supplies, air con−ditioning and cooling water as well as fire protection and other
alarm systems. The department is also responsible for the planning and installation of
new machines.
The classic tasks of the department, such as machine operation, production planning
and controlling have altered over time. Today, ma−chine operators are only required to
run complex video and graphic equipment.
More important and significant nowadays is the support for servers and workstations,
video and visualization services and network management. These tasks, together with
the necessary software development and maintenance, de−mand qualified and skilled
82
personnel.
For more information please contact:
Erika Fischer
Tel. 0711/685−4515
Fax 0711/682357
E−Mail: [email protected]−stuttgart.de
BASIC SERVICES
Operations
PROJECTS OF RUS
[email protected].−stuttgart.de
Title:
ACTS INFOWIN
Category:
Information infrastructure
Subject:
Provision of ACTS project information infrastructure
Partners:
DeTeBerkom
Source:
ACTS
Duration:
status: negotiating
Contact:
Barbara Burr (prime contractor)
Title:
ACTS National Sub−Host
Category:
Project support infrastructure
Subject:
Provision of infrastructure for ACTS projects
Partners:
State Science Ministry, DeTeBerkom
Source:
State of Baden−Württemberg’s provision of network and computing infrastructures
Duration:
ongoing
Contact:
Barbara Burr / Paul Christ
Title:
ADONNIS
83
Category:
HPCN, simulation, visualization, CSCW
Subject:
Collaborative distributed simulation/visualzation in aerospace pre−design (CFD) trials
using the European ATM field trial
Partners:
ONERA, NLR, Dassault, Deutsche Airbus, DLR, CIRA, Alenia, CASA
Source:
ESPRIT 9033
Duration:
11/93 − 12/95
Contact:
Ulrich Lang
Title:
ATHOC
Category:
ATM over CATV networks, HPCN, simulation, visualization, CSCW
Subject:
Collaborative distributed simulation/visualzation, CSCW, ATM over CATV networks,
interworking
Partners:
ALCATEL SEL CRC, ETHZ, INTEGAN, Bell Antwerp, CET Portugal, NTU Athens,
Verbraucherzentrale Baden−Württemberg
Source:
ACTS 0037
Duration:
09/95 − 08/98
Contact:
Paul Christ
Title:
BelWü4M
Category:
HPCN, CSCW, visualization, application projects
Subject:
Co−ordination of 10 network−oriented application projects proposed to the DFN RTB
framework
Partners:
Universities of Tübingen, Heidelberg, Mannheim, Karlsruhe
Source:
DFN
Duration:
2 years (status: delayed)
Contact:
Peter Feil
Title:
BelWü4M infrastructure
Category:
Network development/deployment
Subject:
84
Upgrade of the state science network BelWü to 155 Mbit/s ATM
Partners:
State Science Ministry, DBP Telekom
Source:
State of Baden−Württemberg
Duration:
status: pending
Contact:
Paul Christ
Title:
CAESAR
Category:
HPC
Subject:
Euler solver using unstructured meshes on MPP
Partners:
intel SSD, DASA
Source:
ESPRIT
Duration:
09/94 − 1.5 years
Contact:
Alfred Geiger
Title:
CIO
Category:
CSCW, multimedia, QoS in networks
Subject:
CSCW, joint editing, multimedia mail, advanced transport systems on top of ATM etc.
Partners:
DeTeBerkom, ETHZ, University of Ulm, TUB, CET, NTR, DBP FTZ
Source:
RACE 2060
Duration:
01/92 − 12/95
Contact:
Andreas Rozek
Title:
Development and test of innvovative products − Rapid prototyping
Category:
Simulation, visualization, HPC
Subject:
Integrated software environment for simulation and visualization, user interfaces in
motorcar industries
Partners:
Mercedes−Benz, FHG − IAO/IPA
Source:
German SRA (SFB)
Duration:
85
07/94 − 3 years
Contact:
Ulrich Lang
Title:
DFN−NOC
Category:
Network operations
Subject:
Management of the German and international IP
Partners:
DFN
Source:
DFN
Duration:
08/93 − 12/96
Contact:
Peter Merdian
Title:
DFN−NOC (Timeserver)
Category:
Network management/time service provision
Subject:
Time service provision
Partners:
DFN
Source:
DFN
Duration:
01/95 − 12/96
Contact:
Peter Merdian
Title:
DFN RTB−NOC
Category:
Network management
Subject:
Management of the evolving so−called Regional Testbeds (RTB) of the DFN
Partners:
DFN
Source:
DFN
Duration:
01/95 − 12/97
Contact:
Peter Merdian
Title:
DFN RPC
Category:
RPC, distributed computing environment, DCE
86
Subject:
Development of a versatile, performant Fortran oriented RPC in co−operation with a
user group
Partners:
University of Tübingen, ISD, IKE University of Stuttgart, AWI Bremen etc.
Source:
DFN
Duration:
ongoing − 12/96
Contact:
Rolf Rabenseifner
Title:
Europort 1
Category:
HPC
Subject:
Porting the multiblock Navier−Stokes solver NSMB to parallel platforms
Partners:
CERFACS
Source:
ESPRIT
Duration:
09/94 − 2 years
Contact:
Uwe Küster
Title:
HiATM
Category:
Network system
Subject:
Ethernet−to−ATM box
Partners:
Hirschmann GmbH
Source: Hirschmann GmbH
Duration:
ongoing
Contact:
Christopher Copplestone
Title:
High−temperature problems of re−entrant space transport systems
Category:
HPC
Subject:
Modelling and validation of thermo−physical effects of re−entry. 3D URANUS−code,
parallelization
Partners:
IRS University of Stuttgart
Source:
German SRA (SFB)
87
Duration:
(06/93 − )10/95 − 09/98
Contact:
Alfred Geiger
Title:
HPC ISE
Category:
Visualization, parallelization, HPC
Subject:
Load balancing, dynamic distributed data structures, distributed and parallel
visualization
Partners:
Daimler Benz, Renault, Computational Dynamics Ltd.
Source:
ESPRIT/IT
Duration:
01/96 − 3 years
Contact:
Alfred Geiger / Ulrich Lang
Title:
MERCI
Category:
CSCW, desktop video conferencing
Subject:
CSCW, seminars, teaching over MBONE/Internet, interworking H.261/ISDN − packet
video
Partners:
UCL, INRIA, KTH, GMD, UoO, TELES
Source:
TELEMATICS for Research, 1644
Duration:
11/95 − 10/97
Contact:
C.−D. Schulz / Paul Christ
Title:
Methods and algorithms to simulate physical processes on high performance computers
Category:
Visualization, parallelization, HPC
Subject:
Development of parallel volume visualization methods on parallel computers
Partners:
ICA University of Stuttgart, TAT University of Tübingen
Source:
German SRA (SFB)
Duration:
07/94 − 3 years
Contact:
Ulrich Lang
Title:
88
MICE
Category:
CSCW, desktop video conferencing
Subject:
CSCW, seminars, teaching over MBONE/Internet
Partners:
UCL, INRIA, NTR, SICS, KTH, GMD, ULB
Source:
ESPRIT 7602
Duration:
11/92 − 10/95
Contact:
C.−D. Schulz
Title:
MKS
Category:
Multi−body system, simulation, animation, visualization, software integration, RSYST
Subject:
Modular integrative multi−body system
Partners:
14 German universities
Source:
DFG Focus (DFG Schwerpunkt)
Duration:
finished
Contact:
Roland Rühle
Title:
OPTIMA
Category:
Thermal simulation (software integration)
Subject:
Optimization of heating, airconditioning and cooling of buildings
Partners:
IKE, IPVR, IVD, IBK University of Stuttgart
Source:
State Science Ministry
Duration:
04/93 − 12/94
Contact:
Carsten Volle
Title:
PAGEIN
Category:
HPCN, simulation, visualization, CSCW
Subject:
Collaborative distributed simulation/visualzation in aerospace pre−design (CFD)
Partners:
ONERA, NLR, Dassault, Deutsche Airbus, DLR, CIRA, Alenia, CASA
89
Source:
RACE 2031
Duration:
01/92 − 12/95
Contact:
Ulrich Lang
Title:
PARIS
Category:
HPC
Subject:
Parallel RISC cluster based CFD and structural mechanics
Partners:
DLR, IBM, SFB 259
Source:
IBM
Duration:
1992 − ongoing
Contact:
Alfred Geiger
Title:
PROMENVIR
Category:
Software engineering, object oriented design, software integration, probabilistic
simulation for variance reduction, mechanical engineering
Subject:
Multibody sytems, finite element systems
Partners:
CASA, CEIT, UPC, PAC, ITALDESIGN, Blue Engineering, IKOSS
Source:
ESPRIT/IT
Duration:
01/96 − 2 years
Contact:
Jochen Seybold
Title:
Software labor
Category:
Software integration
Subject:
Integrated computerized development of automobiles
Partners:
Daimler Benz AG, Dornier GmbH
Source:
State Science Ministry
Duration:
since 01/95
Contact:
Carsten Volle
90
Title:
SONAH
Category:
Information infrastructure
Subject:
Information infrastructure for the RACE/ ACTS transition phase
Partners:
DeTeBerkom et al.
Source:
RACE
Duration:
03/95 − 02/96
Contact:
Barbara Burr
Title:
USPS
Category:
Network system
Subject:
High−performance interconnection network, HIPPI−to−ATM transition
Partners:
INü, IND, IPVR, IMS University of Stuttgart
Source:
State Science Fokus (Schwerpunkt)
Duration:
01/92 − 03/95
Contact:
Peter Haas
Title:
Visualization in scientific computing
Category:
Visualization, bio−mechanics
Subject:
Visualization in human bio−mechanics and astro−physics, students education
Partners:
TAT, IGS University of Tübingen
Source:
State Science Focus
Duration:
09/94 − 2 years
Contact:
Ulrich Lang
Title:
WIN shuttle
Category:
Internet access via POTS/ISDN
Subject:
Estasblish and run a German−wide internet DFN−WIN access infrastructure via
POTS/ISDN
91
Partners:
−
Source:
DFN
Duration:
09/95 − 3 years
Contact:
Barbara Burr
For more information please see:
Web: http://www.uni−stuttgart.de
Project: ADONNIS ESPRIT 9033
Engineers can perform a simulation on the supercomputer at RUS. Results of
simulations are visualized e.g. as coloured pressure distributions or particle flow around
the aircraft body or wing (see screen snapshot). Simultaneous display on the workstation
of all cooperating partners allow to discuss and analyse the simulations.
Audio−/videoconferencing functionalities are closely integrated into the software
environment to enable the discussion.
Fig.\x11 1:\x14 Network Configuration of INTEROP ’94
The ESPRIT project ADONNIS consists of a set of experiments conducted by the
European Aerospace Industry. An aim of the experiments is to evaluate the benefits of
european high speed network infrastructure usage for different aerospace application
cases.
The application case selected for the INTEROP ’94 demonstrates the cooperative
analysis of an airflow simulation around a new aircraft. An engineer located at the
INTEROP ’94 stand co−operates with engineers at the Deutsche Aerospace Airbus DA,
Bremen/Germany, at the University of Stuttgart Computer Centre RUS,
Stutt−gart/Germany, and the ONERA, Chatillon/France.
Fig.\x11 2:\x14 Particle Flow around the Aircraft Wing
For more information please contact:
Harald Nebel
Tel. 0711/685−5790
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
92
Project: RACE 2060 CIO
Coordination, Implementation and
Operation of Multimedia Teleservices
Joint Viewing and Tele Operation Service
Talk to each other, see each other, work to−gether on one computer program − but not at
the same location!
Systems
· Sun SPARCstation
· SGI Indigo
· Apple Macintosh
Networks
· LANs
· ATM
· ISDN
Protocols
· TCP/IP, UDP/IP
· XTPX
CIO Teleservices for Computer Supported
Collaborative Work
Use your current programs in a distributed enviroment:
· Do not change anything!
· Do not recompile!
· Do not link again!
93
Just start your application when JVTOS is running...
... and be prepared for
· Upcoming network technologies
· Advanced transport protocols
· Support for quality of service!
Project Partners
Operators
Centro de Estudos de Telecommunicações (P)
Deutsche Bundespost Telekom (D)
DeTeBerkom GmbH (D)
Norwegian Telecom Research (N)
Royal PTT Nederland NV (NL)
TELEFÓNICA (E)
User Interface
Media Port Berlin GmbH (D)
Software Houses & Manufacturers
Ascom Tech Ltd. (CH)
ACOTEC GmbH (D)
INTERSIS Automação, s.a. (P)
Online Park GmbH (D)
Siemens AG (D)
94
Research Institutes
Eidgenössische TH Zürich (CH)
Ges. für Mathematik und Datenverarbeitung (D)
Technische Universität Berlin (D)
Universität Stuttgart (D)
Universität Ulm (D)
Université de Liège (B)
For more information please contact:
Paul Christ/Andreas Rozek
Tel. 0711/685−2515
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Project: DFN NOC
Since late 1993 the DFN Network Operation Center (DFN NOC) is located at the BelWü
Coordination. The DFN NOC is run by order of the "Association for the promotion of a
German research network" (Deutsches Forschungsnetz, DFN). It provides basic IP
services to the German scientific and research community.
This includes operation of
· the ATM based high−speed IP network
· the X.25 based WiN−IP backbone
· international IP connections for the DFN−IP service
Connectivity within the scientific and research community of Germany is provided by
the Wissenschaftsnetz (WiN) which is based upon ATM and X.25 and offers access
bandwidths of 9.6 KBit/s, 64 KBit/s, 128 KBit/s, 2 MBit/s and 34 MBit/s to its members.
The ATM based B−WiN consists of ten central backbone routers with about 30 customer
access points using an access speed of 34 MBit/s (155 MBit/s in autumn ‘96). At the
customer sides the ATM switches are managed by the Deutsche Telekom and the WiN
routers are managed by the DFN NOC. Currently the only service is IP − X.25 and ATM
is planned for late ‘96.
95
The DFN NOC organises the IP service within the X.25 WiN by managing a connectivity
database. It contains the X.25 access data of the 300 WiN members. This includes
approximately 170 members which are connected to the X.25 WiN−IP backbone.
The X.25 WiN−IP backbone consists of Cisco routers at ten different sites across
Germany and are managed by the DFN NOC. They are fully meshed via 2 MBit/s X.25
lines.
The international IP connections for the DFN−IP service are located at Düsseldorf. DFN
cus−tomers normally reach this foreign access point via WiN.
At Düsseldorf various lines run to foreign partner organisations allowing European, US,
and worldwide IP connectivity. These are 6 MBit/s to DANTE/BT (Europe through
Amsterdam), 4MBit/s to MCI (oversea) ,2 MBit/s to DANTE (Europe, US, and worldwide
through Amsterdam via Aachen), 1.5 MBit/s to ESnet (US and worldwide through
Princeton), and 512 KBit/s to Moscow. The DANTE and ESnet lines are set up for
mutual backup in case of failure. These lines give international IP connectivity to nearly
300 DFN−IP members with more than 1200 IP networks and way beyond 200,000 hosts
(nameservice count) which covers approximately half of the hosts connected to the
Internet in Germany. The IP traffic on all foreign access lines now amounts to more than
2 TBytes per month.
All routers of the DFN−IP service and the WiN−IP backbone though located at different
sites in Germany are centrally managed by the DFN NOC at Stuttgart.
The network is permanently monitored regard−ing performance and faults.
Automatic tools generate alerts also outside regular business hours.
Although no general round−the−clock service is offered members of the DFN NOC are
normally available at least on the weekends resulting in a high service level. The
management of the IP network also includes support and advice to members of DFN−IP
and WiN−IP on installing and maintaining IP connectivity, and on perform−ance and
fault management. Moreover, two mailing lists, an ftp server, and a WWW server are
available presenting user reports, handbooks, trouble tickets, and current monitoring
information online from the network.
For more information please contact:
Dr. Joachim Schmitz
Tel. 0711/685−5576
Fax 0711/6787626
E−Mail: [email protected]
Project: HiATM
The Computer Centre has worked in close co−operation with the company Richard
96
Hirsch−mann GmbH for many years. In 1984, the world’s first fibre−optic Ethernet LAN
was installed at the university. Since 1987, the Computer Centre has been closely
involved in the design and subsequent development of a full−speed remote Ethernet
bridge, the MultiLAN Switch MR8−03. This cooperation has now been extended to the
design and development of an ATM−Ethernet inter−working unit based upon the
MR8−03. The first prototypes are expected early in the summer of 1995. They will be
used to allow the university’s LANs to be connected to ATM backbones (both public and
private) and to provide platforms for the development of software by researchers
(including students) e.g., in the areas of traffic management and policing.
Fig.\x11 1:\x14 Multiport Bridge
For more information please contact:
Christopher J. Copplestone
Tel. 0711/685−5987
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Project: HSL−MUX
110 Mb/s via VBN (Telekom)
The HSLMUX (High−Speed−LAN Multiplexer) converts 100 Mb/s and/or 10 Mb/s data
streams to the 140 Mb/s VBN−Frame (VBN, Public Broadband Network, Telekom).
Depending upon the LANs connected, the HSLMUX has to be equipped with either 100
Mb/s coaxial or fibre−optic interface or with a 10 Mb/s Thick−Wire−Ethernet interface.
Possible configurations are shown in the following table:
Tab.\x11 1:\x14 HSLMUX−Interface Configurations
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
100 Mb/s−fibre 100 Mb/s−coax 10 Mb/s Thick−Wire
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
1
−
1
−
1
1
−
−
5
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Using the HSLMUX it is possible to connect LANs over the VBN as shown in figure 1.
This may be done using dial−up or permanent VBN connections.
Fig.\x11 1:\x14 HSLMUX−VBN Connections
The largest FDDI−Ring worldwide?
In October 1991, the two Super Computer Centres in Stuttgart and Karlsruhe were
connected using HLSMUXs’ over a permanent VBN−Connection. This is the largest
97
FDDI−Ring worldwide (150 km). At each centre, the HSLMUXs’, being the only
participants in the WAN−FDDI−Ring, are each connected to a router.
Fig.\x11 2:\x14 FDDI−Ring Stuttgart−Karlsruhe
The longest UltraNet
In the autumn of 1992, the UltraNet LANs in Bremerhaven (Alfred−Wegener−Institute)
and Tübingen (University) were connected to Stuttgart, using HSLMUX with 100 Mb/s
coaxial interfaces. UltraNet’s special Link−Layer Protocol allows long distances to be
spanned with a lower performance loss.
Tab.\x11 2:\x14 UltraNet Performance via VBN
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Sites
Performance
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Stuttgart<−>Tübingen
90 Mb/s
Stuttgart<−>Bremerhaven 70 Mb/s
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Fig.\x11 3:\x14 UltraNet and VBN
Both locations were connected to Stuttgart with automatic dial−up connections.
The first public ATM LAN/WAN
During CeBIT ’93, several institutions set up a LAN at a booth in Hannover.
This ATM−LAN and the ATM−LAN at RUS were connected using HSLMUXs’ (AMUX)
equipped with fibre−optic interfaces. Over this ATM−VBN dialup connection transfer
rates of up to 80 Mb/s were recorded.
Fig.\x11 4:\x14 CeBIT ’93 ATM Configuration
Interop ’93 Paris
For Interop ’93, three ATM−LANs (Munich, Berlin, and Stuttgart) were connected using
the HSLMUXs’ and VBN. The connection to the Paris booth network and the three ATM
LANs was accomplished at Stuttgart using the Deutsche Telekom’s SMDS Datex−M
Service.
For more information please contact:
Wilfried Milow
Tel. 0711/685−5988
Fax 0711/6787626
98
E−Mail: [email protected]−stuttgart.de
Fig.\x11 5:\x14 Interop ’93 ATM Configuration
Project: InfoWin Multimedia
Information Window for ACTS
The InfoWin project will create and maintain the ACTS Information Window. This will
allow the ACTS projects to see the information world surrounding them, and provide to
the world a view of all aspects of the work in ACTS.
The project involves the National Hosts in ACTS which provide the distributed platform
on which the information services can be built. It works at the service layer to provide
information and services to ACTS projects.
We offer to
· Operate WWW information services
· Provide distributed archive and retrieval
services
· Provide project areas on servers to promote collaborative work amongst ACTS projects
· Gather, edit and electronically publish information from projects
· Gather, edit and publish filtered external information relevant to ACTS activities
The Partners:
· RUS / D
· Analysiys Ltd / GB
· DeTeBerkom GmbH / D
· CP2i / F
· CSELT / I
· NCSR Demokritos / GR
· Telefonica + ID / E
· BBN − Burger Breedband Net / B
99
· BIT − Bureau for International Research
and Technology Cooperation / A
· INRIA / F
· C&C − KTH Center for Computing &
Communinication Systems / S
· Post and Telecom Iceland / ICE
· UNI−C / DK
· Telenor / N
· Open University / GB
· Fernuniversität Hagen / D
· IENM − Institute for Information Economy
and New Media / A
· IGD − Fraunhofer Institute for Computer
Graphics / D
· Intracom / GR
· Swiss Telecom / CH
For more information please contact:
Barbara Burr
Tel.: 0711/685−5811
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
http://www.rus.uni−stuttgart.de/infowin/
Project: ESPRIT 7602 MICE
In 1992, the CEC agreed to finance a one−year project called The Piloting of Multimedia
Inte−grated Conferencing for Europe (MICE). This ESPRIT project completed Phase I in
early 1994, but work is continuing within the initial collaborating group.
The consortium, with UCL (University College London) as the coordinating partner,
consists of:
· Belgium Free University of Brussels (ULB)
100
· France INRIA Sophia Antipolis
· Germany GMD Darmstadt, RUS Stuttgart
· Norway University of Oslo (UiO), Norwegian Telecom Research (NTR)
· Sweden KTH, Swedish Institute of Computer Science (SICS)
· UK University College London (UCL).
The goal of the MICE project is to pilot inter−working between european researchers,
and also to connect them to sites in the US, using existing network facilities. The MICE
system currently allows multimedia conferencing (audio, video, and shared workspace)
between con−ference rooms and workstation−based facilities, hardware and software
codecs, packet−switched networks and ISDN, using both unicast (point−to−point) and
multicast (multi−point) technology.
In 1993 the project had 3 overlapping phases: definition, trial and evaluation. During the
definition phase, a multimedia conferencing reference architecture was defined. The
facilities required, such as conference rooms, workstations and the Conference
Management and Multiplexing Centre (CMMC) at UCL, have been specified.
During the trial phase in 1993, the facilities of all three areas were continuously
improved. In this phase interworking between the MICE partners, and sites in the US,
were demonstrated successfully in public events at the following confer−ences:
· Joint European Networking Conference (JENC) in Trondheim/Norway
· Internet Engineering Task Force (27th IETF) in Amsterdam/Dutch
· Interop ’93 in Paris/France
· JENC5/INET ’94 in Prague/Czech Republic.
In October 1993, the MICE project started the MICE International Seminar Series on
Multi−media, Communications and Networks, Distributed Systems and CSCW, with
UCL and SICS as the principal transmitting sites, along with GMD, INRIA and LBL.
The strengths (and weaknesses) of the MICE facilities were detailed in the evaluation
phase, in the light of experience drawn from these seminars together with the weekly
MICE project multicast meetings.
MICE partners are working to improve the exist−ing software tools for audio, video and
shared workspace. To allow better use of both workstations and conference rooms.
Current investiga−tions are focusing on:
· Interworking with multimedia servers
101
· Security
· Traffic monitoring, modelling, management
· Moving to high−speed networks.
MICE continues to help with events which demonstrate how the available technology
allows national or international collaboration. Diverse user groups, such as medical staff
and physicists are beginning to use the MICE approach. A new series of International
seminars is scheduled for 1994/95.
National support centres exist, or are in the process of being established, throughout
Europe. Another document in this series describes their objectives and functions.
For more information please contact:
Paul Christ
Tel. 0711/685−2515
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Web: http://www−ks.rus.uni−stuttgart.de/mice/
Project: Multibody Systems
Analysis and Design of Multibody Systems with Database
Integration using an Object−Oriented Data Model
In the nationwide German research project "Dynamic of Multibody System" a
parameterized object−oriented data model was developed to define the geometric and
dynamic properties of multibody systems. The object−oriented data model describes
engineering applications, such as multibody systems are, in a natural and efficient way.
This object−oriented data model is implemented within RSYST. With this data mod−el
and RSYST as an interface and integration technology of data and modules with an
object−oriented database, 15 Universities in Germany built up a common multibody
system software package. RSYST provides 15 application mod−ules to treat with
multibody systems:
· Define and modify the objects describing the dynamic and geometric properties:
MBSEDIT, GEOEDIT, MBSGET, GEOGET, MBSPARAM
· List and print all objects multibody system: MBSLIST, MBSPRINT
· Determine the topology of multibody systems: MBSTOPO
· Compute consistent position and velocity of a multibody system with closed kinematic
loops: MBSPOSI, MBSVEL
102
· Kinematic analysis of a multibody system with and without closed kinematic loops and
online visualization: MBSKINE
· Compute the input files for the DYMOLA multibody system library: MBSDYM
· Online and off−line visualization of multibody systems with the module MBSVIS.
Fig.\x11 1:\x14 Pedestrian Bridge in Kiel−Hörn
Fig.\x11 2:\x14 Visualization of a Trajectory Optimization
Since the DFG multibody system package is based on RSYST his modules can easily
used in conjunction with other RSYST modules. In particular the modules of the
ANDECS(1)−project are a very useful addition to the multibody sys−tem modules,
because a broad range of analysis and design methods become available for multibody
systems. Especially it is possible to compute multi−objective parameter and trajectory
optimization and the user is enabled to visualize every optimization step. To define the
properties of a light weight robot following steps are necessary:
· Definition of the multibody system dynamic and geometric data by an editor or by
inter−active input with the modules MBSEDIT and GEOEDIT
· Generating the input file for the general dynamic modelling language DYMOLA(2) by
the module MBSDYM. Dymola generates parameterized symbolic equations of motion
where the code grows only linear with the number of degrees of freedom of the multibody
system
· Definition of parameterized input signals and initial conditions for simulation module
DSSIM. Simulation results, initial conditions and actual parameters of the simulation
run could be stored on the database
· Multi−objective optimization with the module MOPS in ANDECS. Every optimization
step consists of a lot of simulation runs of DSSIM3 and the corresponding DSblock.
For more information please contact:
Jochen Seybold
Tel. 0711/685−2047
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Projects: Numerical Mathematics
103
Solution of Conservative Equations on Unstructured
Grids
with Arbitrarily Complex Cells
Clemens Helf
Today, the bottleneck of industrial flow simulation for complex technical geometries is
grid generation and grid adaption. In the same time flow solvers require high quality
grids to compute accurate solutions.
The project CEQ (Conservative EQuation solv−er) gives a new approach by completely
gene−rating the grid during the flow calculation on the base of a single multiply
connected cell. The description of the problem geometry serves as an initial grid.
Self−adaptive refinement divides arbitrary cells along arbitrary hyperplanes. Special
techniques fit existing nodes and limit the complexity of resulting cells. Multiple flow
features are captured by controlling refinement by location and direction. The numerical
technique is a second order ENO like explicit Finite Volume scheme and is capable of
producing accurate solutions on these complex grids. Formulas for computation of
volume, centroid and all others moments of arbitrary polyhedra are implemented.
The object oriented implementation allows handling of 2D as well as 3D problems. The
code is written in C++. The grid database part can be used for other time dependent
conser−vative equations. The data structures allow vec−torization of the computationally
intensive parts in principle. The complete code including refinement is parallelized on
base of DDD. Automatic dynamic load balancing will be provided. Visual−ization will be
done by a special project.
The program is now working in 2D. 3D refine−ment is in progress. Navier Stokes
equations will be implemented in the near future. Parallelized multi grid techniques will
be implemented.
Dynamic Distributed Data:
An Efficient Programming Model
for Parallel and Adaptive Algorithms
Klaus Birken
Parallelizing computational intensive algorithms based on dynamic data structures (e.g.
adaptive PDE solvers) will often be doomed to failure if one does heavily rely on pure
message−passing layers as the basic access point to the parallel hardware.
Various problems as for data redundancy, con−sistency and load balancing can only be
tackled using an appropriate level of abstraction. With Dynamic Distributed Data (DDD)
this abstraction is available on a fine−grain object level. DDD provides a dynamic
representation of data graphs, transfer operations of any set of objects and abstract
interfaces across local−memory borders.
104
Usage of DDD will result in parallel applications, which are efficient and portable. The
changes of the sequential code are minimal; complex real−world examples could be
parallelized within a few days.
Distributed Visualization
of Arbitrary Unstructured Grids
Thomas Schmidt
Computational simulations for complex geo−metries nowadays often deal with
unstructured grids. That’s why scientific visualization must also be extended to these
grid types. A visualization system is presented which works with any type of
unstructured grids, i.e. arbitrary polygonal and polyhedral grids. Results from finite
volume (cell centred) and finite element me−thods can be visualized. Additionally
time−de−pendent data can be processed and inter−polation between timesteps is
possible.
This data may be transferred directly from a simulation program and therefore online
visualized. To integrate this task into a computational simulation an object−oriented
interface is presented which allows easy connection from simulation to visualization.
This interface also pro−vides a connection to the technical database system RSYST.
Therefore it is possible to read grids and initial data from the database and write results
back to it. Preprocessing, CAD and other modules can be accessed on this way.
Esprit Project
Parallel Aero of Europort 1
Uwe Küster, Manuela Zürn
In this Esprit project a Multi Block Navier Stokes Solver has to be parallelized and
tested on dif−ferent platforms. CERFACS/France, KTH/Sweden, Cira/Italy,
EPFL/Switzerland, SAAB/Sweden, Aerospatiale/France, and RUS/Germany are the
partners.
For more information please contact:
Uwe Küster
Tel. 0711/685−5984
Fax 0711/6788363
E−Mail: [email protected]−stuttgart.de
Contents IMG
Project: OPTIMA
The main goal of the OPTIMA project is op−timizing HVAC systems (heating,
105
ventilation and air−conditioning systems) and building structures with respect to energy
consumption. The main focus is on the development of an integrated computerized
system for thermal simulation pur−poses. A central data repository defined by a data
model provides data persisency. The resulting data model considers object−oriented
philoso−phies and provides a simple and clear solution for the specific needs of thermal
simulations for buildings and HVAC systems.
Various tools will operate on a central database to optimize building and technical
equipment in design, construction, and building management through the whole
life−cycle. The data structure underlying the database is formulated with the data
description language EXPRESS created in the STEP project (STandard for the Exchange
of Product model data). EXPRESS−G as a graphical subset of EXPRESS is used to
visualize essential parts of the data structure. This graphical notation depicting the
classes as rectangles is independ−ent of any programming language. The classes can be
implemented using C++, Small−talk or any other object−oriented language.
In OPTIMA project, the data model will be mapped as a first approach on a relational
database (Ingres), other database systems (especially ob−ject−oriented systems) are
considered later on.
Fig.\x11 1:\x14 Populating the Data Model by CAD
In an early stage of a building design the architect determines roughly the dimensions,
floors and zones. Architectural zones describe spaces of the same usage, e.g. business
offices or rooms for HVAC appliances. To capture these seman−tics the datatype space is
introduced in the data model. Space is an important notion for a volume which is
bounded on all sides by enclosing structures. This can be the whole building space with
an internal structure of walls or a zone or only a single room. An important task of the
system is the possibility of rough simulations based on an incomplete data set. This
feature provides a powerful tool for the architect to compare different concepts in early
phases of the building design.
Fig.\x11 2:\x14 Classes and Objects of Enclosures
Detailed thermal simulations based on a refined data set is possible with an interface to
CAD systems (Fig.1). In correspondence to prefab−ricated walls and windows an
enclosure with its attributes can be instantiated independent of any space information
(and vice versa). The different enclosure types are ordered hierarchically in an
inheritance tree realizing the concept of generali−zation and specialization (Fig. 2). The
connec−tions between spaces and enclosures can be reduced to a topological graph of
vertices and edges (Fig.1). With this approach the rules of topology theory can be
applied. In this manner a vertex corresponds to a space and an edge com−plies to an
enclosure and the air and heat−flow through the enclosure. This abstract view helps
detecting heat losses as a start for thermal optimi−zation. A very compact and efficient
data descrip−tion was found in the OPTIMA data model in accordance with
object−oriented principles.
For more information please contact:
106
Carsten Volle
Tel. 0711/685−5927
Fax 0711/6787626
E−Mail: volle.uni−stuttgart.de
IMG Contents IMG
Project: Parallel Computing
CAESAR
Clusters of computational intensive Applications for Engineering Design and Simulation
on scal−able parallel Architectures.
CAESAR focuses on computational methods to improve industrial competitiveness. It
aims at demonstrating the scope for broader and effective exploitation of the emerging
parallel hardware technology.
RUS is working in one part of this project together with Intel ESDC (European
Supercomput−ing Development Centre) and Daimler Benz Aerospace (DASA). The aim
of the subproject is to port an existing solver to heterogeneous computing environments
and demonstrate portability on different parallel hardware platforms.
Starting from an existing prototype version of the flow solver for a shared memory
parallel architecture, the code will be analysed with respect to further parallelization on
distributed memory multicomputers. The major result will be a parallelization strategy
(either data parallel−ism like available using HPF or message pass−ing which could be
based on the newly developed standard MPI). Based on this strat−egy the flow solver
will be parallelized.
Portability of the resulting code as well as scal−ability will be the major goals. Thus in a
last step verification of the code for different hardware platforms will be done. In this
last step RUS will serve as the demo−site making available its wide range of different
MPP platforms.
PARIS
The PARIS (PArallel RISc) Project was initiated at the University of Stuttgart in the
year 1992 as a cooperation between
· IBM
107
· DLR − German Aerospace Research Institute
· RUS − Computing Centre of the University of Stuttgart
· CRP 259 − Collaborative Research Project "High Temperature Problems of Re−Usable
Space Transportation Systems".
Major items of the project are:
· Using a RISC−cluster for solving complex problems of computational fluid dynamics
and structural mechanics
· Investigating various numerical algorithms and parallel techniques for their use on
workstation clusters, including comparisons with massively parallel machines and
vector computers
· Comparing different network techniques in the cluster (Ethernet, FDDI, SOCC)
· Developing strategies for the use of clusters as parallel computers
· Testing programming and development tools (MPI, PVM, FORGE90, ParaGraph, etc.)
with large engineering problems
· Teaching students and scientific personal how to use workstation clusters for parallel
jobs.
One aim for the future is the participation of industrial users.
CRP 259 −
High Temperature Problems of
Re−Usable Space Transportation Systems
In this Collaborative Research Project (CRP) the Computing Centre of the University of
Stuttgart (RUS) participates − joined with the Institute for Space Flight Systems of the
University of Stuttgart (IRS) − in the subproject "Numerical Re−En−trance Aero
Thermodynamics". The second fi−nancing period of this project part began in the
summer of 1993 for a duration of 3 years.
The first period of the IRS URANUS−Project consisted of developing a fluid dynamics
program with a consistent thermo−physical multi−temperature−modelling for the gas
phase and an exact efficient solver for the conservation equations of non−equilibrium
fluxes.
The goal of the second period is improving and validating the modelling of
thermo−physical effects in re−entrance problems, extending the URANUS−code to
three−dimensional calcula−tions and developing parallel algorithms.
108
Due to the expected very high computing efforts in three−dimensional non−equilibrium
calcula−tions, the task of the RUS consists of working out efficient parallel concepts in
order to achieve an optimal use of parallel architectures, considering especially the
problems of complex data dependencies and the (not necessarily constant) granularity.
The needed analysis of the sequential and parallel program, the program development
and further investigations are taking place on various platforms, such as the
PARIS−cluster which was installed together with the CRP (see also PARIS−Project).
For more information please contact:
Dr. Alfred Geiger
Tel. 0711/685−5719
Fax 0711/6788363
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: RSYST
Integration of Data and Programs using an
Object−Oriented Database System to Simulate
Technical−Scientific Applications
Data during a simulation run are enormously growing with the size and complexity of
prob−lems. To simulate, optimize and visualize such problems in an efficient way or to
validate the simulation results with measures of a real sys−tem, database systems are
needed to store and manage this huge amount of data. The data model describes the
data in a formal way.
The development of a parameterized object−oriented data model for multibody systems
en−ables to map this data on a database system. This data model defines the dynamic
and geo−metric properties of a multibody system. In order to use the data model, it must
be implemented by an object−oriented database system. The data model is independent
from the implemen−tation and suitable for symbolic and numeric multibody formalisms.
This DFG data model is implemented with RSYST. RSYST is a software system, which
integrates data, methods and models in a con−sistent environment. It is mainly used for
the simulation and design of engineering systems. The core of RSYST is an
object−oriented database to store and manage the application data as data objects. It is
also the interface for the integration of application programs into RSYST. The
development of integrated systems is supported by the user interface, the memory
man−agement system, the error−handling system, the output system and by the graphic
modules.
109
Fig.\x11 1:\x14 Cooperative Research via RSYST Integration
Computational modules and graphic modules are realized in RSYST as function
modules. A function module is an encapsulated program unit with interfaces to the user,
database, output system and system parameters. Since function modules are
independent units, modules can be removed and new modules can be added with−out
affecting other modules. This provides a reliable shell of service functionalities,
especially for the application programmer. This open architecture of RSYST is
extendable and adaptable to every problem.
Modules in RSYST are executed by a control program, called the control monitor. The
monitor provides a command language and can be used in interactive or in batch mode.
Complex prob−lems are solved by the execution of a sequence of modules, defined by a
macro, which is written with the command language and executed under control of the
monitor. The command language allows sequences of modules, conditional branches and
loops, e.g. to perform iterations. Between the modules, no direct communication is
allowed, instead data exchange is done via the database system. Complex computations
such as optimization loops and long−time simulations, may cause frequent modules
transitions. To speed−up the computation, RSYST provides a database version, which is
resident in main memory.
Because of this system architecture it is possible to integrate other modules from other
users and partners. The DLR Oberpfaffenhofen de−velop a commercial software
package, called ANDECS. ANDECS stands for Analysis and Design of Controlled
Systems and includes modules for simulation, multi−objective parameter optimization
and it is a flexible environment for the analysis and design of controlled dy−namic
systems.
For more information please contact:
Jochen Seybold
Tel. 0711/685−2047
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: RUS−DCE
A Pilot Project
in distributed Computing
In summer 1991, in cooperation and with some support from IBM, RUS initiated a
project to investigate the technologies of distributed computing.
110
At this time OSF−DCE was but an interesting blue print, but promised to offer the right
features and functionality. Hence we decided to evaluate the available ingredient
technologies, and to eventually offer these as new services to the users.
Fig.\x11 1:\x14 OSF − Distributed Computing Environment: Architecture
The first manifest result of the project was the introduction of xntp, which today is used
to synchronize all production machines and an un−known number of machines on and
out of campus.
By mid November 1991 we installed the first AFS cell in Germany. AFS is a secure and
truly distributed file system. Today AFS is widely used at the university, and it is an
important and integral part of the current production environment at RUS. The SERVus
cluster could not have been conceived in its present form and functionality without the
use of AFS.
Fig.\x11 2:\x14 CDS Name Space for the Stuttgart University Cell
Fig.\x11 3:\x14 DCE Security Space for the Stuttgart University Cell
Despite its lack of finer administrative granu−larity, AFS is the mature and widely used
production distributed computing environment available today.
It was our aim to get hold of OSF−DCE at an early stage. RUS participated in IBM’s
EPP (be−ta test) program for the AIX implementation of OSF−DCE. The DCE test cell
was configured in November 1992, and DFS was introduced in summer 1993. This by
now heterogeneous en−vironment has since stabilized and is in daily use by members of
the project team. Since summer 1994, when we participated in Cray’s field test for the
Unicos implementation of DCE/DFS, the Cray C94 is part of this scenario and exports
two file systems to the DFS file space.
We are now in the process of establishing a campus wide DCE production cell. This cell
will originally encompass five server machines to cater for the DCE core services and for
extend−ed−DFS. The two Crays will as well act as DFS servers, enabling the export of
their user file systems in an efficient and secure manner.
In defining the structure of this cell the sur−mounting goal is to allow the individual
uni−versity departments as much administrative freedom and autonomy as is possible
within the restraints of security. To this end, the fact that the whole DCE name space,
including even the security name space, is a tree structure, in com−bination with ACL’s,
will be utilized. One of the important consequences of this approach is, that the
university departments may thus man−age their own users. They may do so within a
campus wide environment, but in a secure manner, because they will manage them on a
central security service (Kerberos), which is run on servers maintained by the Computer
Centre.
This will realize the vision of one user having one username, one password, being able to
access all resources, machines, and data he is entitled to, while not being able to access
111
any re−source he is not entitled to. DCE will provide us with a secure and seamless
environment for scientific computing at the University.
Participants:
· Rechenzentrum der Universität Stuttgart
· IBM Stuttgart, Dept. Lehre und Forschung.
Collaboration with:
· Cray Research
· Fakultät Informatik der Universität Stuttgart
· Rechenzentrum der Universität Karlsruhe
· Regionales Rechenzentrum der Universität Köln
· Konrad Zuse Zentrum für Informationsverarbeitung, Berlin
· Computing Centre, Helsinki University of Technology.
For more information please contact:
Dr. Dieter Mack
Tel. 0711/685−5788
Fax 0711/682357
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: Software Labor
After a proposal of the University of Stuttgart has been granted, a software laboratory
will be set up. Main tasks of the software lab are:
· Cooperation between industry and university to develop modern software solutions
· Transfer of software technology and software engineering knowledge from university to
industry
· Improving education at the university with ex−periences and results gaining in the
projects.
112
The software laboratory includes several projects concerning workflow management,
telecommunication, parallel processing, graphical user interfaces, reusability of software
and si−mulation. Within the simulation project RUS/ICA cooperates with Daimler−Benz
AG and DASA Dornier. The scope of the subproject is the integration of vehicle
simulation packages using object−oriented design principles.
In the last decades various software tools have been implemented to calculate special
aspects of a product. In vehicle design and development you will find tools for drawings
(CAD), kinematic calculations, structure analysis and optimization (FEM), aerodynamics
and chassis dynamics (MBS). To avoid multiple data input couplings between two
software−applications are realized with data converters. The fast alteration in
software−technology and the rapid growing software−market leads to a great effort in
imple−menting processors for this data conversion. A recent tendency is the integration
of tools in the CAD environment, e.g. kinematical simulations. Underlying these systems
databases provide data persistency and enable data sharing in network computing.
Fig.\x11 1:\x14 Technical Scientific Integration Platform for Methods and Data
(Graphical User Interface)
Project: Software Labor
At RUS/ICA there is a lot of experience to integrate application systems. Over many
years RSYST as a scientific−technical data management system together with software
integration interfaces was developed. Within the software laboratory modern
technologies to integrate application software based on RSYST have to be evaluated.
Future development efforts will be spent in storing classes and objects. New
stand−ardized programming interfaces to manipulate data are considered (STEP/SDAI,
CORBA).
The resulting object−oriented features of RSYST must be validated with the prototypical
integration of tools in the domain of computer aided vehicle design.
For more information please contact:
Carsten Volle
Tel. 0711/685−5927
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: /sw
/sw − Software Installation Concept
113
A student’s project for distribution of ready to use installed software became the base for
the software installation concept of RUS. In meantime this project was funded by the
Ministry of Research to make available software at large scale in the country of
Baden−Württemberg. The project will be funded from DFN−Verein for two years.
/sw represents a network based concept, to manage the distribution of software
independent from:
· Hardware platform
· Operating system versions
· Provider and
· Software versions.
It has been realized at the RUS in 1992. To achieve this independence a directory tree is
created as a name room, which contains all this different components. All one has to do
for using /sw, is to mount the appropriate part of the tree via the network. Beyond the
executables the tree contains, documentation, libraries and man−pages.
The used file−networking software is AFS (Andrew File System) or NFS (Network File
System). Installation on the provider’s side is done by userfriendly installationscripts.
The conceptual simplicity is liked with a certain but af−fordable organizational effort.
One of the biggest challenges in this project is the coordination of all
Baden−Württemberg universities, who are willing to provide software for /sw and the
information of users how to get easily access to the software. In the meantime even users
in the US are using the software offered via afs in /sw.
In January 1995 the RUS provided on 13 architectures altogether 403 programs in 974
differ−ent installations.
· Architectures in /sw
· axp_osf1 DEC/Alpha running OSF/1 T2.0
· c90_uni8 Cray−C90 running Unicos 8.0.x
· hp700_ux90 Hewlett Packard 9000 Series 700 running HP−UX 9.0.x
· linux_1 Intel PC x86 running Linux 1.0.x
· paragon_12 Intel Paragon XP/S 5 running OSF/1 1.2
· pmax_ul43 DECstation 2100, 3100 or 5000 (single processor) Ultrix 4.3
114
· rs_aix32 IBM RS/6000 running AIX 3.2.5
· sgi_40 Silicon Graphics running IRIX 4.0.x
· sgi_52 Silicon Graphics running IRIX 5.2
· sun4_411 Sun SparcStations running Sun OS sun4_52 Sun SparcStations running
Solaris 2.3
· vax_ul4 VAX systems running Ultrix 4.2 and 4.3.
A list of available programmes and architectures can be found on our WWW Server:
http://www.uni−stuttgart.de/afs/rus/sw/doc/Soft.html/software_homepage.html
For more information please contact:
Barbara Burr
Tel. 0711/1319−111
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: TWIST
Multimedia Training integrated into the Object−Oriented
Simulation
Environment RSYST
Integrated concepts are necessary to handle entirely complex interrelations between
techni−cal components. These concepts lead to shorter innovation cycles and better
products. By this, the approach to solve a technical problem in its entirety requires the
further understanding of adjoined sciences, a good knowledge about the used tools and
some experiences in the be−haviour of complex technical systems. Therefore, the usage
of multimedia tools is of out−standing importance for the necessary teaching, training
and documentation system. Integrated into an object−oriented simulation environment
the hypermedia network offers some flexible and steerable possibilities of analysing
prob−lems. By separating link and information units it’s possible to get an
user−adaptive representation of the information space.
Some of the systems main characteristics are:
· User−adaptive structures
115
· Interactive linking without modification of the information sources
· Complete integration in a professional simulation environment
· Linking of semantic multimedia objects
(e.g. of different databases)
· Possibility to link external objects (outside the simulation environment)
· Integrated object−oriented data models for defining dynamic systems
· Interactive steering of parameterized simulations of dynamic systems.
Fig.\x11 1:\x14 Multimedia Object Set
For more information please contact:
Martin Noack
Tel. 0711/685−5934
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
Project: TWIST
IMG Contents IMG
Project: USPS
Forschungsschwerpunktprogramm des Landes
Baden−Württemberg
Fig.\x11 1:\x14 USPS − Universelle System Plattform Stuttgart
Programmable Gateway System
· Transitions between public & private networks
· Scalable multiprocessor supports protocol offloading
· Fixed and variable length packets or cells
· Custom−designed hardware:
e.g. 200−Mbyte/s SBus interface
116
· Uses standard operating kernels, network protocols and bus systems
Systems
· Sun SPARCstation
· CRAY C94D
· intel Paragon XP/S
Networks
· HIPPI, FCS
· ATM (STS−4)
· Optical WDM
Protocols
· TCP/IP, UDP/IP
· ATM Forum UNI
· Public ATM NNI
Fig.\x11 2:\x14 Module Demonstrator (HIPPI/ATM−Gateway)
For more information please contact:
Peter Haas
Tel. 0711/121−3647
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
IMG Contents IMG
Project: WiNShuttle
The Computer Center of University of Stuttgart RUS has got the assignment from the
DFN−Verein to build up an user−friendly access to the Scientific Network (WiN) over
dial−up lines in about twenty different places in Germany. The WiNShuttle project is
financed by the Federal Department of Education, Research, and Technology (BMBF).
117
The Idea
Electronic mail, information interchange, data transfer and dialogue − computer
communication over networks has become one of the most important forms of
communication of national and international research and scientific areas. It is s easier
for the user to offer and get scientific information by using multimedia data. WiN−
Shuttle offers the technical conditions to access these communications and information
facilities for people, who are interested in science and education. Small and average
science oriented business as well as cultural and social institu−tions or single scientists
can use WiNShuttle to get a large amount of Internet Services − even from home. The
educational field is of prime importance: Every school, every adult education school,
every teacher and student gets the possibility to use this electronic information. This
should guarantee the public duty of education, especially the preparation for the
sophisticated information society.
At the same time it is possible for all users to offer their own informations: information
about research results, library data and museum exhibits, about consulting offers,
colleagues, specific know−how etc.
The Technology
The so called "large shuttles" (internet access points) form the backbone of the service.
Small shuttles distribute the service to more towns. A large shuttle is equiped with a
server, a 2MBit/s WiN−connection, 60 dial−up−lines over ISDN and/or modems. A small
shuttle has 30 dial−up lines. All WiNShuttles offers different internet services like
World Wide Web (WWW), News, File Transfer Protocol (ftp) and electronic mail. Every
user of WiNShuttle will get a starter kit − a software packet, which is easy to install and
offers a simple and fast access to the network.
The Locations and the Time Plan
· Locations for large shuttles:
Berlin, Cologne, Munich, Stuttgart
· Small shuttles are planned in:
Augsburg, Bremen, Chemnitz, Dortmund, Dresden, Erfurt, Essen, Frankfurt/M.,
Hamburg, Hannover, Kiel, Leipzig, Mannheim, Münster, Nürnberg, Rostock.
The first Shuttle started up in December 1995 in Stuttgart. The other large shuttles will
start at the beginning of 1996. The small shuttles will start in the first quarter of 1996 −
according to demand.
The Offer
The fees are split into three groups:
118
1. Single persons, e.g. students, journalists or members of scientific−technical
institutions pay DM 39,95 for 20 hours access time each month
2. Public Institutions of the educational field, e.g. schools, librarys pay DM 49,95 for 40
hours each month
3. Technology transfer institutions, chambers and research−oriented companies pay DM
199,75 for 20 hours each month.
Detailed price informations and a booklet are available at the RUS, Department of
Information Services:
Barbara Burr
Allmandring 30
D−70550 Stuttgart
Germany
Fax 0711/1319203
E−Mail: [email protected]
IMG Contents IMG
Project: DFN Remote Procedure Call
DFN−RPC, a Remote Procedure Call tool, was designed to distribute scientific
applications across workstations and compute servers. DFN−RPC provides a uniform
platform for programm−ing communications interfaces in an easily learnable form in
order to allow the developers of distributed applications to concentrate on the technical
and scientific responsibilities of their disciplines. The DFN−RPC simplifies the most
important methods of distributed and parallel computing.
With Remote Procedure Calls (RPC’s), applications may be distributed without changing
the program model. Asynchronous, buffered asynchronous and parallel RPC’s allow an
efficient and easily programmable parallelization. Data pipes facilitate the forwarding of
messages. If the computers involved use different numbering systems, the data is
automatically converted during the transfer to that representing the destination system.
With automated process starting, parallel process structures can easily be built.
A configurative interconnection network can be established between the server
processes. Additionally the parallel application can be controlled from a graphics
monitor.
This provides the applications’ programmer with an uniform remote procedure call and
message passing tool for developing distributed applica−tions which makes transparent
not only the complexity of communication networks but also the differences in hardware
119
platforms.
Performance was enhanced through con−sequently minimizing the number of operating
system calls. The DFN is drafted for Fortran applications, but may also be used for C
applications. It was developed by order of the German Research Network (Deutsches
Forschungsnetz, DFN) under the project No. TK 558 VA 005.3. Sources and
documentation are available under the terms of the GNU (Library) General Public
License from
ftp://ftp.uni−stuttgart.de/pub/rus/dfn_rpc/ README_dfnrpc.html or.txt.
For more information please contact:
Rolf Rabenseifner
Tel. 0711/685−5530
Fax 0711/6787626
E−Mail: [email protected]−stuttgart.de
IMG
Contents IMG
Fachhochschule Isny der
Naturwissenschaftlich−Technischen
Akademie Prof. Dr. Grübler, gemeinnützige
GmbH
Friedrich Bergler
Hochschulort
Isny liegt in Baden−Württemberg unmittelbar an der Grenze zu Bayern. Isny ist
heilklimatischer Kurort und ein weithin bekannter Wintersportort, eingebettet in eine
herrliche Voralpenlandschaft. Zum Bodensee sowie in die Alpen benötigt man nur etwa
eine halbe Stunde mit dem Auto. Isny zählt ca. 10 000 Einwohner, darunter zur Zeit ca.
800 Studenten und Schüler der Akademie.
Die Akademie
Die Naturwissenschaftlich−Technische Akademie Prof. Dr. Grübler GmbH ist eine der
größten privaten Ausbildungsstätten im berufsbildenden Be−reich in der
Bundesrepublik Deutschland. Zu ihr gehören eine Fachhochschule mit den
Fachbereichen Chemie, Physik und Informatik sowie 6 Berufskollegs zur Ausbildung
120
von technischen Assistenten in den Bereichen Chemie, Datentechnik, Medizin,
Pharmazie, Physik und Um−weltschutz.
Die Akademie kann inzwischen auf eine 50−jährige Ausbildungstradition zurückblicken
und ist wegen ihrer praxisnahen Ausbildung sowie ihrer guten Kontakte zur Industrie
weithin bekannt.
Die Studiengänge an der staatlich anerkannten Fachhochschule
An der Fachhochschule gibt es die Studiengänge
· Allgemeine Physik
· Physikalische Elektronik
· Informatik mit den Schwerpunkten Softwaretechnik, Kommunikationstechnik und
Automationstechnik
· Chemie mit den Schwerpunkten Allgemeine Chemie und Lebensmittelchemie und
· Pharmazeutische Chemie
Die Studiengänge Pharmazeutische Chemie und
Phyikalische Elektronik sind in der Bundesrepublik
einzigartig.
An der FH Isny studieren derzeit ca. 350 Studenten und Studentinnen.
Einen Numerus Clausus gibt es nicht; die Aufnahme erfolgt in der Reihenfolge der
Anmeldungen. Der Studienbeginn ist jeweils nur im Winter−semester möglich.
Rechnerinstallationen
Das Kernstück der Rechnerausstattung bildet ein Ethernet−Verbund aus 30
IBM−RS/6000−Workstations (Modelle 220 und Power−PC 250), Unix−Systemen von
SUN und NEXT sowie 15 486er−PCs. Als Server dienen eine RS/6000−340, eine
RS6000−3AT sowie ein PC mit Pentium−Prozessor und 1GB−Platte.
In das Netz sind verschiedene Druckermedien −Laser−, Tintenstrahl− und
Nadeldrucker − sowie externe Platten, CD−ROM− und Streamer−Laufwerke integriert.
Anbindungen bestehen ferner an ein Token−Ring−Netz mit IBM−PS/2−Modellen, das
unter Novell betrieben wird, sowie an ein Unix−System der Firma BULL mit weiteren
16 a−synchron angeschlossenen PC−Arbeitsplätzen.
Seit Oktober 95 hat die FH Zugang zum BelWü.
121
Anschrift
Fachhochschule Isny
Naturwiss.−Technische Akademie
Prof. Dr. Grübler, gemeinnützige GmbH
Seidenstraße 12−35
D−88316 Isny
Tel.: 07562/97070
Fax: 07562/970771
Ansprechpartner
Rektor
Prof. Dr. Willy Dilger
Tel.: 07562/9707−12
Bereich Chemie/Umweltschutz
Prof. Dr. Wolf Dammertz
Tel.: 07562/9707−55
Bereich Pharmazie/Medizin
Prof. Dr. Wolfgang Ilg
Tel.: 07562/9707−48
Bereich Physik/Informatik
Prof. Dr. Friedrich Bergler
Tel.: 07562/9707−52
Contents IMG Contents IMG
Der Südwestdeutsche Bibliotheksverbund
Wolfgang Heymans
122
Der Südwestdeutsche Bibliotheksverbund (SWB) ist eine
kooperative Einrichtung der Universitäten
Baden−Württembergs, der Träger ist das Ministerium für
Wissenschaft und Forschung
Er wurde 1983 gegründet für die wissenschaftlichen Bibliotheken der Leihregion
Baden−Württemberg, südlicher Teil von Rheinland−Pfalz und Saarland, die Zentrale
wurde an der Universität Konstanz eingerichtet.
Die Aufgaben des Verbund sind
· Bereitstellung einer Online−Datenbank für die kooperative Katalogisierung von
Monographien und anderer Medien der Teilnehmerbibliotheken
· Nachweis der so zentral erfaßten Materialien für die Auskunft in Bibliotheken, den
Leihverkehr zwischen den Bibliotheken sowie für den Wissenschaftler direkt an seinem
Arbeitsplatz
· Zeitschriftennachweis der Bibliotheken aus der Südwestregion und Sachsen sowie
weiterer Verbundbibliotheken aus anderen Regionen (Auszug aus der beim DBI
betriebenen Zeitschriftendatenbank)
· Bereitstellung von Normdateien / Fremdkatalogisaten zur Unterstützung der
Katalogisierung
· Periodische Rücklieferung der Katalogdaten an die Teilnehmerbibliotheken zum
Aufbau und zur Aktualisierung ihrer Lokalsysteme (OPACs).
1986 begann der Routinebetrieb mit fünf katalogisierenden Bibliotheken, 1991 traten
die wissenschaftlichen Bibliotheken Sachsens auf−grund eines Kooperationsvertrages
dem SWB bei. Die saarländischen Bibliotheken nutzen den Verbund derzeit nur zur
Recherche.
Der SWB wird 1996 in das neu zu errichtende Bibliotheksservicezentrum
Baden−Württemberg, eine unselbständige Anstalt des öffentlichen Rechts, integriert.
Teilnehmer (Stand: Januar 1995)
471 aktive Teilnehmerbibliotheken
(mit eigenen Monographien− und Zeitschriftennachweisen) und zwar
4 Landesbibliotheken
Dresden, Karlsruhe, Speyer, Stuttgart
14 Universitätsbibliotheken mit
123
352 Institutsbibliotheken
Chemnitz, Dresden, Freiberg, Freiburg, Heidelberg, Kaiserslautern, Karlsruhe,
Konstanz, Leipzig, Mannheim, Stuttgart, Stuttgart−Hohenheim, Tübingen, Ulm
101 weitere Bibliotheken
25 Fachhochschulen, 5 Pädagogische Hochschulen, 3 Berufsakademien,
7 Max−Planck−Institute, 4 Bundesbehörden, 7 Kirchliche Einrichtungen,
8 Museen, 3 Kommunale Bibliotheken, 5 Gymnasial− und Schulbibliotheken,
4 Archive, 30 sonstige Bibliotheken
515 weitere Bibliotheken
von denen ausschließlich die Zeitschriftenbestände im Verbund nachgewiesen sind
104 passive Teilnehmer
Institutionen, Bibliotheken und Firmen des In− und Auslands, die recherchieren, aber
nicht katalogisieren.
Datenbanken
Die Daten (siehe Tab. 1) werden in zwei Datenbanken bereitgehalten,
· in der Katalogisierungs−Datenbank für die aktive Katalogisierung und
· in der Recherche−Datenbank für Auskunft und Fernleihe.
Tab.\x11 1:\x14 Der gesamte Datenbestand des Verbundes
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Stand 01.01.1995 Zuwachs 1994
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Titelaufnahmen
4.060.000
578.000
davon:
Monographien
3.755.000
562.000
Zeitschriften 305.000
16.000
Bestandsnachweise
9.196.000
1.890.000
davon:
Monographien
8.443.000
1.830.000
Zeitschriften 753.000
60.000
Autorenansetzungen
1.360.000
160.000
Körperschaften (GKD)
503.000
39.000
Schlagwortsätze (SWD+lokal)
443.000
131.000
Fremddaten
3.492.000
329.000
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Der SWB wiederum beliefert neben den Lokalsystemen seiner Teilnehmer den
überregionalen Verbundkatalog (VK) des Deutschen Bibliotheksinstitut (DBI), das
GEROMM/EROMM−Projekt in Göttingen, sowie weitere Institutionen.
Die SWB−Datenbanken werden auf einer Siemens−Nixdorf−Anlage H90−A2 unter
BS2000 im Rechenzentrum der Universität Konstanz bereitgehalten, das für das
Operating des Rechners verantwortlich ist.
124
Die Verbunddatenbank läuft unter dem Softwaresystem BIS der Firma DABIS, mit
anwendungsspezifischen Erweiterungen und Anpas−sungen der Verbundzentrale.
Dieses System stellt eine klassische Großrechnerlösung dar, als Endgeräte beim
Benutzer wurden zunächst \xe3 dumme" Terminals eingesetzt. Inzwischen haben sich
weitgehend PCs mit Terminalemulationen als Endgeräte durchgesetzt.
Für den Dienstgebrauch der Bibliothekare stehen spezielle Terminal−Emulationen zur
Verfügung, Endbenutzer können mit einer VT100−Emulation zeilenorientiert
recherchieren.
1994 hat die Verbundzentrale mit der Entwicklung einer Recherche−Oberfläche für
WWW−Browser nach dem Vorbild des WWW−Gateway im norwegischen
BIBSYS−System begonnen. Dieser WWW−OPAC ist inzwischen freigegeben und
entwickelt sich zum bevorzugten Zugang für den Endnutzer, den Wissenschaftler am
Ar−beitsplatz.
Weitere Informationssysteme
Informationen über Bibliotheken (BIBINFO)
BIBINFO ist ein neu entwickeltes Informationssystem des SWB mit Auskünften wie
Adresse, Telefonnummer, Öffnungszeiten, Fernleihinformationen usw. von Bibliotheken
aus dem In− und Ausland.
BIBINFO ist eine WAIS−Datenbank und wird im WWW mit Links zu lokalen
Informationssystemen und OPACs angeboten, sowie ohne Suchmaschine per FTP als
Verzeichnis der Teilneh−merbibliotheken.
FTP−Server
Auf dem FTP−Server der Verbundzentrale stehen sämtliche Informationen und
Dokumentationen des SWB (z.B. Merkblätter, SWB−Format,
SINDBAD2−Dokumentation) als Text− und PostScript−Dateien zur Verfügung.
WWW−Server
Neben Informationen zum SWB und dem WWW−Zugang zur Recherchedatenbank bietet
der WWW−Server des SWB in erster Linie Navigationshilfen im Internet zu Themen
aus dem Bibliotheksbereich. Ein zweiter Schwerpunkt ist der Kulturraum EUREGIO
Bodensee mit Kulturinformationen rund um den Bodensee.
Für diese Informationssysteme betreibt der SWB einen Internet−Server (SUN
SPARCserver 20).
125
Datennetze
WiN / DATEX−P
Der SWB ist über zwei eigene 64KBit/s−Anschlüsse mit zusammen 400 logischen
Kanälen an das WiN−Netz des DFN−Verein angeschlossen. Diese Leitungen sind
ausschließlich für den Terminaldialog reserviert. Der Zugang zum BS2000−Host erfolgt
über einen X.25−Vorrechner.
BelWü
Über das LAN der Universität Konstanz ist der SWB an das BelWü angeschlossen, alle
IP/Internet−Anwendungen laufen über diese Verbindung. Das RZ der Universität
Konstanz stellt hierzu die Netz−Infrastruktur zur Verfügung. Durch die starke
Unterstützung des Landes für das BelWü−Netz steigt auch der Dialogverkehr mit der
Datenbank über diese Verbindung weiter an. Die BIS−Datenbank ist jedoch nur über
X.25 erreichbar, daher betreibt der SWB zwei TELNET/X.29−Gateways mit je 128
Kanälen. IP−Anwender können auch das Stuttgarter Gateway des DFN−Verein nutzen.
Insgesamt sind in Spitzenzeiten über 500 logische Verbindungen zur Datenbank aktiv.
Die Verbundzentrale selbst ist seit Mai 1995 nicht mehr auf dem Campus der
Universität, sondern etwa 4 km entfernt im Konstanzer Industriegebiet untergebracht
und mit dem Campus über eine digitale 2MBit/s−Festverbindung der Telekom
verbunden.
Diese Verbindung wird für Sprache, Fax und Daten genutzt, an die Multiplexer SIMUX
3638 (OEM Fa. SIEMENS, Hersteller NEWBRIDGE) auf beiden Seiten sind jeweils
Telefonnebenstellenanlage, X.25−Switch und CISCO−IP−Router angeschlossen.
Unsere Netzadressen
Recherche und Katalogisierung mit BibWork oder SINDBAD2/ANSINET
WIN, Datex−P:
45050263000,45050060017, 45050262300
Internet (Telnet/X.29):
gw1.swbv.uni−konstanz.de,
(Login: swb1)
x29.swbv.uni−konstanz.de,
Port 2340
Recherche mit WWW−Browser
WWW:
http://www.swbv.uni−konstanz.de/CGI/cgi−bin/opacform.cgi
126
Linemode−Recherche mit VT100−Terminal (Emulation), Kermit etc.
WIN, Datex−P:
45050262357
Internet (Telnet/X.29):
gw1.swbv.uni−konstanz.de,
(Login: swb3)
Info im Störungsfall
WIN, Datex−P:
45050262355
Internet (Finger):
finger [email protected]−
konstanz.de
Internet (E−Mail):
[email protected]−konstanz.de
Allgemeine Informationsangebote
WWW:
http://www.swbv.uni−konstanz.de/homepage.html
FTP:
ftp.swbv.uni−konstanz.de
Ausblick
In den nächsten Jahren wird das jetzige Verbundsystem auf Großrechnerbasis durch
eine Client−Server−Architektur auf Unix−Systemen ab−gelöst werden. Als erster
Schritt wird Ende 1995 das System BIS2000 der Fa. DABIS beim SWB auf einem
Unix−Server installiert. Im Rahmen des DBV−OSI−Projekts wird dieses System mit
einem Z39.50−Zugang ausgestattet. Ein entsprechender PC−Client mit grafischer
Oberfläche, der den Zu−gang zum SWB, den DBV−OSI−Partnern und an−deren
Z39.50−Datenbanken weltweit gestattet, wird dann ebenfalls zur Verfügung stehen. Im
ersten Halbjahr 1996 wird dieses System die Re−cherchedatenbank übernehmen, das
BIS−Sy−stem unter BS2000 ist dann ausschließlich für die Katalogisierung reserviert.
Parallel dazu ar−beitet der SWB mit dem Nordrhein−Westfälischen und dem
Bayerischen Verbund sowie mit dem Deutschen Bibliotheksinstitut in Berlin zusammen,
um gemeinsam ein zukunftsorientiertes Verbundsystem zu erwerben.
Contents IMG Contents [IMAGE] Die obige Tabelle führt die Rechner im BelWü auf, von
127
denen Sie Informationen bzw. Software erhalten können.
Für den Zugang per ftp lautet der Loginname anonymous oder ftp; als Passwort sollten
Sie Ihre eigene Mailadresse verwenden. Bitte achten Sie beim Gebrauch von ftp darauf,
möglichst nahegelegene bzw. lokale FTP−Server zu verwenden, um die Wide
Area−Leitungen und insbesondere die internationalen Zugänge zu ent−lasten. Ein
Werkzeug zum Auffinden von per anonymous ftp verfügbaren Dateien ist der
Archie−Server (z.B. archie.belwue.de). Als Zu−gangsmöglichkeit gibt es telnet (login:
archie), Mail ([email protected]) mit \xe3 prog <Dateiname>" als Subject (ohne
Anführungszeichen und spitzen Klammern), oder am besten ein lokales
Abfrageprogramm wie archie oder xarchie (erhältlich z.B. auf ftp.uni−stuttgart.de unter
/pub/unix/comm/infosystems/archie). Der Archie−Server läuft an der Universität
Heidelberg (archie.th−darmstadt.de).
Für den Zugang mit WWW benötigen Sie eine entsprechende Zugangssoftware
(Browser) auf Ihrem Rechner (z.B. netscape, mosaic oder lynx), erhältlich z.B. auf
ftp.uni−stuttgart.de unter /pub/comm/infosystems/www/clients
Den Stuttgarter Infoserver können sie zusätzlich mit pad/x29 erreichen: 45050066911
lautet hierfür die X.25−Adresse. Der Karlsruher Infoserver ist zusätzlich per Modem mit
7 Bit, Even Parity anwählbar: 0721/358733, 358734, 60451, 60453 lauten hierfür die
Telefonnummern.
Auf dem Stuttgarter Infoserver finden Sie im Verzeichnis /pub/org/belwue bzw. den
entsprechenden Unterverzeichnissen Benutzerhandbücher (Rechnernetze, Nameserver,
Nutzerinformation), BelWü−relevante Dienste (Dienste−Liste, sendmail.cf) und weitere
Dokumente (BelWü−Spots). Hardkopien können Sie über Herrn Klank beziehen
(0711/685−2506, [email protected]−stuttgart.de).
Aktuelle Informationen (insbesondere Netzstörungen) werden auch über die
News−Gruppe BelWü verteilt.
BelWü−Teilnehmer, die keinen eigenen News−Server besitzen, können die
new.belwue.de (129.143.4.4) als News−Server für den Newsreader benutzen.
Newsreader für Unix, MS−DOS und VMS im Sourcecode können Sie beispielsweise auf
ftp.uni−stuttgart.de im Verzeichnis pub/comm/news/beginner/software finden.
Für verschiedene Unix−Rechnerplattformen fertig kompilierte Public Domain Software
erhalten Sie über das /sw−Projekt, das von den Universitäten Stuttgart und Tübingen
betreut wird. Zugriffsmethoden sind ftp, AFS oder NFS. Näheres finden Sie auf
ftp.uni−stuttgart.de in /sw/doc/sw−*
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
BelWü−Beauftragte
Willibald Meyer
Universität Freiburg Rechenzentrum
Hermann−Herder−Str. 10
79104 Freiburg
0761/203−4622
[email protected]−freiburg.de Hartmuth Heldt
Universität Heidelberg Rechenzentrum
Im Neuenheimer Feld 293
69120 Heidelberg
128
06221/54−5451, Fax: −5581
[email protected]−heidelberg.de Andreas Tabbert
Universität Hohenheim Rechenzentrum
Schloß Westhof−Süd
70593 Stuttgart
0711/459−2838
tabbert@uni−hohenheim.de Brian Worden
Regionales Hochschulrechenzentrum
Postfach 3049
Paul−Ehrlich−Straße
67653 Kaiserslautern
0631/205−2448
worden@uni−kl.de Dr. Bruno Lortz
Universität Karlsruhe Rechenzentrum
Zirkel 2
Postfach 6980
76128 Karlsruhe
0721/608−4030
[email protected]−karlsruhe.de Jörg Vreemann
Universität Konstanz Rechenzentrum
Postfach 5560
78434 Konstanz
07531/88−3893
joerg.vreemann@uni−konstanz.de Ralf−Peter Winkens
Universität Mannheim Rechenzentrum
L15,16
68131 Mannheim
0621/292−5781, Fax: −5012
[email protected]−mannheim.de Dr. Lisa Golka
Rechenzentrum der Universität Stuttgart
Allmandring 30
0550 Stuttgart
0711/685−5983
[email protected]−stuttgart.de Dr. Heinz Hipp
Universität Tübingen
Zentrum für Datenverarbeitung
Brunnenstr. 27
72074 Tübingen
07071/29−6967, Fax: −5912
[email protected]−tuebingen.d400.de Karl Gaissmeier
Universität Ulm Rechenzentrum
Albert−Einstein−Allee 11
89069 Ulm
0731/502−2499
[email protected]−ulm.de BelWü−Koordination Rechenzentrum der Universität
Stuttgart
Allmandring 30
70550 Stuttgart
belwue−[email protected] Betrieb und Dienste
129
Peter Merdian
0711/1319−129
[email protected]−stuttgart.de
Jürgen Georgi
0711/685−5739
[email protected]
Joseph Michl
0711/1319−131
[email protected] Entwicklung und Projekte Paul Christ
0711/685−2515
[email protected]−stuttgart.de hris Copplestone
0711/685−5987
[email protected]−stuttgart.de Peter W. Haas
0711/121−3647
[email protected]−stuttgart.de BelWü−Maillisten
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
netz−[email protected]
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Inhaltsverzeichnisse aller BelWü−Spots
Die Ausgaben der BelWü−Spots können Sie über die BelWü−Koordination
(Rechenzentrum der Universität Stuttgart, Allmandring 30, 70550 Stuttgart, Tel.:
0711/685−5804, belwue−[email protected]) beziehen. Im übrigen sind die
Ausgaben in verschiedenen Formaten (TeX, PostScript, HP) auf dem Stuttgarter
Infoserver (Verzeichnis pub/org/belwue/spots) erhältlich.
Seite
Ausgabe 1/91:
Landesforschungsnetz BelWü (Kurzinfo)
GENIUS: Ein Dienst für Biologen und Mediziner,
DKFZ Heidelberg 2−12
FH Esslingen/FH Heilbronn 13−15
Seite
Ausgabe 2/91:
Netzgraphik und "NetCentral Station" 1/2
Anwendersoftware im BelWü 4−46
KOALA: Die UB im Netz, Uni Konstanz 47−52
130
FH Aalen/FH Mannheim 53−56
Seite
Ausgabe 3/91:
BelWü−Verkehrsmatrix 1−5
BelWü AK tagt in Heidelberg 6/7
Fachinformationszentrum Karlsruhe (FIZ) 8−11
Akademische Software Kooperation (ASK) 12−18
FH Reutlingen/Uni Hohenheim 19−27
Seite
Ausgabe 4/91:
In aller Kürze.... 2
Anfragen an die WHOIS−Datenbank 3−7
Das Projekt HD−NET an der Uni Heidelberg 8−19
Ergänzungen der Dienste−Liste der Spots Nr. 2 20−25
FH Furtwangen/FHT Stuttgart 26−29
Seite
Ausgabe 1/92:
In aller Kürze.... 2
Infoserver 3−11
News im BelWü 12−16
X.500 − Directory im BelWü 17−28
Universität Tübingen 29−43
Seite
Ausgabe 1/94:
In aller Kürze.... 2
Mosaic:
Alles unter einem Dach 3
Mosaic Kurzreferenz 8
UDINE: Universal Document Information an Navigation Entry 11
Das Informationssystem Gopher 16
Filetransfer 19
VILLA BelWü 23
Universität Karlsruhe 27
Berufsakademie Mannheim 78
Berufsakademie Ravensburg 81
131