Electronic Mail an der Universität Karlsruhe

Neues Konzept

Der folgende Beitrag beschäftigt sich mit den Neuerungen im Bereich Electronic Mail, die auf Institute bzw. Nutzer in nächster Zeit zukommen werden. Ausgelöst wurden die konzeptionellen Fortschreibungen im wesentlichen durch geänderte Randbedingungen:

• Rapid zunehmende Mißbrauchsaktivitäten im Internet-Mailbereich wie Zusenden von Werbemüll (Spam mail), Mißbrauch fremder Mailports zum Versenden von Spams (Spam relay).

• Bewilligung (HBFG) eines leistungsfähigen, ausfallgesicherten Internet-Serverpools.

• Einführung einer neuen, (durch RZ-Eigenentwicklung) flexiblen Benutzerverwaltung.

• Zunehmende Verbreitung von PC-basierten Mailprogrammen (Mail clients, Mail user agents/MUAs) mit Pop(3)-Zugriff (Post Office Protocol, Variante 3), und inzwischen auch IMAP-Zugriff (Internet Message Access Protocol), einer leistungsfähigeren Protokollvariante, die statt eines Pop-Servers einen IMAP-Server für den Mailzugriff voraussetzt.

• Gestiegene Anforderungen an die Dienstgüte, z. B. Zuverlässigkeit, die auch höhere Überwachungsanforderungen stellen und damit ein zentraleres Mailmanagement zumindest nahelegen.

• Es setzt sich mehr und mehr die Erkenntnis durch, daß der Ruf einer Institution, z. B. der Uni, bereits durch das Fehlverhalten einzelner Personen oder Komponenten, nachhaltig beeinträchtigt werden kann.

• Ablösung des bisherigen zentralen Mailersystems (pp) durch ein moderneres System (exim). Dies wird möglich, da das (ISO-)Mailprotokoll X.400 an der Uni und auch allgemein im technisch wissenschaftlichen Bereich keine Rolle mehr spielt.

• Steigende Anforderungen an einerseits die Flexibilität von Mailadressen (bzgl. Format), andererseits an ihre Konstanz.

• Nachlassende Bedeutung des X.500-Directory als weltweit vernetztes Adreßbuch. Trend: WWW-Konnektivität zwischen eigenständigen, lokalen Directories bzw. Benutzerverwaltungen.

Nachfolgend soll auf die Konzeptionen eingegangen werden, die den geänderten Randbedingungen in den diversen Teilbereichen Rechnung tragen sollen. Weitere Informationen finden Sie unter http://www.uni-karlsruhe.de/Uni/RZ/Netze/Mail/#Konzept.

‘Mißbrauch’ (Spam, Spam relay)

Da beiden Mißbrauchsarten derzeit juristisch kaum oder gar nicht beizukommen ist, bietet sich als alleiniger Ausweg an, das Problem technisch in den Griff zu bekommen, wobei sich zunächst die Frage stellt, ob jeder der ca. 13.000 Rechner auf dem Unicampus einzeln abgesichert werden soll bzw. kann, oder der Campus durch zentrale Filterfunktionen (Mailfirewall) für Spam und Spam relay insgesamt geschützt werden soll. Diese Problematik wird unter: http://www.uni-karlsruhe.de/Uni/RZ/Netze/Mail/konzept_missbrauch_u.html und als Übersicht unter: http://www.uni-karlsruhe.de/Uni/RZ/Netze/Mail/konzept_missbrauch_d.html etwas mehr in die Details gehend abgehandelt bzw. diskutiert, wobei die ‘zentrale’ Lösung des Problems sich letztlich als einzig sinnvolle darstellt (vgl. Abbildung 1). Eine bildliche Darstellung der zentralen Lösung zeigt, daß alle an die Uni adressierten Emails (wie bisher) zum BelWü-Router gelangen, und von dort (mit Ausnahme von ATIS, früher Informatik - Rechnerabteilung IRA ) an zwei Mailer innerhalb eines ausfallgesicherten Internet-Serverpools des RZ weitervermittelt werden.

