ZIDline 06

Nr. 6 / Dezember 2001

ISSN 1605-475X

INFORMATIONEN DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Maßnahmen gegen Viren und Spam

Linux in den Internet-Räumen

Campussoftware Distribution

Seite 2 – Dezember 2001 – ZIDline 6

Inhalt

Zentrale Anti-Viren-Maßnahmen . . . . . . . . . . . . . . . . . . 3

Server-Zertifikate des Zentralen Informatikdienstes . . . 5

Zentrale Anti-Spam-Maßnahmen . . . . . . . . . . . . . . . . . . 6

Telekom-Projekt erfolgreich abgeschlossen. . . . . . . . . . 9

Immer schneller:Gigabit-Netzwerke für die Wissenschaft . . . . . . . . 10

Weitere Qualitätsverbesserungbei der Internetanbindung der TU Wien . . . . . . . . . . 12

Linux in den Internet-Räumen . . . . . . . . . . . . . . . . . . . 14

Citrix Terminal Serverfür die Internet-Räume . . . . . . . . . . . . . . . . . . . . . . 17

Sicherheit unter Linux:Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Wie komme ich zu meiner Campussoftware ?Bestellung – Zugang – Installation . . . . . . . . . . . . . 21

Der neue Software Distribution ServerSunFire 3800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Datenerfassung und -auswertung mit LabVIEWim Laserlabor des Instituts für Allgemeine Physik . 29

Personelle Veränderungen . . . . . . . . . . . . . . . . . . . . . . 33

ZID Beirat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Wählleitungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Auskünfte, Störungsmeldungen . . . . . . . . . . . . . . . . . . 34

Öffnungszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

PersonalverzeichnisTelefonliste, E-Mail-Adressen . . . . . . . . . . . . . . . . 35

Editorial

Ein Hauptthema dieser ZIDline ist die zunehmendeViren- und Spam-Problematik bei E-Mails. Der ZID istgefordert, Maßnahmen anzubieten, um die Situation fürdie Benutzer an der TU Wien zu verbessern.

Laufend können wir über Qualitätsverbesserungender Internetanbindung der TU Wien berichten. Wir dan-ken Herrn Dr. Rastl, dem Leiter des ZID der UniversitätWien, für die Überlassung seines aktualisierten Beitragsüber ACOnet 2001 aus dem Comment 01/3, der Schwester-Zeitschrift an der Uni Wien.

Für die Internet-Räume wurde ein neues Konzept erar-beitet, das auf Thin Clients unter Linux in Kombinationmit Windows Terminal Servern basiert.

Die Serie über „Sicherheit unter Linux“ wird mit ei-nem Artikel über Packet Filter fortgesetzt.

Das umfassende Angebot an Campussoftware erfor-dert leistungsfähige Server und eine effektive Software-Infrastruktur. Der neue Software Distribution Server wirdvorgestellt und ein Überblick über die Online-Bestellungund Installation von Campussoftware gegeben.

Ein Anwenderartikel beschreibt die Erfahrungen amInstitut für Allgemeine Physik mit dem Programm Lab-VIEW in der Experimentsteuerung.

Ich möchte mich an dieser Stelle herzlich bei allenAutoren dieser Ausgabe für ihre Beiträge und bei allenMitarbeitern für die gute Zusammenarbeit bedanken.

Mit den besten Wünschen für 2002

Irmgard HusinskyImpressum / Offenlegung gemäß § 25 Mediengesetz:

Herausgeber, Medieninhaber:Zentraler Informatikdienstder Technischen Universität WienISSN 1605-475X

Grundlegende Richtung: Mitteilungen des ZentralenInformatikdienstes der Technischen Universität Wien

Redaktion: Irmgard Husinsky

Adresse: Technische Universität Wien,Wiedner Hauptstraße 8-10, A-1040 WienTel.: (01) 58801-42014, 42001Fax: (01) 58801-42099E-Mail: [email protected]: http://www.zid.tuwien.ac.at/zidline/

Erstellt mit Corel VenturaDruck: HTU Wirtschaftsbetriebe GmbH,1040 Wien, Tel.: (01) 5863316

www.zid.tuwien.ac.at/zidline/

Viren am Titelblatt: I. Husinsky/A. Klauda

ZentraleAnti-Viren-MaßnahmenUdo Linauer, Johann Haider

Die Infektion mit aggressiven Computerviren über Mail führte immer wieder zu Ausfällen vonComputern im TUNET, die nur mit erheblichem Arbeitsaufwand wieder zu beheben waren. Einweiteres Problem stellen die zahllosen Spam-Mails dar. Der ZID erhält regelmäßig Beschwerdenüber Spam-Mails, die von der Mehrzahl der Mitarbeiter an der TU Wien als Belästigungempfunden werden (dazu mehr im Artikel „Zentrale Anti-Spam-Maßnahmen“, Seite 6).

Aufgrund wiederholter Anfragen seitens der Institute erweitert der ZID das Mailbastionsservice [1]um einen zentralen Virenscanner und einen Spam-Filter für eingehende Mail. Absolute Sicherheitkönnen wir nicht garantieren, die Erfahrungen aus dem Testbetrieb versprechen jedoch einedrastische Verbesserung der momentanen Lage !

Zentraler Virencheck

Seit Jahren bedrohen Computerviren [2], TrojanischePferde, Computerwürmer und dergleichen (zurzeit sindca. 65000 bekannt) vorwiegend Rechner mit Microsoft-Betriebssystemen. Aus diesem Grund bietet der ZID imRahmen der Campussoftware [3] Antiviren-Software zuextrem günstigen Konditionen an. Der Einsatz solcherSoftware am Arbeitsplatz ist eine höchst empfehlenswer-te Selbstschutzmaßnahme für den sicheren Betrieb einesComputers (siehe auch Security Policy [4]) und kanndurch keine zentrale Sicherheitsinfrastruktur komplett er-setzt werden !

Die Infektion mit Viren erfolgt über Diskette,CDROM oder beim Surfen im Web (aktive Inhalte oderDownload), erfahrungsgemäß aber vor allem durch ver-seuchte Mail-Anhänge (Attachments). Die Einrichtung ei-nes zentralen Virenscanners für Mails durch den ZID imRahmen des Mailbastionsservices wird diese Gefahr inZukunft vermindern. An dieser Stelle möchten wir in

Erinnerung rufen, dass das Mailbastionsservice alsSchutz für unsere Mailserver gegen Missbrauch durchExterne implementiert wurde. Es ist asymmetrisch undkann prinzipiell keinen Schutz vor internen Attacken bie-ten. Dieser Umstand gibt uns die Möglichkeit, automa-tisch, ohne Umkonfiguration (!) seitens der Benutzer,Virenschutz für alle Mails zu bieten, die von „außen“ andie TU Wien gelangen. Damit ist schon viel gewonnen,weil die meisten Viren zuallererst einmal von außenkommen und dann über die TU Wien weiter verbreitetwerden. Automatischen Schutz auch für abgehende Mailsgenießen die Benutzer der vom ZID betriebenen Server(mail.zserv, pop, stud3, stud4, Applikationsserver).

Instituts-Mailserver

Schutz für abgehende Mail kann durch explizite Anga-be des abgehenden Mailrouters (mr.tuwien.ac.at)zum Versenden von Mails erreicht werden. Für einenMailserver geschieht dies durch Angabe eines „Smart Re-lay Hosts“ (siehe unten). Alternativ dazu können Benut-zer ihren Mail-Client umkonfigurieren. Dafür muss imMailprogramm mr.tuwien.ac.at als „AusgehenderMailserver“ („Outgoing Mail Server“) eintragen werden.Weiters muss der Instituts-Firewall, falls vorhanden, denZugriff auf mr.tuwien.ac.at gestatten. Wenden Siesich bei Problemen an Ihren lokalen Systemadministratoroder die Computer Help Line des ZID, DW 42124 (beiaufrechtem Servicevertrag [5]). Dieses Service steht nurBenutzern im TUNET zur Verfügung.

ZIDline 6 – Dezember 2001 – Seite 3

Sender

Empfänger

Viren-

Check

Spam-

Check

Relay-

Check

Frage: „Kann durch eine Digitalkamera ein

Virus in ein Computersystem gelangen ?“

Antwort: „Klar, wenn es Ihnen gelingt,

eines zu fotografieren.“

aus: PC Magazin, September 2001

FunktionsweiseDie Mail wird vom Mailserver (Mailbastionsrechner)

auf einen Rechner umgeleitet, der ausschließlich zum Vi-renscannen eingesetzt wird. Insgesamt vier solcher Servergarantieren ausreichende Ausfallssicherheit. Wird keinbekanntes Virus gefunden, erfolgt die Zustellung derMail in der bisher bekannten Weise. Wird ein Virus ent-deckt, erhalten sowohl der Absender als auch der Emp-fänger vom Mailbastionsservice eine Mail, die auf dieverseuchte Nachricht hinweist. Diese Mail enthält Absen-der, Empfänger, Beschreibung des gefundenen Virus unddie Mail-Header, so dass die beteiligten Benutzer feststel-len können, wer die Nachricht gesendet hat. Die ver-seuchte Mail selbst wird nicht zugestellt. Bei aus-gehenden oder internen Mails, also bei der Verwendungdes abgehenden Mailrouters (mr.tuwien.ac.at),kommen dieselben Mechanismen zum Einsatz, mit demkleinen Unterschied, dass der „externe“ Empfänger nichtvon dem Zustellversuch informiert wird.

Informationen zu Anzahl und Art der abgefangenenViren können auf der Webseite

http://nic.tuwien.ac.at/services/mail/virstats.html

abgefragt werden.

WarnungEs gibt keinen absoluten Schutz vor Viren (aber einen

messbaren) ! Nicht für jedes neue Virus gibt es gleichein Gegengift. Es können nicht alle Datenformate über-prüft werden (z. B. verschlüsselte Mails). Accounts beiexternen Providern (Hotmail etc.) werden aufgrund derverwendeten Protokolle in der Regel nicht vom Mailbas-tionsservice geschützt. Wir empfehlen daher trotz deszentralen Virenchecks auch weiterhin die allgemeinenVerhaltensregeln zum Schutz vor Viren zu beachten [6].

Technische DetailsAlle von außerhalb erreichbaren zentralen Mailserver

der TU Wien (derzeit 4 Stück) werden mit einem Viren-scanner ausgestattet. Zu diesem Zweck wird jedem dieserServer ein weiterer Rechner zugeordnet, der das Überprü-fen auf Viren übernimmt.

Hard- und Software-Ausstattung für den Scanrechner:

Dual Athlon 1.2 GHz1 GB RAM2x18 GB DiskRed Hat Linux 7.2amavis-perl-11 [7]McAfee Viruscan 4.14 [8]

Die Kommunikation zwischen beiden Rechnern er-folgt über das Milter (=Mail Filter) Protokoll [9]. DieAufgabe von amavis ist es, die Mail so aufzubereiten,dass der Virenscanner in der Lage ist, ein mögliches Vi-rus zu entdecken, d. h. die Datenkonversionen, die voroder beim Versenden der Mail durchgeführt wurden(z. B. Packen der Datei oder Mail-Transfer-Encoding:base64), werden wieder rückgängig gemacht.

Unterstützte Dateiformate:

Mail Transfer Encoding: quoted printable, base64Mail Encoding: uuencoded, xxencoded, binhex, TNEFDatenkompression: gzip, compress, bzip2Dateiarchive: tar, Zip, RAR, LHA, Arc, Zoo, Arj

Wenn kein Virus entdeckt wird, wird die Mail an denEmpfänger weitergeleitet, andernfalls wird das Weiterlei-ten der Mail unterbunden. In diesem Fall erhalten derAbsender und der Empfänger eine virenfreie Benachrich-tigung.


From: [email protected]: Tue, 23 Oct 2001 23:20:43 +0200 (MET DST)Message-Id: <[email protected]>To: <[email protected]>Subject: VIRUS IN YOUR MAILX-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)

V I R U S A L E R T

Our viruschecker found the

APStrojan

virus(es) in your email to the following recipient(s):

-> <[email protected]>

Please check your system for viruses, or ask your system administratorto do so.

For your reference, here are the headers from your email:

—————— BEGIN HEADERS ——————————————-

Received: (from odysseus@localhost)by tauris.com (8.9.3/8.9.3) id XAA04339for [email protected]; Tue, 23 Oct 2001 23:20:39 +0200 (MET DST)Date: Tue, 23 Oct 2001 23:20:39 +0200 (MET DST)From: Odysseus <[email protected]>Message-ID: <[email protected]>Mime-Version: 1.0To: [email protected]: HorseContent-Type: multipart/mixed; boundary="-"

—————— END HEADERS ———————————————

Benachrichtigung an den Absender, z. B.:

From: [email protected]: Tue, 23 Oct 2001 23:20:47 +0200 (MET DST)Message-Id: <[email protected]>To: <[email protected]>Subject: VIRUS IN MAIL FOR YOU FROM <[email protected]>X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)

V I R U S A L E R T

Our viruschecker found the

APStrojan

virus(es) in an email to you from:

<[email protected]>

Delivery of the email was stopped!

Please contact your system administrator for details.

For your reference, here are the headers from the email:

—————— BEGIN HEADERS ——————————————-

...

—————— END HEADERS ———————————————

Benachrichtigung an den Empfänger, z. B.:

Erste ResultateSeit Mitte Oktober ist ein Virenscanner nach dem be-

schriebenen Schema für den ZID in Betrieb. Obwohl derEmpfängerkreis relativ klein ist, wurden täglich Mails ab-gefangen, die ein Virus enthielten.

Virus Anzahl

W32/SirCam@MM 142

W32/Nimda 9

W32/Magistr 6

W32/Anset@MM 6

W32/Nimda@MM 5

W32/Hybris.gen@MM 2

ZIP-Crash 1

W95/Kuang.GR 1

W32/Magistr.a.dam1 1

Tabelle: Viren von 15. 10. bis 15. 11.

Beispiel für den „Smart Relay Host“Nur für Systemadministratoren in der Domänetuwien.ac.at !

Um ausgehende Mail über den abgehenden Mailrou-ter zu verschicken, setzt man in der Datei sendmail.cf

den Parameter DS auf mr.tuwien.ac.at (die DS Zei-le ist wahrscheinlich schon vorhanden, nur der Wert istzu ergänzen). Die Zeile sieht dann wie folgt aus:

DS mr.tuwien.ac.at

Zur Aktivierung muss sendmail neu gestartet wer-den. Dieselbe Funktionalität gibt es auch bei anderenMailservern (z. B. unter Novell). Details finden Sie in derDokumentation Ihres Systems oder können bei den Kon-taktpersonen des Plattformservices des ZID (siehe [5]) er-fragt werden.

Referenzen

[1] ZIDline 4, Dezember 2000: http://www.zid.tuwien. ac.at/zidline/zl04/mailbast.html

[2] c’t 21/2001, S140ff, Jürgen Schmidt, SicherheitsrisikoMicrosoft, Verlag Heinz Heise

[3] Norton Antivirus, McAfee VirusScan, Sophos AntiVirus:http://sts.tuwien.ac.at/css/

[4] http://www.zid.tuwien.ac.at/security/policies/secpol.html[5] http://sts.tuwien.ac.at/pss/

http://www.tu-berlin.de/www/software/avprev.shtml[6] http://www.bsi.de/antivir1/texte/hinweise.htm[7] http://www.amavis.org/[8] http://www.mcafee.com/anti-virus/[9] http://www.sendmail.com/partner/resources/development/

milter_api


Server-Zertifikatedes Zentralen InformatikdienstesTU Testzertifizierungsstelle:http://www.zid.tuwien.ac.at/security/testca/

Fingerprints der Test-CAs und der von ihnen ausgegebenenServerzertifikate:

Zertifikat der Root-Test-CA (PCA)gültig von Dec 30 1999 bis Dec 26 2014MD5 Fingerprint=0D:D9:02:9C:24:61:85:9E:72:59:93:28:68:3D:B3:7C

Zertifikat der Server-Test-CA (SCA)gültig von Dec 30 1999 bis Dec 27 2009MD5 Fingerprint=03:2F:CB:C6:B6:5B:FC:00:C0:56:41:DF:CD:E9:AF:98

Zertifikat der User-Test-CA (UCA)gültig von Dec 30 1999 bis Dec 27 2009MD5 Fingerprint=3C:B3:AC:1F:83:D0:C9:1E:3E:11:31:53:A0:F3:C9:88

Server-Zertifikat von stud3.tuwien.ac.atgültig von: Nov 15 2001 bis Dec 5 2002MD5 Fingerprint=FC:4E:CB:FC:53:E5:09:9B:08:E9:84:76:C1:17:CC:0B

Server-Zertifikat von stud4.tuwien.ac.atgültig von: Nov 15 2001 bis Dec 5 2002MD5 Fingerprint=8C:16:D0:EF:EA:40:BA:EE:96:FA:D5:39:4A:36:1A:EB

Server-Zertifikat von mail.zserv.tuwien.ac.atgültig von: Nov 15 2001 bis Dec 5 2002MD5 Fingerprint=B7:4C:50:58:9D:8E:D6:E3:68:AF:62:36:BB:22:8B:E8

Server-Zertifikat von studman.ben.tuwien.ac.atgültig von Jan 18 2001 bis Jan 18 2002MD5 Fingerprint=9F:DD:07:6D:73:5E:9C:E6:51:62:4E:D7:53:4B:46:E6

Server-Zertifikat von swd.tuwien.ac.atgültig von May 10 2001 bis May 25 2002MD5 Fingerprint=88:08:46:AB:A8:B9:78:AA:35:EE:6B:AA:6A:CC:B4:20

Fingerprints von „TC TrustCenter Class 2 CA“:Server-Zertifikat voninfo.tuwien.ac.at (Informationsserver für die TU Wien)gültig von Mar 27 2001 bis Mar 27 2002MD5 Fingerprint=90:F4:99:B5:6B:DC:71:D8:81:EE:CB:24:0E:03:19:4C

