Û¥-x@ €¸p×z8oz$z$$z$z$z$z$z2z2z2z2z2z Weitere Informationen finden Sie unter http://www.uni- karlsruhe.de/Uni/RZ/Netze/Mail/#Konzept.<%0> @UEBER LINIEN = ‘Mißbrauch’ (Spam, Spam relay) Wie in der RZ-News vom Dezember 97 berichtet, ist im Internet - mit Zunahme des kommerziellen Angebots - auch ein rapides Ansteigen von Werbemüll (Spams) und damit einhergehend des Mißbrauchs fremder Mailports zur Spam-Vermittlung (Spam relaying) zu beobachten. 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. <%-2>Diese Problematik wird unter: http://www. <%-6>uni-karlsruhe.de/Uni/RZ/Netze/Mail/konzept_ missbrauch_u.html<%-8> und als Übersicht unter: http:// <%0>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. 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. @BODY VORN = Realisierung des Konzepts bezüglich Mißbrauch In diesem Bereich liegt bereits eine gewisse Betriebserfahrung vor, da seit mehreren Monaten ein neuer <%-2>Mailer (nz15/exim), die alte Mailerumgebung (nz11/pp) und einige I<%0>nstitute 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. @UEBER LINIEN = Nutzerzugriff auf Email Parallel zum Trend des Arbeitens mit PC-basierten Systemen, läuft auch der Trend zur Benutzung dieser Systeme für Mailempfang und -versand. Diese Mailprogramme (Mail clients, Mail user agents/MUAs) sind dabei in der Regel nicht eigenständig, sondern wickeln Mailempfang und -versand über Server ab, die normalerweise Tag und Nacht laufen und deren Funktionalität ausreichend sein muß für die an sie gestellten Aufgaben. 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. 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: @BODY BLICK 1 = 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. @BODY BLICK 1 = 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. @UEBER LINIEN = <%-4>Adressenverwaltung (Ablage, Zugriff, Pflege)<%0> Bei Mailadressen lassen sich grundsätzlich zwei Typen unterscheiden. Die einen sind eher vom Typ Zustelladresse und enthalten z. B. neben der (Domain-) Angabe des Mailzustellers, mehr oder weniger kryptische Anteile, eventuell auch ‘Hostnames’. Die anderen sind die eigentlichen, d. h. vorzugsweise zu propagierenden Mailadressen. Im Idealfall, bei Kenntnis persönlicher Merkmale wie Vorname und/oder Nachname, Institut/Dienststelle u. ä., können diese aufgrund ihrer Technologie-Unabhängigkeit durchaus treffsicher erraten werden. 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. @BODY VORN = 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). @BODY VORN = Benutzerverwaltung <%-2>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.<%0> 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: @BODY BLICK 1 = Größere Flächendeckung durch Einbeziehung in das    normale Antragswesen (separater X.500-Antrag entfällt) @BODY BLICK 1 = Funktionale Erweiterungen @BODY BLICK 1 = Keine doppelte Datenhaltung wegen der Gefahr von Inkonsistenzen @BODY BLICK 1 = 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. @BODY BLICK 1 = Professioneller Zugriff via WWW: @BODY BLICK 2 = Daten und Paßwort laufen (via ssl) verschlüsselt über das Netz @BODY BLICK 2 = Jede Uni-domain hat eine eigene Benutzerverwaltung @BODY BLICK 2 = 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 @BODY BLICK 2 = Der Zugriff auf die Daten erfolgt unter Beachtung datenschutzrechtlicher Belange auf mehreren Hierarchie-Ebenen: @BODY BLICK 3 = Ebene 0: Administrator der Benutzerverwaltung (alles schreiben, alles lesen) @BODY BLICK 3 = Ebene 1: EDV-Beauftragter (alles lesen, partiell schreiben für Gruppe/Institut) @BODY BLICK 3 = Ebene 2: Benutzer an der Universität (alles lesen, partiell schreiben bzgl. eigenem Eintrag) @BODY BLICK 3 = 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). @UEBER LINIEN = Erweiterung der Mailadressen (User-Aliase, Maildomains) Das Format der bereits erwähnten (X.500- bzw. generischen) Mailadressen der Universität war im wesentlichen aus technischen Gründen Einschränkungen unterworfen, die sobald wie möglich, im Zuge der Portierung von X.500 zur Benutzerverwaltung des RZ, aufgehoben werden. Ein weiteres Format (mit Institutskürzel), das einige Institute benutzten, ist nachfolgend ebenfalls aufgeführt. @BODY VORN = Bisherige Formate, soweit langfristig sinnvoll: @BODY BLICK 1 = Abkürzungen:<<(p-)fak>> =>> (Pseudo-)FakultätEntweder ‘Fakultät’, z. B. ‘math’ für ‘Mathematik’ oder ‘Pseudofakultät’, z. B. ‘stud’ für Studierendebereich<> =>> Institutskürzel, z. B. ‘mkl’ für ‘Maschinenkonstruktionslehre’<> =>> ‘Fakultät’, z. B. ‘mach’ für ‘Maschinenbau’<> Zeichenfolge, vorzugsweise <> und <>.<>, bei Bedarf weitere Konstrukte @BODY BLICK 1 = Für natürliche Personen (Beisp.: Adam.Mueller@ math.uni-karlsruhe.de):<>.<>@<<(p-)fak>>.UNI- KARLSRUHE.DE @BODY BLICK 1 = Für institutionelle Adressen (Beisp.: Fachschaft@ mach.uni-karlsruhe.de): <>@<<(p-)fak>>.UNI-KARLSRUHE.DE @BODY BLICK 1 = Format für Institute (Beisp.: schneider@mkl. mach.uni-karlsruhe.de): @EINRUECKEN = <>@<>.<>.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 <>@UNI-KARLSRUHE.DE, sie werden nach Absprache z. B. für Institutionen vergeben. Freigaben auf dieser Ebene werden - wegen möglicher Interferenzen - restriktiv gehandhabt. A<%-3>dressen des <%0>Formats ...@uni-karlsruhe.de werden also künftig, unter Beachtung der Gefahr von Fehlzustellung durch Mehrdeutigkeit u. ä., grundsätzlich unterstützt. S<%-3>innvoll kann dies z. B. sein für institutionelle Adressen wie <>@uni-karlsruhe.de und Anlaufadressen wie MKL@uni-karlsruhe.de,<%-4> RZ@uni-karlsruhe.de oder Verwaltung@ uni-karlsruhe.de. @AUSRUECKEN = @BODY VORN = Zukünftig unterstützte Formate (die oben genannten Formate sind als Sonderfall enthalten): @BODY BLICK 1 = <>@UNI-KARLSRUHE.DE @BODY BLICK 1 = <>@<<(p-)fak>>.UNI-KARLSRUHE.DE @BODY BLICK 1 = <>@<>.<>.UNI-KARLSRUHE.DE @BODY BLICK 1 = <>@<>.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 <>@<>.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. @UEBER LINIEN = Sonstige Erweiterungen des Dienstangebots Unter Ausnutzung der flexiblen Ausbaumöglichkeit der Benutzerverwaltung sieht das RZ-Konzept weitere Dienstangebote für die Gesamtuniversität vor. 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. <%-2>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.<%0> 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. @BODY VORN = Dietrich Eckert/Holger Zimmermann, Tel. -2066, Email: Postmaster@rz.uni-karlsruhe.de. @UEBER = Neu:Schaltungssimulator Electronics Workbench @AUTOR FUNKTIN = Dieter Kruk <%-2>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.<%0> @BODY VORN = In der Standard-Version sind folgende Analysen möglich: @BODY BLICK 1 = Gleichstrom-Arbeitspunkt-Analyse @BODY BLICK 1 = Analyse des Einschwingverhaltens @BODY BLICK 1 = Frequenzanalyse (AC Frequency) @BODY BLICK 1 = Fourier-Analyse @BODY BLICK 1 = Rauschanalyse (Noise) @BODY BLICK 1 = Temperaturanalyse (statisch) @BODY VORN = @BODY VORN = Die Developer-Version bietet darüber hinaus folgende Analysen: @BODY BLICK 1 = Temperaturanalyse (Variation über definierten Bereich) @BODY BLICK 1 = Pol-Nullstellen-Analyse @BODY BLICK 1 = Klirrfaktor-Analyse (Distortion) @BODY BLICK 1 = Parameter-Variations-Analyse (Parameter-Sweep) @BODY BLICK 1 = Empfindlichkeitsanalyse (AC/DC Sensitivity) @BODY BLICK 1 = Analyse der übertragungsfunktion (Transfer-Function) @BODY BLICK 1 = 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. @BODY VORN = Anmeldungen hierzu sollten per Email oder Anruf bis 30.6.1998 bei mir eingehen. @BODY VORN = Dieter Kruk, Tel. -3785, Email kruk@rz.uni-karlsruhe. de @UEBER = Mikro-Elektro-Mechanische Systeme (MEMS) @UEBER LINIEN = EUROPRACTICE bietet MEMS-Entwicklungssoftware an @AUTOR FUNKTIN = Dieter Kruk 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: @BODY BLICK 1 = 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. @BODY BLICK 1 = SMASH-Simulator von Dolphin Integration mit Erweiterungen, die auch die MEMS-Funktionalität mit einbeziehen. @BODY BLICK 1 = 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. @BODY BLICK 1 = 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. @BODY VORN = <%-3>Dieter Kruk, Tel. -3785, Email kruk@rz.uni-karlsruhe.de<%0>. @UEBER = BUG in HP JetAdmin-Software für Windows95 @AUTOR FUNKTIN = Rainer Steinmüller 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: @BODY BLICK 1 = Der Betrieb eines einzelnen Rechners mit HP JetAdmin verschlechtert den Durchsatz des Netzsegmentes bereits wesentlich. @BODY BLICK 1 = Die Verbindungen zwischen den Teilnetz-Bereichen (Etagenbereich, Gebäudebereich) werden ebenfalls beeinträchtigt, da auch die Router wesentlich stärker belastet werden. @BODY BLICK 1 = 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). @BODY VORN = Rainer Steinmüller, Tel. -4736, steinmueller@rz.uni-karlsruhe.de. @UEBER = Kurz berichtet ... @UEBER LINIEN = Software-Migration am Parallelrechner IBM RS/6000 SP ab 29.6.1998 @AUTOR FUNKTIN = Wolfgang Preuss 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. @UEBER LINIEN = Vorführung neuer Präsentationstechnik @AUTOR FUNKTIN = Susanne Witschel 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. @BODY TABS = Datum: Donnerstag, 18.6.1998 @BODY TABS = Zeit: 10.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG @BODY VORN = Susanne Witschel, Tel. -3784, Email: Susanne.Witschel@rz.uni-karlsruhe.de @UEBER = Personalia Frau Dr. Barbara Kathan war in der Zeit vom 1.2.1993 bis zum 25.7.1997 am Rechenzentrum der Universität Karlsruhe als wissenschaftliche Angestellte tätig. Sie arbeitete in der Abteilung Betriebssysteme und hat dort in erster Linie die Workstations IBM RS/6000 des Rechenzentrums und etlicher Universitätsinstitute betreut. 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. @G. BREIT ZENT = @G. BREIT ZENT = @G. BREIT ZENT = 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. @G. BREIT ZENT = @G. BREIT ZENT = ********************************** @G. BREIT ZENT = uˆ€   % pŸ €š|#Š#½$Ë$à$á$&&) )')2)-+-³2¹2h3p3Æ3Î3'4/4•44l5¥537d7G>H>‰@§@±DÜDL]MÅiËiñiöijj¡j³jßnên¶p¸p¸pû÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷ûûû;€·Ö    Æ+Žó·”‘ Ù Û õ % , Ô—cŸupš?þÚ˜ º!Æ"l#­$Î%&+( ))2)+-- -+-¢.y/ö/"0s0T1†1×12Ö2X3¶34…4\5¥5$7&7d7:è:`;¤;<Ž<<[=V@|@å@/A’A Bççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q BmBoB:C¡DÜDpEãFýH"JVKºKõKLLcMeM«MÝMN@NaNˆN¶NÅNOZOƒOµOöO3PyPŸP¡PÌSàTïUMV”VÇV W'W)WUX0Y®Y™ZàZâZ&]v]ª]Ï]Ñ]\^_º_C`ý`dafabb‚bÒbïbBcdcfc d™deRevexe3h¶i¸iäij-j/jççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q/j‡jœjàkŽl7mÄmlnn’n¥n(op[pnp£p¶p¶p¸pçççççççççççççççççâ& Рp@ à°€P ðÀ!F  Þ8o¸p€¸p9€ B/j¸p:;<. Tms Rmn RSymbol"Helv1þMS LineDraw8o"neÐaw