Abbildung 1

Der eine Mailer ist wie bisher für den RZ-administrierten Mailbereich zuständig, der andere nimmt - als fest konfigurierter Mailforwarder, in etwa vergleichbar einem Router - die Mails für die restliche Uni an. Sobald der jeweilige Campusmailer (im Institut, Wohnheim, Fachschaft o. ä.) empfangsbereit ist, was leider häufig nicht der Fall ist, wird die Mail weitervermittelt. Da dieser zentrale Server zuverlässig Mail entgegennimmt, andererseits eine viel zu hohe Anzahl von Campusmailern die an sie gestellten Serveranforderungen nicht erfüllen, und mitunter Stunden bis Tage keine Mails annehmen, z. B. wegen Abschaltung, verbessert sich die Abnahmequalität und damit die Außenwirkung der Universität.

Beide Mailer wirken in Verbindung mit dem vorgeschalteten Router “beschützend”, d. h. verhindern jeglichen Mißbrauch eines Unirechners im Sinne von ‘Spam relay’. Diese Unterdrückung von Spam relay ist unbedingt notwendig, da Rechner bzw. Domänen, die Spam relay zulassen, sich der Gefahr aussetzen, von der Internet-Community ‘geächtet’ zu werden und so ihre Mailkonnektivität zu verlieren.

Die Mailer bieten auch gute Ansätze zum Ausfiltern von ‘Spams’ bzw. sonstiger fahrlässig bis böswillig losgetretener Massenmails wie ‘Mailbombs’, ‘Mailloops’ und dergleichen. Die Filterung kann sowohl auf Userebene, als auch zentral erfolgen, wobei die ‘Policy’ (Absprache, Vereinbarung, Regeln) für zentrales Filtern einvernehmlich mit den Betroffenen entwickelt oder zumindest transparent und diskussionsfähig gehalten werden muß, sofern es sich nicht um die Abwendung akuter Betriebsgefährdung handelt.

Bei Gefahr einer Betriebsstörung wird - sozusagen auf Zuruf - eine dem Problem entsprechende Filterfunktion entwickelt und initialisiert, die die Problemmails nicht mehr in die Uni läßt, sondern ante portas abschmettert, wobei grundsätzlich auch automatisierte Verfahren, z. B. für unüberwachte Zeiten, zum Zuge kommen könnten.

Realisierung des Konzepts bezüglich Mißbrauch
In diesem Bereich liegt bereits eine gewisse Betriebserfahrung vor, da seit mehreren Monaten ein neuer Mailer (nz15/exim), die alte Mailerumgebung (nz11/pp) und einige Institute vor ‘Spam relay’ schützt.

Die Portierung der jetzigen nz15- und nz11-Funktionen auf den neuen Internet-Serverpool ist vorbereitet und wird in den nächsten Wochen erfolgen.

Erst nachdem ausreichend positive Betriebserfahrungen mit dem neuen System vorliegen, d.h. keinesfalls als Automatismus, wird ein testweiser Probebetrieb gemäß Konzept eingeführt: Alle Mails (ausgenommen ATIS) laufen über die zentralen Mailer des RZ, der Mailport aller Unirechner ist dann von außerhalb, bezogen auf den BelWü-Router, nicht mehr ansprechbar.

Nutzerzugriff auf Email

Für den Mailempfang ist dies üblicherweise ein Pop(3)-Server (Post Office Protocol/Variante 3), der die auf dem Server wartende Mail eines Benutzers vom Server-Mailspool zum PC übermittelt.