Fingerprints der „self signed“ Serverzertifikate:Server-Zertifikat voniu.zid.tuwien.ac.at (Campussoftware Verwaltung)gültig von Mar 1 1999 bis Mar 1 2002MD5 Fingerprint=A0:FF:97:E3:25:5D:07:B9:20:CC:84:D6:88:05:EB:0F

ZentraleAnti-Spam-MaßnahmenJohann E. Klasek

Schon lange sind TUNET-Benutzer ein beliebtes Ziel von Spam-Mails aus aller Welt.Mittlerweile nimmt das Ausmaß dieser Form von unverlangt zugestellten E-Mails mitunterunangenehme Dimensionen an. Sowohl für die Benutzer bzw. Empfänger solcher E-Mailsals auch die Server-Betreiber. Zudem kommen noch Folgeerscheinungen von nicht unmittelbardie TU Wien betreffenden Spam-Mails, die sich auf andere Weise bemerkbar machen und sichim Wesentlichen in der erhöhten Belastung der Bastionsrechner widerspiegeln (was bisher abernoch keinen Grund zur Besorgnis darstellte).

Die sich aus diesen teils bedrohlichen Entwicklungenergebenden vier Problemfelder münden derzeit in entspre-chenden Strategien, die versuchen, dem E-Mail-Missbrauch(auch unter Berufung auf das Telekommunikationsgesetz,TKG §101, [1]) entgegenzuwirken:

1. Das TUNET als Quelle von Spams wird unterbunden:Durch Einsatz von Mailbastionsrechnern wird derzeiterfolgreich das dem Ruf der TU nicht besonders zu-trägliche und administrationsintensive 3rd-Party Relay-ing verhindert.

2. Spam-Mails mit TU-fremdem Ursprung sind mit ge-fälschtem TU-Absender versehen, und gelangen alsRetourmail an die TU: Diese können (als Option) fürgewisse Zielbereiche nach gewissen Adressmusternam Mailbastionsrechner blockiert werden.

3. Empfänger im Bereich des TUNET werden vonSpam-Mails heimgesucht. Mittels Zugriffseinschrän-kungen von Absender-E-Mailadressen und Serverad-ressen, basierend auf nicht im DNS auflösbare Adres-sen, auf konkrete Vorfälle die TU Wien betreffendoder auf dynamische im Internet angebotene Blackho-le-Listen mit globalem Status, werden derartige Spam-Mails blockiert.

4. E-Mails werden nach Viren- bzw. Wurmbefall unter-sucht und gegebenenfalls unterdrückt (bei entsprechen-der Benachrichtigung des Empfängers). Mehr dazu imArtikel „Zentrale Anti-Viren-Maßnahmen“ auf Seite 3.

Spam Mail Relaying

Maßnahmen zum ersten Problemfeld sind bereits inden letzten zwei Jahren umgesetzt worden, sodass mitt-lerweile die gesamte TU flächendeckend über den Bas-tionsrechner geleitet wird. Der Zugriff von außerhalb des

TUNET auf TCP Port 25 des SMTP-Protokolls ist (imWesentlichen bis auf die Bastionsrechner) gesperrt. DieBastionsrechner – wie bereits in [2] vorgestellt – leitendann die ankommenden E-Mails TU-intern weiter. Inter-essierte Empfänger können diese zusätzliche Zwischen-station einer erhaltenen E-Mail auch daran erkennen, dassdie detaillierte Ansicht des Mail-Headers eine Received-Line mit bzw. von tuvok.kom.tuwien.ac.at oderneelix.kom.tuwien.ac.at enthält.

Beim Mailverkehr innerhalb des TUNET sind die Bas-tionsrechner nicht involviert, wobei z. B. die Wähllei-tungszugänge der TU Wien natürlich zum TUNET zurechnen sind, nicht aber die TU Wien Chello StudentConnect-Teilnehmer.