Eine modernere und leistungsfähigere Variante zu Pop ist IMAP, das am RZ bereits seit geraumer Zeit im Testbetrieb läuft (zwei IMAP-Server), aber noch nicht zur allgemeinen Benutzung freigegeben ist. Pop und IMAP werden vermutlich lange Zeit koexistieren, die strategische Bedeutung von IMAP dürfte aber höher einzustufen sein, da es z. B. bezüglich Mail- und Folderbearbeitung konzeptionell für wechselnden Zugriff (von daheim, unterwegs, Dienststelle) besser geeignet ist.

Für den Versand der Mails vom PC ins Internet bedienen sich die Mailprogramme in der Regel eines sogenannten SMTP-Servers. Dieser nimmt die Mails vom PC entgegen und vermittelt sie weiter.

Abbildung 2

In Abbildung 2 ist das Szenarium dargestellt, wobei diese Mailumgebung in verschiedener Hinsicht sozusagen der Idealfall wäre, nicht zuletzt vom Mailmanagement her, da es nur wenige und damit auch leichter überwachbare und ersetzbare Komponenten gibt (Ausfallsicherung, vgl. Abbildung 2).

Die tatsächliche Umgebung sieht allerdings noch deutlich unordentlicher aus (‘Sendmail-Verhau’ u. ä.). Deshalb wird in nächster Zukunft angestrebt, alle Mails zentral auszuliefern und diese zum Campus zu ‘exportieren’ (Ersetzen von Sendmail- durch NFS-Verbindungen).

Die IMAP/Pop-Servermaschine (vgl. Abbildung 2) soll letztlich alle RZ-Accounts bzw. Benutzer bedienen können, wobei dieser Service vorläufig zweigeteilt sein wird:

• Alter Bereich: Hier wird - wie gehabt - ‘ungesichert’ auf die Mail zugegriffen. Der Vorteil ist, daß sozusagen alle Mailprogramme hierfür (weiter) benutzt werden können. Der Nachteil ist, daß alle Daten, auch Paßwörter, unverschlüsselt über das Netz gehen und damit grundsätzlich abgehört werden können.

• Neuer Bereich (Internet-Serverpool): Hier wird ‘gesichert’ auf die Mail zugegriffen (ssl-Verfahren) mit dem Nachteil, daß Client- und Serverseite zusammenpassen müssen, was während einer Übergangszeit sich noch recht prohibitiv für eine stärkere Nutzung auswirken dürfte.

Abbildung 3

Adressenverwaltung (Ablage, Zugriff, Pflege)

Zwingend notwendig ist dabei nur die Zustelladresse, wobei diese aber eher temporären Charakter hat und insofern der zunehmenden Forderung nach langfristigen bis ‘ewigen’ Mailadressen in der Regel nicht gerecht werden kann.

X.500 -Directory
Seit Jahren betreibt das RZ für die Universität das sogenannte X.500, ein Adreßbuch (Directory) mit mehreren tausend freiwilliger (per X.500-Antrag) Einträge, das den oben gemachten Ausführungen insofern Rechnung trägt, als eine ‘ewige’, aussagekräftige und damit grundsätzlich errat- bzw. konstruierbare Mailadresse automatisch zu jedem Eintrag erzeugt wird (generische Mailadresse). Jeder Nutzer kann via WWW seiner X.500-Adresse eine frei wählbare zweite Mailadresse zuordnen.

An diese zweite Mailadresse wird dann - im Sinne eines Nachsendeauftrags - die Mail ausgeliefert. Selbst nach Verlassen der Universität funktioniert die generische Mailadresse - solange gewünscht - weiter, indem der Universitätsangehörige via WWW selbst die jeweils von ihm gewünschte Auslieferung einträgt (Beispiel: Anfragen zu Veröffentlichungen können noch beantwortet werden, auch wenn der Autor längst die Uni verlassen hat. Eine Nichtzustellbarkeit würde mangelnde Professionalität bekunden).

Benutzerverwaltung
Nachdem X.500 - wie eingangs erwähnt - an Bedeutung verloren hat, andererseits das RZ ein neues Benutzerverwaltungssystem entwickelt hat, mit dem ungleich flexibler auf diverse Wünsche und Anforderungen eingegangen werden kann, wird das System seit geraumer Zeit in den Mittelpunkt aller Überlegungen zu Verbesserungen und Erweiterungen in diesem Bereich gestellt.

Das Konzept sieht inzwischen vor, das X.500 ‘stoßfrei’ in die neue Benutzerverwaltung überzuführen, wobei die bisherigen Funktionen beibehalten, ansonsten aber auch funktionale Fortschreibungen vorgenommen werden:

• Größere Flächendeckung durch Einbeziehung in das  normale Antragswesen (separater X.500-Antrag entfällt)

• Funktionale Erweiterungen

• Keine doppelte Datenhaltung wegen der Gefahr von Inkonsistenzen

• Offen für zukünftige Anforderungen. Als Beispiel wäre die an anderer Stelle beschriebene Erweiterung der Mailadreßformate zu nennen, die ohne Benutzerverwaltung nicht hätte in Angriff genommen werden können.

• Professioneller Zugriff via WWW:
  • Daten und Paßwort laufen (via ssl) verschlüsselt über das Netz
  • Jede Uni-domain hat eine eigene Benutzerverwaltung
  • Es gibt "account-basierte"
  • und freie Einträge d. h. Einträge von Universitätsangehörigen, die entweder die Uni verlassen haben oder die nicht vom RZ administriert werden
  • Der Zugriff auf die Daten erfolgt unter Beachtung datenschutzrechtlicher Belange auf mehreren Hierarchie-Ebenen:
    • Ebene 0: Administrator der Benutzerverwaltung (alles schreiben, alles lesen)
    • Ebene 1: EDV-Beauftragter (alles lesen, partiell schreiben für Gruppe/Institut)
    • Ebene 2: Benutzer an der Universität (alles lesen, partiell schreiben bzgl. eigenem Eintrag)
    • Ebene 3: Sonstige (begrenzte Recherchiermöglichkeit, soweit Belangen des Datenschutzes und der Mißbrauchsverhinderung, wie z. B. dem extensiven Sammeln von Adressen, Rechnung getragen werden kann).

Erweiterung der Mailadressen (User-Aliase, Maildomains)

Bisherige Formate, soweit langfristig sinnvoll:

• Abkürzungen:
  <(p-)fak> => (Pseudo-)Fakultät
  Entweder ‘Fakultät’, z. B. ‘math’ für ‘Mathematik’ oder ‘Pseudofakultät’, z. B. ‘stud’ für Studierendebereich
  <inst-k> => Institutskürzel, z. B. ‘mkl’ für ‘Maschinenkonstruktionslehre’ <fak> => ‘Fakultät’, z. B. ‘mach’ für ‘Maschinenbau’<user-alias> Zeichenfolge, vorzugsweise <nachname> und <vorname>.<nachname>, bei Bedarf weitere Konstrukte

• Für natürliche Personen (Beisp.: Adam.Mueller@math.uni-karlsruhe.de):
  <vorname>.<nachname>@<(p-)fak>.UNI-KARLSRUHE.DE

• Für institutionelle Adressen (Beisp.: Fachschaft@mach.uni-karlsruhe.de):
  <name>@<(p-)fak>.UNI-KARLSRUHE.DE

• Format für Institute (Beisp.: schneider@mkl.mach.uni-karlsruhe.de):
  <name o. ä.>@<inst-k>.<fak>.UNI-KARLSRUHE.DE

Es gilt nun, diese bewährten und langfristig sinnvollen Adreßformate auf das erdenkliche Optimum ‘aufzubohren’, um alles zweckmäßig Vorhandene oder langfristig eventuell zu Recht Gewünschte abzudecken.