Einer speziellen Behandlung bedarf es bei so genann-ten „Externen Domains“ (also solchen, die nicht auftuwien.ac.at enden), die auf TU Nameservern oderauch anderen, externen Nameservern betrieben werdenund, was wesentlich ist, einen im TUNET befindlichenMailserver verwenden wollen. Diese Domains bzw. derenMailserver sind dann mit Begründung für den Zusam-menhang mit den Aufgaben der TU Wien dem ZID zumelden (http://nic.tuwien.ac.at/formulare/domain.pdf),wodurch auch für diese externen Domains die Umleitungüber die Bastionsrechner realisiert werden kann und so-mit dem Sicherheitskonzept genüge getan wird.

Spam Address Faking

Mit der zweiten Maßnahme tritt man einer Problema-tik entgegen, die mit Spam-Mails zum Vorschein kom-men, die weder an der TU ihren Ursprung haben nochdorthin gesendet werden. Dennoch brechen schubweiseund zeitlich gehäuft von unterschiedlichsten Mailserverndes Internet wahre Mailstürme auf vermeintliche TU-


Mailadressen herein. Dabei handelt es um automatischvon Mailservern generierte Nachrichten, die offensicht-lich von Spam-Mails herrühren, die an nicht (mehr) exis-tierende oder anderweitig nicht erreichbare Empfängergegangen sind und nun an den Absender zurück ge-schickt werden. Dabei agieren die Spam-Mail-Verteilerschon im Vorfeld so geschickt, dass sie als Absende-adresse ihrer Spam-Mails eine existierende Domain (ebeneine der TU Wien) heranziehen und irgendwelche auto-matisch generierte User-Bezeichnungen (die vorab nichtüberprüfbar sind) aus Ziffern und Buchstaben verwenden.Damit geht man als Spammer einer statischen Filterungauf die Absenderadresse und einer Blockierung vonnicht-auflösbaren Adressen (bezieht sich immer nur aufden Domain-Teil einer E-Mail-Adresse) aus dem Weg.Explizit erwähnt soll hier die Tatsache sein, dass alle imMail-Header gemachten Angaben, speziell die Adressen,beliebig gefälscht sein können und nicht für die Mail-Zu-stellung herangezogen werden (für eine Antwort-Mail al-lerdings dann schon). Die relevanten Zustelladressenwerden direkt über das Simple Mail Transfer Protocol(SMTP) – entspricht dem Briefkuvert – gesondert über-tragen und sind dann für Empfänger nicht mehr (direkt)sichtbar.

Die Tatsache, dass so die TU Wien bzw. deren Bas-tionsrechner von den im Internet verteilten Mailservernmit derartigen Retourmails überschwemmt wird, kanndurchaus als Distributed Denial of Service Attack(DDoS) gewertet werden, die zwar nicht auf diesen Ef-fekt hin ausgerichtet ist, aber dennoch den ursprünglichenSpam-Mail-Versendern sehr wohl bewusst sein dürfte.

Da es sich in der Regel um Institutsdomains handelt,die auf diese Art missbraucht werden, sind natürlich auchdie entsprechenden Instituts-Mailserver, an die dieseMails dann weitergeleitet werden, betroffen. Auch wennam Institut die Fantasiebenutzer als Empfänger abgewie-sen werden, kommt durch das Zwischenspeichern unddas Verarbeiten jeder einzelnen Nachricht eine merkbareBelastung auf den Bastionsrechnern zustande. Aus die-sem Grund bietet der ZID eine optionale Blockierungvon speziellen Empfängeradressformen (User-Teil be-ginnt mit einem Buchstaben und endet auf mindestenszwei Ziffern), bezogen auf Hosts oder Subdomains derTU Wien Domain tuwien.ac.at, an. Bei Gefahr im

Verzug wird die Errichtung der Blockade vorab durchge-führt und das Institut darüber informiert, um etwaigeKonflikte mit der regulären Mailadressierung zu vermei-den. Auf Wunsch kann diese Blockade weiterhin perma-nent oder auch zeitlich begrenzt weitergeführt werden.

Spam Filtering

Die dritte Maßnahme bedient sich, in Anlehnung andie Empfehlung aus RFC 2505 (Anti-Spam Recommen-dations [3]), diverser Mechanismen, um direkte, an TU-Adressen gerichtete Spam-Mails abzuweisen.

Diese erzeugen bis heute zum Teil recht heftige Kon-troversen bei Vertretern der Persönlichkeitsrechte, admi-nistrativen Organen von Firmen und Einrichtungen,kommerziellen Spam-Versendern und schließlich den ei-gentlichen E-Mail-Empfängern selbst. Im Falle der TUWien werden optionale Methoden angeboten, die es er-lauben, gewisse Verfahren abhängig von Empfängerad-ressbereichen auf Antrag zu aktivieren oder zudeaktivieren.

Konkret sind nun folgende Mechanismen implemen-tiert bzw. vorgesehen:

1. Nicht auflösbare Absender-Adressen werden stan-dardmäßig abgewiesen, d. h. wenn der Domainteil ei-ner E-Mail-Adresse nicht mit einem Mailserver asso-ziiert werden kann oder kein Hostname ist (Überprü-fung via DNS – Domain Name Service), wird die be-gonnene Verbindung abgebrochen und eine E-Mail-Übertragung kommt erst gar nicht zustande.Dabei können zwei unterschiedliche Situationen auf-treten: Kann der Name z. B. wegen eines vorüberge-henden Nameserverausfalls nicht überprüft werden,wird ein temporärer Fehler an den absendenden Mail-server retourniert, der es dann eine gewisse Zeit lang(in der Regel fünf Tage) weiter probiert. Hingegenwird bei einer negativen Antwort eines Nameserversdie Abweisung durch einen permanenten Fehlerstatusangezeigt (was freilich so mancher Spam-Server igno-riert und dennoch weiter sendet) und an den Absenderzurückgemeldet.Wenn ein derartiges Verhalten für ein Institut mit ei-ner eigenen Mail-Domain nicht akzeptabel ist, besteht


SPAM Server

TU Mailbastionsrechner

tunamea/b

mail-abuse.org

TUNET

DNS LookupDNS Lookup

RBL+ Zone

Access List andereBlackhole Lists

Spam-Filter ArbeitsweiseSpam Empfänger Server

Spam ServerFrom: @...tuwien.ac.at

TU Mailbastionsrechner

Mailserver

@...tuwien.ac.at

TUNET

Spam Aussendung

Mailer Daemon Reply

Konsequenzen von Sender Address Faking

die Möglichkeit, die entsprechende Subdomain vondieser Verfahrensweise auszunehmen.

2. Manuelle Blockaden aufgrund lokaler Vorfälle:Anzeichen wie die erhöhte Belastung der Bastions-rechner oder steigender Bandbreitenverbrauch bzw.abrupt angestiegene Mailtransferraten werden zumAnlass genommen, nach eingehender Prüfung manuel-le Blockaden auf den Bastionsrechnern und den zen-tralen Mailservern zu errichten. Damit wird der Zu-griff nach Kriterien wie• IP-Adresse des Absender-Mailservers oder• E-Mail-Adresse des Absenders (Benutzer oder die

gesamte Domain)abgewiesen, wobei der Absender durch einen perman-ten Fehlerstatus auf das Nichtvorhandensein des ge-wünschten Empfängers hingewiesen wird (im Rahmeneiner Retourmail durch das Mailsystem des Absen-ders). Wenn sich die Lage nach einiger Zeit stabilisierthat, werden die Sperren wieder abgebaut.

3. Blackhole Listen (MAPS, ORDB, ORBZ, ...)Mit so genannten dynamischen Realtime BlackholeLists (oftmals kurz als RBL bezeichnet), wie z. B. diediversen Listen der Mail Abuse Prevention SystemOrganisation [4], ist eine globale, stets auf dem aktuel-len Stand befindliche Datenbank über das normaler-weise für die Namensauflösung im Internet zuständigeDNS-System realisiert. Damit werden eingehende Mail-verbindungen sofort überprüft, ob sie von gelistetenMailservern, Dialup-Hosts und ungenutzten Adress-bereichen stammen und gegebenenfalls blockiert. Esexistieren einige derartige Systeme, die mit teils sehrunterschiedlichen bis hin zu verwirrenden Kriterienschwarze Schafe (Spammer-Systeme) sammeln, über-prüfen und gegebenenfalls aus den entsprechendenDatenbanken wieder entfernen.

Die TU Wien hat vorerst die Nutzung des erst kürz-lich kostenpflichtig gewordenen RBL+ von Mail Abu-se Prevention System (MAPS) beantragt und wird dieVerwendung auf den TU-eigenen Nameservern zurVerfügung stellen. Die dafür notwendigen Nameservi-ce Zonen liegen dort als Replikat vor, sodass entspre-chende Anfragen nicht stets auf den externen MAPS-Nameserver zugreifen, was sonst je nach aktueller Er-reichbarkeit zeitliche Verzögerungen mit sich bringenkann.

Auf den Mailbastionsrechnern ist ein Service geplant,das wiederum auf Subdomain-Granularität das RBL-Verfahren auswählen lässt, ob und welche RBL-Va-rianten eingesetzt werden sollen. Mit MAPS als lang-jährigem Anbieter eines solchen Services (die RBL+Liste umfasst etwa 470.000 Einträge) wird vorerst einAnfang gesetzt, wobei durchaus auch andere RBL-An-bieter in Frage kommen können (z. B. ORDB mit etwa120.000 Einträgen). Deren Verwendung sollte aberstets unter Bedachtnahme auf Konventionen, Bedin-gungen (wie man z. B. Server von einer Liste wiederweg bekommt) und technische Realisierung des jewei-ligen Anbieters abgewogen werden. Dies wirkt sich inweiterer Folge auch auf die Angreifbarkeit solcher

Services durch juristische Mittel aus. Kaum eines derlänger im Umlauf befindlichen Services ist nicht ingerichtliche Auseinandersetzungen involviert gewesen,wovon man sich in den News-Kanälen der Web-Prä-senz der Serviceanbieter überzeugen kann. Prominen-testes Opfer in der jüngeren Vergangenheit war sicher-lich die ORBS-Liste, die mit der Einstellung ihrer Tä-tigkeit just etliche Nachahmer (wie etwa ORDB [5]oder ORBZ [6]) gefunden hat.Zum Teil arbeiten Spam-Befürworter und sie unter-stützende Provider derart eng zusammen, dass Name-server der RBL-Betreiber aus gewissen Teilen des In-ternet schlecht oder gar nicht erreichbar sind. Im Inter-net verteilt agierende Nameserver hingegen unterstrei-chen hierbei die Stärke und das Durchsetzungsvermö-gen eines Services.

In den Referenzen [4-9] finden sich einige Verweise aufSeiten diverser RBL-Serviceanbieter und Anti-Spam-Projekte, die hier kaum vollständig zitiert werden kön-nen, aber untereinander stark verwoben sind und damitzu allen Ecken der Anti-Spam-Gemeinschaft führen.

VirenDas vierte und letzte hier genannte Problemfeld ist

nicht unmittelbar mit der Spam-Problematik verbundenzu sehen, aber dennoch diesem gewissermaßen verwandt.Natürlich rufen via E-Mail verteilte Viren prinzipiell diegleichen unangenehmen Effekte (in den meisten Fällennoch schlimmere) hervor, die unerwünscht eingelangteNachrichten zu Spam-Mails machen. Die zuvor erwähn-ten RBL-Anbieter tragen dieser Situation zum Teil Rech-nung, in dem auch sonstige auffällige (etwa virenversen-dende) Mailserver bzw. allgemein formuliert, absendendeHosts aus dem Internet, in deren schwarze Liste aufneh-men, wobei dieser Ansatz meist mit der Verbreitungsge-schwindigkeit von Viren nicht mithalten bzw. derenVerbreitung effektiv verhindern kann. Ausführ-lichereszu diesem Thema ist im Artikel „Zentrale Anti-Viren-Maßnahmen“ auf Seite 3 nachzulesen.

Abschließend muss man dennoch feststellen, dassganz gleich, welche Strategien auch immer zum Einsatzkommen, stets Lücken und Möglichkeiten für die Ver-breitung von Spam-Mails und auch Viren auf E-Mail-Ba-sis existieren werden. Die Dynamik des Internet und dieteils starken kommerziellen Interessen hinter der Anwen-dung von Spam-Mails scheinen auch in Zukunft der Ga-rant dafür zu sein.

Referenzen

[1] Telekommunikationsgesetz:http://www.tkc.at/WWW/RechtsDB.nsf/pages/TKG (TKG §101Unerbetene Anrufe, Bgbl. I Nr. 188/1999 vom 20.8.1999)

[2] ZIDline 4, Dezember 2000, S. 3, Mailbastionsrechner - eineelegante Lösung der Spam-Problematik,http://www.zid.tuwien.ac.at/zidline/zl04/mailbast.html

[3] RFC 2505 Anti-Spam Recommendations for SMTP MTAs:ftp://ftp.isi.edu/in-notes/rfc2505.txt

[4] MAPS Realtime Blackhole List: www.mail-abuse.org,[5] Open Relay Database: http://ordb.org/[6] Open Relay Blackhole Zones: http://www.orbz.org/[7] OsiruSofts Open Relay Spam Stopper: http://relays.osirusoft.com/[8] Spam Prevention Early Warning System: http://spews.org/[9] The Spamhaus Project: http://spamhaus.org/


Telekom-Projekterfolgreich abgeschlossenWolfgang Kleinert

Am 31. 7. 2001 konnte nach erfolgreicher Schlussabnahme das Telekom-Projekt an der TU Wienendgültig abgeschlossen werden. Dies wurde durch eine gewaltige Schlussanstrengung vonManagement und Mitarbeitern der Auftragnehmer Telekom Austria und Ericsson Austria, desPlaners und der Mitarbeiter des ZID erreicht. Dafür möchte ich allen Beteiligten herzlich danken.

In einem früheren Artikel (ZIDline 3, Juni 2000) hatteich bereits die Komplexität und die Gründe für die aufge-tretenen Verzögerungen bei unserem Telekom-Projektausführlich analysiert. Die dort beschriebenen Problemekonnten inzwischen alle zufrieden stellend gelöst werden.An der TU Wien ist jetzt ein Telekommunikationssystemrealisiert, dessen technisches Konzept in einigen wesent-lichen Punkten bis an die Grenzen des von der Telekom-munikations-Branche Machbaren geht. Die Kombinationvon Desaster-toleranten Teilzentralen, die an einem ATM-Backbone gemeinsam mit der Datenkommunikation einesgroßen universitären Netzes betrieben werden, mit einemflächendeckenden DECT-System und einem chipkarten-basierten Verrechnungssystem, bei dem alle, durch exten-sive Verwendung von Least-Cost-Routing von mehrerenProvidern anfallenden Gebühren direkt an die Endbenut-zer verrechnet werden (noch dazu mit der weiter gehen-den Anforderung, dass mit einer Chipkarte sowohlDienst- als auch Privat- und Projektgespräche durchge-führt und abgerechnet werden können), ist in dieser Formeinmalig und zeigt, wozu die Telekommunikationsin-dustrie imstande ist.

Aus der Sicht unserer Endkunden war das Telekom-System bis auf immer wieder vereinzelt auftretende, un-

erklärliche Abbrüche von DECT-Gesprächen seit Som-mer 2000 in den unspektakulären Dauerbetrieb überge-gangen. Diese Probleme, die übrigens nicht nur an derTU Wien sondern weltweit aufgetreten sind, konnten nurdurch eine Reihe von Software-Patches und einen Firm-ware-Upgrade in den DECT-Sendern und -Geräten eini-germaßen zufriedenstellend gelöst werden, was einigeZeit in Anspruch nahm.

Als Betreiber musste der ZID allerdings darauf beste-hen, dass alle Detailprobleme gelöst werden, die bei denTests der für die Desaster-Toleranz wichtigen Group-Switch-Dopplung aufgetreten waren. Natürlich hoffenwir, dass ein Desaster-Fall wie Wassereinbruch oderBrand bei einer der Hauptanlagen im Freihaus oder amKarlsplatz nie eintreten wird, aber es mussten alle mögli-chen Fälle durchgespielt und das erwartete Systemverhal-ten demonstriert werden. Ebenso wichtig für den Betriebdes Gesamtsystems war die Beseitigung aller kleinenFehler beim Datenabgleich des DNA-Servers mit den Da-ten der Zentralen Verwaltung und den White Pages sowieder Synchronisation mit der TelekommunikationsanlageMD 110.


Immer schneller:Gigabit-Netzwerke für dieWissenschaftPeter RastlZentraler Informatikdienst der Universität [email protected]

Die Anbindung von Universitäten und Schulen an dasweltweite Internet erfolgt im Allgemeinen nicht über dennächstbesten Internet-Provider, sondern wird in den meis-ten Staaten von eigenen nationalen Wissenschaftsnetzen(NREN – National Research and Education Network) er-bracht. Auf diese Weise können die universitären Internet-Services landesweit gut koordiniert und wirtschaftlicheVorteile durch den gemeinsamen Einkauf größerer Netz-kapazitäten und die Inanspruchnahme nationaler und in-ternationaler Fördermittel genutzt werden. Außerdemsind gerade die Universitäten daran interessiert, neuetechnische Entwicklungen im Internet bereits einzusetzen,bevor sie am Markt allgemein verfügbar sind. Schließlichhat sich ja das Internet im universitären Bereich entwi-ckelt und wurde hier jahrelang erfolgreich verwendet, ehees seinen Siegeszug auch außerhalb der akademischenWelt antrat (siehe „Es begann an der Uni Wien: 10 JahreInternet in Österreich“, Comment 00/2, Seite 2 bzw. un-ter http://www.univie.ac.at/comment/00-2/002_2.html).

In Österreich wird das nationale Wissenschaftsnetz(„ACOnet“), das allen gemeinnützigen Einrichtungen derForschung, Bildung und Kultur zur Verfügung steht,nicht von einer selbständigen Organisation mit eigenerRechtspersönlichkeit, sondern vom Zentralen Informatik-dienst der Universität Wien betrieben. ACOnet ist einBackbone-Netz, das die Netzwerke der gegenwärtig 74Mitgliedsorganisationen untereinander und mit dem Inter-net verbindet. Jede dieser Organisationen ist mit einer be-stimmten Bandbreite, nach der sich auch der Kostenanteilfür die Teilnahme an ACOnet richtet, an einen der achtACOnet-Anschlusspunkte (PoP – Point of Presence) an-gebunden. Die ACOnet-PoPs befinden sich an der UniWien, der TU Graz, den Universitäten Linz, Salzburg,Innsbruck, Klagenfurt und Leoben sowie an der Fach-hochschule Dornbirn.

Der ACOnet-Backbone – also die Verbindung dieserPoPs – wurde bisher mit ATM-Strecken der TelekomAustria betrieben, deren Bandbreite entsprechend denständig steigenden Anforderungen typischerweise jedesJahr verdoppelt wurde (zuletzt beispielsweise Wien–Graz128 Mbit/s, Wien–Innsbruck 32 Mbit/s, Wien–Leoben8 Mbit/s). Technisch gesehen sind heute allerdings auchim Weitverkehrsbereich bereits Bandbreiten von mehre-ren Gigabit pro Sekunde möglich. Damit werden im In-ternet neue Services realisierbar, die bisher nur imlokalen Bereich mit ausreichender Qualität genutzt wer-den konnten (z. B. Video-Streams).

Um an den Universitäten eine innovative Verwendungdes Datennetzes zu stimulieren, etwa beim Einsatz derneuen Medien, sind Bandbreiten im Gigabit-Bereich er-forderlich. Erst wenn das Netzwerk die Voraussetzungenfür solche Anwendungen bietet, werden sie an den Uni-versitäten Fuß fassen können. Deshalb hat der ZID derUniversität Wien Ende vorigen Jahres die Umstellungdes ACOnet-Backbone auf Gigabit-Bandbreiten in An-griff genommen: Sowohl die nationalen Backbone-Ver-bindungen als auch die internationale Internet-Anbindungwerden derzeit massiv aufgestockt.

Im November 2001 wurden im Rahmen eines neuenServicevertrags mit der Telekom Austria sechs der achtACOnet-PoPs über Lichtwellenleiter mit einer Bandbreitevon 1,25 Gbit/s verbunden (siehe Abb. 1); für die beidenStandorte Leoben und Dornbirn wird im nächsten Jahreine Aufstockung auf 100 Mbit/s angestrebt. Diese neue,um eine Größenordnung leistungsfähigere Infrastrukturermöglicht es, künftig den Datenverkehr innerhalb vonACOnet wie in einem LAN ohne Verkehrsbeschränkun-gen – abgesehen vom Gigabit-Limit – zu erlauben undnur die Bandbreiten für den Datenverkehr nach außen(ins nationale und internationale Internet) entsprechend


den von den ACOnet-Teilnehmern getragenen Kostenan-teilen zu beschränken.

ACOnet betreibt seine externen Verbindungen übermehrere Anschlüsse: Die NRENs der meisten Staaten Eu-ropas und die an diese Wissenschaftsnetze angeschlosse-nen Institutionen sind über ein eigenes europäischesWissenschaftsnetz untereinander verbunden, welches inKooperation der europäischen NRENs mit finanziellerUnterstützung durch die EU-Kommission errichtet wurde.An dieses europäische Wissenschaftsnetz, das im Lauf

der Jahre unter verschiedenen Namen (zuletzt: TEN-155– Trans European Network at 155 Mbps) ständig ausge-baut wurde, war ACOnet zuletzt mit einer Bandbreitevon 90 Mbit/s angeschlossen.

Die europäischen NRENs haben bereits 1999 ein Pro-jekt unter dem Namen GÉANT gestartet, um ein Multi-Gigabit-Backbonenetz als Nachfolge für TEN-155 zu er-richten. Dieses für 4 Jahre geplante Projekt mit einem ge-schätzten Kostenaufwand von 200 Millionen Euro wirdvon der EU-Kommission in ihrem 5. Rahmenprogramm


Abb. 1: Nationale und internationale ACOnet-Verbindungen ab November 2001

Abb. 2: Geplante internationale Verbindungen im europäischen Wissenschaftsnetz GÉANT

mit 80 Millionen Euro gefördert. Ein Konsortium von 27NRENs (für 31 europäische Nationen) unter der Koordi-nation von DANTE, einer für diesen Zweck von denNRENs gegründeten und in Cambridge (UK) behei-mateten Non-Profit-Firma, ist für die Management-Entscheidungen im GÉANT-Projekt verantwortlich. Esist geplant, auch leistungsfähige Verbindungen zu denWissenschaftsnetzen in anderen Kontinenten zu errichtenund innerhalb der vierjährigen Projektlaufzeit die Band-breite im europäischen Backbone-Netz auf 100 Gbit/s zuerhöhen.

Im August 2000 hat DANTE eine europaweite Aus-schreibung gestartet, um die für das GÉANT-Netz erfor-derlichen Datenverbindungen zu beschaffen. Nach einemaufwendigen Auswahlverfahren (immerhin waren Ange-bote von 31 Anbietern zu evaluieren) wurden schließlicham 5. Juli 2001 die Verträge mit den Bestbietern COLTTelecom, T-Systems (Deutsche Telekom) und Telia un-terzeichnet, die den Kern des GÉANT-Netzes mit Band-breiten von 10 bzw. 2,5 Gbit/s bereitstellen. Österreich istdabei mit einer 10 Gbit/s-Verbindung nach Genf und ei-

ner 2,5 Gbit/s-Verbindung nach Frankfurt in dieses Netz-werk integriert und bildet auch den Anschlussknotennach Ungarn, Slowenien und Kroatien (siehe Abb. 2).Das GÉANT-Netz ist im November 2001 in Betriebgegangen; ACOnet wurde mit einer Bandbreite von 620Mbit/s daran angeschlossen, was eine Steigerung ummehr als das Zehnfache gegenüber dem Vorjahr bedeutet.

Über den VIX (Vienna Internet eXchange; siehe Com-ment 01/1, Seite 30 bzw. http://www.univie.ac.at/comment/01-1/011_30.html) ist ACOnet mit den kommerziellenösterreichischen Internet-Providern (und auch einigenausländischen) verbunden. Die Verbindung zu sämtlichenNetzknoten im Internet, die nicht über den VIX oder überTEN-155 zu erreichen sind, stellt ACOnet durch einenAnschluss an Ebone, einen der führenden Internet-Back-bones, her (derzeit 200 Mbit/s, ab 2002 620 Mbit/s).Dass alle diese Verbesserungen bei gleichbleibendemACOnet-Budget (jährlich etwa 80 Millionen Schilling)möglich waren, gehört wohl auch zu den Erfolgen dieserAnstrengungen.

Weitere Qualitätsverbesserungbei der Internetanbindungder TU WienJohann Kainrath

Und es wächst und wächst und wächst ...Laut einer aktuellen Studie der TeleGeography-Gruppe sind zwischen 2000 und 2001 dieinternationalen Internet-Bandbreiten um nicht weniger als 174 Prozent gewachsen, was mehr alseiner Verdoppelung dieser entspricht. Von 1999 auf 2000 betrug die Steigerung der Bandbreitegar 382%. Für Europa ist damit die genutzte Bandbreite von 232 auf 675 GB/s gewachsen.

Neuer ProviderCOLT Telecom Austria GmbH

Das Bemühen, der TU Wien eine qualitativ hochwerti-ge Internetanbindung zu garantieren, erfordert eine stän-dige Beobachtung der Internet-Serviceanbieter und derenService-Qualität. Daher wurde im Herbst dieses Jahresdie zweite Internetanbindung der TU Wien (Schwerpunktinternationaler Verkehr und USA) entsprechend rechtzei-tig vor Ablauf des bisherigen Vertrags mit KPNQwestneu ausgeschrieben. Als Bestbieter wurde COLT Tele-com Austria GmbH ermittelt.

Entwicklung seit dem Jahr 2000

Wie sicher bekannt, verfügt die TU Wien über zweisehr leistungsfähige Anbindungen an das Internet. AnfangApril 2000 wurde von AT&T Global Network Services(5 MBit/s) erstmals zu KPNQwest (6 MBit/s) gewechselt.Die ACOnet-Bandbreite betrug damals 16 MBit/s. Mit 2.November 2000 wurde die Internetanbindung überKPNQwest abermals erhöht, und zwar auf 8 MBit/s; am2. Mai 2001 erfolgte die nächste Erweiterung auf 10MBit/s. Die ACOnet-Verbindung hatte zu diesem Zeit-punkt bereits 32 MBit/s Kapazität. Die Bandbreitenent-wicklung von Oktober 2000 bis Oktober 2001 (noch mit


KPNQwest als Service-Provider) ist in nachfolgenderStatistik dokumentiert.

Wie die Grafik deutlich zeigt, ist seit Juni die abge-hende Belastung (also der Verkehr von der TU Wien indas Internet) extrem gestiegen. Mit ein Grund für dieseEntwicklung war und ist die Verwendung von Applika-tionen auf dem Gebiet der Multimedia-Technologie.Dazu zählen die so genannten Peer-to-Peer FilesharingTools.

Hochlastsituationen (wie in der nachfolgenden Grafikzu sehen) auf der Internetverbindung treten zunehmendhäufiger auf, dabei ist der abgehende Verkehr am „An-schlag“ und der eigentliche wissenschaftliche Nutzver-kehr bleibt dadurch nicht mehr ohne Beeinträchtigung.Dieser Zustand wirkt sich natürlich auch auf den ankom-menden Verkehr (Mail, Zugriff auf Web-Seiten im Inter-net, ...) aus.

Aktuelle Kapazität der AnbindungDie Umstellung auf den neuen Provider COLT erfolg-

te am 31. 10. 2001 nachmittags. Die verwendete Techno-logie zur Anbindung basiert auf dem 100 MBit/s EthernetStandard. Damit ist keine Abhängigkeit mehr von ande-ren Leitungsprovidern gegeben, denn COLT hat eine ei-

gene Glasfaserstrecke bis in die TU Wien errichtet. Durchdiese Realisierung ist weiters auch eine problemloseKapazitätserweiterung ohne neuerlichen Installationsauf-wand möglich.

Mit 1. November 2001 wurde diese zweite Internet-anbindung der TU Wien nun mit insgesamt 17 MBit/srealisiert (wobei davon 4 MBit/s zu günstigeren Kondi-tionen für das Goodie Domain Service reserviert sind).

COLT Telecom Austria GmbH ist ein Tochterunter-nehmen der COLT Telecom Group plc mit Sitz in London.Das Unternehmen ist auf Geschäftskunden ausgerichtetund betreibt in Wien ein eigenes hochleistungsfähigesGlasfasernetz zur Übertragung von Daten, Sprache undMultimedia-Applikationen.

ACOnetAuch der Haupt-Provider der TU Wien baut seine Ka-

pazitäten weiter aus und marschiert in Richtung GigabitEthernet. Siehe dazu den Artikel „Immer schneller: Giga-bit-Netzwerke für die Wissenschaft“ von Peter Rastl, Lei-ter ZID der Universität Wien, in dieser Ausgabe derZIDline.

Die Erhöhung der ACOnet-Bandbreite für die TU Wienauf 64 MBit/s wird noch im Quartal 4/2001 erfolgen.

Derzeit weist die Internetanbindung der TU Wien so-mit folgende Kapazität auf:

ACOnet 32 MBit/sCOLT 13 MBit/s

+ 4 MBit/s für Goodie Domain Service

Einerseits ist dadurch der Bedarf an wissenschaftlicherBandbreite auf sehr hohem Qualitätsniveau garantiert, an-dererseits werden zudem noch ausreichend Reserven fürProjekte und sonstigen Datenverkehr geboten. Und dieserwird sicherlich durch den ständigen Ausbau der Wissen-schaftsnetzwerke bzw. des Internet generell weiter konti-nuierlich steigen.


Abgehender (dunkle Linie) und ankommender (graue Fläche)Verkehr der TU Wien im Zeitraum Oktober 2000 bis 2001

über die KPNQwest Verbindung.

Hochlastsituation abgehender Verkehr (dunkle Linie),ein Tag Anfang September 2001

Aktuelle Auslastung der COLT Verbindung (17 MBit/s)12. bis 13. November 2001

Linuxin den Internet-RäumenMartin G. Rathmayer

Die derzeitigen Benutzer-PCs in den Internet-Räumen des ZID laufen unter Windows 95 undwerden übers Netzwerk gebootet. Das Konzept hat sich bis jetzt sehr gut bewährt, da es relativgut administrierbar ist und eine sichere und stabile Arbeitsumgebung für den Benutzer bietet.Dieses System kann aus zwei Gründen nicht mehr länger aufrecht erhalten werden:Zum Ersten ist die bestehende technische Lösung mit neuen Hardware-Komponenten nicht mehrrealisierbar. Zum Zweiten ist ein Umstieg auf ein neueres Betriebssystem auf Grund modernerApplikationen dringend notwendig, allerdings wird das Prinzip des „Remote Network Boot“ unterWindows ME, Windows 2000 oder zukünftigen Windows-Versionen nicht mehr unterstützt. Da einelokale Installation bei einer so großen Anzahl von PCs nicht ausreichend wartbar ist, wurde einanderer Weg, basierend auf Thin Clients unter Linux in Kombination mit Windows TerminalServern, gewählt. Dieses neue Konzept ist sehr vielversprechend, da es flexibel und gutausbaubar ist und die beiden zukünftigen großen Welten Linux und Windows miteinanderverbindet.

Konzept

Das neue System sieht wie bisher „diskless“ PCs vor,die allerdings unter Linux laufen und darüber hinaus pergeeigneter Client Software Zugriff auf eine spezielleAuswahl aktueller Windows-Applikation haben. Diese sogenannten Thin Clients werden ebenfalls übers Netzwerkgebootet und greifen auch auf das „Home Directory“ desjeweiligen Benutzers am UNIX Studentenserver zu. DasKonzept ist ähnlich der derzeitigen LBR/Mars Alternati-ve und wird diese auch zur Gänze ablösen.

Die Bedienung einer Linux Workstation ist heutzutagebereits sehr komfortabel und nahezu „Windows like“, so-dass ein Umstieg auf dieses Betriebssystem ohne Proble-me von einem Studenten der Technischen UniversitätWien zu bewältigen ist. Auch steht bereits eine großeAnzahl von guten Linux-Applikationen zur Verfügung,sodass der Standardbenutzer damit sicherlich sein Aus-langen finden wird. Zusätzlich gibt es eine Citrix Win-dows Terminal Server Farm, auf der per ICA (Indepen-dent Computing Architecture) Client eine ausgewählteAnzahl von Standard Windows-Applikationen und eineReihe spezieller Windows-Programme (z. B. für Übun-gen) ausgeführt werden können.

Thin Client Hardware

Die eingesetzten PCs haben alle 128-256 MB Haupt-speicher, Pentium II oder Celeron Prozessoren und teil-weise CDROM-Laufwerke und Wheel-Mäuse. EinigeClients sind bereits mit 100 MBit/s ans TUNET angebun-den und bieten sogar Audio-Unterstützung. Ein Paralleloder USB ZIP Drive kann überall angeschlossen werden.Alle Geräte besitzen deutsche Tastaturen und 17" Moni-tore. Alte, langsamere Geräte werden vollständig ersetzt.In Zukunft wird überall eine maximale Ausbaustufe an-gestrebt. Es ist ebenfalls geplant, die VT100 Terminalsdurch Kiosk PCs zu ersetzen.

Remote Boot Server Hardware

Die Linux Boot Server besitzen eine gute Netz- und I/OPerformance für die NFS Verbindungen, d. h. schnelleSCSI-Platten und eine gute Bus-Bandbreite (Dual Pen-tium III mit mindestens 512 MB und zwei Netzwerkkar-ten). Ausfallssicherheit und Leistungssteigerung wirddurch mehrere redundante Server (derzeit zwei Stück) er-reicht, die von einem Master Server ihre Konfigurationenund von einem Reference Client ihre zu exportierendenDaten laden. Die Windows-Applikationen liegen auf


einer eigenen Server Farm (derzeit drei Rechner), die un-ter Windows 2000 mit Citrix Metaframe XP betriebenwird (siehe „Citrix Terminal Server für die Internet-Räu-me“, Seite 17).

Software

Als Basis dient die komplette Linux RedHat Distribu-tion Version 7.x (Kernel 2.4.x) mit KDE (Version 2.x)als Desktop-Empfehlung. Im Wesentlichen werden diewichtigsten KDE-Applikationen für Mail/News/WWWvom ZID unterstützt sowie einige ausgewählte Applika-tionen wie Netscape, Acrobat Reader usw. Darüber hin-aus sind natürlich weitere Software-Pakete wie z. B. Star/Open-Office installiert, diese werden derzeit aber vomZID nicht unterstützt. Die Aktualisierung von Systemund Applikationen erfolgt je nach Verfügbarkeit undSinnhaftigkeit. Bei den Windows-Applikationen wirdhauptsächlich das MS Office Paket angeboten. Eine voll-ständige Liste aller installierten bzw. vom ZID unter-stützten Programmen wird auf den Web-Seiten des ZIDveröffentlicht.

Services

Die Thin Clients haben wie bisher je nach Zugangsbe-rechtigung vollen Zugang zum Internet und den Servicesdes ZID (UNIX Account, Mailbox, News Server, White

Pages, Drucken über Copy Card). In einer erstenTestphase wird es für die Benutzer des neuen Systemskeine Kernzeitbeschränkung geben.

Technische Realisierung

Nach dem Einschalten des PC-Arbeitsplatzes wirdübers Netzwerk ein DHCP Server kontaktiert, der demClient alle notwendigen Boot-Informationen (IP-Konfigu-ration, Bootfile und notwendige Start-Parameter) mitteilt.Danach wird je nach Methode (PXE oder Etherboot) perTFTP ein komprimiertes Image (ca. 1.5 MB) vom BootServer geladen, welches Kernel, Netzwerktreiber und einminimales Root Filesystem enthält. Nach Dekomprimie-ren und Ausführen des Kernels wird das Root Filesystemin einer wenige MB großen Ramdisk entpackt und derInit-Prozess wird gestartet. Dieser führt sofort alle not-wendigen NFS Mounts durch (/usr, /bin, /sbin, /lib, ...),startet wichtige System-Prozesse und wartet auf die User-Validierung. Diese erfolgt durch einen authentifiziertenMount des Home-Filesystems am Studentenserver per„NFS On Demand“ (s. u.). Danach werden noch einigeJobs durchgeführt (z. B. Initialisierung des User Directo-ries, Hardware-Erkennung, Starten von Services) undschließlich wird der Desktop gestartet. Das Gerät kannjederzeit ohne weitere Aktionen einfach abgeschaltetwerden.


I CA

NF

SD

HC

P

NF

SO

DPC PC

LinuxBoot

Server

UNIXStudenten-

server

UNIXStudenten-

server

LinuxBoot

Server

Switch

PC PC PC PC PC PC

Switch

Switch Print

Server

Citrix Server Farm

. . . . . .

Internet-Raum Internet-Raum

TUNET

Linux Remote Boot in den Internet-Räumen

Server

Die Redundanz der Boot Server wird dadurch bewerk-stelligt, dass mehrere Server auf DHCP Requests lau-schen und bei Ausfall eines Servers einfach der nächsteantwortet. Die Boot-Information enthält auch eine Listevon NFS-Servern, welche für das Mounten zur Verfü-gung stehen. Damit kann eine Lastaufteilung, die ja ei-gentlich nur für NFS relevant ist, erzielt werden. Sollteallerdings ein bereits gemounteter NFS-Server ausfallen,wird der Client inoperabel und muss neu gebootetwerden. Für Client-übergreifende Informationen stehtnoch ein Scratch Space am Boot Server zur Verfügung.

Client

Die Ramdisk des Clients, die das Root-Filesystem ent-hält, ist so groß gewählt, dass für /boot, /etc, /dev und/var genügend Platz ist. Dafür reichen in der Regel 3-5 MB aus. /tmp wird ebenfalls im Memory realisiert und/var/tmp liegt am Boot Server. Da Swappen über Netznahezu unbrauchbar ist, wird darauf verzichtet und jederClient mit ausreichend viel Hauptspeicher ausgestattet (inZukunft alle PCs mit 256 MB).

User Validierung

Die Benutzervalidierung geschieht nach Mounten derR/O Filesysteme und vor dem Mounten des Home-File-systems. Im Prinzip existiert auf dem Boot Server für je-den Remote Client und jeden User ein Datensatz, derInformationen über Konfiguration und Zugriffsrechte ent-hält. Dadurch ist es einerseits möglich, mehrere Benut-zergruppen mit verschiedenen Berechtigungsprofilen(Student, Kursteilnehmer, Tagungsbesucher) zu verwal-ten, und andererseits unterschiedliche Hardware Konfigu-rationen und Zugriffsmechanismen (Multimedia PC,Übungs PC, Kiosk PC, X-Terminal) zu ermöglichen. ImNormalfall geschieht die Validierung eines Studenten im-plizit durch den NFSOD Mount am Studentenserver. Esist aber auch ein Zugriff auf andere Server bzw. per alter-nativem Protokoll (z. B. SMB) möglich.

Windows Applikationen

Das technische Prinzip einer Windows Terminal Sessionsowie die Integration in das Linux-Umfeld (SessionWindow, Home Directory, Drucken etc.) werden in ei-nem separaten Artikel erläutert (siehe nächste Seite).

SecurityDa es sich bei den Client PCs um UNIX-Systeme han-

delt, könnte ein Benutzer das System theoretisch hackenund Root-Berechtigung erlangen. Dieses „Privileg“ bringtihm aber nicht viel und ist spätestens nach dem nächstenReboot wieder weg. Auf alle Fälle zieht es keine Session-übergreifenden Beeinträchtigungen für den nächsten Usernach sich, da dieses System ja „remote“ gebootet wird.Die Möglichkeit, dass der Client während einer Sessionvon außen gehackt wird, und dadurch ein Datenverlustfür den aktuellen Benutzer entsteht, ist sicherlich geringerals auf einem Studentenserver direkt.

Ein Problempunkt ist noch die Art und Weise, wieHome Directories gemountet werden. Da nicht 100-pro-zentig auszuschließen ist, dass sich doch ein User Root-Berechtigung am Client verschafft, kommt ein normalerNFS Mount nicht in Frage. Deshalb muss eine Methodeverwendet werden, die auf alle Fälle eine Validierung er-fordert. AFS und DCE scheiden aus administrativen undtechnischen Gründen aus. Bleibt eigentlich nur nochSamba, das leider einige sehr gravierende Nachteile be-sitzt (keine Symlinks, kein File Locking, ...). Da geradeviele der neuen KDE- und Gnome-Applikationen dieseFeatures benötigen, kommt es sehr schnell zu einem in-stabilen Betrieb. Da es NFS4 noch nicht gibt, wurde eineeigene Variante (unter Verwendung von NFS3) entwi-ckelt. Das Ganze nennt sich NFSOD (NFS On Demand)und basiert auf einem Client-Server-Mechanismus, beidem nach einem Validierungsschritt das User Home-Ver-zeichnis explizit für den Remote Client exportiert wird.Dann wird per Keep-alive Mechanismus die Existenzdes Clients überwacht und bei Terminierung desselbigender Export sofort entfernt. Ein zusätzlicher Überwa-chungsjob verhindert die Ausnutzung möglicher Sicher-heitslücken von NFS durch abgestürzte Daemons oderandere Probleme.

AusblickDas neue Konzept ist teilweise bereits im Zuge einer

Java-Übung im Internet-Raum Favoritenstraße im Ein-satz. Ende November wird der Internet-Raum FHBR2(Freihaus, 2. Stock) zur Gänze umgestellt und es wirddort nur noch Linux zur Verfügung stehen. Danach wer-den schrittweise die anderen Internet-Räume dazu kom-men. Hinweise und Einführungsunterlagen werdenrechtzeitig im Web zur Verfügung gestellt. Die Tutorenwerden auf das neue System eingeschult und geben Aus-kunft über unterstützte Applikationen und einfache Linux-Fragen.


Citrix Terminal Serverfür die Internet-RäumeHartwig Flamm

Um die Möglichkeiten der Nutzung der Internet-Räume noch vielfältiger zu gestalten, haben wireine Citrix Server-Farm in Betrieb genommen. Sie soll es ermöglichen, beliebige Software auf denRechnern in den Internet-Räumen laufen zu lassen, ohne dass diese für eine lokale Nutzunginstalliert werden muss.

Durch die Umstellung der Internet-Räume auf Linuxerhält dieses Service eine besondere Bedeutung. Dadurchkönnen auch Windows-Applikationen auf den Linux-Ar-beitsplätzen genutzt werden.

Längerfristig soll es möglich sein, dass auch InstituteWindows-Applikationen auf ihren eigenen Servern anbie-ten, die von den Arbeitsplätzen in den Internet-Räumenaus genutzt werden können.

Citrix KonzeptDie Terminal-Services auf Windows-Servern bieten

die Möglichkeit, Applikationen auf einem zentralen gutausgebauten Server ablaufen zu lassen, die Bildschirm-ausgabe jedoch auf einen entfernten Arbeitsplatz umzu-leiten. Ein Server kann dabei eine Reihe von graphischenLogins parallel betreuen.

Die Applikation wird von dem Administrator des Ser-vers betreut. An dieser Stelle erfolgt auch die Zugriffs-kontrolle. Ein Arbeitsplatz kann Verbindungen zu einerVielzahl an Servern aufbauen, sofern der Benutzer dazuberechtigt ist.

Auf dem Arbeitsplatz des Benutzers wird die Zugriffs-Software installiert. Damit können jetzt Verbindungen zuder Server-Farm definiert werden. Der Client lädt die ak-tuelle Liste der verfügbaren Applikationen der Farm, ausdieser wird dann die gewünschte ausgewählt. Einige Pa-rameter wie Verschlüsselung, Farbtiefe, Audioqualität undso weiter können noch verändert werden. Bei Applikatio-nen, die nicht für anonymen Betrieb konfiguriert sind,kann auch noch ein Benutzername eingegeben werden.

Wird die Verbindung aktiviert, so kontaktiert derClient die Farm und bekommt dort, auf Grund der LoadBalancing Algorithmen, einen Server für seine Sessionzugewiesen. Dorthin baut er dann eine verschlüsselteVerbindung auf. Man erhält das Login-Fenster des Ser-vers auf dem Bildschirm, es sei denn die Verbindung istanonym oder ein Standard für Username und Passwort istdefiniert.

Nach dem erfolgreichen Login werden die Laufwerkeund Drucker des Arbeitsplatzes auf den Server verbundenund das Applikationsfenster wird geöffnet.

Nach dem Beenden einer anonymen Verbindung wirddas temporäre Profil gelöscht.

Die Verwendung der Metaframe XP Software von Ci-trix bringt, gegenüber dem Microsoft Terminal Server,eine Reihe von entscheidenden Vorteilen. Die wichtigs-ten werden im Folgenden kurz dargelegt.

Citrix Lizenzvergabe

Die Zugriffslizenzen sind bei Citrix nicht an denClient sondern an den Server gebunden. Das heißt, eswerden nur Verbindungen als aktiv gerechnet, die gleich-zeitig auf den Server zugreifen und nicht, wie bei Micro-soft, die Arbeitsplatzrechner, von denen aus eineVerbindung aufgebaut werden könnte. Ein serverseitiges


Citrix Server Farm

r

Linux

Windows

Citrix Terminal Session

Management der Lizenzen wird dadurch erst sinnvollmöglich.

Der größte Vorteil der Citrix Software in diesemPunkt besteht aber darin, dass mehrere Server zu einemVerbund, der Citrix Server Farm, zusammengefasst wer-den können. Die Lizenzen können sich dann frei im Poolbewegen und dort eingesetzt werden, wo sie gerade ge-braucht werden. Gemeinsam mit den „publizierten Appli-kationen“ und Load Balancing (siehe unten) lässt sich dieVerwendung der Lizenzen sehr schön steuern.

Rahmenlose Fenster

Der Benutzer baut seine Verbindung nicht zu einemspeziellen Server auf sondern wählt eine in der Citrix-Farm publizierte Applikation aus und verbindet sich zudieser. Er wird dann zu einem der Server, welcher diegewünschte Applikation anbietet, verbunden. Der Benut-zer erhält aber kein Terminal-Fenster mit dem Windows-Desktop sondern es erscheint nur die Applikation selbst,so als würde sie lokal auf dem Client ablaufen.

Da dem Benutzer der Desktop nicht zur Verfügungsteht, kann er auch nur die publizierte Applikation nutzenund die Ressourcen des Servers nicht einfach für andereZwecke abzweigen.

Echtes Load Balancing

Die Aufteilung der Verbindungsanfragen auf die ein-zelnen Server kann durch Load Balancing Algorithmengesteuert werden. Darin können die Anzahl der Instanzendes Programms, die maximale Netzbandbreite, CPU-oder Speicherbelegung und vieles mehr als Parameterverarbeitet werden.

Über dieses System kann der Zugriff auf einzelne Ap-plikationen auch auf einzelne IP-Adressen oder Adress-bereiche eingeschränkt werden.

Einige weitere Kleinigkeiten

Die Citrix Client Software gibt es für sehr viele ver-schiedene Plattformen. Neben allen Microsoft Systemen,auch DOS und PocketPC, werden auch Apple und neunUNIX-Derivate unterstützt. Die Darstellung kann mit ei-ner Farbtiefe von bis zu 24-Bit erfolgen und die Einbin-dung von Sound ist möglich.

Eine Citrix Session erlaubt es, die lokalen Laufwerkeund Drucker des Arbeitsplatzes am Server sichtbar zumachen. Die Applikationen können daher ihre Dokumen-te direkt auf das lokale Filesystem des Benutzers schrei-ben. Sie erscheinen am Server sogar unter dem gleichenNamen wie am (Windows-)Client. Der Benutzer hat sei-ne Daten also immer am lokalen Rechner zur Verfügung.Ein Cut&Paste-Mechanismus ist zwischen Linux undWin-dows eingeschränkt möglich.

Mit Hilfe der Citrix Management Konsole kann dieServer-Farm vom Arbeitsplatz des Administrators auskonfiguriert werden. Es können zum Beispiel Applikatio-nen publiziert oder Load Balancing Parameter adjustiertwerden. Sessions, die im System hängen bleiben, weilder Benutzer die Verbindung zur Farm verloren hat, kön-nen vor Ablauf der „Gnadenfrist“ entfernt werden.

Die ZID-FarmDie Citrix Server Farm des ZID besteht derzeit aus

drei Rechnern:

Licence-Master:IBM Netfinity 45002 Pentium III 733 MHz1,5 GB Hauptspeicher

2 Member Server:Transtec 2400L2 * Pentium III 1000 MHz2 GB Hauptspeicher

Derzeit sind die zwei Java-Entwicklungsumgebungen,Forte von Sun und JBuilder von Borland, für denÜbungsbetrieb installiert.

Für den Test der neuen Softwarelösung für die Inter-net-Räume sind vorerst Word2000, Excel2000, Power-Point2000 und Access2000 installiert. Der IE5 aus demStandard Windows ist ebenfalls publiziert.

Um die Problematik der Windows-Validierung zu um-gehen, sind alle Applikationen für den anonymen Ge-brauch publiziert. Allerdings ist die Verwendung auf denAdressbereich der Internet-Räume beschränkt. Da aberauch bei anonymen Verbindungen die beteiligten Arbeits-plätze mit geloggt werden, ergibt sich dadurch kein Si-cherheitsproblem.

Im Moment stehen uns 20 Verbindungslizenzen zurVerfügung. Diese sollten von diesen drei Rechnern pro-blemlos bewältigt werden. Wahrscheinlich ist auch einehöhere Last, also zusätzliche Lizenzen, noch ohne signifi-kante Beeinträchtigung des Betriebes möglich. Sollte dieNachfrage nach diesem Softwareservice massiv ansteigen,so werden allerdings zusätzliche Server nötig werden.


Word am Linux Desktop

Sicherheit unter Linux:Packet FilterWalter Selos

Zusätzlich zu den in der letzten ZIDline behandelten Sicherheitsmechanismen (z. B. inetd undTCP-Wrapper) gibt es für Linux noch eine generellere Methode, um den IP-Netzwerkverkehr undvor allem den wichtigen TCP-Netzwerkverkehr zu kontrollieren und bei Bedarf einzuschränken.Diese Methode heißt „Packet Filtering“ und ist ein Grundbestandteil jeder Firewall. Die meistenFirewalls verfügen darüber hinaus auch über Mechanismen zur Adressübersetzung (NetworkAddress Translation), über Proxy-Funktionalität und einiges mehr.

Jeder Verkehr über ein Netzwerk wird in Form vonPaketen gesendet. Jedes dieser Pakete beinhaltet Verwal-tungsinformation, den so genannten Header, und dieNutzdaten, den Body.

Im Header befinden sich Informationen über Herkunft(Source Address) und Ziel (Destination Address) des Pa-kets, über das verwendete IP-Protokoll (z. B. TCP, UDP,ICMP, ...) und einiges mehr (siehe IANA, Internet Assig-ned Numbers Authority, www.iana.org). Neben der reinenDatenübertragung gibt es bei verbindungsorientierten IP-Protokollen (z. B. Transmission Control Protocol (TCP))spezielle Pakete für den Verbindungsaufbau bzw. -abbau.Auf dem TCP-Protokoll basieren die bekanntesten Servi-ces im Internet, wie z. B. HTTP (Web Traffic), SMTP(Mail-Transfer), SSH (Secure Shell) und Datentransfer(z. B. FTP).

Um auf Paketebene effektiv Zugriffsbeschränkun-gen und Kontrollmechanismen zu realisieren, mussman im besten Fall alle Informationen über die involvier-ten Protokolle haben, besonders wichtig sind aber die vonden Services verwendeten Portadressen. Ebenso ist eswichtig zu wissen, welche weiteren Services zur ein-wandfreien Funktion eines gewünschten Services im Hin-tergrund noch von Bedeutung sind. Zum Surfen imInternet reicht es nicht aus, nur HTTP (Port 80) zuzulas-sen, man benötigt zumindest noch das Domain NameService (DNS) mit Port 53 des UDP-Protokolls, sonstwerden keine Zielknoten über deren Namen erkannt. Fürein derartiges Zusammenspiel mehrerer Protokolle gibt eszahlreiche Beispiele. Eine Liste der häufig verwendetenProtokolle (UDP und TCP) mit den zugehörigen Port-adressen sind in der Datei „/etc/services“ aufgelistet undkönnen dadurch auch über den Servicenamen und nichtnur über die Portnummer spezifiziert werden.

Zur Verwendung eines Packet Filters sind also gewis-se Grundkenntnisse über den Netzwerkverkehr not-

wendig, und ich möchte dringend von der Verwendungdieser Mechanismen abraten, solange man nicht wirklichweiß, was man will bzw. welche Services auf dem Rech-ner benötigt werden. Befolgt man diesen Rat nicht, läuftman Gefahr, sich in falscher Sicherheit zu wiegen, weilman ja ohnehin die „Firewall“ aktiviert hat, ohne zu wis-sen, was da noch alles an den Filterregeln vorbei läuft,oder erwünschte Services funktionieren aufgrund falscherKonfiguration nicht mehr.

Zur Filtersoftware

Unter Linux werden zwei Packet Filter eingesetzt:ipchains für Kernels 2.2.x bzw. netfilter/iptables für Ker-nels 2.4.x.

Die Grundidee ist für beide die gleiche:(Namen und Syntax werden hier von ipchains verwendet,für iptables sind sie leicht unterschiedlich.)

Man kann ein Muster bekannt geben und eine dafüranzuwendende Methode, hier Target genannt. Stimmtein Packetheader mit diesem Muster überein, wird dieTarget-Methode darauf angewandt.

Targets können vordefinierte Aktionen sein, wie z. B.ACCEPT Paket wird weitergeleitet

DENY Paket wird nicht weitergeleitet und einfachvergessen

REJECT wie DENY, nur dass freundlicherweise eineICMP-Nachricht an den Sender zurück ge-schickt wird, damit der Sender nicht auf einTimeout warten muss.

Über die Funktionalität eines Packet Filters hinaus führenfolgende Targets:

MASQ kann ein privates Subnetz so verstecken, dasses als eine IP-Adresse nach außen erscheint


(dies geschieht durch Austausch der Port-nummern). Da es aber nicht möglich ist,von außen eine Verbindung zu einem derdahinter versteckten Computer aufzuneh-men, können solche Konfigurationen dieSicherheit wesentlich erhöhen.

REDIRECT Pakete können aus der Input-Chain (odereiner selbst definierten) an ein lokales So-cket umgeleitet werden.

NAT (nur bei iptables verfügbar) die Source-Adresse bzw. die Destinations-Adresse ei-nes Pakets kann gegen eine andere ausge-tauscht werden.

Schließlich kann als Target eine selbstdefiniertekomplexe „Chain“ angegeben werden, in die man eineMenge von Regeln einbauen kann. Diese Technik kannman verwenden um vorzufiltern, wenn man z. B. für ver-schiedene Subnetze unterschiedliche Regeln (Rulesets)anwenden möchte. Es gibt bereits fix vorgegebene„Chains“, z. B. input, output und forward.

Mit Hilfe von „Policies“ kann man das Standard-Ver-halten einer „Chain“ festlegen, wenn keine der definier-ten Regeln zutrifft, also generell ablehnen (DENY) oderzulassen (ACCEPT).

Der Sicherheitsbewusste wird wohl demnach eineDeny-Policy wählen. Dabei muss man natürlich wissen,was man explizit alles erlauben muss, um einen Betriebzu gewährleisten (siehe das oben angeführte Beispiel mitDNS, ebenso wäre z. B. zu bedenken, wenn man alles,also auch ICMP, für die Output-Chain sperrt, das TargetREJECT sich genau so verhalten würde wie DENY –also wieder einmal: Vorsicht ist geboten ! ).

Beispiel für eine Filterregel

ipchains -A input -s 128.131.xxx.0/24 -d 128.131.xxx.123

www -p tcp -j ACCEPT

ipchains -A input -s 0/0 -d 128.131.xxx.123 www -p tcp -y -j

REJECT -l

-A append (Anhängen am Ende der Kette)-s Source Address (Absender)-d Destination Address (Empfänger)-p Protokoll-j Target-l wenn das Muster zutrifft, wird ein Eintrag ins

Logfile geschrieben-y heißt, nur SYN-Pakete (dienen zum Verbindungs-

aufbau für TCP) werden behandelt

Bei den oben angeführten Regeln geht es darum, denZugriff auf den Webserver des Rechners 128.131.xxx.123 zu kontrollieren. Es soll der Zugriff nur vom ei-genen Subnetz aus erlaubt sein. Die zweite Zeile ist nö-tig, wenn die Policy für die Input-Chain nicht aufREJECT gesetzt ist, z. B.: ipchains -P input REJECT

Genauere Interpretation:1. Zeile: Alles, was vom Subnetz 128.131.xxx.0 mit derNetzmaske 255.255.255.0 (= 24 Bits) kommt und an dieMaschine 128.131.xxx.123 geht, ein TCP-Paket ist und

fürs WWW-Port (80, siehe /etc/services) bestimmt ist,wird erlaubt.

Wenn der Verkehr mit dem Muster nicht überein-stimmt, wird die nächste Zeile abgearbeitet. TCP-Verkehrmit beliebiger Absenderadresse und dem Ziel128.131.xxx.123 auf dem HTTP-Port (80) wird schonbeim Verbindungsaufbau (-y) abgeblockt und der Ver-such ins Logfile geschrieben. So kann man dokumentie-ren, wenn jemand mit dem Web-Server von 128.131.xxx.123 Verbindung aufnehmen will, dem der Zugriffverwehrt ist.

Will man jenen Netzwerkverkehr, der einem bestimm-ten Muster entspricht, nur mitloggen, wird die Regelohne Target (also ohne -j XXXX) aber mit der -l Optiondefiniert. Das kann auch zur Verifikation und Fehlersu-che sehr nützlich sein.

Dieses Beispiel soll den grundlegenden Mechanismusder Paketfilterung erläutern. Durch die Definition eige-ner „Chains“ können sehr leistungsfähige und komplexeFiltermechanismen geschaffen werden.

Hinweise auf die Dokumentation, die Sie für einenEchtbetrieb unbedingt benötigen, finden Sie unten. Ummit den Paketfiltern sinnvoll arbeiten zu können, mussman sich doch ziemlich tief in die Materie einarbeiten, dawürden „Kochrezepte“ wohl nicht sehr hilfreich sein.

Zu erwähnen ist noch, dass einige Linuxdistributionenvorgefertigte Firewall-Scripts mit z. T. sehr komplexen Re-geln beinhalten. Meist sind sie sehr unübersichtlich, sodassman nicht leicht Modifikationen darin vornehmen kann.

Dringende Empfehlung

Sowohl was diese fertigen Scripts betrifft als auchnach der Erstellung seiner eigenen Filterregeln, finde iches empfehlenswert, das Filterverhalten ausführlich zu tes-ten, um sicher zu sein, dass das, was erlaubt ist, auchwirklich funktioniert, und – wichtig für die Sicherheit –dass auch die Restriktionen voll funktionsfähig sind.

Dokumentation

1. Sehen Sie die mitgelieferten Manualpages durch:z. B.: man ipchains oder man iptables.

2. Sehr informativ sind die dazugehörigen HOWTOs,welche im Zuge des LDP (Linux Documentation Pro-ject) verfügbar gemacht wurden.

Die Links für die TU:für ipchains in den HOWTOS:http://gd.tuwien.ac.at/opsys/linux/LDP/HOWTO/IPCHAINS-HOWTO.html

für netfilter/iptables in Network-Administrators-Guide:http://gd.tuwien.ac.at/opsys/linux/LDP/LDP/nag2/x-087-2-firewall.future.html

Allgemeine Information zu TCP/IP:"The Linux Networking Overview HOWTO":http://gd.tuwien.ac.at/opsys/linux/LDP/HOWTO/Networking-Overview-HOWTO.html

"A TCP/IP Tutorial":http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1180.html


Wie komme ich zu meinerCampussoftware ?Bestellung – Zugang – Installation

Andreas Klauda, Martin Holzinger

Die von der Abteilung Standardsoftware des ZID verwaltete Campussoftware steht den Institutender TU Wien gegen einen bestimmten Kostenersatz zur Verfügung. Informieren Sie sich über dasreichhaltige Angebot auf der Webseite: sts.tuwien.ac.at/css/angebot.html

Die Campussoftware wird über den Software Distribu-tion Server (SWD) und andere Server zugänglich ge-macht, wobei jeder Lizenznehmer einen Account erhält,unter dem er auf seine lizenzierten Programme zugreifenkann.

Online-BestellungWenn Sie bereits über einen Campussoftware-Account

(Benutzernamen und Passwort) verfügen, können Sieneue Softwarelizenzen online unter

sts.tuwien.ac.at/css/online.html

bestellen. Diese Bestellung muss dann vom Freigabebe-rechtigten des Instituts online bestätigt werden. Der Be-steller sollte sich mit dem Freigabeberechtigten in Ver-bindung setzen, da dieser nicht automatisch von der Be-stellung verständigt wird.

Sollten Sie noch keinen Account besitzen, muss dieerste Bestellung per Formular durchgeführt werden. DieFormulare sind auf obiger Webseite unter dem Punkt„Bestellformulare“ zu finden. Benutzername und Pass-wort erhalten Sie bei der ersten Softwarebestellung vonuns per Hauspost.

Freigabeberechtigte müssen dem ZID bekannt gegebenwerden. Das können der Institutsvorstand und/oder ande-re vom Institutsvorstand nominierte Mitarbeiter sein. Injedem Fall muss ein spezielles Stammdatenblatt ausge-füllt und an die Abt. Standardsoftware geschickt werden(erhältlich online als Postscript- oder PDF-File unter sts.tuwien.ac.at/css/online.html (stammdat.pdf bzw. stammdat.ps unter „Bestellformulare“) oder im Sekretariat desZID).

Mit der Nominierung erhalten die Freigabeberechtig-ten das Recht, Bestellungen online zu bestätigen, womitdiese wirksam werden. Wenn der Freigabeberechtigteschon Lizenznehmer ist, dann hat er bereits einen Ac-count (Benutzername und Passwort) zugewiesen bekom-men, der auch für das Bestätigen von Bestellungen zuverwenden ist. Andernfalls wird ihm im Zuge der Nomi-nierung ein Account zugewiesen.

Nach der Freigabe steht die Software dem Benutzerspätestens am nächsten Tag zur Verfügung.

Bei jeder Bestellung ist auch die Wartung inkludiert.Wenn diese nicht gewünscht wird, muss sie explizit ge-kündigt werden (Formular wartungsende.pdf/ps), d. h. dasProdukt kann in der momentan lizenzierten Version weiterverwendet werden, es können jedoch keine Updates mehrbezogen werden. Wird eine Lizenz storniert (Formularstorno.pdf/ps), so muss das Programm vom Rechner ge-löscht werden. Um dem gesamten Campus größere Res-sourcen einzuräumen, wird ersucht, nicht mehr benötigteLizenzen an den ZID durch Stornierung zurück zu geben.


Institutsvorstand

Freigabeberechtigter

Besteller

VerrechnungSoftwareServer

SoftwareBestellung Campus

Software

Stammdatenblatt

Quartalsumbu

chungen

Monatsin

form

atio

n

Freigabe

INSTITUT

ZID Standardsoftware

Information

Konten-aufteilung

Quästu

r

Bestell- und Verrechnungsabläufe

InstallationDie Software wird für mehrere Plattformen angeboten

und dementsprechend auf verschiedenen Servern zur Ver-fügung gestellt. Im Folgenden wird die Installation be-stellter Software für Windows-, Macintosh- und Unix-Systeme beschrieben.

Windows

Die einfachste Methode unter Windows ist die Ver-wendung des Netzlaufwerks. Damit ist es möglich, diegewünschte Software direkt von unserem SWD-Serverzu installieren, ohne vorher alle Files auf eine lokaleFestplatte kopieren zu müssen (so wie früher mit FTP).

In den Dateien readme.1st, welche mit jedem Text-editor geöffnet werden können, finden Sie wichtige Infor-mationen wie Seriennummern oder Installationshinweise.

Und so funktioniert das Ganze:

• Den Windows-Explorer starten.• Im Menü Extras den Punkt Netzlaufwerk verbinden

wählen.• In der sich öffnenden Dialogbox wird automatisch das

nächste freie Laufwerk angezeigt, welches bei Bedarfauch geändert werden kann. In dem Eingabefeld darunterwird folgender Netzwerkpfad eingegeben:

\\swd\benutzername (z.B. \\swd\aklauda)

• Die Checkbox Verbindung wiederherstellen1 sollte de-

aktiviert werden.

Im nächsten Dialog wird nach dem Passwort gefragt. BeiWindows NT/2000/XP-Rechnern gibt es noch ein zu-sätzliches Feld für den Benutzernamen, welches aber leergelassen werden kann.

Bei Windows 9x/ME Systemen sollte die CheckboxKennwort speichern

1, aus Sicherheitsgründen deakti-viert werden.

In dem nun vorhandenen Netzlaufwerk sind alle lizen-zierten Programme sichtbar, z. B.:

Die WWW-Direktinstallation (TUINST) und dieHome-Verzeichnisse über den Webbrowser stehen nichtmehr zur Verfügung, da die Installation über Samba(Netzlaufwerk) einfacher ist und das Service kaum mehrverwendet wurde.

Sollten Sie keine Verbindung zum SWD-Server her-stellen können, sind folgende Dinge zu beachten:

1. Ihr Netzwerk muss richtig konfiguriert und verkabeltsein.

2. Ihr Rechner muss angemeldet sein und einen gültigenDNS-Eintrag haben (Anmeldung: http://nic.tuwien.ac.at/tunet/anmeldung.html).

3. Mit dem Befehl ping und der Angabe der IP-Adres-se des Software-Servers kann überprüft werden, ob derSWD-Server erreichbar ist (Eingabe command überStart-Menu – Ausführen):

Dann öffnet sich ein DOS-Fenster, dort geben Sieping 128.130.34.149 ein.


1 Der genaue Wortlaut variiert je nach Betriebssystem

Eine positive Rückmeldung des SWD-Servers ist infolgendem Bild ersichtlich:

Auf einigen Rechnern ist noch ein Eintrag in der DateiLMHOSTS notwendig, dieses finden Sie auf

Windows 9x/ME-PCs im Systemverzeichnis(z.B. C:\windows),

Windows NT/2000/XP-PCs im Systemverzeichnis\system32\drivers\etc(z.B. c:\winnt\system32\drivers\etc).

Eventuell hat die Datei die Endung SAM. In diesemFall muss sie zu LMHOSTS (ohne Punkt) umbenanntwerden. Danach kann sie mit einem Texteditor (z.B. Note-pad) geöffnet werden, um folgende Zeile hinzuzufügen:

128.130.34.149 swd

Eventuell ist die Aktivierung der LMHOSTS-Abfrageüber Netzwerkeigenschaften / LAN-Verbindung / Eigen-schaften des TCP/IP-Protokolls über die WINS-Regis-trierkarte notwendig:

Ein Neustart ist im Normalfall nicht notwendig.Danach sollte eine Verbindung möglich sein.

Macintosh

Zugangswege sind:

• AppleShare über AppleTalk:„Archiv“ in der Zone „EDV-Zentrum“

• AppleShare über TCP/IP:„Server IP Adresse ...“ macos.tuwien.ac.atVoraussetzung ist zumindest System Software 7.5.3,Open Transport 1.1.2 und AppleShare Client 3.7.2.Dieser Weg bietet einen etwas höheren Durchsatz alsAppleShare über AppleTalk.

• http://macos.tuwien.ac.at/Archiv/Dieser Weg erlaubt keine Direktinstallation vom Server.Außerdem wird Ihr Passwort im Klartext übertragen. DerZugriff auf große Dokumente kann sehr lange dauern.

UNIX

Der Zugang zum SWD-Server über FTP, welcher fürdie meisten UNIX-Programme verwendet wird, bleibtweiterhin erhalten und wird demnächst durch ein SecureFTP ergänzt, das eine sichere (verschlüsselte) Übertra-gung der Daten ermöglicht.

Für Campussoftware-Produkte für UNIX-Plattformengibt es je nach Produkt unterschiedliche Zugangsmecha-nismen. Am SWD-Server ist entsprechende Dokumenta-tion in den readme-Files vorhanden.


Der neueSoftware Distribution ServerSunFire 3800Helmut Mastal, Werner Steinmann

Der neue Software-Server SunFire 3800 steht kurz vor der Inbetriebnahme als Hauptsystem fürdie Verteilung der Campus-Software der TU Wien. Damit wird das symmetrisch-redundanteDoppelsystem von Sun Enterprise 450 Servern sukzessive abgelöst, und es kommt mittelfristig zueiner Konfiguration mit innerer Redundanz und einem höheren Anteil an aktiven Komponenten.

Entwicklung des Software DistributionServers in den letzten drei Jahren

In den Jahren 1997/98 wurden zuletzt die Systeme desSoftware Distribution Servers neu installiert, indem eineSPARCstation 20 durch 2 gleiche, redundante SystemeSun Enterprise 450 mit je 2 296 MHz Prozessoren und je512 Mbyte Memory ersetzt wurde. Die SPARCstation 20hatte bereits 3 Jahre zuvor eine noch ältere Sun Maschine(SPARCstation 330) abgelöst. Die beiden 450 Systeme,die also schon die 3. Generation der Software Distribu-tion Server darstellten, bildeten ein symmetrisches Acti-ve-Standby Paar. Zur Vorrätighaltung der zu verteilendenCampus-Software dienten zwei StorageWorks RAID-Sys-teme mit netto ca. 500 Gbyte Speicherplatz bei den da-maligen Plattengrößen. An Software wurde angeboten:Anwendungssoftware für PC und Unix sowie Betriebs-systeme für PC. Gleichzeitig wurde die Administrations-software SDS (Software-Distribution-System) laufendweiter entwickelt und verfeinert, mit der die Validierungder Benutzer und die Zuordnung der in Sublizenzen ver-gebenen Software-Pakete ermöglicht wird. Den Benut-zern steht die Software über die Services FTP, Sambaund HTTPS zur Verfügung. Der Zugang über SFTP wirdderzeit in Erwägung gezogen.

Erfreulicherweise entwickelten sich der Software-Ser-ver und die Akzeptanz seiner Dienstleistungen sehr gut.Es war in den letzten Jahren mit einem zehnprozentigenjährlichen Zuwachs bei der Anzahl der Software-Downloads zu rechnen. Der Speicherplatzbedarf fürCampus-Software stieg aber wegen der zunehmendenKomplexität der Software-Pakete und höheren Speziali-sierung bis zu 40 Prozent pro Jahr. Dieser Zuwachs

konnte zeitweise nur durch eine rigorose Politik bei derZurverfügungstellung alter Software-Versionen bewältigtwerden.

Es ist daher nicht verwunderlich, dass bald nach derInstallation der Enterprise 450 Servergeneration Überle-gungen über die nächste Innovation angestellt wurden.Dabei bildete sich folgende Zielvorstellung heraus: NachErreichung des Endes des Lifecycles der 450 sollte einServer/Speicher-System zur Verfügung stehen, das in derLage war, wesentlich größere Datenmengen (Terabytes)vorrätig zu halten, und das auch leistungsfähig genugwar, die notwendigen seriellen Batch-orientierten Opera-tionen (Backup, Linken der den Benutzern zugewandtenVerzeichnisse mit den gespeicherten Daten) in einer ver-nünftigen Zeit durchzuführen. Auch sollte diese Leistungdadurch erbracht werden, dass ein höherer Anteil der Ge-samtressourcen aktiv dem Benutzerbetrieb zur Verfügungsteht als bisher.

Mit diesem Szenario als Ziel wurden bereits in denJahren 1999 und 2000 Investitionen getätigt, die unmit-telbare Entlastungen bei den vorhandenen 450 Systemenbringen sollten, aber auf jeden Fall auch in das Gesamt-konzept der nächsten Servergeneration ab 2001/2002 pas-sen mussten. In diesem Sinne wurden im Herbst 1999zwei Bandwechselsysteme (Jukeboxes) vom Typ Over-land LibraryXpress mit je 15 Slots für Backup-Zweckeangeschafft, die das vorhandene DLT 7000 Laufwerk ab-lösten und in ihrer Kapazität bis zu ca. 1 Terabyte Datenausreichen werden. Im Frühjahr 2001 wurde schließlichdie Backup-Maschine SPARCstation 20 (SWD-Serverder 2. Generation) durch eine Sun Enterprise 450 abge-löst und damit die Performance der Server-Backups ver-bessert.



SWD 1. GenerationSPARCstation 330 (hinten)plus Plattengehäuse

SWD 2. GenerationSPARCstation 20

2 OverlandBandwechselsysteme+ Sun Enterprise 450

SunFire 3800:Fronttüre geöffnetsichtbar(von oben nach unten):RAID T3Domain ControllerCPU/Memory BoardcPCI Interface Kartenredundante Stromanschlüsse

SunFire 3800:Gesamtansicht

Altes StorageWorksRAID-System 450

SWD 3. GenerationSun Enterprise 450

Neues MetaStorRAID-System 3702

Die wesentliche Erneuerung im Jahr 2000 war derÜbergang zu einer neuen Generation von Speichersyste-men. Es wurde das MetaStor RAID-System 3702 ange-schafft, das mit heutigen Plattengrößen (73 Gbyte) bis zu2 Terabyte (netto etwa 1.5 Terabyte) sinnvoll ausbaubarist und paarweise redundante Verbindungen zu jedemHost in Fibre-Channel Technologie mit Gigabit-Übertra-gungsraten ermöglicht. Das RAID-System 3702 ist damitals SAN (Storage Area Network) anzusprechen und hatmit einem Lifecycle von etwa 5 Jahren genau so in diebestehende vollredundante Konfiguration der 450er zupassen wie in die Endkonfiguration mit innerer Redun-danz, die voraussichtlich 2002/2003 erreicht werdenwird.

Erfahrungen aus der bisherigenStruktur

Die bestehende, aus den Jahren 1997/98 stammendeServergeneration ist als symmetrische, hoch redundanteLösung anzusehen, mit den beiden Sun Enterprise 450Systemen als 100-prozentiges gegenseitiges Backup,während die beiden alten (jetzt schon außer Betrieb ge-nommenen) StorageWorks RAID-Systeme für einen sinn-vollen Benutzerbetrieb stets gleichzeitig benötigt wurden.

Hochredundante Lösungen können folgende Probleme insich bergen: einerseits sind möglicherweise Komponen-ten doppelt ausgeführt, die nie oder sehr selten (innerhalbdes Lifecycles von etwa 3 Jahren) Fehler aufweisen, an-dererseits können gerade in hochredundanten Konfigura-tionen sehr leicht neue Single-Points-of-Failure entstehen(oder übersehen werden), allein dadurch, dass die Verbin-dungen zwischen den einzelnen Redundanzebenen nichtmit der erforderlichen 4fach-Redundanz ausgeführt sind.

Die vollständige Redundanz für ein Service bewirkt,dass höchstens die Hälfte aller vorhandenen Ressourcenproduktiv genutzt werden kann, während der Rest nur da-rauf wartet, dass irgendeine aktive Komponente ausfällt.Auch in der ursprünglichen Sun 450 Konfiguration gabes solche versteckte Single-Points-of-Failure: das warendas ATM-Interface für den Benutzerzugang, sowie diefür beide Systeme gemeinsame USV (unterbrechungs-freie Stromversorgung), die nur einen einzigen Strom-kreis unterstützte. Alle diese versteckten Problemekonnten mit geringen Mitteln noch für die alten 450 Sys-teme behoben werden und für die Neuplanung entspre-chend berücksichtigt werden (nur 100 Mbit/s Ethernet-Interfaces, zwei Stromkreise einer neuen Emerson USV(von Liebert Hiross) dediziert für den Software-Server).Untersucht man die tatsächlich aufgetretenen Takeovers,also die fehlerbedingten Wechsel von einem System zumanderen, so findet man etwa ein Takeover pro Monat imDurchschnitt, wobei aber die Mehrzahl zu Lasten der al-ten USV geht, jedoch kein einziger Fall auf ein perma-nentes Hardware-Problem bei den Serversystemen zurückzuführen ist.

Planung des neuen ServersSunFire 3800

Schon bei den ersten Planungen für das neue Softwa-reserver-System war klar, dass bei einem System, dasServices für den gesamten Campus 24 Stunden pro Tagüber das Netz anbietet, nie wirklich auf Redundanz ver-zichtet werden kann. Es sollte aber bei allen Komponen-ten, insbesondere bei den teuren Ressourcen wieProzessoren und Speicher genau abgeschätzt werden, obeine 100-prozentige Redundanz wirklich notwendig undsinnvoll ist, und ob nicht Redundanz in geringerem Aus-maß eine genügend hohe Verfügbarkeit liefert. Es ergabsich daraus in der Folge die Forderung, dass von den kri-tischen, teuren Ressourcen mindestens zwei Drittel aktivfür den Normalbetrieb zur Verfügung stehen sollen, undhöchstens ein Drittel als Hot-Standby bereit gehaltenwird.

Da im heurigen Frühjahr die SunFire Servergenerationals Nachfolgeserie der Sun Enterprise Generation auf denMarkt kam, wurden Lösungen, die Redundanz in einembestimmten Ausmaß vorsehen, durch das in der SunFireSerie ab dem Modell 3800 vorhandene Domainkonzeptsehr begünstigt. Dieses baut auf innere Redundanz aufund kann Ressourcen im Verhältnis von Prozessor/Me-mory-Boards aufteilen. Da es schließlich gelang, einenSunFire Server 3800 mit 4 Sparc III Prozessoren und 4Gbyte Memory zu einem unschlagbar günstigen Einfüh-rungspreis von Sun Austria zu erwerben, war der weitereWeg klar: Neben der SunFire 3800 als aktivem Server


0

200

400

600

800

1000

1200

Jän-9

7

Mär-

97

Mai-97

Jun-9

7

Aug-9

7

Okt-

97

Dez-9

7

Feb-9

8

Apr-

98

Jun-9

8

Aug-9

8

Okt-

98

Dez-9

8

Feb-9

9

Apr-

99

Jun-9

9

Aug-9

9

Okt-

99

Dez-9

9

Feb-0

0

Apr-

00

Jun-0

0

Aug-0

0

Okt-

00

Dez-0

0

frei

Produktdaten (netto)

Produktdaten (Parity)

Spare

UFS-Logging

home

Übersicht RAID-Belegung (GB)1. 1. 1997 bis 31. 12. 2000

0

200

400

600

800

1000

1200

1400

1600

1800

Mai Jun Jul Aug Sep Okt Nov Dez

Office

Adobe

Corel

WindowsWin/NTWin2000NAntiVirusVirusUtil

Technet/Eudora/VBasic,VisualC,/Matlab/Mathematica

Sonstige

SWD-Downloads im Jahr 2000nach Produktgruppen

bleibt zunächst eine der Sun 450 mit einem auf 2 Gbyteerweiterten Hauptspeicher als Hot-Standby Server erhal-ten. Zu einem späteren Zeitpunkt wird unter Ausnützungdes Domainkonzepts die SunFire 3800 um eine zweiteDomain mit nur 2 Prozessoren erweitert, sodass dannwieder zwei Drittel des Gesamtsystems aktiv bleiben.Das zweite alte Sun Enterprise 450 System bleibt (wiedie meisten älteren Software-Server-Systeme) produktiverhalten und wird in Zukunft als neuer Goodie-Domain-Server eingesetzt werden.

Installation und Konfiguration desneuen Servers

Hardware

Die drei vorhandenen Sun Ultra Enterprise 450 Serverwerden Schritt für Schritt durch eine Sun Fire 3800 mitzwei Domains ersetzt. Mit der SunFire 3800 verlagertsich die Redundanz durch mehrere getrennte Maschinenauf die Ausfallssicherheit innerhalb eines Gehäuses, wo-bei weiterhin eine Cluster-Konfiguration mit Failover be-trieben wird. Momentan besteht der Cluster aus einer SunUltra Enterprise 450 und einer SunFire 3800 mit einerDomain.

Die Begriffe Domain und Partition verwendet Sun indiesem Zusammenhang zur Beschreibung verschiedenerKonfigurationsmöglichkeiten ihrer SMP Server. DieseKonzepte wurden mit der Sun Enterprise 10000 (Starfire,mit bis zu 64 UltraSPARC-II Prozessoren und 64 Giga-byte Hauptspeicher) populär und sind in der SunFire Se-rie weiterentwickelt worden.

Eine Sun Enterprise 450 ist schon seit einiger Zeit de-diziert als Backup-Server mit Legato NetWorker im Ein-satz. Das Backup großer Datenmengen ebenso wie dasEinspielen läuft weitgehend über ein eigenes internesNetzwerk und nicht über die vom offiziellen TUNET er-reichbaren Anschlüsse.

Eine weitere E450 wird nun für gd.tuwien.ac.at frei;generell wird in all unseren Plänen einer sinnvollen Nut-zung für wiederverwertbare Teile hohe Bedeutung beige-messen. Und die dritte – zurzeit im Cluster befindliche –450-er dient dem Testen und Entwickeln von Softwarebzw. als Ersatz bei Problemen.

Die bisherige Variante mit mehreren Maschinen warkostenneutral zu einem brauchbaren Wartungsvertrag undgab uns mehr Flexibilität bei Entwicklung und Testen.Bei der neuen Maschine ist ein Wartungsvertrag imBundle dabei.

Die Sun Enterprise 450 Systeme sind jeweils mit2 x 296 MHz UltraSPARC-II Prozessoren, mindestens1 GB Memory, redundanten Netzteilen, Lüftern, SCSI-Controllern, Fibrechannel-Controllern, Ethernet- undATM-Anschlüssen ausgestattet. Es gab seit ihrem Einsatzkeine Totalausfälle der Maschinen sondern eher nur Stan-dardsituationen wie Platten- oder Memory-Tausch. Dieheiklen ATM-Anschlüsse haben sich nicht bewährt undwurden durch Fastethernet-Controller ersetzt, die absolutproblemlos funktionieren und als Vierfachanschlüsseauch sehr kostengünstig sind.

Die neue Sun Fire 3800 hat ein CPU Board mit 4 GBMemory und 4x750 MHz UltraSPARC III CPUs (d. h.eine Domain/Partition). Sie ist mit einem Sun StorEdgeT3 RAID und einem Media Tray D240 in einem SunFire Systemschrank eingebaut, wobei bezüglich Ausfalls-sicherheit gegenüber unserer bisherigen Konfigurationschon im Design viele Vorkehrungen getroffen sind undman nicht den Eindruck von Add-ons hat. Sogar die PCIKarten sind im Betrieb tauschbar, sie sind als cPCI (com-pact PCI) ausgeführt. Dieser Kartentyp ist aber (noch)nicht sehr weit verbreitet und falls man ganz bestimmteKarten wie für die Fibrechannel-Anbindung der verwen-deten MetaStor RAIDs sucht, ist das langwieriger als dieVerwendung gängigerer Interfaces. Das CPU Board ist inunserer Konfiguration natürlich nicht sinnvoll im Betriebzu wechseln, sondern erst wenn ein zweites als zweiteDomain vorhanden wäre. Im Betriebssystem bzw. im Do-main Controller ist entsprechende Unterstützung derHardware vorgesehen, es lassen sich z. B. CPUs und In-terfaces aktivieren/deaktivieren.

Software

Bei der Software-Liste ist Einiges bereits durch dieverwendete Hardware vorgegeben:

Als Betriebssystem für die neue Anlage ist Solaris 8ab Release 4/01 notwendig, d. h. z. B., dass wir alle ein-gesetzte Software auf 64-Bit-Tauglichkeit überprüfenmussten. Auf der älteren Anlage war noch Solaris 2.6 inVerwendung (nach Version 2.6 wurde mit 7 bzw. jetztaktuell 8 weitergezählt). Unserer Anforderung nach mög-lichst weit verbreiteter Software entspricht Solaris immernoch, obwohl sich in den letzten Jahren die Verbreitungverschiedener Unix-artiger Betriebssysteme stark geän-dert hat. Die unter diesem Betriebssystem vorhandeneProgrammierumgebung ist uns vertraut, wobei wir dabeiwesentlich auf das GNU Project und andere frei verfüg-bare Programme zurückgreifen und nicht nur Produktevon Sun einsetzen. Die von Sun mitgelieferten Versionenvon Perl etc. sind oft nicht die Versionen, auf die unsereVerteilungsmechanismen aufbauen, und müssen ergänztwerden. Auch bei der Programmierumgebung gab es un-ter Solaris 8 nicht nur einen Namenswechsel auf Fortestatt bisher Workshop. Adaptierungen der Verteilungsme-chanismen über TCP/IP oder andere an der TU gewün-schte Protokolle sollten aber keine ernsthaften Problemebereiten.

Als Cluster-Software mit Failover-Eigenschaftenwählten wir nach unseren bisherigen Erfahrungen wiederdas Produkt Watchdog der Firma Apptime (ehemals Fir-ma Wizard) in München, das unseren Anforderungen(KISS – keep it small and simple) entspricht (siehe:www.apptime.de). Das von Sun selbst angebotene Clus-ter Environment ist ausschließlich auf Sun-Produkte kon-zentriert und wäre schon aus diesem Grund für unsereKonfiguration nicht sinnvoll einsetzbar.

Als Backup-Software verwenden wir Solstice BackupVersion 6.0.1 (= Legato NetWorker), wobei wir zurzeit35 Clients auf einem eigenen Backup Server unterstützen(Sun Enterprise 450 mit 2 Overland DLT Juke Boxes).


Im Falle eines GAUs wäre mit einer Woche zu rech-nen, bis Hunderte von GigaBytes wieder von den Bän-dern restauriert sind.

Zur Unterstützung von Filesystemen, Volumes, demVerändern von Filesystemen im Betrieb (Growfs), Trans-action Tracking (Journaled File Systems) und zum Auf-setzen unserer Verteilungs-Software verwenden wirweiterhin Online DiskSuite Version 4.2.1 (ODS) unterSolaris. Dieser betriebssystemnahe Software-Teil ist inso-fern kritisch, als auch hier die Umstellung von Solaris 2.6bzw. 7 auf 8 zum Tragen kommt. Ein Übergang auf Ve-ritas Produkte, die von Sun für seine eigenen Cluster-Lö-sungen verwendet und angeboten wird, war bisher nichtnotwendig, denn ODS wird entgegen anders lautendenAnkündigungen weiterhin unterstützt und ist für unsereBedürfnisse ausreichend.

Das bereits vorhandene Notification System (Mail,SNMP, Pager, Auswerten von Logs) wird kontinuierlichweiter verbessert, wobei auf entsprechende Unterstützungbei den neueren Komponenten geachtet wurde. Die Mo-nitoring Services bei der USV oder Ambiental Monito-ring bei den Suns sind wesentliche Verbesserungengegenüber der alten Anlage.

Um mit der Entwicklung bei den Konsolen für Server(Domain Controller) oder RAID Schritt zu halten, habenwir ein neues, rein administratives 10 MBit/s Netzwerkeingeführt. Das Sun T3 RAID hat einerseits bereits garkeine serielle Konsole mehr, andererseits sind zur Konfi-guration über Ethernet nur unsichere Protokolle wie Tel-net und Ftp vorgesehen. Bei Netzwerkdruckern ist dieseArt von Konfiguration im schlimmsten Fall wahrschein-lich höchstens lästig, aber kein Desaster wie eine gestörteKonfiguration bei einem RAID. Die Steuerung der Stora-geWorks RAIDs basierte noch auf einem offensichtlichproprietären Betriebssystem der Firma Digital, der Do-main Controller, das T3 und die MetaStor RAIDs bauenhingegen auf bekannten embedded UNIX-Systemen wieVxWorks oder pSOSystem auf. Das Ansprechen derRAIDs zur Konfiguration über den SCSI-Bus ist aber erstnach einer Grundkonfiguration im Console Mode mög-lich oder andere elementare Funktionen wie FirmwareUpgrade sind (sinnvollerweise) nur so vorgesehen.

Ausblick und zukünftige ServicesDie Vollinbetriebnahme der SunFire 3800 ist mit dem

Zusammenschluss mit dem RAID-System 3702 noch imNovember diesen Jahres geplant und möglicherweise beiErscheinen der ZIDline bereits abgeschlossen. Die Benut-

zer am Campus der TU Wien sollten davon nicht allzuviel merken. Auch die Services des neuen Servers wer-den weiterhin über den generischen Hostnamen swd.tuwien.ac.at angesprochen. Nach der Inbetriebnahme istdaran gedacht, SFTP (Secure FTP) als neues Service an-zubieten, insbesondere aber nicht ausschließlich fürUnix-Benutzer, da das alte FTP keine verschlüsselteÜbertragung kennt, Samba-Clients im Unix-Bereich abernicht sehr verbreitet sind (vergl. auch den Artikel „Wiekomme ich zu meiner Campussoftware ?“ auf Seite 21).

Referenzen

Für den allgemeinen Überblick ein Buch von:Adrian Cockcroft and Richard Pettit, Sun Performanceand Tuning, Sun Microsystems Press, Second edition,560 pages, ISBN 0-13-095249-4

Ältere Artikel zum Software Dstribution Service an derTU Wien sind im Archiv der Ausgaben von Zeitschriftendes ZID nachzulesen:www.zid.tuwien.ac.at/zidline/archiv.html

Für aktuelle Informationen einige Web Pages der Herstel-ler im Internet bzw. Software Server zur verwendetenSoftware auf swd.tuwien.ac.at, z. B. sind die Manuals fürSun Systeme über deren Homepage oder direkt unterdocs.sun.com zu finden:

Sun Microsystems, white papers, manuals, patches:www.sun.comSunFire 6800/4800/3800 Systems Overview Manual

Overland Data DLT juke boxes: www.overlanddata.com

LSI Logic - Metastor RAID: www.lsilogic.com

JNI - fibre channel adapter: www.jni.com

Apptime - Watchdog Cluster Software: www.apptime.deApptime Watchdog Service Cluster System Adminstra-tion Handbook, Juli 2001

The Apache Software Foundation, Web Server:www.apache.org

Samba Web Pages, Samba Server (Netbios over TCP/IP):www.samba.org

aufbereitete Solaris Freeware: www.sunfreeware.com

Liebert Hiross Emerson USV: www.liebert-hiross.de

Peter Pawlak, „Five Nines“ – Is It Even Possible ? Direc-tions on Microsoft UPDATE, Juni 2001


Neu als Campussoftware:⇒ LabVIEW 6.0⇒ Sophos Anti-Virus⇒ PATRAN Visualisierungsprogramm für Finite-Elemente-Programme

für Windows, Linux und HP-UX

sts.tuwien.ac.at/css/angebot.html

Datenerfassung und–auswertung mit LabVIEWim Laserlabor des Institutsfür Allgemeine PhysikReinhard Schnitzer und Wolfgang HusinskyInstitut für Allgemeine Physik, Technische Universität [email protected], [email protected]

Seit kurzem ist das Programm LabVIEW auch als Campuslizenz für Institute der TU Wienerhältlich. Für TU-Studenten gibt es eine Studentenlizenz. LabVIEW ist eines der bekanntestenProgramme zum Erstellen von Applikationen für die Steuer- und Messtechnik, mit einerproduktiven graphischen Programmierumgebung. Der folgende Artikel beschreibt mehrjährigeErfahrungen mit LabVIEW in der Experimentsteuerung.

Warum LabVIEW ?Am Institut für Allgemeine Physik wird LabVIEW

seit etwa 10 Jahren im Laserlabor für die Steuerung vonExperimenten genutzt. Zum damaligen Zeitpunkt war derEinsatz dieser neuartigen Programmiersprache (eigentlichbesser Programmierumgebung) noch ziemlich exotischund wurde von vielen mit Misstrauen (in etwa als Spiele-rei) betrachtet. Letzter Anstoß, LabVIEW generell für un-ser Experiment zur Steuerung, Datenerfassung undteilweise auch Datenauswertung zu verwenden, war fol-gendes Ereignis: Wir verwendeten zum damaligen Zeit-punkt eine PDP 11 zur Steuerung und Datenerfassungund die Programme waren in Assembler und Fortran ge-schrieben und liefen unter einem „ernst zu nehmenden“Betriebssystem. Wir hatten damals im Wesentlichen alsVerdienst des Dissertanten P. Wurz gut funktionierendeTreiber für unsere GPIB (IEEE)-Interface-bestückten Ge-räte. Für ein neues Tektronix Digital-Oszilloskop sollteeinfach die gespeicherte Kurve ausgelesen und abgespei-chert werden. Versuche, unsere GPIB Treiber zu adaptie-ren und zu verwenden, scheiterten im Wesentlichendaran, dass offensichtlich eine Inkompatibilität zwischendem IEEE Interface des Oszilloskops und der PDP trotzwochenlanger Versuche auch der Experten nicht zumZiel führte. Tests bei der Firma Tektronix zeigten, dassdas Interface des Scopes nicht defekt war. Schließlichversuchten wir auf einem damaligen MacII und der Ur-Version von LabVIEW, die wir dafür anschafften, das

Problem zu lösen. Innerhalb eines Vormittags hatten wirein funktionierendes Programm zum Datenerfassen undeinfachen Steuern des Digitalscopes. Darauf hin be-schlossen wir, RSX auf einer PDP für die weitere Daten-erfassung und Steuerung in unserem Labor ein gutesBetriebssystem sein zu lassen und auf Macintosh mitLabVIEW umzustellen.

Seither verwenden wir ausschließlich LabVIEW imLaserlabor für verschiedenste Zwecke (eine kurze Über-sicht folgt weiter unten) und auch andere Gruppen am In-stitut setzen heute LabVIEW ein. Ursprünglich haupt-sächlich auf MacOS Systemen laufend, hat sich Lab-VIEW auch als Standard auf Windows-Systemen etabliert.

Charakteristika von LabVIEW

LabVIEW ist eine graphische Programmiersprache(sowohl die Benutzeroberfläche ist dabei ein Abbild einesGerätes als auch die Programmierung selbst erfolgt gra-phisch), die ursprünglich dazu gedacht war, Daten vonanalogen und digitalen Quellen komfortabel zu erfassen,nachzubearbeiten und zu speichern. Dabei ist es dasZiel, ein „virtuelles Gerät“ (mit Schaltern, Zeigern etc.)zu erstellen. Ein großer Vorteil, der sich bei der Verwen-dung von LabVIEW zwangsweise ergibt, ist diese graphi-sche, anschauliche Methode, aber vielleicht nochwichtiger, die dabei phantastisch einfache und direkte


Art, mit verschiedensten Datentypen und Datenströmen,wie sie aus Messgeräten kommen, zurechtzukommen. Je-der, der einmal die Datenerfassung eines einfachen Gerä-tes mit Assembler durchgeführt hat (man denke nur andie Behandlung von Floatingpointzahlen), wird das schät-zen. Es hat sich gezeigt, dass dies in einem Universitäts-labor besonders vorteilhaft ist, da auch Studenten, dienicht Experten in Datenverarbeitung sind, relativ leichtfrüher erstellte Programme verstehen und adaptieren so-wie in kurzer Zeit eigene erstellen können.

Als Konsequenz hat man nicht mehr seitenlangen„Spaghetticode“ sondern eine halbwegs übersichtlichegraphische Benutzeroberfläche, die auf einen Blick ver-rät, was das Programm macht. Die unterschiedlichen Va-riablentypen sind durch verschiedene Farben der Ver-bindungsleitungen gekennzeichnet und sind daher leichtzu unterscheiden. Im Vergleich zu traditionellen Program-miersprachen wie C, C++, Fortran und ähnlichen, ist es beiLabVIEW nicht notwendig, den gesamten Text zu lesen,denn man hat das ganze Programm wie ein Bild vor sich.

Das Programmieren in LabVIEW hat eine Ähnlichkeitmit dem Entwickeln einer elektronischen Schaltung. Dieeinzelnen Variablen können in einer graphisch anspre-chenden Benutzeroberfläche durch Schalter oder mit Hil-fe der Tastatur eingegeben werden. Je nachdem, ob essich um eine Boolesche Variable, einen String, eine Inte-ger oder Real-Zahl handelt, gibt es verschiedene Mög-lichkeiten der Eingabe. Für eine Zahl zum Beispiel hatman verschiedene Drehknöpfe, für eine Boolesche Varia-ble existieren verschiedene Arten von Schaltern, dieTrue/False Zustände. Genauso umfangreiche Eingabe-möglichkeiten gibt es auch für den Variablentyp String.

In Abbildung 1 sind einige Ein- und Ausgabeelementeabgebildet. Ähnlich funktioniert auch die Ein- und Aus-gabe von Booleschen Variablen. Man sieht aber schon andieser Stelle die Vorteile von LabVIEW. Es ist keine lan-ge Einarbeitungszeit notwendig, um ein Virtuelles Mess-instrument mit einer übersichtlichen Benutzeroberfläche

zu gestalten. Ähnlich einfach ist es auch, die einzelnenEingabewerte, die so genannten „Controls“, die in derAbbildung 1a zu sehen sind, mit den virtuellen Ausgabe-geräten, den so genannten „Indicators“, zu verbinden.Dies ist in Abbildung 1b zu sehen. Allerdings ist dieshier nur zur Demonstration gedacht. In Wirklichkeit kanndazwischen jede Menge Datenmanipulation erfolgen.

Man kann die Eingabegrößen mathematisch mit denAusgabewerten verknüpfen und anzeigen lassen, kannaber auch Instrumente steuern, Daten in den Computereinlesen und mit LabVIEW nachbearbeiten und dann inein File abspeichern, oder auch über das Internet verschi-cken. Die Möglichkeiten von LabVIEW sind in der Zwi-schenzeit schon weit über das Steuern von Messungenhinausgewachsen.

Die bereits beim Kauf von LabVIEW vorgefertigtenVirtual Instruments (VIs) für die Kommunikation mit ex-ternen Geräten sind sehr hilfreich bei der Programmie-rung. Zum einen kann man sich bei den Demo-programmen gute Tipps für die Umsetzung eigener Ideenholen, und zum anderen sind sie oft eine Ausgangsbasisfür die Verwirklichung eines eigenen virtuellen Messin-strumentes. Seit es LabVIEW gibt, ist die langwierige Er-stellung von Benutzeroberflächen im LaborbereichGeschichte. LabVIEW bietet die Möglichkeit, selbständigin kurzer Zeit qualitativ hochwertige Programme zuschreiben, die die Steuerung, die Datenerfassung und dieAuswertung und Weiterverarbeitung voll automatisiertübernehmen. Für die meisten gängigen kommerziellenGeräte gibt es mittlerweile VIs.

Für alle, die dem graphischen Programmieren dochnicht ganz vertrauen, bietet LabVIEW auch die Möglich-keit, die alten vertrauten C-Routinen einzubinden und nurdie neue Benutzeroberfläche mit LabVIEW zu erstellen.Dadurch hat man die Möglichkeit, alte, gut bewährte Pro-gramme mit den Vorteilen von LabVIEW zu verbindenund verwenden.


Abbildung 1:a) Einige Ein- und Ausgabeinstrumente für die Erstellung eines virtuellen Instrumentes.

b) Mathematische Verknüpfung dieser Ein und Ausgabegeräte im Diagramm.

0,00

Numerisch

0,00

Numerisch 2

1 0

0

2

4

6

8

Schieber

1 0

0

2

4

6

8

Schieber 2

Schieber 3Schieber 4

1 00 2 4 6 8

Schieber 51 00 2 4 6 8

Schieber 6

Schieber 7

Schieber 8

1 001

2

3

45

6

7

8

9

Runduminstrument

30,00,0

5,010,0 15,0 20,0

25,0

Drehspulinstrument

10,00,0

2,0

4,0 6,0

8,0

Drehregler

10,00,0

2,0

4,0 6,0

8,0

Drehknopf

1 0

0

2

4

6

8

Tank

100

0

2 0

4 0

6 0

8 0

Thermometer

a)

Numerisch

Numerisch 2

Schieber

Schieber 2Schieber 3

Schieber 4

Schieber 5

Schieber 6

Schieber 7

Schieber 8

Runduminstrument

Drehspulinstrument

Drehregler

Drehknopf

Tank

Thermometer

b)

Im so genannten „Diagramm“ werden dann die ein-zelnen virtuellen Eingabeinstrumente mit den Ausgabein-strumenten verknüpft. Dies geschieht auch auf einergraphischen Benutzeroberfläche. Alle auf dem Frontpanelplatzierten „Controls“ und „Indicators“ scheinen als Sym-bol in der Programmieroberfläche (Diagramm) auf. Dortkann man dann wie in einem elektronischen Schaltplandie Eingabeinstrumente mit verschiedenen Operationenverknüpfen und dann das Endergebnis an den „Indicator“ausgeben. Ein einfaches Beispiel ist in Abbildung 1b aufder rechten Seite zu sehen.

Eine weitere Stärke von LabVIEW ist nun, dass es dieMöglichkeit bietet, mit der Hardware und dem Betriebs-system zu kommunizieren. Das Einlesen von Analogsig-nalen mit unterschiedlicher Abtastrate sowie dasAusgeben von Analogsignalen, die aus einem File ausge-lesen werden, oder auch im Programm direkt errechnetwerden können, zählt genauso wie das Ansteuern vonGeräten über einen IEEE Bus zu den fundamentalen Be-dienelementen von LabVIEW.

LabVIEW im Laserlabor des Institutsfür Allgemeine Physik

Datenerfassung