Neu sind Adressen der Form <policy>@UNI-KARLSRUHE.DE, sie werden nach Absprache z. B. für Institutionen vergeben. Freigaben auf dieser Ebene werden - wegen möglicher Interferenzen - restriktiv gehandhabt. Adressen des Formats ...@uni-karlsruhe.de werden also künftig, unter Beachtung der Gefahr von Fehlzustellung durch Mehrdeutigkeit u. ä., grundsätzlich unterstützt. Sinnvoll kann dies z. B. sein für institutionelle Adressen wie <tagung>@uni-karlsruhe.de und Anlaufadressen wie MKL@uni-karlsruhe.de, RZ@uni-karlsruhe.de oder Verwaltung@uni-karlsruhe.de.

Zukünftig unterstützte Formate (die oben genannten Formate sind als Sonderfall enthalten):

• <policy>@UNI-KARLSRUHE.DE
• <user-alias>@<(p-)fak>.UNI-KARLSRUHE.DE
• <user-alias>@<inst-k>.<fak>.UNI-KARLSRUHE.DE
• <user-alias>@<inst-k>.UNI-KARLSRUHE.DE

Die beiden letzten Formate könnten dabei grundsätzlich vom jeweiligen Institut ‘gepflegt’ werden, z. B. via Benutzerverwaltung, während die ersten beiden Formate sinnvollerweise unter RZ-Pflege fallen.

Das Format <user-alias>@<inst-k>.UNI-KARLSRUHE.DE ist neu und dürfte, da es kurz ist und dem Umgangssprachlichen direkt entspricht (“MKL an der Uni Karlsruhe”), sicher einige Liebhaber finden, wobei alle Formate funktionieren, zur Propagierung der Adresse aber nur eine einzige Form ausgewählt und benutzt werden sollte.

Sonstige Erweiterungen des Dienstangebots

Als wichtigstes Beispiel wäre hier eine Art Transformation der Ausfallsicherheit des RZ-Mailservice zu den Institutsmailern zu nennen. Im Gegensatz zu den meisten Instituten ist das RZ inzwischen in der Lage, den Mailservice mit personeller und technischer Redundanz zu betreiben. Durch das zentrale Mailkonzept kann diese Redundanz auf die Institute übertragen werden.

Diese Transformation setzt allerdings Vorarbeiten, z. B. des EDV-Beauftragten, bezüglich Benutzerverwaltung (Aufnahme und Pflege von Nutzerdaten) voraus, näheres hierzu zu gegebener Zeit. Sind diese Vorarbeiten geleistet und der Institutsmailer fällt aus, kann der Maildatenstrom des Instituts, sozusagen auf  Zuruf, in den zentralen Mailspool des RZ gelenkt werden, von wo aus er dann (z. B. via PC, nach Umtrag auf den neuen (Pop/IMAP-)Server) abgerufen werden kann. Auch der Versand der Mails dürfte problemlos möglich sein.

Statt eines ‘Mailgaus’ sind natürlich auch weniger spektakuläre Gründe denkbar, z. B. ein Rechner ist veraltet oder unzuverlässig und soll nicht mehr ersetzt werden, oder Personalmangel, z. B. ein Hiwi geht, oder die Mail-Admin nimmt Mutterschaftsurlaub, soll andere Aufgaben übernehmen, ...

In diesen und anderen Fällen kann es also durchaus sinnvoll sein, RZ-Dienste in Anspruch zu nehmen, da hier personell (Wochenendüberwachung, Rufbereitschaft, Personal-’backup’) und technisch (ausfallgesicherter Serverpool) mehr Aufwand zur Erzielung einer professionellen Dienstgüte getrieben werden kann.

Dietrich Eckert/Holger Zimmermann, Tel. -2066, Email: Postmaster@rz.uni-karlsruhe.de.

Neu:
Schaltungssimulator Electronics Workbench