Wir verwenden LabVIEW nun schon seit mehr als 10Jahren, um verschiedene Laser, Spektrometer, BoxcarAnalysatoren, Oszilloskope, Camac Interfaces, Analog-Digital Converter und Schrittmotoren zu steuern undMessdaten zu erfassen.

In Abbildung 2 ist das selbstentwickelte VI eines beiuns im Labor verwendeten optischen Spektrometers dar-gestellt. Das Spektrum wird von einem CCD-ArraySpektrometer aufgenommen und dann als Analogsignalan eine im Handel erhältliche multifunktionale AD-Wandlerkarte mit Timingfunktion geschickt. Mit Lab-VIEW wird dann das Auslesen des Spektrums und dasTiming für das Spektrometer verwirklicht. Weiters be-steht dann die Möglichkeit, das Spektrum weiterzuverar-beiten, zu analysieren und abzuspeichern. DiesesSpektrum dient zur permanenten Überwachung des Spek-trums der Laserstrahlung eines Ti:Saphir Femtosekunden-lasers [1, 2].

Weiters verwenden wir LabVIEW, um Massenspek-tren und Energieverteilungen von emittierten Sekundär-teilchen zu messen [3]. Im Speziellen beschäftigen wiruns mit der grundlegenden Frage, wie das Laserlicht mitMaterie wechselwirkt. Dazu verwenden wir ein Ultra-Kurzzeit Lasersystem mit einer Wellenlänge von 800nmund einer Pulsdauer von 30fs, sowie einen Excimerlasermit einer ArF Füllung [4-6], der Laserstrahlung im UV-Bereich liefert. Diese beiden Laser werden je nach Artdes Experiments zum Ionisieren von Teilchen bzw. zurAblation von Materialien (Metalle, Halbleiter, biologi-sches Gewebe) verwendet. Die Steuerung und das Ti-ming der Lasersysteme erfolgt mittels LabVIEW und derdazugehörigen Elektronik. Die Abbildung 3 zeigt sche-matisch die Steuerung des Messelektronik durch denComputer. Weiters wurde die Entwicklung einer Horn-hautdrehbank (Eximer Laser Corneal Shaping ELCS [4,7]) mittels LabVIEW-Steuerung durchgeführt.

Über programmierbare Verzögerungsgeneratoren (Le-Croy 4222PDG und LeCroy 2323) wurde das Timing derbeiden Laser (Neutralteilchendetektion bei der Laserabla-tion) bzw. des Primärionenstrahls und des Lasers für dieNachionisation (Neutralteilchendetektion bei der Zerstäu-bung) eingestellt und mit dem Oszilloskop gemessen. DieSteuerung der beiden verwendeten Laser und das Ausle-sen des Messsignals vom Oszilloskop konnte mithilfe ge-eigneter Hardware von einem mit LabVIEW selbstent-wickelten Programm mit Benutzeroberfläche gesteuertwerden.

In weiteren LabVIEW-Programmen werden dann dieMesssignale in Energieverteilungen umgerechnet mitModellen verglichen.

Ein wichtiger Bestandteil des eben beschriebenen Ex-periments ist die Erfassung der Massenspektren von ge-sputterten Teilchen. Das dazu verwendete Spektrometerist ein Flugzeitmassenspektrometer. Die Auswertung der


5

device ( 1 )

00

channels (0)

2048

ANZAHL DER SCANNS(1000)

[ clock source string ]

I/O connector

clock source code

channel clock source

1,50

Integration Clock

12000,00

MasterClock

2,4

0,2