Vor wenigen Wochen ging in einem unserer Institute der Schaltungssimulator “Electronics Workbench” in Betrieb. Das Programm bietet einen bemerkenswerten Funktionsumfang und läßt sich - zum Beispiel für Vergleichsrechnungen, Bauteileaustausch oder Entwurf einer Leiterplatte - auch zusammen mit anderen Programmen verwenden.

In der Standard-Version sind folgende Analysen möglich:

• Gleichstrom-Arbeitspunkt-Analyse
• Analyse des Einschwingverhaltens
• Frequenzanalyse (AC Frequency)
• Fourier-Analyse
• Rauschanalyse (Noise)
• Temperaturanalyse (statisch)

• Temperaturanalyse (Variation über definierten Bereich)
• Pol-Nullstellen-Analyse
• Klirrfaktor-Analyse (Distortion)
• Parameter-Variations-Analyse (Parameter-Sweep)
• Empfindlichkeitsanalyse (AC/DC Sensitivity)
• Analyse der übertragungsfunktion (Transfer-Function)
• Monte-Carlo-Analyse.

Die Schaltungen lassen sich aus Bauteilen aufbauen, die in einer umfangreichen Bibliothek mitgeliefert werden. Die Skala der aktiven Bauelemente beginnt bei Ersatzschaltungen von NPN- und PNP-Transistoren nach Gummel-Poon und Ebers-Moll und geht bis zu fertigen Operationsverstärkern nach Boyle-Pederson-Cohn. Bei den digitalen Bausteinen reicht das Angebot bis zu Voll-Addierern, TTL- und CMOS-Bausteinen (74xxx, 40xx). Unter den neun Arten von virtuellen Meßgeräten seien nur die folgenden herausgegriffen: universelle Meßwertegraphik, Multimeter, Zweikanal-Oszilloskop, Frequenzgang-Analysator, Funktionsgenerator, 16-Kanal-Bitmuster-Generator. Electronics Workbench bietet auch eine Schnappschußfunktion, mit der beliebige Bildschirmausschnitte in die Zwischenablage von Windows übernommen werden können.

Der Austausch von Schaltungen oder Teilen hiervon mit anderen Programmen ist im SPICE-Format möglich (*.CIR). Der Export von Netzlisten kann in mehreren Formaten auch an Programme zur Leiterplatten-Entflechtung (Eagle, Protel, Pads, Orcad, Layo1, Tango, Ultimate) erfolgen.

Das Programm wird als Einzel-Lizenz angeboten und bietet ein gutes Preis-/Leistungsverhältnis. Eine Demo-Version (für begrenzten Schaltungsumfang) ist im Rechenzentrum erhältlich. Bei Bedarf ist das RZ auch bereit, innerhalb des Campus eine Vorführung zu organisieren.

Anmeldungen hierzu sollten per Email oder Anruf bis 30.6.1998 bei mir eingehen.
Dieter Kruk, Tel. -3785, Email kruk@rz.uni-karlsruhe.de

Mikro-Elektro-Mechanische Systeme (MEMS)

EUROPRACTICE bietet MEMS-Entwicklungssoftware an

Seit kurzem steht im Rechenzentrum ein größeres Angebotspaket bereit, mit dem die europäische Ausbildungsinitiative EUROPRACTICE ihre Angebotspalette nun auch auf das Gebiet der Mikro-Elektro-Mechanischen Systeme (MEMS) ausdehnt. Die Erweiterung des Angebots bezieht sich auf folgende Komponenten:

• Rechnerwerkzeuge von MEMSCAP/Mentor Graphics. Neben den Hardware-Beschreibungssprachen VHDL und Verilog steht speziell zur Beschreibung von MEMS-Komponenten als zusätzliche Sprache HDL-A zur Verfügung.
• SMASH-Simulator von Dolphin Integration mit Erweiterungen, die auch die MEMS-Funktionalität mit einbeziehen.
• MEMS-orientierte Software-Tools, die in TANNER EDA-Produkten enthalten sind. Das Gesamtpaket ermöglicht die Entwurfseingabe der Mikromechanik und -elektronik, die Simulation, das Layout und den Test von MEMS und ICs.
• Zugang zu verschiedenen MEMS-Fabriken (Foundries).