0,4

0,6

0,8

1,0

1,2

1,4

1,6

1,8

2,0

2,2

950,0650,0 680,0 700,0 720,0 740,0 760,0 780,0 800,0 820,0 840,0 860,0 880,0 900,0 920,0

Plot 0

Abbildung 2: Das Frontpanel eines virtuellen Spektrometers.

Abbildung 3: Schema der Steuerung der Laser, des Spektrome-ters und der Datenerfassung mit Hilfe des Computers. Mit Hilfe derbeiden Photodioden PD1 und PD2 wurde die zeitliche Verzögerung

des Excimerlaser relativ zum Ti:Saphir Laser gemessen.

Flugzeitspektren und das Umrechnen der Flugzeitspek-tren in Massenspektren wird wieder von einem Lab-VIEW-Programm ausgeführt. Das Frontpanel des hierfürverwendeten Programms ist in Abbildung 4 zu sehen.

Datenauswertung und SimulationNeben der Hauptverwendung von LabVIEW als

Datenerfassungs- und Gerätesteuerungsumgebung wirdLabVIEW auch an Stelle von traditionellen Programmier-sprachen oft vorteilhaft als Datenauswertungsumgebungeingesetzt. Durch die graphische Oberfläche, aber beson-ders wegen seiner vielzähligen Routinen zur Umwand-lung von Datenformaten hat sich LabVIEW besondersdann als praktisch erwiesen, wenn es notwendig ist, ver-schieden abgespeicherte Daten weiterzuverarbeiten. Diegraphische Oberfläche eignet sich auch gut für einfachereSimulationen, da praktisch alle notwendigen Funktionen(Integrierer, Summierer etc.) vorhanden sind und wie ineiner Schaltung „verdrahtet“ werden können.

UpdatesDie aktuelle Version von LabVIEW ist Version 6. Wir

haben bisher im Wesentlichen mit allen Versionen biseinschließlich 4 gearbeitet. Die Umstellung auf neue Ver-sionen ist meist problematisch, wenn man die doch rechtkomplexen Programme und immer wieder auftauchendeInkompatibilitäten beim Wechseln auf eine neue Versionbedenkt. Im Prinzip sind die Programme aufwärts kom-patibel, jedoch kommt es immer wieder vor, dass gewisseFunktionen in neueren Versionen nicht mehr unterstütztwerden oder zumindest leicht geändert wurden. Eine Um-stellung einer laufenden Messanordnung ist daher immerein gewisses Risiko.

Bedingt verbessert wurde ein Manko von älteren Lab-VIEW Versionen, nämlich die nicht vorhandene Ab-wärtskompatibilität (Kompatibilität der VIs mit älterenVersionen). Man kann VIs aus der Version 6 im FormatLabVIEW 5, aber nicht älteren Versionen abspeichern.VIs, die mit älteren Versionen geschrieben wurden, sindmit den oben erwähnten Einschränkungen mit LabVIEW6 weiterzuverwenden, allerdings ist es nicht mehr mög-lich, VIs, die mit LabVIEW 6 bearbeitet wurden, in Lab-VIEW 4 oder älter zu verwenden.

Die Hilfe zu den einzelnen VIs gibt es seit Version 6auch in Deutsch, was vielleicht für den einen oder ande-ren ganz angenehm ist, allerdings haben sich zu dendeutschen Beschreibungen auch manche englische Be-schreibungen dazugesellt. Die Suchroutinen in der Lab-VIEW 6 Hilfe sind einigermaßen übersichtlich gestaltetund lassen sich auch leicht bedienen.

Das große Plus, das sofort ins Auge sticht, ist die Tat-sache, dass sich im Aufbau der Benutzeroberfläche zuden früheren Versionen nur wenig geändert hat. Es sindzwar eine ganze Reihe praktischer VIs dazugekommen,aber an den bisher gewohnten Möglichkeiten hat sichnicht viel geändert. So ist es kein großes Problem, mit derneuen verbesserten Version von LabVIEW zu arbeiten.

Literatur

[1] F. Krausz, „From femtochemistry to attophysics“,Physics World, 14, 9 pp. 41-46, 2001 Sep

[2] T. Brabec and F. Krausz, „Intense few-cycle laserfields: Frontiers of nonlinear optics“, Reviews ofModern Physics, 72, 2 pp. 545-591, 2000 Apr

[3] W. Husinsky and G. Betz, „Fundamental aspects ofSNMS for Thin Film Characterization – experimen-tal studies and computer simulations [Review]“,Thin Solid Films, 272, 2 pp. 289-309, 1996

[4] V. Schmidt, W. Husinsky, R. Graf, F. Fitzal and M.Grabenwöger, "„Tissue perforation of vessel substi-tutes using a femtosecond Ti:Sapphire laser sys-tem“, to be published in SPIE series, pp., 2000

[5] A. Cortona, W. Husinsky and G. Betz, „Influenceof adsorbates, crystal structure, and target tempera-ture on the sputtering yield and kinetic-energy dis-tribution of excited Ni atoms“, Physical Review B-Condensed Matter, 59, 23 pp. 15495-15505, 1999

[6] M. Grabenwoger, F. Fitzal, J. Sider, C. Cseko, H.Bergmeister, H. Schima, W. Husinsky, P. Bock andE. Wolner, „Endothelialization of biosynthetic vas-cular prostheses after laser perforation“, Ann Tho-rac Surg, 66, 6 Suppl pp. S110-4, 1998

[7] J. Altmann, G. Grabner, W. Husinsky, S. Mitterer,I. Baumgartner, F. Skorpik and T. Asenbauer, „Cor-neal Lathing Using the Excimer Laser and a Com-puter-Controlled Positioning System: Part I-Lathingof Epikeratoplasty Lenticules“, Journal of Refr. andCorneal Surgery, 7, pp. 377-384, 1991


Ex.Clock

5 nsec10 nsec

20 nsec40 nsec80 nsec

160 nsec

320 nsec

Zeit_zw.Datenpunkten

5000

Gemittelte SpektrenON

DatenAbspeichern?

c0=1.147259E-7t 0 = - 7 0 2date:10.08.2000time: 16:52c0=2.968254E-8t 0 = - 8 3 5date:02.08.1999time: 17:21

Text-File

8000

Anzahl der Datenwerte

90000

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

55000

60000

65000

70000

75000

80000

85000

300000 5000 10000 15000 20000 25000

ZEITSPEKTRUM

114,72593n

c 0

-702,35922

t 0

Kalibrierungskonstante:

1

m1

40

m2

2250

t1

17970

t2

OFF

Integralspeichern?

Messung7_nHexan_oPl

output filesystemdisk:schnitzer:plasma:

output path

17500,00 16000,00 21000,00 43000,00 47000,0011400,000

UG:ns

43600,00 47600,0012400,00 18500,00 17000,00 26000,000

OG:ns

0

Index

1 0 0

number of shots

OFF

Intensity?

OFF

ToF?

c0=2.968254E-8t 0 = - 8 3 5date:02.08.1999time: 17:21

Kommentar

peak1 peak2 peak3 peak4

0,00

threshold

OFF

filter?

0,00

low cutoff freq: fl

0,00

high cutoff freq: fh

0,00

sampling freq: fs

Lowpass

filter type

2

NOP time

0,00

mittl. Leistung (mW)

Abbildung 4: Teil der Benutzeroberfläche eines Programms zurAufnahme von Flugzeitspektren von laser-nachionisierten Atomen

und Molekülen.

Personelle Veränderungen

Seit Anfang Juni 2001 arbeitet HerrWerner Steinmann ([email protected], Nst. 42036) wieder halb-tags in der Betreuung des Softwaredistri-butionsservers, anstelle von Frau Dipl.-Ing. Elisabeth Donnaberger, die AnfangJuni den ZID verlassen hat.

Ab 1. Oktober 2001 übernimmt FrauNatalie Vejnoska ([email protected], Nst. 42034) in der Abt. Standard-software die Nachfolge von Herrn Dipl.-Ing. Markus Klug im Software Setup.

Herr Dipl.-Ing. Markus Klug arbeite-te von Mai 1998 bis Oktober 2000 undim August 2001 im Bereich des CampusSoftware Setup, mit Schwerpunkt bei denAufbereitungsarbeiten von Microsoft-Produkten und UNIX-Anwendungen. Erwar ein fleißiger, genauer und anerkann-ter Fachmann und Kollege. Wir wün-schen ihm weiterhin viel Erfolg.

Herr Gerold Mosinzer ([email protected], Nst: 42023) arbeitet seitAnfang November halbtags als Unterstüt-zung im Bereich Infrastruktur der Abt.Standardsoftware.

Herr Michael Hofbauer ([email protected], Nst. 42085) ist seit An-fang Juni im Bereich der Internet-Servi-ces für Studierende, Hardware-Support,tätig.

Herr Manfred Hautzinger ([email protected], Nst. 42087) unterstütztseit Anfang Juli die Abteilung ZentraleServices in der Unix-Systembetreuung(IBM SP).

Herr Andreas Schulz hat auf eigenen Wunsch denZID verlassen. Er war etwa ein Jahr halbtags in der Abt.Zentrale Services tätig.

Seit Mitte September 2001 ist HerrAnil Datta ([email protected], Nst.42042) in der Abteilung Kommunikationim Referat Server tätig. Er wird primärHerrn DI Klasek im Bereich der Betreu-ung des Mail- und White Pages Servicesunterstützen.

Wir wünschen allen neuen Mitarbeiterinnen und Mit-arbeitern viel Erfolg und Freude bei ihrer Tätigkeit amZID.


ZID BeiratZur Unterstützung der notwendigen Kommunikation zwischen

den Fakuläten und dem ZID wurde ein beratendes Gremium für IT-Angelegenheiten eingerichtet (ZID Beirat). Es besteht aus zweivom Senat entsandten Mitgliedern und je einem Mitglied aus deneinzelnen Fakultäten, das vom Dekan entsandt wird. Aus dem Se-nat wird je ein Mitglied aus dem Kreis der Studierenden und eines

aus der Fakultät für Technische Naturwissenschaften und Informa-tik entsandt. Dieses Gremium wird mindestens viermal im Jahrvom Vorsitzenden des Beirates einberufen.

(siehe Betriebs- und Benutzungsordnung des Zentralen Informa-tikdienstes, § 10 (1))

Die Mitglieder des ZID Beirats sind:

Univ. Prof. Karlheinz Schwarz Vorsitz Senat [email protected]

Andreas Traxler Senat [email protected]

DI Christian Schranz BI [email protected]

Ao.Prof. Erasmus Langer ET [email protected]

Univ.Prof. Georg Franck-Oberaspach RA [email protected]

Ao. Prof. Helmut Böhm Stv. MB [email protected]

Dr. Robert Sablatnig TNI [email protected]

Wählleitungen01 / 589 32 Normaltarif

07189 15893 Online-Tarif(50 km um Wien)

Datenformate:

300 - 56000 Bit/s (V.92)

MNP5/V.42bis/V.44

PPP

ISDN Synchronous PPP

Auskünfte, StörungsmeldungenSekretariatTel.: 58801-42001

E-Mail: [email protected]

TUNET

Störungen

Tel.: 58801-42003


Rechneranmeldung


TelekomHotline: 08 (nur innerhalb der TU)


Chipkarten,

Abrechnung: 58801-42008

IT-SicherheitE-Mail: [email protected]

Service-Line Abt. StandardsoftwareTel.: 58801-42004


SystemunterstützungComputer Help Line 42124


Web: sts.tuwien.ac.at/pss/

CampussoftwareE-Mail: [email protected]

[email protected]

Zentrale Server, OperatingTel.: 58801-42005


Internet-RäumeTel.: 58801-42006



ÖffnungszeitenSekretariatFreihaus, 2. Stock, gelber Bereich

Montag bis Freitag, 8 Uhr bis 13 Uhr

• Ausgabe und Entgegennahme von Formularen für Be-nutzungsbewilligungen für Rechner des ZID,

• Internet-Service für Studierende: Vergabe von Benut-zungsbewilligungen, die nicht automatisch erteiltwerden können,

• allgemeine Beantwortung von Benutzeranfragen,Weiterleitung an fachkundige Mitarbeiter.

Telefonische Anfragen: 58801-42001

Operator-AusgabeFreihaus, 2. Stock, roter BereichMontag bis Freitag, 7 Uhr 30 bis 20 Uhr

• Ausgabe für Farbdrucker.• Passwortvergabe für das Internet-Service für Studie-

rende.• Ausgabe diverser Informationen für Studierende, Wei-

terleitung von Anfragen an fachkundige Mitarbeiter.

Internet-Räume

Die Internet-Räume (in den Gebäuden Karlsplatz, Frei-haus, Gußhausstraße, Treitlstraße, Gumpendorferstraße, Bib-liothek, Favoritenstraße) sind im Regelfall entsprechendden Öffnungszeiten des jeweiligen Gebäudes geöffnet.An Sonn- und Feiertagen ist kein Betrieb. Siehe auchhttp://student.tuwien.ac.at/internetraeume/Tutoren (Studienassistenten) sind in den Internet-Räumenim Freihaus und in der Favoritenstraße anwesend (Zeitenunter: http://student.tuwien.ac.at/tutoren/).

PersonalverzeichnisTelefonliste, E-Mail-Adressen

Zentraler Informatikdienst (ZID)

der Technischen Universität Wien

Wiedner Hauptstraße 8-10 / E020

A - 1040 Wien

Tel.: (01) 58801-42000 (Leitung)

Tel.: (01) 58801-42001 (Sekretariat)

Fax: (01) 58801-42099

Web: www.zid.tuwien.ac.at

Leiter des Zentralen Informatikdienstes:

W. Kleinert 42010 [email protected]

Administration:

A. Müller 42015 [email protected]

M. Grebhann-Haas 42018 [email protected]

Öffentlichkeitsarbeit

I. Husinsky 42014 [email protected]

IT-Sicherheit

U. Linauer 42026 [email protected]

Abteilung Zentrale Services

www.zid.tuwien.ac.at/zserv/

Leitung

P. Berger 42070 [email protected]

W. Altfahrt 42072 [email protected]

J. Beiglböck 42071 [email protected]

P. Deinlein 42074 [email protected]

P. Egler 42094 [email protected]

H. Eigenberger 42075 [email protected]

C. Felber 42083 [email protected]

H. Flamm 42092 [email protected]

W. Haider 42078 [email protected]

E. Haunschmid 42080 [email protected]

M. Hautzinger 42087 [email protected]

M. Hofbauer 42085 [email protected]

P. Kolmann 42095 [email protected]

F. Mayer 42082 [email protected]

J. Pfennig 42076 [email protected]

M. Rathmayer 42086 [email protected]

M. Roth 42091 [email protected]

J. Sadovsky 42073 [email protected]

E. Srubar 42084 [email protected]

Werner Weiss 42077 [email protected]

Abteilung Kommunikation

nic.tuwien.ac.at

Leitung

J. Demel 42040 [email protected]

S. Beer 42061 [email protected]

F. Blöser 42041 [email protected]

G. Bruckner 42046 [email protected]

S. Dangel 42066 [email protected]

A. Datta 42042 [email protected]

T. Eigner 42052 [email protected]

S. Geringer 42065 [email protected]

J. Haider 42043 [email protected]

M. Hanold 42062 [email protected]

P. Hasler 42044 [email protected]

S. Helmlinger 42063 [email protected]

H. Kainrath 42045 [email protected]

J. Klasek 42049 [email protected]

W. Koch 42053 [email protected]

T. Linneweh 42055 [email protected]

I. Macsek 42047 [email protected]

F. Matasovic 42048 [email protected]

W. Meyer 42050 [email protected]

R. Vojta 42054 [email protected]

Walter Weiss 42051 [email protected]

Abteilung Standardsoftware

sts.tuwien.ac.at

Leitung

A. Blauensteiner 42020 [email protected]

C. Beisteiner 42021 [email protected]

J. Donatowicz 42028 [email protected]

G. Gollmann 42022 [email protected]

M. Holzinger 42025 [email protected]

A. Klauda 42024 [email protected]

H. Mastal 42079 [email protected]

H. Mayer 42027 [email protected]

G. Mosinzer 42023 [email protected]

E. Schörg 42029 [email protected]

R. Sedlaczek 42030 [email protected]

W. Selos 42031 [email protected]

B. Simon 42032 [email protected]

A. Sprinzl 42033 [email protected]

W. Steinmann 42036 [email protected]

P. Torzicky 42035 [email protected]

N. Vejnoska 42034 [email protected]


Documents

ZIDline 06