Über das Rechenzentrum können alle Institute von diesen Angeboten Gebrauch machen. Informationsmaterial sendet Ihnen das RZ gerne zu. Darüber hinaus liegen im Rechenzentrum Einladungen zu mehreren Mikroelektronik-Fachtagungen vor, unter denen sich einzelne neuerdings auch mit MEMS-Technologien befassen. Diese Unterlagen können ebenfalls an interessierte Institute weitergegeben werden. Kurzfassungen dieser Einladungen finden Sie auch auf den Web-Seiten des Rechenzentrums unter: http://www.rz.uni-karlsruhe.de/Uni/RZ/Personen/rz28/tagungen.txt.

Dieter Kruk, Tel. -3785, Email kruk@rz.uni-karlsruhe.de

BUG in HP JetAdmin-Software für Windows95

Allen Windows95-Benutzern, die die HP JetAdmin- Software installiert haben, wird empfohlen, die Version 3.0 (oder neuer) zu installieren.

Ältere Versionen haben einen Bug, der darin besteht, das Netz mit einem nahezu konstanten Datenstrom (Pakete, bestehend aus Broadcasts und SNMP-Requests) zu belasten.

Diese Pakete dienen offensichtlich dazu, irgendwelche netzwerkfähigen Drucker (falls vorhanden) im Netz automatisch zu finden und anzusprechen. Dies wirkt sich folgendermaßen aus:

• Der Betrieb eines einzelnen Rechners mit HP JetAdmin verschlechtert den Durchsatz des Netzsegmentes bereits wesentlich.
• Die Verbindungen zwischen den Teilnetz-Bereichen (Etagenbereich, Gebäudebereich) werden ebenfalls beeinträchtigt, da auch die Router wesentlich stärker belastet werden.
• Es kommt zu “authentication failures” auf den vom RZ administrierten Netzkomponenten.

Die Version 3.0 (deutsch) kann z. B. unter der folgender URL heruntergeladen werden: http://www.hp.com/cposupport/networking/software/ja115ge.exe.html

Es gibt auch diverse Mirror-Server mit demselben Software-Paket (String für Suchmaschine: hpja95).

Rainer Steinmüller, Tel. -4736, Email: steinmueller@rz.uni-karlsruhe.de.

Kurz berichtet ...

Software-Migration am Parallelrechner IBM RS/6000 SP ab 29.6.1998

Wie bereits in den letzten RZ-News angekündigt, steht am Parallelrechner IBM SP eine Softwaremigration an. Als Umstellungsbeginn wurde jetzt gemeinsam mit IBM der 29.6.1998 festgelegt.

Wir rechnen nach jetzigem Kenntnisstand mit einer SP-Betriebs- und Nutzungs-Unterbrechung vom 29.6. bis etwa 12.7.1998.

Ein Rundschreiben mit genaueren Einzelheiten wurde von uns an alle Einrichtungen und Institute verschickt, welche die SP nutzen.

Vorführung neuer Präsentationstechnik

Die Firma MAIKS aus Mannheim wird am Donnerstag, den 18. Juni 1998, im RZ, Raum 217 “SMART Boards” präsentieren. Dabei handelt es sich um eine elektronische Tafel, die an einen PC angeschlossen wird, so daß jede “Tafelseite” als Datenfile abgespeichert werden kann. Zusammen mit einem Datenprojektor (auch ein solcher wird gezeigt) kann das ganze dann als Multimediawand verwendet werden: das Monitorbild wird auf die (weiße) Tafel projiziert, dort mit elektronischer Tinte angebrachte Handzeichnungen werden auf den Monitor des PC zurückprojiziert. Darüber hinaus können PC-Anwendungen statt mit der Maus mit dem Finger direkt auf der Tafel angesteuert werden, ähnlich wie bei einem Touchscreen.

Diese Boards sind interessant für alle, die Kurse und Vorlesungen am RZ halten und z. B. Programmierbeispiele zeigen oder Texte markieren wollen. Das Monitorbild kann zusammen mit den Handzeichnungen jederzeit abgespeichert und z. B. für Skripten ausgedruckt werden (laut Vertreiber). Alle diese Features sollen im Rahmen von Application sharing auch für Videokonferenzen nutzbar sein.

Datum: Zeit: Ort:	Donnerstag, 18.6.1998 10.00 Uhr RZ, Raum 217, 2. OG

Susanne Witschel, Tel. -3784, Email: Susanne.Witschel@rz.uni-karlsruhe.de

Personalia

In ihren Tätigkeitszeitraum fiel auch die Installation des Parallelrechners IBM SP, der mit seinen 256 Knoten zu den leistungsstärksten Rechnern dieser Art in Europa zählt.

Anschließend war sie im Rahmen des Virtuellen Rechenzentrums bis zum 30.5.1998 am Forschungszentrum Karlsruhe angestellt und zeitweise an das Rechenzentrum abgeordnet.

Sie hat ihre Aufgaben mit großer Umsicht und großem Engagement ausgeführt, wofür wir ihr auch an dieser Stelle nochmals sehr danken wollen.

Für ihren weiteren beruflichen Werdegang in der freien Wirtschaft, wo ihr eine interessante neue Aufgabe angeboten wurde, wünschen wir ihr alles Gute und viel Erfolg.

************************************************************************

Zum 30. April hat uns nach fast 4-jähriger Tätigkeit Herr Peter Pfeil verlassen, um in die Universitätsverwaltung überzuwechseln.

Herr Pfeil hat während seiner RZ-Zeit als Verwaltungsangestellter für die ASK die Rechnungstellung der bundes- und landesweit vertriebenen Softwarelizenzen erledigt. Nunmehr wird das Vertriebsgeschäft von der ASKnet GmbH fortgesetzt.

Das RZ wünscht Herrn Pfeil in seinem neuen Aufgabenbereich alles Gute.

************************************************************************

Frau Dipl.-Phys. Ioana Rednic ist seit dem 1.5.1998 in der Abteilung Kommunikation als wissenschaftliche Mitarbeiterin angestellt. Im Rahmen ihrer Tätigkeit im Deutschen Network Information Center (DE-NIC) ist sie zuständig für den Betrieb des DE-Nameservers, die Automatisierung und Abwicklung der Aufträge und die Bearbeitung allgemeiner Anfragen und Anträge zur Domainvergabe. Ihr Arbeitsplatz befindet sich im Raum 214, Tel. 373723, Email: Ioana.Rednic@nic.de.

************************************************************************

25jähriges Jubiläum

Am Rechenzentrum haben Frau Hamdiye Kunt-Sarac im Mai und Herr Heinz Ehrmann im April ihr 25jähriges Dienstjubiläum gefeiert. Beide gehören seit Anfang Ihrer Tätigkeit am Rechenzentrum zur Abteilung Betrieb. Dort stellen sie sicher, daß die Anlagen des Rechenzentrums funktionieren. Zu ihren Aufgabenschwerpunkten zählen die Überwachung der zentralen Server, der Netzkomponenten, der Plotter, der Drucker, der dezentralen Workstationpools in den Instituten, aber auch der Brandmelder und vieles andere mehr. Herr Ehrmann wird unseren Kunden auch durch seine Tätigkeit in der Betriebsauskunft bekannt sein. Das Rechenzentrum wünscht Frau Kunt-Sarac und Herrn Ehrmann alles Gute für die Zukunft und dankt ihnen recht herzlich für die langjährige und engagierte Mitarbeit.