ZIDline 05

Studenten Software Service

Neu: IBM RS/6000 SP

Gigabit Ethernet

Nr. 5 / Juni 2001

ISSN 1605-475X

INFORMATIONEN DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Seite 2 – Juni 2001 – ZIDline 5

Inhalt

Der neue Applikationsserver Freie ProgrammierungIBM RS/6000 SP Hochleistungsserver . . . . . . . . . . . 3

Studenten Software Service . . . . . . . . . . . . . . . . . . . . . . 8

TUNET Backbone & Gigabit . . . . . . . . . . . . . . . . . . . . 13

Sicherheit unter Linux16 Schritte zu einem sicheren Linux-System . . . . . . . . 17

Systemunterstützungder Arbeitsplatzrechner und ServerStatistiken und Analysen . . . . . . . . . . . . . . . . . . . . . . . 22Erfahrungen mit der Systemunterstützung . . . . . . . . . . 24

www.tuwien.ac.at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Aufbau eines geschützten Subnetzes im TUNET. . . . . 29

CFX-TASCflow Version 2.10und CFX-TurboGrid Version 1.5 . . . . . . . . . . . . . . 38

Betriebs- und Benutzungsordnung . . . . . . . . . . . . . . . . 41

Personelle Veränderungen . . . . . . . . . . . . . . . . . . . . . . 43

Server-Zertifikate des Zentralen Informatikdienstes . . 44

Öffnungszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Wählleitungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

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

PersonalverzeichnisTelefonliste, E-Mail-Adressen . . . . . . . . . . . . . . . . . . . 47

Editorial

Hier eine kurze Zusammenfassung des Inhalts derSommer-Ausgabe der ZIDline. Wir hoffen, dass etwasInteressantes für Sie dabei ist.

Wir stellen unseren neuen Applikationsserver für FreieProgrammierung vor, ein System IBM RS/6000 SP 9070-550, es ist auch auf dem Titelblatt zu sehen.

Studierende der TU Wien können Software zu äußerstgünstigen Preisen erwerben. Dieses „Studenten SoftwareService“ der Abt. Standardsoftware wird im Detail prä-sentiert. Ein Bericht befasst sich mit Erfahrungen undAnalysen zur Systemunterstützung der Arbeitsplatzrech-ner und Server der Institute.

Gigabit Ethernet hält Einzug im TUNET, siehe dazuab Seite 13. Zum Thema Security finden Sie in dieserAusgabe Tipps „wie kann ich mein Linux-System sichermachen“ und den Erfahrungsbericht eines Instituts überden Aufbau eines geschützten Subnetzes im TUNET.

Die momentanen Arbeiten und Diskussionen rund umeine neue Web-Präsenz für die TU sind der Anlass fürden Artikel auf Seite 27.

Die Einsatzmöglichkeiten des auf einem zentralen Ap-plikationsserver des ZID installierten Software-PaketsCFX-TASCflow werden aus der Sicht eines Anwendersaufgezeigt.

Wir drucken die Betriebs- und Benutzungsordnung desZentralen Informatikdienstes (ZID) der Technischen Uni-versität Wien. Sie wurde am 25. April 2001 vom Akade-mischen Senat beschlossen und tritt in Kraft, sobald sievom Bundesministerium für Bildung, Wissenschaft undKultur genehmigt und im Mitteilungsblatt der TU Wienveröffentlicht wurde.

Mein besonderer Dank gilt allen Autoren dieser Aus-gabe für ihre Beiträge und die gute Zusammenarbeit.

Irmgard Husinsky

Impressum / 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/

Der neueApplikationsserverFreie ProgrammierungIBM RS/6000 SPHochleistungsserverPeter Berger

Im Sommer 2000 wurde mit den Vorbereitungsarbeiten für eine Ausschreibung eines neuenApplikationsservers „Freie Programmierung“ als Ersatz für den über 4 Jahre alten NEC-Vektorrechner (Applikationsserver „Lineare Algebra“) begonnen. Eine Arbeitsgruppe unter derLeitung des ZID, bestehend aus Vertretern der Hauptbenutzer der Applikationsserver „FreieProgrammierung“ und „Lineare Algebra“, erarbeitete die Spezifikationen und stellteBenchmarkprogramme zur Verfügung.

Am 3. Oktober 2000 wurde eine EU-weite öffentlicheAusschreibung für dieses Hochleistungs-Serversystemveröffentlicht. Als maximaler Finanzrahmen standen ATS8,5 Mio (aufgeteilt auf zwei Teilzahlungen, 2001 und2002) zur Verfügung. Die Ausschreibung wurde von 21Firmen abgeholt, von 5 Firmen wurden Angebote bis zurAnbotseröffnung am 23. 11. 2000 abgegeben.

Nach einer intensiven Evaluierungsphase wurde am15. 2. 2001 der Zuschlag der Firma IBM für ein SystemIBM RS/6000 SP 9070-550, bestehend aus 3 KnotenSMP High Node (je 16 Prozessoren Power3, 375 MHz,Nighthawk2), erteilt.

Ein Blick in die Vergangenheitder SP-Systeme

In den späten 80er-Jahren gründete IBM ein Labor,The High Performance Supercomputer System Develop-ment Laboratory (HPSSDL), um eine Supercomputer-Technologie zu entwickeln, die möglichst auf weit ver-breitete, nicht exotische Architekturen aufsetzt und ska-lierbar in Leistung und Preis war.

1990 veröffentlichte die IBM Advanced WorkstationDivision in Austin, Texas, die RISC-Systemfamilie (RS/

6000) auf UNIX-Basis (Betriebssystem AIX). DieseRISC-Workstations wurden von HPSSDL in „Nodes“ ge-packt und in „Frames“ zusammengefasst.

Zur gleichen Zeit wurde ein High-Speed Switch(Code-Name Vulcan) entwickelt, der die Zusammen-schaltung von 16 Stück RS/6000 Systemen in einem Fra-me ermöglichte. Verbunden über ESCON-Adapter undeine entsprechende Management-Software war diesesSystem der erste Schritt zur SP-Serie.

1993 kam dieses System als SP1 (Scalable ParallelSystem) auf den Markt, die Anzahl von Knoten betrugmax. 512 (gleichzusetzen mit max. 512 Prozessoren), alsManagement-Software wurde PSSP (Parallel SystemSupport Program) entwickelt und eingesetzt.

1994 wurde die SP2 vorgestellt, ausgestattet mit unter-schiedlichen Knoten und Prozessoren (Power2 und PowerPC).

1996 wurde die SP-Serie als Top-End der RS/6000Produktserie angekündigt, die Knoten unterstützen SMP-Architektur (Symmetric Multiprocessor), die Kopplungder Knoten erfolgt entweder über den Hochleistungs-Switch oder über einen Gigabit Ethernet Switch.

ZIDline 5 – Juni 2001 – Seite 3

Die Architektur des neuen SystemsIBM RS/6000 SP 9070-550

Das System besteht aus 3 SMP-Knoten (Nighthawk2),die in einem SP-Frame installiert sind. Jeder Knoten ver-fügt über 16 Prozesssoren, 16 GB Hauptspeicher und 2lokale 36 GB Platten. Das Massenspeicher-Subsystembesteht aus einem externen SSA-System (IBM 7133/D40SSA) mit insgesamt 10 SSA-Platten mit je 36 GB, dieüber SSA-Kabel mit dem ersten und zweiten Knoten ver-bunden sind. Zur Datensicherung ist ein LTO UltriumTape (IBM 3581/H17 LTO, 100/200 GB Speicherkapazi-tät) installiert. Die Kopplung der Knoten erfolgt über Gi-gabit Ethernet und einen GBit-Switch mit 6 Ports.

Das Management der SP erfolgt über eine Control-Workstation (RS/6000 F50), die über RS232 und einengetrennten Management-LAN (100 MBit/s, Switch) mitden SP-Knoten verbunden ist.

Der Anschluss an das lokale Netz der TU Wien ist mit2x 100 MBit/s realisiert.

Bei der Erstellung der Spezifikationen für die Aus-schreibung wurde von der Arbeitsgruppe gemeinsam mit

dem ZID festgelegt, dass bei Clustersystemen die Knotenüber mindestens 4 Prozessoren, die auf ein gemeinsamesMemory zugreifen (SMP-Architektur), verfügen müssen.

Es war gefordert, dass die Kopplung dieser Knoten füreine Prozessoranzahl von 4 pro Knoten über ein Kopp-lungsmedium mit einer Bandbreite deutlich größer1 GBit/s erfolgen muss. Bei Knoten mit mehr als 4 Pro-zessoren wurde die Bandbreite mit mindestens 1 GBit/sfestgelegt.

Der Grund dieser Abstufung ist die Tatsache, dass vonSeiten der Institute für die großen Produktionsjobs keinhoher Grad an Parallelisierung verwendet wird. Die Nut-zung von CPU-Ressourcen über Knotengrenzen hinausist von untergeordneter Bedeutung, wenn eine ausrei-chende Anzahl von CPUs innerhalb eines Knotens zurVerfügung steht.

Die Kopplung der Knoten über Gigabit-Ethernet er-möglicht (z. B. über MPI) die Nutzung von Ressourcenüber Knotengrenzen hinweg, ist aber wesentlich preis-günstiger als die Kopplung über einen Hochleistungs-Switch.


Control-Workstation

IBM F50

16 GB Memory (2048 bit Busbreite)

2x 36 GBPlatten (LVD)

Gigabit-Ethernet

IBM 375 MHz SMP High Node


16 CPUs (Power3-II, 375 MHz)

Gigabit - Switch

Ethernet-Switch100Mbit/s

TUNET


Gigabit-Ethernet

SSARAID Contr.




SCSI

Disk-Subsystem

160 MB/s

10 x 36GB

IBM 7133 SSA

IBM LTO Ultrium

SP LAN (Management)

Cluster-Kopplung

TP


Gigabit-Ethernet

SSARAID Contr.



SCSITP

TP

Architektur IBM RS/6000 SP 9070-550

Hardware:

IBM RS/6000 SP 9070-550 mit3x Knoten 375 MHz SMP High Node (Nighthawk2),

pro Knoten mit16x CPU (Power3-II, 375 MHz, 8 MB Cache)

16 GB Hauptspeicher2x 36 GB interne Platten (LVD)1x Gigabit-Ethernet1x 10/100 Ethernet (Management)4x 10/100 Ethernet (nur Knoten 1)1x SSA RAID Controller (nur Knoten 1 und 2)1x SCSI (FWD, nur Knoten 1 und 2)

Disk-Subsystem IBM 7133/D40 SSA,10x 36 GB SSA-Platten

Backup-Subsystem IBM 3581/H17 LTO UltriumGigabit-Switch zur Kopplung der Knoten100 MBit Switch zur Kopplung des Management-LANControl-Workstation IBM 7025/F50

Einige Leistungszahlen:

SPECint95 23.5

SPECfp95 51.3

SPECint2000 252

SPECfp2000 337

Linpack 1000x1000 1208 Mflops (1 Prozessor)

Das Kernstück der SP – der 375 MHz Power3SMP High Node (Nighthawk2)

Prozessoren:16 Prozessoren (Power3-II, 375 MHz,

CMOS 7S Kupfertechnik)Superskalar-Architektur mit 8 Execution Units32 KB Instruction Cache, 64 KB Data Cache,

8MB L2 CacheSMP-Architektur

Hauptspeicher:16 GB, 4 Memory-Cards mit je 4 GB

(max. 64 GB möglich)4 Banks mit je 8 DIMM-Slots pro Memory-Card4 GB/sec Bandbreite pro CPU-Card,

16 GB/sec Gesamtbandbreite

I/O-Subsystem:2 getrennte PCI-Controller, SP-Switch Adapter

(500 MB/sec)PCI 0: 1x 32-Bit, 2x 64-Bit, Ultra-SCSI, 10/100 EthernetPCI 1: 2x 64-Bit

Disk-Subsystem:2x interne 36 GB Platten, Ultra-SCSI,

10.000 rpm (Spiegelung)

Das externe Platten-Subsystem

Als externes Storage-Subsystem kommt ein IBM 7133D40 (SSA-Subsystem), bestehend aus 10x 36 GB SSA-Platten, zum Einsatz. Dieses Subsystem ist über zwei


Blockdiagramm des 375 MHz Power3 SMP High Node (Nighthawk2)

SSA-Loops mit zwei SSA-Adaptern (FC 6230 AdvancedSerialRAID Plus Adapter) mit den Knoten verbunden.Mit diesem Controller können die Platten in RAID-Sets(RAID 0, 1, 5) zusammengefasst werden, hot-spare Diskswerden natürlich unterstützt.

Serial Storage Architecture (SSA)ist eine schnelle, hochverfügbare, serielle Verkabelungs-technologie zur Verbindung von Platten und Hostadap-tern auf Kupferbasis. SSA ist ein offener Standard (ANSIX3T10.1), der von der SSA Industry Association ent-wickelt wurde.

Die Basis der SSA-Technologie bildet die Loop, einebidirektionale, im full-duplex Mode arbeitende serielleVerbindung zwischen den Hostadaptern und den Platten.Zwei unabhängige physikalische Pfade zum Lesen undzwei zum Schreiben zu jeder Platte in der Loop ermög-lichen den Zugriff auf das Plattensystem auch dann,wenn die Loop an einer Stelle unterbrochen ist (z.B. Aus-fall einer Platte oder defektes Kabel). Die maximaleTransfer-Rate für jeden Schreib- oder Lesevorgang be-trägt 40 MB/s, für die Loop ergibt das eine Bandbreitevon maximal 160 MB/s.

Jeder Hostadapter verfügt über 2 Loops, die unabhän-gig und gleichzeitig lesen und schreiben können. Da-durch können sowohl Konfigurationen mit hoherVerfügbarkeit als auch mit hoher Durchsatzleistung reali-siert werden. Die Kabel und Platten sind hot-pluggable,die Loop ist im Fehlerfall self-configuring und self-repai-ring, maximal 48 Platten sind pro Loop zulässig.

SSA ermöglicht ein Mapping der SCSI-2 Funktionen,aus der Sicht der Hostsoftware ist das Plattensystem einSCSI-System mit allen Funktionalitäten.

Das Storage-Subsystem IBM 7133 / D40besteht aus einem Gehäuse (Rackversion) mit 2 unabhän-gigen Netzteilen, 16 Steckplätzen für SSA-Platten und ei-ner internen Verkabelung, die jeweils 4 Platten in eineLoop zusammenschaltet. Diese Loops sind nach außengeführt und können über SSA-Kabel (max. 25 m Kupfer,max. 10 km Glasfaser) an die Hostadapter angeschlossenwerden.

Die Konfiguration am ZID besteht aus 10 SSA-Plattenmit je 36 GB, die über 2 Loops mit den RAID-Control-lern verbunden sind. Die Platten bilden zwei RAID5-Sets, die über die beiden Loops gleichzeitig angesprochenwerden können. Um die Ausfallssicherheit zu erhöhen,wurde in einem anderen Knoten ein zweiter RAID-Con-troller installiert, der im Normalbetrieb nicht verwendetwird.

Auf dem externen Storage-Subsystem befinden sichdie Home-Verzeichnisse der Benutzer, die über NFS anden Knoten zur Verfügung stehen.

Backup-System – IBM 3581 Ultrium TapeAutoloader

Im Jahr 1997 entwickelten die Firmen IBM, HP undSeagate gemeinsam einen neuen Standard – das LinearTape-Open (LTO) Program. Ziel von LTO war, offeneSpezifikationen für Bandspeichersysteme mit hoher Ka-pazität und Geschwindigkeit zu entwickeln (http://www.lto-technology.com/).

Zwei unterschiedliche Bandformate wurden definiert,LTO Accelis und Ultrium, wobei das Accelis-Format(Doppelspule, 8 mm Band) für hohe Zugriffsgeschwin-digkeit optimiert wurde, das Ultrium-Format (single-reel,½ Zoll Band) für hohe Speicherkapazitäten gedacht ist.


Die Basistechnologie von LTO wird als „multi-chan-nel linear serpentine recording“ bezeichnet. Die Datenwerden auf 384 Spuren geschrieben, die auf 4 Data-Bands zu je 96 Tracks aufgeteilt werden. Ein Schreib/Le-sekopf schreibt 8 Spuren gleichzeitig, beginnend vomBandbeginn zum Bandende. Dann wird die Position in-nerhalb des Bandes gewechselt und die nächsten 8 Spu-ren vom Bandende zum Anfang geschrieben. Für dierichtige Positionierung des Kopfes sorgen 5 Servo-Bands,die sich zwischen den 4 Data-Bands befinden.

Der LTO Ultrium Tape Autoloader IBM 3581 spei-chert bis zu 100 GB (200 GB mit 2:1 Komprimierung)auf ein Ultrium-Medium. Die Host-Schnittstelle ist SCSI,die Transferrate beträgt 15 MB/s. Der Autoloader kann 7Kassetten aufnehmen, das ergibt eine maximale Speicher-kapazität von 700 GB (ohne Komprimierung).

Betriebssystem und Applikationssoftware

Software:AIX 4.3 (SP-Version und alle Komponenten des

TU Campusvertrages)PSSP V2.4Parallel Environment for AIX V2.3C und C++ CompilerFortran77 und Fortran90 CompilerHPF V1.3PD-Software (tcsh, ssh, …)LoadLeveler V2.2

Applikationssoftware:ESSL und OSLParallel ESSL und Parallel OSLLaPack und ScaLaPackNAG Library Mark 19

Die Installation weiterer Softwarekomponenten erfolgtdem Bedarf entsprechend, vor allem der Einsatz von

Software, die diese Rechnerarchitektur optimal nützen, isterforderlich (sowohl scalar wie auch zur Parallelisie-rung).

Zugang über das TUNET

Der Systemzugang erfolgt ausschließlich über denKnoten 1 (sp01), nur dieser ist an das lokale Netz der TUWien angeschlossen (Fast Ethernet, 100 MBit/s). Die an-deren Knoten und die Control-Workstation sind direktnicht erreichbar, können aber vom „Zugangsknoten“ ausangesprochen werden. Aus Sicherheitsgründen ist der Zu-gang nur über Secure Shell möglich (telnet und ftp sindnicht offen), ebenso können die Berkeley r-Commands(rlogin, rcp, ...) nicht verwendet werden.

Der Hostname (des Zugangsknotens) ist

hal.zserv.tuwien.ac.at

Betriebskonzept und Betriebsmittelvergabe

Die Abnahme des Gesamtsystems wurde erfolgreicham 27. April 2001 durchgeführt. Das System läuft imTestbetrieb, Anträge für eine Usernummer bitte wie üb-lich an das Sekretariat des ZID senden. Ein Betriebskon-zept mit entsprechenden Batch-Queues wird demnächstzur Verfügung stehen.

Das neue System steht allen Instituten der TU Wienfür selbstentwickelte Applikationen (freie Programmie-rung) mit relativ geringem Parallelisierungsgrad aber mithohem Ressourcenbedarf (CPU und Speicherzugriffe) zurVerfügung.

Die Systemadministration und die Projektberatungwird von Herrn Dr. Ernst Haunschmid übernommen, fürFragen stehen wir jederzeit gerne zur Verfügung.


Studenten Software ServiceBernhard Simon

Seit dem Wintersemester 1999/2000 ermöglicht der Zentrale Informatikdienst den Studierenden ander TU Wien – als erster Universität in Österreich – den Bezug diverser Software zu äußerstgünstigen Preisen. Dieses Service, das von der TU Wien stark subventioniert wird, hat großenZuspruch gefunden. Im Folgenden werden die Voruntersuchungen, die Realisierung, das Angebotund die Erfahrungen zu diesem Service ausgeführt.

Evaluierung

Zum Zeitpunkt, als im Jahr 1999 ernsthaft an die Ein-führung eines „Studenten Software Service“ (SSS) ge-dacht wurde, stellte die Abteilung Standardsoftware imBereich der Distribution kostenpflichtiger Software mitden beiden Diensten „Campus Software Service“ (CSS)und „Plattform Software Service“ (PSS) ihre Leistungenhauptsächlich den Instituten und Verwaltungseinrichtun-gen der TU Wien zur Verfügung. Im Laufe der letztenJahre hat sich dabei ein gut funktionierendes System eta-bliert, das Bestellung, Bezug, Wartung und Verrechnungder verschiedensten Produkte zum Großteil automatisiertund servergestützt (Datenbank, Softwaremedien) ab-wickelt.

Um einerseits dem Auftrag des ZID nachzukommen,seine Leistungen nicht nur für Forschung und Adminis-tration zur Verfügung zu stellen, sondern auch im Be-reich der Lehre den Studenten zugänglich zu machen,andererseits dem Interesse der Studenten nach kosten-günstiger Software, die im Rahmen der Ausbildung sinn-voll eingesetzt werden kann, zu entsprechen, wurde –weil auch von einzelnen Firmen die Bereitschaft zur Un-terstützung dieses Vorhabens vorhanden war – von derAbteilung Standardsoftware das Projekt „Studenten Soft-ware Service“ ins Leben gerufen, mit dem Ziel – nachKlärung der dafür notwendigen Voraussetzungen undSchaffung der entsprechenden Rahmenbedingungen – abdem Wintersemester 1999/2000 Campussoftware in denSoftwarekategorien Graphik/Visualisierung, Mathematik,Office Automation und PC Systemsoftware für Studentenanzubieten.

Unter Berücksichtigung der Vorgaben

1. Jeder Student der TU Wien soll berechtigt sein, Cam-pus Software für Studenten zu beziehen.

2. Die Studentensoftware sollte (möglichst in vollemLeistungsumfang) zu einem attraktiven Preis angebo-ten werden.

3. Der Administrationsaufwand sollte minimal sein (keinzusätzliches Personal).

4. Bereits bestehende Infrastruktur und Verteilungsme-chanismen sollten nach Möglichkeit genutzt werden.

stellte sich sehr bald heraus, dass existierende Mechanis-men zur Abwicklung von Geschäftsfällen, wie sie – ab-gestimmt auf die vorhandenen Strukturen einer Universi-tät (Institute, Personal) – eingerichtet wurden, für dieVerteilung der Studentensoftware nur in geringem Maßeanwendbar sind. Die wichtigsten Unterschiede in denProblembereichen

• Personen – Erfassung aller Studenten, Identifikation, Er-reichbarkeit

• Verteilung – Zugangsmöglichkeit zum Server (Netzan-bindung erforderlich, Accounts), Zugang von außerhalbdes TUNET (Einschränkungen, Protokolle, Bandbreite)

• Verrechnung – Infrastruktur müsste komplett neu aufge-baut werden

zeigten auf, dass eine servergestützte Verteilung der Stu-dentensoftware unter den derzeitigen Voraussetzungen ander TU nicht durchführbar ist.

Der traditionelle Ansatz für die Verteilung von Soft-ware (Produktion und Verkauf der Medien) kann – weileine entsprechende Verkaufsstelle im ZID nicht einge-richtet ist – nur mit externer Unterstützung realisiert wer-den. In Gesprächen mit der Hochschülerschaft der TUWien (HTU) stellte sich heraus, dass nicht nur die Bereit-schaft zur Zusammenarbeit vorhanden ist, sondern auchmit dem Lehrmittelzentrum (LMZ) die Voraussetzungenund Kapazitäten existieren, Studentensoftware allen Be-zugsberechtigten zu verkaufen.

Im Zusammenhang mit der Produktion der Medienwurde untersucht, ob die Produktion – nach Anschaffungentsprechender Geräte – im Haus erfolgen kann, oderbesser einer externen Firma übertragen werden soll. Un-ter Berücksichtigung der zu erwartenden Stückzahlen undder erforderlichen Qualität stellte sich – nachdem eine


Firma gefunden wurde, die auch Kleinserien prompt lie-fern kann – die zweite Variante als sinnvoller heraus.

Wegen der Kosten, die bei der externen Produktionder CDs anfallen, muss sich das Angebot auf jene Pro-dukte beschränken, bei denen der Absatz von großenStückzahlen (mindestens 1000 pro Version) zu erwartenist und zu deren Verteilung eine CD ausreicht. In Sonder-fällen – wenn ein Produkt, das aus mehreren CDs be-steht, auf eine CD zusammengeschnitten werden muss –wird auch eine eingeschränkte Funktionalität in Kauf ge-nommen, jedoch explizit darauf hingewiesen.

Unter Berücksichtigung der angegebenen Bedingun-gen ergab sich letztendlich folgende Arbeitsteilung alsGrundlage für die Realisierung des „Studenten SoftwareService“:

ZID, Abteilung Standardsoftware:• Abschluss der Campusverträge• Bereitstellung der Medien (Produktion extern)• Ankündigungen, (Lizenz-)Informationen• Logistik, Lizenzkontrollen

HTU, Lehrmittelzentrum:• Überprüfung der Identität (Studentenausweis)• Unterzeichnung der Lizenzbedingungen

durch den Studenten• Verkauf der Software• Rückmeldung der Verkaufsdaten an den ZID• Public Relations

Realisierung

Dieser Abschnitt stellt das Studenten Software Service– wie es seit Oktober 1999 läuft – vor, gibt einen Über-blick über das aktuelle Softwareangebot und beleuchtetdas Service aus der Sicht der Studenten, des Lehrmittel-zentrums und des ZID.

Das Studenten Software Service, das vom ZentralenInformatikdienst, Abt. Standardsoftware in Zusammenar-beit mit der Hochschülerschaft der Technischen Universi-tät Wien (HTU) und zum Teil mit dem Institut fürAnalysis und Technische Mathematik, Abt. Regelungs-mathematik und Simulation angeboten wird, soll den Stu-denten eine legale Möglichkeit zum Einsatz wichtigerSoftware bieten und wird von der Technischen Universi-tät entsprechend subventioniert. Die Software hat zumeistden normalen Leistungsumfang und wird den Studentenstark verbilligt für ihren privaten Heimgebrauch zur Ver-fügung gestellt. Sie beinhaltet keine gedruckte Doku-mentation und darf nur für nicht kommerzielle Anwen-dungen eingesetzt werden.

Jeder Student der Technischen Universität Wien istberechtigt, Campus Software für Studenten zu beziehen.Die Verteilung erfolgt über die Buchhandlungen desLehrmittelzentrums (Bibliotheksgebäude der TU bzw. amRilkeplatz 3). Der Student unterschreibt eine Erklärung,dass er sich an die Lizenzbedingungen hält und erhälteine CD mit der Software, wobei ein geringer Kostenbei-trag (für jedes Produkt weniger als ATS 100.-) verrechnetwird. Neue Versionen dieser Software sind in gleicherWeise beziehbar.

Berechtigt sind alle Studierenden, die an der TU Wiengültig rückgemeldet sind und dies im Lehrmittelzentrumbeim Kauf der Software durch Vorlage eines gültigenStudentenausweises oder einer Inskriptionsbestätigungnachweisen können.

Die von den Studenten unterzeichneten Lizenzbedin-gungen garantieren, dass die Studentensoftware nichtzweckentfremdet verwendet wird:

1. Die Lizenz für die Campus Software für Studenten be-rechtigt nur Studenten der Technischen UniversitätWien zur Nutzung (Speichern, Laden, Ausführen) derSoftware auf genau einem Personal Computer untergenau einer Version genau eines Betriebssystems undgilt solange die Bedingung „Student der TechnischenUniversität Wien“ erfüllt ist.

2. Es darf maximal eine Software-Kopie zu Backup-bzw. Archivierungs-Zwecken angelegt werden und dieSoftware (bzw. Kopien davon) darf nicht an Dritteweitergegeben werden.

3. Die Software darf nur zu Zwecken der eigenen Aus-bildung genutzt werden. Jede – wie auch immer gear-tete – kommerzielle Nutzung ist nicht gestattet.

4. Der Lizenznehmer verpflichtet sich, keine Versuche(wie z.B. durch Reverse Engineering oder Disassem-bling) zu unternehmen, geheime bzw. vertrauliche In-formationen über die Funktionalität der Software undderen interne und externe Schnittstellen herauszu-finden.

5. Wenn die Bedingungen (Student der Technischen Uni-versität Wien) für die Verwendung der Software nichtmehr erfüllt sind, darf die Software nicht mehr weiter-verwendet werden und muss vom Rechner entferntwerden. Medien und Kopien davon müssen unbrauch-bar gemacht werden.

Microsoft Produkte dürfen (nach den derzeit gültigenBestimmungen) auch nach Beendigung des Studiumsweiter verwendet werden, dann allerdings nur für den pri-vaten Gebrauch.

Alle Lizenzen gelten jeweils für den vollen Produkt-umfang, selbst wenn aus Kostengründen nur ein Teil derSoftware auf der im Lehrmittelzentrum verteilten CD un-tergebracht werden konnte. Bei Microsoft Produkten be-rechtigt die Studentenlizenz auch zum Einsatz eineranderssprachigen Variante des lizenzierten Produkts, dasallerdings nur anstelle der erworbenen deutschen Version.

Nachfolgende Aufstellung gibt einen Überblick überdas aktuelle Softwareangebot für Studenten und listetvollständigkeitshalber auch ältere – längst ausverkaufte –Versionen aus dem Bereich Mathematik.

Für die ursprünglich zur Verteilung vorgesehenen Pro-dukte MS Visio 2000, MATLAB und Adobe Photoshopkonnten mit den Firmen keine akzeptablen Verträge aus-verhandelt werden, sodass es derzeit keine Möglichkeiteiner Studentenlizenz gibt.

Informationen zum Studenten Software Service wer-den den Studenten über verschiedene Kanäle angeboten:


• SSS Homepage als primärer Einstiegspunkt zu Informa-tionen: http://sts.tuwien.ac.at/sss.htmlSie beschreibt ganz allgemein das Studenten SoftwareService, gibt Hinweise zum Bezug der Software und zuden Lizenzbedingungen und enthält die so genanntenProduktpages mit Kurzinformationen zum jeweiligenProdukt, Versionsangaben, Preis, spezielle Lizenzbedin-gungen, technische Anforderungen und Links zu weiter-führenden Informationen (des Herstellers).

• Newsgroup at.tuwien.student(und at.tuwien.zid.neuigkeiten)Hier wird punktuell über neue Produkte bzw. Updates in-formiert und einmal pro Semester ein Überblick über dasaktuelle Software-Angebot gegeben. Dieses Mediumwird auch genutzt, um Fragen von allgemeinem Interesse(z.B. über Produktumfang oder spezielle Lizenzangele-genheiten) zu klären.

• Schaukasten im Freihaus 2. Stock, gelber Bereich, beimInternet Raum FHBR2

• Plakate des LehrmittelzentrumsBesonders wirksam sind die Plakate in den Verkaufsräu-men des LMZ oder die Plakatständer, die gelegentlichvor dem Geschäft aufgestellt werden.

• Aussendungen und Zeitschriften der HTU (z. B. zu Se-mesterbeginn)

Neben seinen Verkaufs- und Kontrolltätigkeiten er-fasst das Lehrmittelzentrum (derzeit noch manuell) allezur Lizenzkontrolle relevanten Verkaufsdaten und gibtsie an den ZID weiter. Auch die von den Studenten un-terzeichneten Lizenzbedingungen werden – als Beleg denFirmen gegenüber – im ZID archiviert.

Von der Entscheidung, ein bestimmtes Produkt alsStudentensoftware anzubieten, bis hin zu dessen Vertei-lung und Wartung ist ein langer Weg, der nur dann er-folgreich ist, wenn alle daran Beteiligten gut zusam-menarbeiten:• Vertragsverhandlungen• Abkommen mit der HTU• Erstellen einer Master CD, falls erforderlich• Testen, Prüfsummenerstellung, CD-Beschriftung• Produktion der CDs durch externe Firma• Überprüfung der Lieferung (Stichproben)• Erstellen von Informationsmaterial (Beiblatt etc.)

• Ankündigungen (Web, Newsgroups, Schaukasten,Plakate)

• Verkauf durch LMZ• Bearbeitung von Anfragen, Problemen,

Nachbestellungen, neue Versionen• Erfassung, Kontrolle und Verrechnung

der Verkaufsdaten, in Abteilungsdatenbank

Statistik

Den folgenden Untersuchungen über Anzahl der Li-zenzen pro Student und Verteilung nach Studienjahrgän-gen liegt das gesamte vorhandene Datenmaterial (vomStart des Service am 14. 10. 1999 bis zum zuletzt erfass-ten Wert am 4. 5. 2001) zugrunde. Bis zu diesem Stich-tag – dem Zeitpunkt der Fertigstellung dieses Berichtes –wurden insgesamt 13379 Lizenzen an 5783 Studentenvergeben.

Diese Lizenzen teilen sich folgendermaßen auf die 9derzeit angebotenen Produkte auf, wobei bereits 70% derLizenzen durch die 4 gängigen Microsoft Produkte Officeund Windows 98/Me/2000 abgedeckt sind (Abb. 1).

Bei Klassifizierung der 13379 Lizenzen nach Studien-jahrgang (erste und zweite Stelle der Matrikelnummer)des Käufers zeigt sich die erwartete Abnahme an Lizen-zen bei Studenten höheren Semesters (Abb. 2). Auffal-lend ist der relativ hohe Anteil älterer Semester.


Produkt Version Plattform seit bis Code Auflage

Maple 5.1 Win/Mac/Linux 14.10.1999 27.07.2000 MAP9901 650

6.01 Win/Mac/Linux 26.09.2000 MAP0002 1000

Mathematica 4.0.1 Win/Mac/Linux 06.12.1999 01.07.2000 MAT9901 850

4.0.2 Win/Mac/Linux 20.07.2000 20.04.2001 MAT0002 1000

4.1 Win/Mac/Linux 25.04.2001 MAT0103 1000

MS Windows 98 Second Ed., deutsch Win 24.05.2000 W980001 2000

MS Office 2000 Prof., deutsch Win 27.06.2000 OFF0001 4000

MS Windows 2000 Prof., deutsch Win 20.07.2000 W2K0001 3000

Lotus SmartSuite 9.5, deutsch Win 28.09.2000 LSS0001 1000

MS Windows Me deutsch Win 03.10.2000 WME0001 2000

MS Visual Studio 6.0 TU Ed., deutsch Win 05.10.2000 VST0001 1000

SigmaPlot 2000 6.1 Win 01.03.2001 SPL0101 500

Abb. 1: Verteilung der Lizenzen nach Produkten

Zwischen den einzelnen Studienjahrgängen gibt es sogeringe Abweichungen beim Verhältnis der einzelnenProdukte zueinander, dass es sogar auffällt, wenn Erstse-mestrige vermehrt Windows Me (18% statt durchschnitt-lich 12%) kaufen und die Studienjahrgänge 1950-79 sichweniger für Office und Windows (57% statt 70%) inter-essieren.

Abbildung 3 zeigt, wie viele CDs jeder einzelne der5783 Studenten erworben hat. Auch hier gibt es wiedereine gute Übereinstimmung zwischen den einzelnen Stu-dienjahrgängen. Bemerkenswert ist einzig, dass die Stu-dienjahrgänge 1950-79 zu einem hohen Anteil (18% stattdurchschnittlich 4%) 6 und mehr CDs kaufen.

Die Lizenzentwicklung für die einzelnen Produkte seitdem Bestehen des Studenten Software Service ist in Ab-bildung 4 dargestellt. Neben den erwarteten steilen An-stiegen in den Wochen unmittelbar nach der Einführungeines neuen Produkts sind die beachtlichen Zuwächse zuBeginn des Wintersemesters 2000/2001 besonders auffäl-lig und lassen sich mit folgenden Zahlen belegen.

In den vier Wochen zu Semesterbeginn (das warenauch die einzigen Wochen des Jahres 2000 mit einemWochenumsatz von mehr als 500 Lizenzen, Spitzenwerte:

zweite Oktoberwoche mit insgesamt 858 Lizenzen, 9.Oktober mit 209 Stück Tagesumsatz), wurde – bezogenauf die Stückzahlen – fast ein Drittel (29.7%) des Jahres-umsatzes abgewickelt. In diesem Zeitraum erreichtenauch die einzelnen Produkte – was die täglichen Ver-kaufszahlen betrifft – ihr relatives Maximum. Den abso-luten Rekord hält bislang Office mit den 3 Spitzenwerten104, 63 bzw. 80 – aufgestellt zwischen dem 28. und 30.Juni, also den drei Tagen nach der Freigabe des Produkts.

Wie die Auswertung der Web-Zugriffsdaten des Jahres2000 zeigt, wurden die Informationsseiten über das Stu-dentensoftware Angebot (nicht nur von Rechnern an derTU Wien) häufig frequentiert, wobei alle Informationenpublic waren und Zugriffe von Teleweb, Chello, ... bei„nicht TU“ gezählt wurden.

2000 hosts requests kbytes %transfer

nur TU 1337 28923 61337 28.2

nicht TU 13298 75249 156235 71.8

Summe 14635 104172 217572 100

Dabei fanden die Informationen über Mathematica, dieLizenzbestimmungen, und in weiterer Folge über die Pro-dukte Maple, Windows 98 und Office 2000 besonderesInteresse.


Abb. 3: Verteilung der Studentennach Anzahl der Lizenzen

Abb. 2: Verteilung der Lizenzennach Studienjahrgang des Käufers

500

1000

1500

2000

2500

3000

3500

Okt Nov Dez Jän Feb Mär Apr Mai Jun Jul Aug0

Sep2001

Okt Nov Dez Jän Feb Mär AprSigmaPlotLotus SmartSuite

MS Visual Studio

Maple

MS Windows 98MS Windows MeMathematica

MS Windows 2000

MS Office 2000

1999 2000

Abb. 4: Lizenzentwicklung gesamt

Erfahrungen

Die Erfahrungen seit dem Beginn der Verteilung imHerbst 1999 zeigen nicht nur eine erfolgreiche Umsetzungder konzipierten Distributionsmechanismen und eine aus-gezeichnete Zusammenarbeit mit den Partnern, sondernauch, dass dieses Service bei den Studenten gut ankommtund stärker als ursprünglich vermutet genutzt wird.

Aufgrund der ersten Verkaufszahlen konnte davonausgegangen werden, dass von den meisten Produktenzumindest 1000 Stück verkauft werden. Somit war esmöglich, die Produktionskosten pro CD durch entspre-chend große Serien – wodurch erst ein billigeres Produk-tionsverfahren angewendet werden konnte – auf ungefährein Drittel des bei Kleinserien erzielbaren Preises zu re-duzieren.

Da im Vorhinein nicht abzuschätzen war, wie groß derBedarf bei den einzelnen Produkten sein wird, wurdenalle neuen Produkte zunächst mit einer Auflage von 1000Stück eingeführt, und erst später – der Nachfrage entspre-chend – in 1000er Schritten nachproduziert.

Die mit der Produktion der CDs beauftragte FirmaFANCY-MEDIA erwies sich als sehr zuverlässig und ar-beitet mit hoher Qualität, was sich daran zeigte, dass diewenigen als unlesbar reklamierten CDs zumeist in Ord-nung waren und der Fehler vielmehr an defekten CDLaufwerken der Studenten lag. Trotzdem kam es (durcheher untypische Produktionsfehler) zur Lieferung vonzwei Serien mit jeweils 1000 defekten CDs, die aufgrundder bestehenden Kontrollmechanismen im ZID rechtzei-tig vor deren Verteilung als solche erkannt wurden.Nachdem bewiesen werden konnte, dass die Ursache desProblems nicht eine fehlerhafte Vorlage (Master CD)war, wurde die Lieferung ohne zusätzliche Kostenprompt ausgetauscht. Ab diesem Zeitpunkt wurde ver-stärkt daran gearbeitet, mögliche Fehlerquellen bei derErstellung der Master CD durch zusätzliche Tests zu ver-meiden und die Identität von Kopie(n) und Master durchPrüfsummen zu verifizieren.

In einer im Dezember 1999 mit der Verteilung vonMathematica gestarteten Umfrage wurden Richtwerteüber den Einsatz der von den Studenten verwendetenPlattformen Windows, Linux bzw. Macintosh gesammelt,um bei Bedarf die Produktion plattformspezifischer CDsbesser steuern zu können. Dabei stellte sich heraus, dassdie Studenten zum überwiegenden Teil Windows ver-wenden und dass eine Produktion von eigenen, plattform-spezifischen CDs wegen der zu geringen Stückzahlenwohl kaum in Frage kommt.

Von Studentenseite wurde unter anderem angeregt,auch Linux-Distributionen ins Programm aufzunehmenund einige Produkte zusätzlich in anderen Sprachvarian-ten (z. B. in Englisch) anzubieten. Ersteres erwies sichnach internen Diskussionen allein schon produktionstech-nisch als nicht zielführend (relativ billige kommerzielleAngebote, Vielfalt der Distributionen, Häufigkeit der Up-dates). Aufgrund der erforderlichen hohen Stückzahlenist die Verteilung einer zusätzlichen Sprachvariante einesProdukts kostenbedingt nicht durchführbar, eine Umstel-lung des gesamten Angebotes z. B. von deutsch auf eng-lisch – allein schon vom Bedarf her – unrealistisch.

Schon von Anbeginn war klar, dass aufgrund der zuerwartenden großen Studenten- und Lizenzzahlen dasService so aufgezogen werden muss, dass kein direkterKontakt des ZID mit den Studenten erforderlich wird undnur in Ausnahmefällen auf administrative bzw. Lizenz-fragen – jedoch nicht auf Supportwünsche – persönlicheingegangen werden muss. In diesem Zusammenhangstellten sich vom Hersteller 1:1 übernommene und vomZID nicht weiter modifizierte CDs rein argumentativ alsvorteilhaft heraus, wenn Beschwerden über angeblichnicht installierbare Software vorgebracht wurden. Um dasProdukt Mathematica verwenden zu können, muss sichjeder Lizenznehmer bei der Firma Wolfram Research re-gistrieren und ein Passwort anfordern, das nach ca. einemJahr abläuft. Dadurch ergibt sich ein nicht kalkulierbarerexterner Faktor, der (verständlicherweise) verstärkt zuAnfragen und Beschwerden führt, wenn es Probleme beidieser Registrierung gibt – egal, wer der Verursacher da-für ist. In den bisher zwei Fällen, als die Registrierungs-stelle über mehrere Tage hindurch nicht erreichbar war,oder – noch unangenehmer – nicht funktionierende Pass-wörter ausstellte, zeigte sich, dass solche Ausnahmesitua-tionen einen Mitarbeiter in seinen sonstigen Tätigkeitenmehr oder weniger lahmlegen.

Ausblick

Für die nächsten Jahre ist eine Weiterführung diesesServices und ein kontinuierlicher Ausbau des Angebotsvorgesehen.

Konkret geplant sind die Verteilung der neuen Micro-soft XP Produkte sowie laufende Updates von bereits eta-blierter Software wie Mathematica oder Maple.

Es bleibt abzuwarten, ob bzw. welche Auswirkung dieEinführung von Studiengebühren auf das Studenten Soft-ware Service haben wird.

Mit flächendeckenden und einheitlichen Mechanismenzur Identifikation und Authentifikation aller TU Studen-ten (z. B. Student-Card, Accounts für alle Studenten)könnte die Administration der Studentensoftware effizien-ter gestaltet und die Lizenzkontrolle verbessert werden.

Vortragende, die in ihren Lehrveranstaltungen Studen-tensoftware als Hilfsmittel empfehlen oder verwenden,sollten mit dem ZID Kontakt aufnehmen, damit einerseitssichergestellt ist, dass zu Beginn der jeweiligen Veran-staltung im Lehrmittelzentrum ausreichend Medien la-gernd sind, andererseits sie selbst über geplante Ver-änderungen (Updates, neue Produkte) vorab informiertwerden können.

Wir sind überzeugt, dass dem ZID mit der Einführungdes Studenten Software Service ein weiterer Beitrag zumlegalen Einsatz von Standardsoftware gelungen ist undhoffen, dass die angebotenen Produkte von den Studentenwidmungsgemäß als wertvolle Unterstützung im Rahmenihrer Ausbildung genutzt werden.

Webpage

sts.tuwien.ac.at/sss.html


TUNET Backbone& GigabitJohann Kainrath

Neben der ATM-Technologie, die sich nicht so schnell aus dem TUNET verabschieden wird, hältGigabit Ethernet Einzug, eine Technologie, die neben 1000 MBit/s Bandbreite auch Stabilität undFlexibilität für das High-Speed Backbone der TU Wien verspricht.

Backbone an der TU Wien

Die bereits 1996 begonnene Umstrukturierung desBackbone auf ein ATM-Netz konnte im Jahr 1999 weit-gehend abgeschlossen werden. Die Infrastruktur für dieDatenkommunikation zur Verbindung der Gebäudekom-plexe am Campusbereich basierte damit zu diesem Zeit-punkt fast ausschließlich auf Asynchronous TransferMode (ATM) über Glasfaserkabeln. ATM bot neben an-deren Vorteilen wie Skalierbarkeit auch im BereichSprachdienste in einem Netzwerk Möglichkeiten zur Rea-lisierung. Durch die Flexibilität von ATM war die Inte-gration des neuen über die TU-Standorte verteilten undredundant aufgebauten Telekommunikationssystems indas TUNET-Daten-Backbone möglich.

Mit der gewählten ATM Implementierung stand undsteht allen Benutzern der TU Wien mittels TUNET einemoderne und leistungsstarke Infrastruktur zur Verfügung,die sich auf stabile Art und Weise bereits bewährt hat.

Hauptanforderungen an das Backbone, nämlich ausrei-chend Bandbreite zur Übertragung von Daten und Spra-che auf sämtlichen Verbindungen sowie Redundanz inhöchstem Maße, sind garantiert, erfordern jedoch einenstetig vorangetriebenen Ausbauprozess.

Kernstück bisheriger Planungen war nach wie vor dieVerbindung der zentralen Gebäudekomplexe Freihaus,Karlsplatz und Gußhaus mit ausreichender Kapazität,nämlich 622 MBit/s. 1999 wurde in dieses Dreieck dervierte Eckpfeiler, nämlich der Gebäudekomplex Favori-tenstraße integriert. Damit verfügte die TU Wien über ge-nug Bandbreite am Campusbereich, in Summe also über7 OC12 (622 MBit/s) Verbindungen zwischen oben er-wähnten Standorten.

Bisher gelang es durch geeignete Infrastruktur-Anpas-sungen immer, diesen steigenden Bedarf der Datenkom-munikation sowohl im Backbone als auch bei derAnbindung im Institutsbereich zu befriedigen. Die Band-breite auf einem ATM Link im TUNET beträgt jedoch

maximal 622 MBit/s (entspricht OC12). Gigabit Ethernetbietet hier von Beginn weg höhere Bandbreiten, außer-dem ist eine mögliche Skalierbarkeit durch so genannteGigabit Ethernet Channels gegeben.

1999 erstmals Gigabit

Als neue Technologie wurde daher bereits 1999 erst-mals Gigabit Ethernet bei Uplinks vom Backbone zumDistribution/Access-Bereich ins Spiel gebracht. Im Frei-haus und in der Favoritenstraße wurden erste sehr positi-ve Erfahrungen gesammelt. Bereits damals wurde darangedacht, die zur Datenkommunikation eingesetzte Tech-nologie (ATM LAN Emulation = Emulieren eines Ether-net LANs auf ATM Zellen Technologie) zu Gunsten vonGigabit Ethernet zu reduzieren. In diese Richtung gingenund gehen auch die Entwicklungen und Trends am Netz-werksektor.

Gigabit Ethernet (GE) – Die Technologie

100 MBit/s oder Fast Ethernet reichte vielen bereitsbei seiner Einführung nicht aus, somit wurde im Juni1998 eine neue höhere Bandbreitentechnologie auf dieIndustrie losgelassen. Gigabit Ethernet (IEEE 802.3z)spezifiziert Datenübertragung im Bereich 1000 MBit/s,also wieder eine zehnfache Steigerung der Bandbreite.Wozu ist diese erneute Steigerung eigentlich notwendig ?Manchmal scheint es schon schwierig zu sein, eine 100MBit/s Full Duplex Verbindung voll auszulasten. Wasalso mit 1000 MBit/s tun ? Befürworter der GigabitEthernet-Technologie sehen Haupteinsatzgebiete einer-seits im Backbone-Bereich (Verbindungen zwischen Ge-bäuden bzw. als Uplink im Gebäude) als auch im BereichAnschluss von High Speed Fileservern. Es ist nicht zu er-warten, dass normale Netzwerkclients (PCs, Worksta-tions) demnächst flächendeckend direkt via GigabitEthernet angeschlossen werden. Diverse Studien belegen,dass bei Workstations in der „Pentium PC Klasse“, in de-nen ein Gigabit Ethernet Interface eingebaut wird, die


(Netzwerk-) Performance eher sinkt und die CPU bei ho-hem Netzverkehr überlastet ist (eine erreichte Datenratevon 400 MBit/s scheint hier zum heutigen Zeitpunkt rea-listisch zu sein). Hier werden wohl auch Netzwerk-Karten Abhilfe bringen, die den TCP/IP-Stack bereits on-

board implementiert haben. Andererseits können UNIXHochleistungsworkstations durchaus von einer GigabitEthernet Pipe zum Netzwerk profitieren.

Die Gigabit Ethernet Spezifikation mixt Eigenschaftenvon 802.3 Ethernet und Fiber Channel (eine GigabitTechnologie als LAN-Ersatz zum direkten High SpeedZusammenschluss zwischen Fileservern). Die beiden un-tersten Ebenen der Fiber Channel Architektur werden mitden Ethernet 802.3 MAC und LLC Layers zum GigabitEthernet Standard formiert. Wie Fast Ethernet (100 MBit/s)unterstützt Gigabit Ethernet ebenfalls sowohl Half Du-plex als auch Full Duplex Modi. Der Full Duplex Modusbedeutet somit eine Kapazität von 2 GBit/s auf einemLink.

Die 802.3z Gigabit Ethernet Spezifikationen definie-ren für unterschiedliche Typen von Medien (Glas, Kup-fer) verschiedene Distanzen, die in nachfolgender Tabellezusammengefasst sind.

Standard Kabelkategorie Kabellänge(geswitcht)[Minimum: 2 Meter]

1000BaseCX Kupfer, Twisted Pairgeschirmt (150 Ohm)

bis 25 Meter

1000BaseT Kupfer, Kategorie 5 UTP(ungeschirmt 4 Paare)

bis 100 Meter

1000BaseSX Glas, Multimode(50µm,62,5µm; 850nm)

220 bis 550 Meter

1000BaseLX Glas, Multimode,Singlemode, (1300nm)

bis 550 Meterbis 5 Kilometer

1000BaseLH Glas, Singlemode(9µm,10µm)

bis 10 Kilometer

1000BaseZX Glas, Singlemode(9µm,10µm)

bis 90 Kilometer

Um beim Einsatz von Gigabit Verbindungen flexibelzu sein, sind die Gigabit Ethernet Einschübe in den Swit-

ches meistens nicht fix konfiguriert, sondern erlaubenden Einsatz von so genannten GBICs. Diese GigabitEthernet Interface Converter werden einfach in das be-treffende Gigabit Ethernet Device eingesteckt und erlau-ben somit je nach Bedarf den Einsatz des richtigenConnectors (1000BaseSX, LX). Diese Variante ist zudemnoch kostengünstig.

Gigabit & ATM TUNET 2000

Zunächst waren im Zuge des Telekommunikationspro-jektes die Umbauten im ATM Backbone nach wie vornicht abgeschlossen. Das an der TU Wien eingesetzteund über alle Standorte verteilte Ericsson Telekommuni-kationssystem MD110 setzt ein synchron laufendes ATMNetz mit all seinen Knoten voraus. Durch die schrittweiseinstallierten neuen ATM Module konnte die erforderlicheGenauigkeit (Präzision) schließlich erfüllt werden.

Alle Wartungen bzw. Erweiterungen standen im Zei-chen, die hohe Verfügbarkeit des TUNET aufrecht zu er-halten. In einem so großen ATM LAN Emulation Netzwie dem an der TU Wien implementierten (übrigens ei-nes der größten in Österreich neben anderen wie etwa beiSteyr Fahrzeugtechnik) ist dies freilich mit hohem Mana-gementaufwand bei Konfigurationsänderungen verbunden.

Im Hintergrund der Umbauten zeichnete sich bereitsseit einiger Zeit Gigabit Ethernet als neue Backbone-Technologie in der IT-Branche ab, die wesentlich billige-re Technik (nämlich pures Ethernet) als die Overlay-Technik von ATM (Ethernet LAN Emulation über ATM)verwendet. Diese Technik verspricht eine kostengünstigeInvestition in Bandbreite (billigere Geräte, einfachereTechnologie – kommt aus der bekannten und bewährten10Base und 100Base Ethernet Entwicklungsschiene). Zu-dem bietet diese Technologie den Vorteil, einerseits imBackbone als auch im Distribution- bzw. Access-Bereicheingesetzt werden zu können. Weniger Komplexität beider Konfiguration und damit weniger Fehleranfälligkeitschlagen sich in weniger Aufwand beim Troubleshootingnieder.

Implementierung von Gigabit im TUNET

Gigabit Ethernet Technologie soll einerseits im TU-NET Backbone zur Verbindung der Gebäudekomplexeeingesetzt werden. Andererseits sollen Etagenverteiler imGebäude optional (wenn die Notwendigkeit und Möglich-keit von der Infrastruktur her gegeben ist) redundant anzwei Backbone Switche mit Gigabit Ethernet Uplinks an-gebunden werden, um Ausfallssicherheit zu garantieren.

Die Gebäude selbst sollen auf alle Fälle redundant andie Core Switche angebunden werden, um hier größt-mögliche Ausfallssicherheit zu bieten. Vor allem abersollen dadurch geplante Eingriffe in das Backbone Netzim Rahmen der Netzwartung unproblematisch erfolgen


Gebäude

Gebäude

1000Mbps 1000Mbps

1000Mbps

10 10 10010

WS

1000

10 10 100

WS W S

Router

Router

Router

WS

WS WS WSSrv

1000Mps = 1Gps

Gigabit Ethernet Backbone Architektur

Cisco 4912G – 12Port Gigabit Switch

können. Aus Sicht der Benutzer sollen dann Störungendurch Wartungsarbeiten weitgehend vermieden werden.

Im größten Vernetzungsprojekt im Jahr 1999, der In-betriebnahme des neuen Gebäudes in der Favoritenstraße,wurden mit diesen beiden Varianten bereits erste Gehver-suche unternommen. Allerdings sind die Etagenverteilerim gesamten Gebäudekomplex nicht in redundanter Wei-se angebunden. Die Erfahrungen waren trotzdem äußerstpositiv, somit konnte der nächste Schritt in Richtung Gi-gabit Ethernet im gesamten Backbone getan werden.

Aufgrund der aktuellen ATM Backbone Struktur undder eingesetzten Switch-Modelle bot sich als Übergangs-lösung die Implementierung eines Gigabit Ethernet Rin-ges parallel zum ATM Netz an. Durch die Beschaffungweiterer Einschübe für die freien Steckplätze in denBackbone Switches und der Verwendung freier GlasfaserInfrastruktur konnte die Implementierung relativ rasch er-folgen und erste Erfahrungen konnten gesammelt werden.Die Ringtopologie ist jedoch nicht die Struktur, die einenoptimalen Einsatz der Gigabit Ethernet Technologie ga-rantiert.

Erste Besprechungen zum Thema Gigabit Ethernet imTUNET Backbone fanden im Juni 2000 statt. Nach Klar-heit über die ersten Schritte der Implementierung erfolg-ten im November 2000 letzte Teillieferungen vonModulen. Nach einem nochmaligen Feinschliff des Kon-zeptes wurde von uns mit dem Einbau der Gigabit Ether-net Komponenten noch im November 2000 begonnen.Schließlich erfolgte die „Inbetriebnahme“ von GigabitEthernet im TUNET Backbone im Dezember 2000. Lei-der funktionierte die in Zusammenarbeit mit dem Liefe-ranten ausgearbeitete Lösung nicht in gewünschter Weiseund führte zu mehreren längeren Ausfällen des TUNET

Backbones im Zeitraum Dezember 2000 bis Jänner 2001.Erst durch ein Abweichen vom ursprünglichen Imple-mentierungskonzept und daraus resultierende Umkonfigu-rationen (nur je ein Übergang zwischen ATM LANEmulation und Gigabit Ethernet für das betroffene Back-bone LAN) gelang es, die Instabilitäten in den Griff zubekommen und den gewohnten Servicelevel wieder her-zustellen.

Gigabit im TUNET 2001

Von der bis jetzt zwischenzeitlich aus Kostengründenimplementierten Ringtopologie soll auf eine Sterntopolo-gie übergegangen werden. Die Realisierung soll noch imSommer 2001 erfolgen.

Der Core Bereich (innerster Backbone Bereich) sollvorerst ausschließlich auf Layer 2 des ISO/OSI Sieben-Schichtenmodels realisiert werden. Wie in der Grafik an-geführt, sollen die wichtigsten Gebäudekomplexe an diebeiden redundant ausgeführten Core Switche angeschlos-sen werden.

Mit dem Einsatz von Gigabit Ethernet im TUNETBackbone wird auch die Reduktion der bisherigen Proto-kollvielfalt umgesetzt. Bisher konnte neben dem Haupt-protokoll TCP/IP je nach Standort auch eine teilweiseAusfallssicherheit anderer Protokolle wie Novell (IPX/SPX), AppleTalk und Decnet Phase IV implementiertwerden. Die Redundanz im Gigabit Ethernet bedeutet IP-Only. Die vorgesehenen Geräte auf diesem Gebiet sindkombinierte Switch(Layer 2)/Router(Layer3) in einer fi-xen (nicht modularen) Konfiguration. Dies schlägt sich indeutlich niedrigeren Anschaffungskosten nieder. Redun-danz für die anderen erwähnten Protokolle im Gigabit


Core

Gebäude 1

Gebäude 2

ATM

ATM

Layer 2 Switch

Layer 3 Switch/

Router

Layer 2 Core Switch

ATMATM ATM Lan Emulation

Backbone VLANs

Gigabit Trunk

CS1

CS1

Implementierungsvarianten von Gigabit im TUNET Backbone und Distribution/Access-Bereich

Bereich implementieren zu wollen, würde die Anschaf-fung hochmodularer und extrem teurer Geräte (im Millio-nen Schilling Bereich) bedeuten und wäre nichtvertretbar.

Hardware-Ausstattung des Backbones

Derzeit umfasst das Backbone 17 Core Switche, dassind 11 kombinierte ATM/Ethernet Switche (Cisco Cata-lyst 5500) sowie 5 reine ATM Switche (Cisco LS1010).2 ATM Routeserver (Cisco 7507) sowie 5 Routeswitch-Module und einige kleinere Router erledigen das Routingder Datenpakete über das Backbone. Insgesamt verbindenderzeit sieben Gigabit Ethernet Verbindungen (Trunks)ausgewählte Backbone Switche untereinander.

Backbone & Telekommunikation

Die in den zentralen Bereichen Freihaus, Karlsplatz,Gußhaus und Favoritenstraße sowie an den StandortenTreitlstraße, Resselgasse, Karlsgasse und Argentinierstra-ße installierten ATM- bzw. kombinierten ATM-Ethernet-Switche ermöglichen die Integration von Daten und Spra-che an der TU Wien. Immerhin beansprucht die Tele-kommunikation permanent ca. 70 MBit/s auf deneinzelnen Backbone-Verbindungen. Das entspricht den35 CES Verbindungen (CES = Circuit Emulation Serviceüber ATM entspricht 2 MBit/s CBR Constant BitrateTraffic), die quer durch das ATM Backbone gespanntsind.

Da zurzeit VOIP (Voice over IP = Telefonie über IP)an der TU Wien kein Thema ist und Gigabit Ethernetsonst keine Möglichkeit zur Integration von Sprache bie-tet, wird die ATM Technologie nicht so schnell aus demTUNET verschwinden.

Backbone & Internet-Anbindung

Die geplante Gigabit Ethernet Topologie unterstützt inhohem Ausmaß die Möglichkeit, die redundante Internet-Anbindung der TU Wien über zwei unabhängige Service-provider wie bisher zu implementieren. Weiters ist siegeeignet, die Firewall für die TU Wien optimal zu inte-grieren.

Backbone & externe Standorte

Die ATM-Technologie wird auch dazu eingesetzt, umsowohl Daten- als auch Telefonverbindungen zu abge-setzten Standorten zu realisieren. Die bereits im Jahre1999 realisierten 2 MBit/s ATM-Strecken zu Theresia-numgasse, Aspanggründe und Atominstitut zeichnen sichdurch hervorragende Stabilität aus. Die Kapazität der An-bindung reichte zwar im Jahr 2000 für alle Standorte aus,dennoch wird an eine Migration auf die Ethernet Techno-logie gedacht. Voraussetzung ist jedoch, entsprechendeGlasfaserstrecken zu diesen Standorten zu errichten –eine nicht ganz billige Angelegenheit (dieses Problembesteht derzeit auch für den Standort Getreidemarkt).

Konklusion

ATM wird im TUNET erhalten bleiben. In der Tele-kommunikation führt kein Weg daran vorbei, aber auchin der Datenkommunikation ist ATM zur Realisierungexterner Verbindungen nicht wegzudenken. Die Zukunftwird jedoch mit Sicherheit verstärkt Gigabit Ethernetbringen. Am Horizont schimmert aber schon der – wegender eingesetzten Wellenlänge nicht sichtbare – 10 GigabitEthernet Lichtstrahl, siehe http://www.10gea.org/.


Karlsplatz / Resselgasse

Treitlstraße,Perlmooserhaus

ZIDInterneträume

FreihausBibliothek

Gußhaus

Favoritenstraße

Argentinierstraße(Karlsgasse)

Getreidemarkt

Freihaus

G UßHAUS

Gigabit Ethernet Link

Switch/Router mitGigabit Uplink

Gigabit Core Switch

TUNET Gigabit BackbonePlan 2001

Sicherheit unter Linux16 Schritte zu einem sicheren Linux-System

Walter Selos

Linux findet, vor allem als zuverlässiges Server-Betriebssystem, immer mehr Verbreitung. Diemeisten dieser Linux-Installationen sind, insbesondere an der TU, ständig mit dem Internetverbunden. Aus diesem Grund ist es besonders wichtig, über die Sicherheit der InstallationÜberlegungen anzustellen.

Checkliste

Tipp 1 Starten Sie nur die benötigten Services (Daemons)

a Start über Startupscripts

Die folgenden Daemons werden über Startupscripts gestartet, welche sich in einem für den jeweiligenRunlevel relevanten Verzeichnis befinden.

Wie weiß ich den Standard Runlevel ?

grep default /etc/inittab

Als Ergebnis sehen Sie eine Zeile, z.B:

id:3:initdefault:

Die 3 entspricht dem eingestellten Runlevel.

Wenn Sie z.B. den unten angegebenen dhcp-Server deaktivieren wollen, gehen Sie in das dem Runlevelentsprechende Verzeichnis z.B. /etc/rc.d/rc3.d (kann je nach Distribution variieren) und nennen Siedie Datei S35dhcpd auf s35dhcpd um.

Beim nächsten Reboot wird dieser Daemon nicht mehr gestartet.

Die Nummer hinter dem „S“ gibt die Startreihenfolge an und kann je nach Distribution variieren.


Das Gerücht, Linux sei ein „Hacker-Betriebssystem“,geht einerseits auf die große Verbreitung und gute Doku-mentation zurück, bewahrheitet sich bezüglich Netz-werksicherheit aber nur dann, wenn das entsprechendeFachwissen, das zum Betrieb eines Servers nötig wäre,fehlt (das gilt nicht nur für Linux). Da die Installationvon Linux jetzt schon sehr bequem und menügeführtvonstatten geht, ist dafür ein solches Wissen nicht nötig,um zu einem lauffähigen Linux zu kommen, was sich imBetrieb allerdings rächen kann. Um sich dieses Wissen

gezielter aneignen zu können, möchte ich in Form einerCheckliste die mir am wichtigsten erscheinenden Punktezusammenfassen. So haben Sie einerseits eine grobeKonfigurations-Richtlinie zur Verfügung, andererseitskönnen Sie Ihr Wissen gezielter vertiefen, wenn Sie beimDurchlesen der Checkliste auf Wissenslücken stoßen.

Es ist für ein komplexes Server-Betriebssystem, wel-ches noch dazu in verschiedensten Distributionen undVersionen verfügbar ist, evident, dass diese Liste keinenAnspruch auf Vollständigkeit hat.

Einige Beispiele von Startupscripts:

S05apmd You only need this for laptopsS10xntpd Network time protocolS11portmap Required if you have any rpc services, such as NIS or NFSS15sound Saves sound cared settingsS15netfs This is the nfs client, used for mounting filesystems from a nfs serverS20rstatd Try to avoid running any r services,S20rusersd they provide too much information to remote usersS20rwhodS20rwalldS20bootparamd Used for diskless clients, you probably don’t need this vulnerable serviceS25squid Proxy serverS34yppasswdd Required if you are a NIS server, this is an extremely vulnerable serviceS35ypserv Required if you are a NIS server, this is an extremely vulnerable serviceS35dhcpd Starts dhcp server daemonS40atd Used for the at service, similar to cron, by not required by the systemS45pcmcia You only need this script for laptopsS50snmpd SNMP daemon, can give remote users detailed information about your systemS55named DNS server. If you are setting up DNS, upgrade to the latest version of BIND

http://www.isc.org/bind.htmlS55routed RIP, don’t run this unless you REALLY need itS60lpd Printing servicesS60mars-nwe Netware file and print serverS60nfs Use for NFS server, do not run unless you absolutely have toS72amd AutoMount daemon, used to mount remote file systemsS75gated used to run other routing protocols, such as OSPFS80sendmail You can still send email if you turn this script off, you just will not

be able to receive or relayS85httpd Apache webserver, I recommend you upgrade to the latest version

http://www.apache.org/S87ypbind Required if you are a NIS clientS90xfs X font serverS95innd News serverS99linuxconf Used to remotely configure Linux systems via browser,

every black-hat’s dream :)

b Start über inetd.conf -> TCP-Wrapper einbauen

Beispiel: Hier ist z.B. nur ftp und swat (Samba Configuration Tool) erlaubt, ftp und swat werden über denTCP-Wrapper (tcpd) umgeleitet. Das System läuft auch noch, wenn man alles auskommentiert, also keinefalsche Scheu, besser man dreht ein Service ab, das man nachher wieder aktivieren muss, als man wirdOpfer einer Hackerattacke!

## inetd.conf This file describes the services that will be available# through the INETD TCP/IP super server. To re-configure# the running INETD process, edit this file, then send the# INETD process a SIGHUP signal.## Version: @(#)/etc/inetd.conf 3.10 05/27/93## Authors: Original taken from BSD UNIX 4.3/TAHOE.# Fred N. van Kempen, <[email protected]>## Modified for Debian Linux by Ian A. Murdock <[email protected]>## Modified for RHS Linux by Marc Ewing <[email protected]>## <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>## Echo, discard, daytime, and chargen are used primarily for testing.## To re-read this file after changes, just do a ‘killall -HUP inetd’##echo stream tcp nowait root internal#echo dgram udp wait root internal#discard stream tcp nowait root internal#discard dgram udp wait root internal#daytime stream tcp nowait root internal#daytime dgram udp wait root internal#chargen stream tcp nowait root internal#chargen dgram udp wait root internal#time stream tcp nowait root internal#time dgram udp wait root internal## These are standard services.#

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a

#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd## Shell, login, exec, comsat and talk are BSD protocols.##shell stream tcp nowait root /usr/sbin/tcpd in.rshd#login stream tcp nowait root /usr/sbin/tcpd in.rlogind#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd#comsat dgram udp wait root /usr/sbin/tcpd in.comsat#talk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkd#ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd#dtalk stream tcp wait nobody.tty /usr/sbin/tcpd in.dtalkd## Pop and imap mail services et al#


#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d#imap stream tcp nowait root /usr/sbin/tcpd imapd## The Internet UUCP service.##uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l## Tftp service is provided primarily for booting. Most sites# run this only on machines acting as “boot servers.” Do not uncomment# this unless you *need* it.##tftp dgram udp wait root /usr/sbin/tcpd in.tftpd#bootps dgram udp wait root /usr/sbin/tcpd bootpd## Finger, systat and netstat give out user information which may be# valuable to potential “system crackers.” Many sites choose to disable# some or all of these services to improve security.##finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet## Authentication##auth stream tcp wait root /usr/sbin/in.identd in.identd -e -o## End of inetd.conf#linuxconf stream tcp wait root /bin/linuxconf linuxconf —http

swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat swat

Nicht vergessen:

Nach Editieren inetd.conf: killall -HUP inetd (inetd liest das conf-File neu ein!)

Achtung:

Neue Versionen haben oft statt des inetd den xinetd laufen, dann ist die Konfigurationsdatei meist inmehrere, für jedes Service eine, aufgeteilt, die sich in einem eigenen Verzeichnis, meist /etc/xinetd.conf befinden. Dieser neue xinetd hat die TCP-Wrapper-Funktion bereits eingebaut und istflexibler zu konfigurieren. Die Syntax ist etwas anders, siehe „man xinetd“ und „man xinetd.conf“.

Tipp 2 Zugriffsrechte über TCP-Wrapper einschränken

Der TCP-Wrapper wird über 2 config-Dateien konfiguriert. Außerdem müssen die Einträge in /etc/inetd.conf modifiziert werden. Z.B.:

/etc/hosts.deny:ALL: ALL

/etc/hosts.allow:ALL EXCEPT swat: .mysubnet.tuwien.ac.atswat: localhost mycomputer.mysubnet.tuwien.ac.at

Funktion testen !

Das heißt: alle Dienste, die über tcpd gestartet werden, sind für „mysubnet ...“ erlaubt, jedoch swat nurfür die eine Maschine „mycomputer.mysubnet“ und für die lokale Maschine.

Siehe auch: man 5 hosts_access

Auch den Portmapper-Zugriff kann man bei Linux über host.allow/deny konfigurieren.

Achten Sie natürlich auch auf spezielle Services, die Sie selbst gestartet haben: z.B. appletalk, mars-nwe(Novell-Server) etc.

Tipp 3 Shadow Password verwenden, auf sinnvolle Passwörter achten

Bei RedHat: Wenn Sie die Option „shadow-passwords“ beim Installieren vergessen haben, hilft: pwconv

Tipp 4 Auf File Permissions achten beim Einrichten von Usern, Gruppen

Da kann man nicht viel dazu sagen, hängt von der Struktur ab, die man abbilden will.Siehe: man chmod, man chgrp, man chown

Bei RedHat: gute graphische Konfigurationshilfe: linuxconf(damit kann man relativ leicht User und Gruppen verwalten)


Tipp 5 Womöglich nur ssh verwenden (oder onetime-passwd)

Um sich von Windows oder Mac einzuloggen: Teraterm bzw. nifty-telnetTeraterm (für Windows): http://hp.vector.co.jp/authors/VA002416/teraterm.htmlNifty-Telnet (für Mac): http://www.lysator.liu.se/~jonasw/freeware/niftyssh/

Tipp 6 Wenn User für Samba oder pop u.dgl. eingerichtet werden:

keine Shell (/bin/false im /etc/passwd) und eigenes Passwort, welches in keinem Shell-Accountverwendet wird.

Auch für ftp-User, dann muss man aber /bin/false in /etc/shells eintragen.

Sollte sich dann jemand das Passwort mittels eines Sniffers aneignen, kann er zwar Dateien transferieren,jedoch keine Kommandos absetzen bzw. Programme starten.

Tipp 7 Achten Sie auf offene X-Verbindungen

(also remote X-Server: X-Terminal, andere Unix/Linux-Maschine, Windows mit X-Server,z. B. HCL-Exceed)

Wenn X-Windows-Sessions nicht über ssh getunnelt werden, kanna.) im Netz mitgesnifft werden,b.) eine Verbindung zum X-Server von anderswo hergestellt und jeder Tastendruck abgefragt werden.

Punkt b.) ist nur möglich, wenn der X-Server für alle zugänglich ist.Mit dem Befehl xhost Einträge überprüfen/ändern !Zusammengefasst: Vorsicht mit X11 übers Netz !

Tipp 8 Samba Server absichern

• Für Samba: (Fileserver für Windows-Maschinen)• Passwort-Encryption verwenden (mit Win98 oder NT SP ≥ 4)• hosts_allow Liste in den Shares verwenden• wenn SWAT verwendet wird, nur so verwenden, dass keine Sniffingmöglichkeit vorhanden, womöglich nur

für localhost erlauben (/etc/hosts.allow).

Tipp 9 Achten auf Netzwerktopologie: große Collisiondomain ?

Sind andere schwach gesicherte Maschinen im Netz ? -> Gefahr durch potentielle Passwort-Sniffer !

Abhilfe: Bessere Sicherung der Maschinen durch strukturierte Verkabelung, Switches, Bridges etc.

Tipp 10 Eventuell zusätzliche Filterung mit Packetfilter (ipchains)

Logging für die Rules aktivieren ? (option -l)Siehe: http://gd.tuwien.ac.at/opsys/linux/LDP/HOWTO/IPCHAINS-HOWTO.html

Verwenden Sie ipchains und andere Firewall-Lösungen nur, wenn Sie wirklich wissen, was Sie tun, undtesten Sie die Konfiguration auf ihre gewünschte Funktion, damit Sie sicher gehen, dass hier nicht nurSicherheit vorgetäuscht wird.Im Rahmen der Wartungsabkommen können Sie hier Hilfe vom ZID beanspruchen (sts.tuwien.ac.at/pss/).

Tipp 11 Eventuell einfache Firewall-Lösungen

mit packetfilter in forward-chain, Masquerading,siehe http://linux.tuwien.ac.at/firewall.html

Tipp 12 Bei Kernel ≥ 2.2.x -> Spoofing Protection möglich

Spoofing Protection verhindert das Vortäuschen falscher IP-Adressen.

echo 1 > /proc/sys/net/ipv4/conf/ethx/rp_filter


Tipp 13 Achten Sie auf Veröffentlichungen von Securitybugs, Patches ...

Siehe Homepages der diversen Distributionen.

Tipp 14 Erkennen von Hackerattacken I

evtl. cronscripts, welche potentielle Attacken erkennen, wie z.B.: logcheck ...

Achten Sie in den Logfiles auf „connect from unknown“: könnte Portscanner-Aktivitäten anzeigen.

Tipp 15 Erkennen von Hackerattacken II

Kopieren Sie Programme, die Sie zum Aufspüren von Hackern brauchen, wie ps, ls, ifconfig, top,find, grep, cksum, md5sum usw., unter einem anderen Namen auf ein anderes Verzeichnis.

Machen Sie nach der Erstinstallation von diesen (oder vom ganzen /bin/* /sbin/* ) ein cksum odermd5sum und notieren Sie sich die Checksummen (ausdrucken, auf anderer Maschine speichern).z.B:md5sum /bin/* >md5_dateimd5sum /sbin/* >>md5_dateiHeben Sie jetzt die md5_datei gut auf (z.B. auf einem anderen Computer).

Wenn Sie den Verdacht hegen, dass ein Hacker auf Ihrer Maschine sich versteckt hält, machen Sie den obenbeschriebenen Vorgang nochmals in eine andere Datei und vergleichen Sie die beiden Dateien mit „diff“.Wenn Unterschiede gemeldet werden, wurde etwas verändert (könnte natürlich auch von Ihnen durchirgendwelche Updates verursacht sein, daher nach einem Update den Vorgang wiederholen.)

So können Sie feststellen, ob ein Eindringling einige Ihrer wichtigen Systemprogramme ausgetauscht hat,um Spuren zu verschleiern.

Tipp 16 Allgemeine Hinweise

Wenn Sie einfach eine Standardinstallation durchführen, sollten Sie daran denken, dass, je nachDistribution, der Bequemlichkeit halber viele Komponenten und Dienste mitinstalliert werden, die Sie meistnicht brauchen.

Informieren Sie sich bitte, was das für Komponenten sind, die da laufen.

Machen Sie einen Portscan (dieser wird auf Wunsch vom ZID für Sie durchgeführt: E-Mail [email protected] mit dem Betreff „Systemcheck“.)

Tipp 1 soll Ihnen dabei als Anhaltspunkt und Hilfe dienen, allerdings ohne einen Anspruch aufVollständigkeit.

Vorsicht bei fertig installierten Firmenlösungen: Erfahrungsgemäß sind die Leute, die das Systeminstallieren, nicht mit so großen Netzwerken, wie auf der TU vorhanden, konfrontiert. Daher fehlt auch ofteine gewisse Erfahrung; wieder laufen einige nicht benötige Dienste.

Weitere Informationen können Sie durch die „HOWTOs“ des LDP (Linux Documentation Project)bekommen, siehe: http://gd.tuwien.ac.at/opsys/Linux/LDP/.

Sollte Ihnen das alles zu viel sein, können Sie für Ihren Server auch einen Wartungsvertrag bei uns (Zentraler Infor-matikdienst, Abteilung Standardsoftware) abschließen, siehe:

sts.tuwien.ac.at/pss/


Systemunterstützungder Arbeitsplatzrechnerund Server

Statistiken und Analysen

Albert Blauensteiner

Der folgende Artikel gibt einen Überblick über den Verlauf der Systemunterstützung seitEinführung des Services Ende 1999 bis zum Ende des ersten Quartals 2001. Die Verteilung derUnterstützung nach Fakultäten, Plattformen und Aufwand wird kurz analysiert.

Einleitung

Ein Aufgabengebiet der Abt. Standardsoftware liegt inder Betreuung und Unterstützung der Server und Arbeits-platzrechner an den einzelnen Instituten der TU Wien.Diese Leistungen werden auf allen gängigen Plattformen,wie den Unix-Systemen von SGI, HP, Compaq, IBM,SUN sowie LINUX und im PC Bereich Windows, Win-dowsNT, W2K sowie auch für Mac erbracht.

Die Einsatzgebiete reichen dabei von der Analyse beiNeuanschaffungen, über die Unterstützung und Beratungin Fehlerfällen und bei Ausbauplänen bis hin zu Fragenvon Betriebs- und Sicherheitsaspekten sowie der Planungdes Einsatzes von Systemkomponenten und der Anwen-dungssoftware. Nicht zu vergessen sind dabei die Fragen,die im Zusammenhang mit der lokalen und überregiona-len Vernetzung auftreten.

Seit Jahren wird von der Abteilung Standardsoftwarediese Systemunterstützung, der so genannte Plattformsup-port, für alle UNIX Systeme sowie VMS angeboten. Da-für waren bisher speziell geschulte Mitarbeiter auch vorOrt im Einsatz. Seit letztem Jahr trägt die AbteilungStandardsoftware mit einer neuen Form der Systemunter-stützung den veränderten Gegebenheiten in der Rechner-landschaft Rechnung.

Seit Beginn des Jahres 2000 besteht die Möglichkeitfür PCs, Workstations und Server an der TechnischenUniversität Wartungsvereinbarungen mit der AbteilungStandardsoftware des Zentralen Informatikdienstes abzu-

schließen. Diese Wartungsvereinbarungen bieten beson-dere Leistungen der Systempflege für die spezifiziertenRechnersysteme an, und zwar in zwei grundsätzlichenKategorien: Einerseits eine Systempflege, die auch einenEinsatz vor Ort umfasst, andererseits eine Fernunter-stützung, die nur über Netzwerk und Telefon erfolgt. Inbeiden Kategorien wird zwischen „normalen“ Arbeits-platzrechnern und Serversystemen unterschieden. Bei denArbeitsplatzrechnern wiederum gibt es noch eine Unter-scheidung zwischen wartungsfreundlichen und wartungs-intensiveren Arbeitsplätzen.

Wenn ein derartiges Rechnersystem mit einer entspre-chenden Wartungsvereinbarung ausgestattet ist, so kön-nen für dieses System Anforderungen zur Hilfestellungüber ein dafür errichtetes Call Center im Zentralen Infor-matikdienst in Anspruch genommen werden. Es wirdeine entsprechende Antwortzeit garantiert und die Anfra-ge entweder mit Mitarbeitern des Zentralen Informatik-dienstes oder mit Mitarbeitern von externen Firmen einerUntersuchung bzw. einer Lösung zugeführt.

Statistisches

Bis zum Ende des ersten Quartals 2001 wurden 455Unterstützungsfälle gezählt, die sich, wie in den beidenfolgenden Abbildungen dargestellt, auf die unterstütztenPlattformen sowie die unterstützten Fakultäten verteilen.


Die meisten Unterstützungsfälle wurden für WindowsNT gezählt, dann für Win 9x sowie Linux, die wenigstenfür Solaris. Es gab mit dem Stichtag insgesamt 345 ab-geschlossene Verträge, davon 270 Systempflegeverträgeund 75 Fernunterstützungsverträge. Die meisten Verträge,nämlich 132, wurden für Windows NT abgeschlossen,die wenigsten für die Plattform Open VMS, nämlich 10.

Die niedrige Unterstützungsquote bei Solaris ist ve-mutlich darauf zurückzuführen, dass zuletzt diese Platt-form vom ZID nach dem Abgang des zuständigenMitarbeiters und der Nichtnachbesetzung nicht mehr un-terstützt werden konnte und dadurch eine Servicelückeentstand.

Es zeigt sich, dass die Verträge zur Plattformunterstüt-zung nach wie vor und zwar im verstärktem Maße zuneh-men, was vermutlich auf den nun einsetzenden Bekannt-heitsgrad, die Budgetsituation an den Instituten und nichtzuletzt auf den tatsächlichen Bedarf zurückgehen dürfte.Über 1300 Stunden wurden dabei für die Unterstützungs-fälle aufgewendet, die meisten, nämlich 363, für dieFakultät für Technische Naturwissenschaften und Infor-matik, die wenigsten, nämlich 136, für die Fakultät fürElektrotechnik und Informationstechnik. Bezüglich derPlattformen ging der größte Aufwand, nämlich 216 Stun-den, in den Bereich HP-UX, der geringste an Solaris. In-teressant ist dabei vielleicht die Tatsache, dass etwa dreiViertel der erbrachten Unterstützungsstunden durch dieAbteilung Standardsoftware selbst erbracht wurde, derRest durch externe Firmen, wobei nur zwei Firmen we-sentlichen Anteil am restlichen Viertel haben.

Bei der monatlichen Bilanz der Öffnungen und Schlie-ßungen der Bearbeitungsfälle zeigt sich ein etwa gleich-förmiges Bild. Die Gesamtzahl der offenen Fälle bleibtnun etwa konstant bei etwa 60.


Unterstützungsfälle nach Plattformen

Abgeschlossene Verträge nach Plattformen

Erbrachte Unterstützungsstunden

Offene Fälle

Öffnungen

Schließungen

Status Unterstützungsfälle

Unterstützungsfälle nach Fakultäten

Ein Wort noch zur Qualität der bereits beendeten Leis-tungen: Von 400 Fällen wurden 240 nicht bewertet, bei111 Fällen waren die Kunden „sehr zufrieden“ (Bestno-te), bei 13 Fällen äußerten sie sich als „nicht zufrieden“.

Es gibt einen eindeutigen Qualitätsunterschied zwi-schen den Eigenleistungen und den Fremdleistungen. Diezukünftige Konzeption und Weiterentwicklung des Platt-formservices wird gerade in Hinblick auf die externenRessourcen und die externe Qualität überprüft und über-arbeitet. Im Großen und Ganzen läuft aber das Servicesowohl logistisch als auch technisch zufriedenstellendund kann so, falls keine besonderen Einschränkungen inden Ressourcen bzw. signifikante Zunahmen in den Ver-trägen bzw. in den Unterstützungsanforderungen stattfin-den, prinzipiell in der bisher erbrachten Form weitergeführt werden.

Erfahrungenmit der SystemunterstützungRudolf Sedlaczek

Aus über einem Jahr Erfahrungen mit der neuen Systemunterstützung lässt sich schon einstatistisch signifikanter Überblick über die Stärken und auch verbesserungswürdigen Aspekteziehen, die im nachfolgenden Artikel detailliert behandelt werden.

Überblick

In den Web-Seiten der Systemunterstützung


sind die Leistungen, Kosten und Randbedingungen derangebotenen Dienstleistungen spezifiziert, weshalb hiernicht nochmals darauf eingegangen wird.

Eine erste Anpassung der Dienstleistungen wurdeschon Mitte vorigen Jahres durchgeführt. Auf vielfachenBenutzerwunsch wurde der Dienstleistungsumfang ohneKostensteigerung ausgedehnt und umfasst nun auch dieInstallation und Unterstützung für MS Office auf denWindows Plattformen.

Konzeptionelles

Das System der Unterstützung basiert auf Wartungs-vereinbarungen für einzelne Rechner, nicht pauschal füralle Rechner einer Organisationseinheit. Das minimiertden Administrationsaufwand gegenüber einer Verrech-nung von Einzelleistungen und erleichtert die Abschät-

zung des Unterstützungsbedarfs. Daraus ergibt sich dieNotwendigkeit, alle Rechner identifizieren zu können.Wurden früher nur die Rechner der proprietären Server-und Workstation-Familien in der Abteilungs-Datenbankaufgenommen und verwaltet, so werden in der neuenSystemunterstützung auch alle Rechner mit Wartungsab-kommen eingetragen. Zur Identifikation dient primär der(eindeutige) TCP/IP-Hostname, da bis auf einzelne Aus-nahmen alle Rechner per LAN am TUNET angeschlos-sen sind. Als weitere Identifikationsmöglichkeit wirdoptional auch die Ethernet-Adresse in der Datenbank ge-speichert. Weitere wesentliche Daten eines Rechners sinddie Plattform, der Einsatztyp (Server oder Arbeitsplatz),der Rechner-Typ (z. B. Pentium PC, Sun Ultra 60, ...),der Eigentümer (Institut) und die Kontaktperson. Erst fürbekannte bzw. durch die Kontaktperson online selbst re-gistrierbare Rechner kann dann schriftlich oder online einWartungsabkommen für Systempflege oder Fernunter-stützung bestellt werden.

Alle diese Daten werden entweder bei der Online-Re-gistrierung durch die Kontaktperson oder bei schriftlicherAnmeldung durch die Mitarbeiter der Gruppe Systemun-


Qualitätsbewertung

terstützung eingetragen. Ist die Kontaktperson noch nichtdurch Software-Bestellungen oder als Server-Betreuer inder Datenbank bekannt und autorisiert, kann die War-tungsvereinbarung nur schriftlich erfolgen. Dann wirddiese Person auch in die Datenbank aufgenommen underhält einen Usernamen und ein generiertes Passwort.

Diese Daten bilden die notwendige Grundlage für dieAbwicklung und Verwaltung der einzelnen Unterstüt-zungsanforderungen, die jeweils bei den Abkommen inder Abteilungs-Datenbank gespeichert werden. Jeder Un-terstützungsfall wird nach erfolgter technischer Bearbei-tung dann auch noch in der Datenbank geschlossen undein Arbeitsbericht und die aufgewendete Zeit werden ein-getragen.

Die Leistungen werden durch die Mitarbeiter derGruppe Systemunterstützung und/oder durch externe Fir-men erbracht, mit denen entsprechende Serviceverträgeabgeschlossen wurden. In mindestens einmal jährlichstattfindenden Besprechungen mit den verantwortlichenFirmenvertretern werden diese Vereinbarungen und dieErfahrungen mit der Firma einem Review unterzogen undbei Bedarf angepasst. Im Jahre 2000 bestanden Verträgemit 9 externen Firmen.

Zur Qualitätssicherung werden besonders die negativbewerteten Fälle, aber auch das Feedback und Beschwer-den über die Qualität externer Firmen und interner Be-treuung aufgearbeitet. Hier ergibt sich ein sehr dif-ferenziertes Bild, nicht nur im Vergleich zwischen denverschiedenen Dienstleistern, sondern auch im Vergleichder Abwicklung verschiedener Calls bei einzelnen Fir-

men. Oft werden Calls zur vollen Zufriedenheit der Kun-den abgewickelt, manchmal werden aber von den glei-chen Bearbeitern Calls wieder nicht entsprechendbehandelt, versprochene Rückrufe und Kontaktaufnah-men bleiben aus. Ein eher negatives Gesamtbild bietetdas nur für telefonische Unterstützung eingesetzte Call-Center der Fa. SCIO. Hier reichten die Beurteilungen von„völlig inkompetent“ über „bemüht, aber trotzdem unfä-hig, das Problem zu lösen“ bis zur Zufriedenheit mit derLösungskompetenz. Dem muss man fairerweise zugutehalten, dass die nur telefonische Unterstützung bei Win-dows oft wirklich nicht leicht möglich ist und mancheProbleme oder Wünsche prinzipiell nicht lösbar oder er-füllbar sind (ohne das Betriebssystem umzuschreiben).

Plattform-Differenzierung

Die Systemunterstützung lässt sich in drei unterschied-lich zu handhabende Bereiche gliedern.

1. Traditionelle proprietäre (Unix-)Plattformen

Hierzu sind auch OpenVMS und Macintosh zu rech-nen. Bei diesen Systemen gibt es (bis auf die Solaris-Plattform) kompetente Betreuungsspezialisten in derAbteilung, für die zur Unterstützung und Eskalationvon Calls Support-Verträge mit den Herstellerfirmenabgeschlossen wurden (mit IBM für AIX, mit HewlettPackard für HP-UX, mit Unisys für IRIX, mit BacherSystems für Solaris und mit Compaq für OpenVMSund Tru64). Hier werden die meisten Calls durch in-terne Bearbeiter abgehandelt und gelöst.Interessant ist hierbei, dass für die zahlenmäßig stärks-



te Unix-Plattform Solaris relativ zur Gesamtzahl diewenigsten Wartungsabkommen abgeschlossen wurden(19%). Dies kann auf die fehlende interne Betreu-ungskapazität zurückgeführt werden. Die relativ meis-ten Wartungsverträge gibt es bei HP-UX undOpenVMS (je 38%), gefolgt von AIX (29%), Irix(28%) und Tru64 (24%).

2. Linux

Dieser Bereich ist im Gegensatz zum proprietärenUnix-Bereich sehr dynamisch wachsend, vor allem imEinsatzgebiet als Server für vielfältigste Dienste. Hierwerden die Unterstützungsleistungen hauptsächlichdurch kompetente interne Spezialisten erbracht unddas Unterstützungsteam durch freiwerdende Kapazitä-ten aus dem zurückgehenden proprietären Unix-Be-reich verstärkt.Die Anzahl der Linux-Server ist nicht bekannt, es gibtaber mit 28 Wartungsabkommen fast so viele wie beiWindows NT/2000 Server.

3. Windows

Die hier zu unterstützenden Plattformen reichen vonden relativ einfachen (aber fehleranfälligen) Windows95/98/Me Systemen über die komplexeren, aber stabi-leren Windows NT Workstations und Windows 2000Professional bis zu komplexen Serversystemen mitWindows NT Server und Windows 2000 Server, des-sen Mächtigkeit und Komplexität die von WindowsNT Server noch um ein Mehrfaches übersteigt.Der gesamte Windows-Bereich ist mit 204 Wartungs-abkommen der zahlenmäßig Größte und auch amschwierigsten zu behandeln. Das liegt an der breitenStreuung der Aufgaben, der eingesetzten Hardwareverschiedenster Firmen und Qualitäten und des Know-hows der Systembetreuer (wo es solche im eigentli-chen Sinn des Wortes überhaupt gibt). Hier gibt esderzeit mehrere externe Unterstützer und aus auch his-torischen Personalgründen nur relativ geringe interneBetreuungskräfte.Besonders in diesem Bereich kommt der Funktion desCall-Dispatchers eine kritische Aufgabe zu, indem erdie einlangenden Fälle zu klassifizieren hat und nachden Kriterien der bestmöglichen Unterstützung zu dengeringst möglichen Gesamtkosten einem internen oderexternen Bearbeiter zuweisen muss. Einfache Aufga-ben (Basisversorgung wie Software-Installation, Upda-tes, Drucker- und Netzwerkkonfiguration, ...) werdenin diesem System von anderen Firmen bzw. Mitarbei-tern abgewickelt als komplexe Problemstellungen ei-nes oftmals erfahrenen Systembetreuers, den man

nicht zu jemandem mit weniger Know-how, als er sel-ber hat, weiterleiten sollte.Bei den Server-Versionen von Windows NT undWindows 2000 besteht nur für 14% der 203 registrier-ten Serversysteme ein Wartungsabkommen. Bei denanderen unterstützten Plattformen ist die Anzahl derRechner nicht erfasst, weshalb man keine vergleichba-ren Prozentzahlen angeben kann. Bezogen auf die An-zahl der lizenzierten Betriebssysteme kann nur eineObergrenze für den tatsächlichen Anteil an Wartungs-abkommen genannt werden: 6% bei Windows 95/98/Me und 12% bei Windows NT/2000.

Ausblick

Aus den Erfahrungen von über einem Jahr mit derneuen beitragsorientierten Systemunterstützung und ein-gehender interner Diskussion darüber werden folgendeMaßnahmen für die weitere Verbesserung der Unterstüt-zungsqualität gesetzt:

1. Reduzierung der Anzahl der externen Firmen auf dasnötigste Minimum. Jede weitere Firma bewirkt zusätz-lichen Administrations- und Koordinationsaufwand. Inder ersten Phase wurden bewusst mehrere Firmenauch für eine Plattform ausgewählt, um Erfahrungenmit der Qualität der versprochenen Dienstleistungen inder Praxis zu sammeln.

2. Interne Betreuungskapazitäten und Know-how werdenverstärkt. Ein Vergleich der Problemlösungskompe-tenz der internen und externen Unterstützer auf Grundvon Feedback, Beschwerden und Fallbewertungen fälltpositiv zugunsten der internen Betreuer aus. Besondersbei den proprietären UNIX Plattformen und Linuxwird das Know-how sehr geschätzt.

3. Für die Windows-Plattformen wird ein angepasstesdifferenziertes Unterstützungsportfolio angeboten:• Telefon-Support über ein Call Center, das in Zu-

kunft vermehrt durch interne Fachkräfte besetztwerden wird.

• Breitenwirksamer Basis Support an den Institutendurch 1 bis max. 2 Firmen, wobei sich die Fa.Kreml als zuverlässiger Partner bisher am bestenbewährt hat.

• Abdeckung von Spezialfragen und komplexen Pro-blemen durch interne und komplementär durch un-vermeidbar teure, aber ihren Preis werte externeSpezialisten. Hier wurden mit der Fa. HP gute Er-fahrungen gemacht.


Bestellungen von Wartungsvereinbarungen undUnterstützungsanforderungen für gewartete Systemeonline rund um die Uhr unter


Telefonische Computer Help Line: 42124Mo-Do 9-16 Uhr, Fr 9-14 Uhr

www.tuwien.ac.atWerner F. SommerAbteilung für Öffentlichkeitsarbeit und Information der Zentralen Verwaltung der TU [email protected]

„Der 26.2. wird an der TU als geschmacklosester Tag in die Geschichtsbücher eingehen.Dieses Webdesign ist eine Schande für eine technische Hochschule unseren Niveaus.“Was war geschehen? An jenem Tag wurde das Aussehen von www.tuwien.ac.at demonstrativgeändert. Die Reaktionen (www.tuwien.ac.at/redesign) – positiv wie negativ – waren heftig. Allein:Es handelt sich NICHT um die neue Webpräsenz der TU. Die lässt noch auf sich warten.

Nachdem die „Briefmarken“ also Ende Februar ausge-dient hatten, gingen die Emotionen hoch. Die zahlreichen„zweckdienlichen Hinweise“ ließen die Hoffnung aufkei-men, dass beim Ende Jänner ausgeschriebenen Wettbe-werb (www.tuwien.ac.at/pr/wettbewerb/) zahlreiche Vor-schläge, wie es besser zu machen wäre, über uns herein-brechen würden. Nun ist der Wettbewerb vorbei, und diequantitative Ausbeute eher bescheiden.

Mag sein, dass die 100.000 Schilling zu wenig Anreizdarstellen. Mag sein, dass Unzufriedenheit nicht zwangs-läufig zum Aufzeigen von Alternativen führt. Sei es, wiees sei. Wir werden versuchen, das gesteckte Ziel trotz-dem zu erreichen: Nämlich im Herbst einen neuen Web-Auftritt der TU präsentieren zu können.

Was bisher geschah

In Zeiten, da die „Killer-Websites“ wie Schwammerlnaus dem Boden schießen, regte sich letztes Jahr an zen-tralen Stellen (nämlich dem Zentralen Informatikdienstund der Zentralen Verwaltung) zusehends Unbehagenhinsichtlich der Webpräsenz der TU. Zwar war die TUschon früh online, seitdem wucherte die Site aber eher,anstatt planvoll zu wachsen. Selbst die vehementestenAnhängerInnen der Philatelie werden nicht bestreiten,dass Inhalt, Design und Technik der TU-Site nicht zeitge-mäß sind. Einige Problempunkte und Optionen:

Inhalt

Strukturell orientiert sich die TU-Site an der Auf-bauorganisation. Im Vordergrund stehen Informationenüber Institute, Einrichtungen, Personen usw. Noch nichtdurchgesetzt hat sich die Orientierung an den Bedürfnis-

sen unserer „KundInnen“. Künftig sollte die Fragestel-lung „Was können wir für wen tun?“ aus dem Schattender wenig nutzenstiftenden Abbildung der Hierarchie tre-ten. Außerdem würde sich das Medium hervorragend an-bieten, die interne Kommunikation durch mehr aktuellenContent anzukurbeln.

Design

Die „Trademark“ der Briefmarken klang bereits an.Wiewohl sie uns gute Dienste geleistet haben, kann – beialler Liebe zur Kontinuität – dies nicht für alle Zeiten dieoptische Repräsentanz sein. Zwar entwickelt sich einCorporate Design (CD) an der TU – bösen Gerüchten zu-folge – immer nur dann, wenn ein Architekt Rektor ist.Trotzdem sollten die wenigen Versatzstücke eines TU-CD´s (Logo, Farbe, ...) durchgängig Niederschlag in denWebseiten finden. Andernfalls ist ein Wiedererkennungs-effekt schwer zu realisieren.

Technik

Die Palette an EDV ist an der TU denkbar breit. AllePlattformen und Clients sind vertreten. Das macht es perse nicht einfacher, funktionale Elemente zu implemen-tieren. Proprietäre Lösungen sind verpönt. Allein dieVielfalt der datenbankgetriebenen Web-Infosysteme ander TU ist beeindruckend. Um nur die wichtigsten zunennen:

• Zentrale Verwaltung: TUWIS, HISTU• ZID: White Pages• Außeninstitut: Forschungsdokumentation• Bibliothek: Aleph 500• )|(unikat: Lehrzielkatalog, Wegweiser


Diese – gut gemeinte, aber wenig reflektierte und ko-ordinierte – Entwicklung führt zu Redundanzen und In-konsistenzen. Freilich wäre es unvertretbar, all dieseetablierten Systeme über Bord zu werfen und den großenWurf in Angriff zu nehmen. Auch ein Warten auf einenevolutionären Bereinigungsprozess erscheint nicht ange-bracht. Allerdings würde das Fokussieren auf EINE Dar-stellung nach außen den UserInnen wohl einiges anVerwirrung ersparen.

Von www.bhutan.at lernen

Jüngst heimste das Institut für Softwaretechnik eineninternationalen Preis für die Site www.bhutan.at ein. Einekomplexe Site mit allem, was das SurferInnen-Herz hö-her schlagen lässt. Gut zu wissen, dass „wir“ das können.

Wiewohl sich aus den Ergebnissen des Wettbewerbswohl kein neues Look-And-Feel für die TU-Site auf-

drängt, werden wir an der Implementierung weiterarbei-ten. Die Verwendung eines Content Management Sys-tems (CMS), was ein schnelles „Befüllen“ der Site mitaktuellen Inhalten ermöglichen soll, ist ebenso fix einge-plant wie effektivere Suchmöglichkeiten.

Es stünde der Technischen Universität gut zu Gesicht,eine Website auf der Höhe der Zeit zu haben. Bleibt zuhoffen, dass die bisherigen Bemühungen von Erfolg ge-krönt sind. Das kann aber nur funktionieren, wenn wirbeim „Bauen“ von Websites dieselben Maßstäbe zur An-wendung bringen, wie wir das beim Bauen von Häuserngewohnheitsmäßig tun. Schließlich gibt es an der TU nicht„nur“ ArchitektInnen, sondern auch InformatikerInnen.

Allerdings handelt es sich auch um eine Glaubensfrage.Glauben wir daran, dass sich ein professionellerer Web-auftritt amortisiert, weil „bessere“ StudentInnen zu unskommen, weil potentere Wirtschaftspartner mit uns ko-operieren und weil wir uns selbst Zeit und Ärger sparen?


„Gestern“ ...

... „Heute“ ...

... „Morgen“

Aufbau eines geschütztenSubnetzes im TUNETWerner Scholz, Thomas Schrefl und Josef FidlerInstitut für Angewandte und Technische [email protected], [email protected], [email protected]

http://magnet.atp.tuwien.ac.at/

Die Vergrößerung der Arbeitsgruppe und besondere Anforderungen an die Netzwerk-Infrastrukturhaben uns veranlasst, ein geschütztes Subnetz innerhalb des TUNET aufzubauen. Über die dabeigemachten Erfahrungen soll im Folgenden berichtet werden.

1 Motivation

Im Lauf der letzten Jahre hat sich die Arbeitsgruppevon Prof. Fidler und Doz. Schrefl kontinuierlich vergrö-ßert. Mittlerweile ist sie auf knapp ein Dutzend Mitarbei-ter und rund 20 Computer (Arbeitsplatz-Rechner undHochleistungs-Workstations) angewachsen.

Damit ist auch der Aufwand für Wartung und Admi-nistration gewachsen, ohne jedoch eine grundlegendeVerbesserung z.B. auf dem Gebiet der Datensicherheit zubringen. Die Umstellung auf twisted-pair-Verkabelungund die Erneuerung einiger Computer machte ein grund-sätzlich neues Konzept notwendig.

Die wichtigsten Aspekte bei der Planung der neuenNetzwerk-Lösung waren Einbruchsicherheit, Datensicher-heit und optimale Ausnützung der Netzwerk und Rechen-kapazitäten bei vereinfachter Administration.

Einbruchsicherheit sollte vor Angriffen von Hackernaus dem Internet bewahren und damit vor den leidvollenErfahrungen, die andere Institute bereits machen mussten.Datensicherheit bedeutet für uns nicht nur Schutz vor Da-tenverlust, sondern auch einen vereinfachten Zugriff aufdie Daten innerhalb des heterogenen Netzwerks. Die vor-handenen und neu anzuschaffenden Rechner sollten dabeioptimal ausgenützt werden und ein leistungsfähiges Um-feld zur Durchführung der mikromagnetischen Simulatio-nen bereitstellen [1].

Wie sind die einzelnen Anforderungen zu erreichen?Wir wollen (und können) nicht alle Möglichkeiten aufzei-gen und vergleichen, sondern beschränken uns auf dieBeschreibung der Lösung, die wir für unsere Arbeits-gruppe gefunden haben.

Von Anfang an war klar, dass die Einbruchsicherheitnur durch eine Firewall-Lösung gewährleistet werdenkann. Dazu ist es notwendig, das Netzwerk so aufzubau-en, dass es genau eine Verbindung zwischen unseremSubnetz und dem Rest des TUNET gibt. Dazu kann manentweder ein „virtuelles LAN“ einrichten oder die Netzeeinfach physisch trennen. An die Schnittstelle der beidenNetze wird die Firewall gesetzt, die die Verbindung zwi-schen den beiden herstellt.

Datensicherheit wollten wir durch einen zentralenFileserver erreichen. Über NFS können Unix und LinuxClients auf die Daten zugreifen, während Windows PCsüber Samba [2] die zentralen Daten erreichen. Dadurchmüssen sich die Benutzer nicht mehr mit „verteilten“ Da-ten auf einer Vielzahl von Rechnern herumschlagen, son-dern haben alles an einem Ort vereint und können dochvon allen Rechnern darauf zugreifen. Außerdem werdenregelmäßige zentrale Backups möglich, die alle wichtigenDaten sichern.

Trotz der „bunten“ Mischung aus DEC Alpha Work-stations, Linux/Alpha Workstations, Linux/Intel PCs undWindows PCs, wollten wir möglichst viele Verwaltungs-aufgaben zentral auf einem Server erledigen und dieClients mit einer einfachen „Standardinstallation“ insNetz einbinden. Vor allem die Benutzer- und Ressour-cenverwaltung sollten zentral erfolgen. Für die Benutzer-verwaltung bietet sich unter Unix/Linux NIS/yellowpages an, das eine zentrale Verwaltung ermöglicht undden Benutzern erlaubt, sich am nächsten freien Rechneranzumelden und die gewohnte Umgebung mit allen per-sönlichen Einstellungen vorzufinden. Ressourcenverwal-tung bedeutet für uns die Verteilung der Computer-simulationen auf die verschiedenen Rechner. Ein zentra-les Queueing-System für Batch-Jobs sollte diese Anfor-derung auch in einer heterogenen Netzlandschaft erfüllen.


Letzteres ist auch das eigentliche Ziel unseres Ent-wurfs: Der Aufbau eines leistungsfähigen Netzwerks fürCPU- und speicher-intensive Computersimulationen.Beim Entwurf hat uns Dr. Robert Lorenz (Institut fürMaterialphysik der Universität Wien) mit seiner langjäh-rigen Erfahrung ausgezeichnet beraten. Die Firma init.at[3] hat die neuen Maschinen vorinstalliert geliefert undkonfiguriert. Wartungsverträge sichern uns dabei den rei-bungslosen Betrieb und entlasten uns von Fehlersucheund Problembehebung. Das wichtigste Argument war(neben dem Preis) vor allem der Komfort, alles aus einerHand zu erhalten, und damit bei Problemen nur einenAnsprechpartner zu haben.

2 Entwurf

Zuerst stellte sich die Frage, ob wir weiterhin die In-frastruktur des TUNET benützen oder unser Subnetzauch physisch vom TUNET trennen. Da wir eine NFS-Anbindung der Clients (auf denen die Computersimula-tionen durchgeführt werden) an einen zentralen Fileserverplanten, war klar, dass die Verbindung der Rechner überdie Switches des ZID mit 10 MBit nicht ausreichen wür-de. Vor allem das letzte Teilstück zum Fileserver (auchwenn es mit 100 MBit angebunden würde) könnte zumFlaschenhals werden. Daher haben wir uns entschlossen,die Rechner mit eigenen Switches zu verbinden und phy-sisch vollkommen vom TUNET zu trennen. In Anbe-tracht der möglichen Netzwerkbelastung haben wir unsschließlich für eine 100 MBit full-duplex Anbindung derClients und ein 1 GBit full-duplex Netzwerkinterfacezum Fileserver entschieden.

Die physische Trennung vereinfacht auch den Einbaueiner Firewall, da man ohne Einrichtung eines „virtuellenLANs“ auskommt. Für Firewalls bieten sich verschiedeneLösungen an. Eine einfache und ausfallssichere Firewallwird vom ZID angeboten [4]. Wir haben uns für eine Lö-sung von init.at entschieden und damit alle neuen Geräteaus einer Hand. Diese Firewall erlaubt auch den Aufbaueines „virtual private network (VPN)“ und damit die Ein-bindung entfernter Rechner (auch außerhalb des TUNETz. B. über chello StudentConnect, Teleweb), für die einVLAN nicht mehr möglich ist (siehe Kap. 5.2). Außer-dem verstecken wir durch IP-Masquerading unser gesam-tes Subnetz hinter einer einzigen IP-Adresse. Dadurchhaben wir hinter der Firewall die Freiheit, in einemClass-C-Netz bis zu 254 IP-Adressen selbst zu vergeben.

Der Fileserver ist das „Herzstück“ unseres Subnetzes.Er sollte mehrere Aufgaben übernehmen:• Datenspeicherung, für die wir rund 200 GB vorgesehen

haben. Der Zugriff auf die Daten muss über NFS undSamba ermöglicht werden.

• Benutzerverwaltung und Authentifizierung mittels NIS/yellow pages.

• Nameserver für unser Subnetz• Master für das Queueing-System• zentrale Installation verschiedener Applikationen

Als Clients haben wir leistungsstarke PCs vorgesehen,die einerseits als Arbeitsplatzrechner dienen und gleich-zeitig im Hintergrund die Computersimulationen durch-führen. Dafür benötigen sie eine schnelle CPU undausreichend Hauptspeicher. Als Betriebssystem haben wiruns für Linux entschieden, da es• stabil genug ist, um eine gleichzeitige Nutzung der Com-

puter als Arbeitsplatzrechner und „Rechenknecht“ zu er-möglichen,

• die gewünschte Client/Server-Architektur optimal unter-stützt,

• von den von uns verwendeten Programmpaketen unter-stützt wird,

• ein ausgezeichnetes Preis/Leistungsverhältnis hat• und wir das Know-how haben, um die notwendigen Ad-

ministrationsaufgaben selbst zu erledigen.

3 Implementierung

Bevor wir uns an die Umsetzung unserer Pläne mach-ten, besprachen wir sie noch ausführlich mit dem ZID.Dabei wurde uns erlaubt, die bestehende twisted-pair-Verkabelung zu benützen und an unseren eigenen Switch,der in das Rack des ZID eingebaut wurde, anzuschließen.

3.1 Das Netzwerk

In Abbildung 1 ist die Struktur unseres Netzwerksskizziert. Die Firewall stellt die Verbindung zwischendem TUNET und dem internen Subnetz über Switch 2her. An Switch 2 sind einige Simulationsrechner (Linux/Alphas) mit 100 MB und der Fileserver mit 1 GB ange-schlossen. Eine zweite Glasfaserleitung stellt die Verbin-dung zu Switch 1 her, an den die bestehende twisted-pairVerkabelung mit den Arbeitsplatzrechnern angeschlossenist. Der Mail- und Webserver ist außerhalb unseres Sub-netzes direkt an das TUNET angeschlossen.


Switch 1

Arbeitsraum 1 Arbeitsraum 2

Switch 2

Serverraum

Fileserver

Linux/Alphas

Firewall

Mail-, Webserver

TUNET

100 Mb pro Maschine100 Mb pro PC

100 Mb100 Mb

10 Mb

1 Gb 1 Gb

100 Mb pro PC

Abbildung 1

3.2 Die Switches

Da unsere Server in einem anderen Raum stehen alsdas Rack, in dem die twisted-pair-Kabel der Arbeitsplätzezusammenlaufen, mussten wir zwei Switches (hp procur-ve 2512 und 2324) kaufen und mittels Glasfaserstrecke(1 GBit) verbinden. Die Anschlüsse der Arbeitsplätzewurden einfach von den Switches des ZID auf unserenverlegt, sodass wir hier eine „saubere“ physikalischeTrennung des TUNET von unserem Subnetz erreichen.Solange das private Netz relativ klein und überschaubarist und damit keine spezielle Konfiguration (VLANs etc.)erfordert, kann auf Management- und Fernwartungsfähig-keiten (SNMP) der Switches verzichtet werden. Demzweiten (zentralen) Switch, an den die Firewall und derFileserver angeschlossen sind, haben wir diese Fähigkei-ten spendiert, um einfachere Möglichkeiten zur Fehlerdi-agnose zu haben. Unbedingt notwendig ist SNMP füruns, wie sich gezeigt hat, jedoch nicht.

3.3 Der Fileserver

Wir haben einen Dual Pentium III 733 MHz mit256 MB ECC RAM ausgewählt, der unter SuSE Li-nux 7.0 [5] betrieben wird. Die geforderte Datensicher-heit wird dabei durch mehrere Maßnahmen erreicht: EinHardware-RAID-Controller verbindet 4 SCSI Festplattenzu einem RAID Level 5 System mit einer Kapazität von80 GB, auf dem das Betriebssystem und die Home-Ver-zeichnisse der Benutzer abgelegt sind. Der Einsatz des„journaling filesystem“ „ReiserFS“ [6] beschleunigt dieRekonstruktion des Filesystems in einen konsistenten Zu-stand auch bei Absturz des Fileservers. Zwei große IDE-Festplatten werden als Software-RAID mit einer Kapazi-tät von 110 GB ebenfalls unter ReiserFS betrieben.

Zur Datensicherung haben wir einen Sony TDL-11000Bandwechsler für 8 Backup-Bänder mit einem eingebau-ten SDL-11000 DDS4 Bandlaufwerk, das komprimiertbis zu 40 GB pro Band speichern kann. Ein Bandwechs-ler ist zwar eine teure aber sehr komfortable Investition,die durch vollautomatische tägliche Backups die Datensi-cherheit garantiert.

3.4 Die Clients

3.4.1 Reine Arbeitsplatzrechner

Die vorhandenen Arbeitsplatzrechner wurden natürlichan die neue Infrastruktur angeschlossen und profitierenvon der schnellen 100 MB full-duplex Anbindung, soferndie jeweilige Netzwerkkarte das unterstützt.

3.4.2 Kombinierte Arbeitsplatz/Simulationsrechner

Fünf neue Athlon PCs mit 900 MHz und 512 MBRAM wurden als Arbeitsplatzrechner, die gleichzeitig imHintergrund Simulationen durchführen, angeschafft unddie Linux-Distribution von RedHat [7] in der Version 6.2installiert. Schnelle 100 MB Netzwerkkarten und schnelleIDE-Festplatten, die im UDMA-Modus betrieben werden,erlauben diesen kombinierten Betrieb. Solange derHauptspeicher ausreicht, ist kaum zu merken, dass dieCPU im Hintergrund mit einer Simulation beschäftigt ist.

Erst wenn auf den virtuellen Speicher auf der Festplatteausgelagert wird, ist ein Performance-Einbruch spürbar.

3.4.3 Simulationsrechner

Sechs Alpha-Clones (Alpha EV56 Prozessoren mit533 MHz auf AlphaPC 164 LX und SX Boards) wurdenebenfalls in unser Netzwerk eingebunden. Da wir mitRedHat 5.2 (Linux Kernel 2.0.25), das bisher installiertwar, immer wieder Probleme mit NFS hatten, wurde einUpdate auf RedHat 6.2 durchgeführt. Der Standard-Ker-nel wurde auch hier durch einen selbst kompilierten(2.2.18) ersetzt.

Außerdem wurde ein Hochleistungsrechner (UP2000:2x Alpha EV67 666 MHz mit 1 GB ECC RAM auf ei-nem AlphaPC 264 DP Board mit Tsunami Chipsatz [8])gekauft, um besonders große Probleme rechnen zu kön-nen. Als Betriebssystem kommt wieder SuSE 7.0 mitselbstkompiliertem Kernel 2.2.17 SMP zum Einsatz.

4 Konfiguration und Administration

4.1 Netzwerkkonfiguration

Da wir so eine „saubere“ Trennung unseres Subnetzesvom TUNET vorgesehen hatten, wurden unserer Plänevom ZID ohne Änderungen akzeptiert. Bei der Bespre-chung wurden im Wesentlichen nur die IP-Adresse derexternen Netzwerkkarte unserer Firewall im TUNET undder Adressraum unseres Subnetzes festgelegt. Dabei wur-de uns das Class-C-Netz 192.168.45.0/24 mit 254 freienIP-Adressen zugewiesen. Da auch Class-C-Adressen in-nerhalb des TUNET voll geroutet werden (!), ist eine ent-sprechende Koordinierung unbedingt notwendig. Dies istvor allem im Falle eines „Lecks“ der Firewall, bei deminterne Pakte nach außen gelangen, wichtig, um den Ur-heber schnell ausfindig machen zu können.

Durch die Aktivierung der Firewall mit IP-Masquera-ding sind natürlich einige Rechner aus dem TUNET„verschwunden“, sodass wir sie in der TUNET-Daten-bank [9] abmelden und die entsprechenden IP-Adressenfreigeben konnten. In unserem Subnetz 128.130.45.0wäre es gar nicht mehr möglich gewesen, alle neuenRechner anzumelden, da der freie Adressraum bereitsausgeschöpft ist.

Will man sich die Administration von IP-Adressen er-sparen, so kann man auch einen DHCP-Server installie-ren. Den Clients wird dann beim Booten automatischeine IP-Adresse vom Server zugewiesen. Meist gibt esaber einige Geräte, die diese Funktionalität nicht unter-stützen, und denen ohnedies eine IP-Adresse fix zugewie-sen werden muss. Den wichtigen Servern werden auchmeist fixe Adressen zugewiesen. Daher haben wir uns ent-schlossen, gleich alle IP-Adressen händisch zu vergeben.

Die Konfiguration der Firewall und des Fileserverswurde von init.at durchgeführt. Diese beiden Rechnerübernehmen mehrere (zentrale) Funktionen in unseremNetzwerk und sollen daher im Folgenden näher beschrie-ben werden.


4.2 Firewall-Konfiguration

Die Firewall ist ein einfacher PC (Intel Celeron633 MHz mit 64 MB RAM und 10 GB Festplatte), dermit einer von init.at modifizierten Linux-Distribution vonDebian läuft. Eine einzige Datei enthält alle Informatio-nen und Regeln zur Konfiguration der Firewall.

Die Firewall ist damit genauso sicher und unsicherwie der Linux-Kernel, der darauf läuft, aber sie ist füruns ein großer Fortschritt im Vergleich zur früheren Si-tuation, als alle Rechner „direkt“ von der ganzen Weltaus erreichbar waren und damit ein potentielles Ziel fürAngriffe aller Art.

Auch eine Sicherheitsüberprüfung durch den ZID [10],die die gängigsten Sicherheitsmängel aufdecken kann, hatuns diesbezüglich beruhigt.

Von außen ist (im Prinzip) ein einziger Port erreich-bar, damit wir uns überhaupt in unser Netz einloggenkönnen (siehe Kap. 5.1). Auch der Zugriff von innennach außen ist auf die notwendigen Dienste (z. B. telnet,ftp, ssh, http, https, news, ntp, pop2, pop3, smtp, domain,ping, finger etc.) eingeschränkt.

Auf der Firewall laufen aus Sicherheitsgründen keineweiteren Dienste wie WWW-Proxies, E-Mail-Server,WWW-Server oder Ähnliches. Diese laufen alle auf an-deren Maschinen. Öffentlich zugängliche Dienste wieWWW-Server oder E-Mail-Server kann man in einer„DMZ“ (demilitarized zone), die zwar durch die Firewallüberwacht wird, in der aber bestimmte Dienste von außenzugänglich sind, unterbringen. Wir haben vorerst daraufverzichtet und den E-Mail- und WWW-Server der Ar-beitsgruppe in die „freie Wildbahn“ gestellt, können aberbei Bedarf jederzeit eine DMZ einrichten.

4.3 Netzwerkoptimierung

Die Firewall erfüllt auch noch einen zweiten Zweck:Sie hält unerwünschten Netzwerkverkehr fern und entlas-tet damit die Anbindung unserer Arbeitsplatzrechner.Beispielsweise die „Fluten“ an Broadcast-Messages, diesich bei jedem Öffnen der Netzwerkumgebung auf einemWindows-PC ins Netz ergießen, werden von der Firewallgefiltert und nicht nach innen weitergeleitet. Natürlichsind unsere Windows-PCs damit von außen nicht mehrsichtbar, aber erstens liegen unsere wichtigen Daten oh-nedies nur noch am Fileserver und zweitens soll auchsonst niemand auf unsere Windows-PCs zugreifen. (Wiewir von außen auf unsere Daten zugreifen können, ist inKap. 5.1 beschrieben.)

Da wir mit unseren eigenen Switches alle Rechner mit100 MB full-duplex anschließen können, wurde bei jenenRechnern, die das nicht automatisch mit dem Switch„ausgehandelt“ haben, händisch nachgeholfen. Sehr hilf-reich waren dabei die LEDs auf unseren Switches, diedie eingestellte Geschwindigkeit für jeden Port anzeigen.Natürlich haben wir auch ein paar ältere Modelle, die nur10 MBit unterstützen, wobei diese alle im half-duplexModus betrieben werden. Die Umstellung einer DECAlphaStation in den 10 MBit full-duplex Modus, der

theoretisch von unseren Switches unterstützt wird, warbeispielsweise nicht möglich.

Schließlich haben wir auch den Netzwerk-Verkehr,der durch NFS-Verbindungen erzeugt wird, reduziert, in-dem wir „automount“ verwenden. Dazu mehr in Kapi-tel 4.4.3 über unsere NFS Konfiguration.

4.4 Fileserver-Konfiguration

Der Fileserver spielt eine zentrale Rolle in unseremSubnetz. Daher haben wir für ihn auch einen Wartungs-vertrag abgeschlossen. Natürlich ist es gefährlich, einereinzigen Maschine alle im Folgenden beschriebenen Auf-gaben zu übertragen, für uns hat es aber mehrere Vortei-le. Erstens haben wir die Maschine fertig konfiguriertgekauft und mit dem Wartungsvertrag dem Lieferantendie Verantwortung für den reibungslosen Betrieb übertra-gen. Zweitens sind fast alle diese Dienste notwendig, umüberhaupt in unserem Netz arbeiten zu können. Würdenwir diese Dienste einer anderen Maschine übertragen,müssten wir für diese ebenfalls einen Wartungsvertragabschließen. Dies kommt wieder nur bei einem neuenGerät in Frage, was weitere Investitionen notwendig ge-macht hätte. Schließlich war es unser Ziel, die Daten nurnoch zentral am Fileserver abzulegen. Sollte dieser aus-fallen, können wir ohnedies nicht auf unsere Daten zu-greifen und sind in unserer Arbeit stark behindert, sodasser möglichst schnell wieder in Betrieb genommen werdenmuss.

4.4.1 NIS/yellow pages

Die zentrale Verwaltung der Benutzeraccounts erfolgtam Fileserver. Dieser stellt über NIS/yellow pages allenClients die Benutzerdaten zur Verfügung. Ein neuer Be-nutzer muss damit nur ein Mal am Fileserver angelegtwerden und kann sich sofort auf jedem beliebigen Unix/Linux-Rechner anmelden. Die home-Verzeichnisse liegennatürlich auch am Fileserver und werden über NFS ex-portiert, sodass jeder Benutzer seine gewohnte Umge-bung und seine persönlichen Einstellungen vorfindet,egal an welchem Rechner er arbeitet. Dies funktioniertbei uns sogar im Mischbetrieb von Athlons und Alphasunter RedHat und SuSE Linux und einer DEC AlphaSta-tion, die unter Compaq Tru64 4.0F läuft, reibungslos.

Wenn man viele Windows NT Rechner in einem hete-rogenen Netz mit Unix/Linux Rechnern zu administrierenhat, lohnt es sich sicher, diese in die zentrale Benutzerau-thentifizierung über NIS/yellow pages einzubinden. Dieskonnte bei uns unterbleiben und unter Windows 95 undWindows 98 kann sich ohnedies „jeder selbst“ seinen Be-nutzeraccount anlegen, wobei es jedoch vorteilhaft ist,die selben Usernamen zu verwenden (siehe Kap. 4.4.4).

4.4.2 DNS

Der Fileserver hat bei uns auch die Aufgaben einesNameservers für die internen IP-Adressen übernommen.Dieser Dienst könnte noch durch einen zweiten Nameser-ver abgesichert werden. Diese Sicherheit bietet uns aberauch die Verteilung der IP-Adressen und Namen in stati-schen „hosts“-Dateien. Bei der Größe unseres Subnetzes


ist die Verwaltung dieser statischen Tabellen noch mög-lich und es reduziert nebenbei wieder den Netzwerkver-kehr durch Einsparung von Anfragen an den Nameserver.

4.4.3 NFS

Die wichtigsten Verzeichnisse werden über NFS ex-portiert und so den Unix/Linux Clients zur Verfügunggestellt. Mit der 2.2.x Serie des Linux-Kernels wurde dieNFS-Implementierung stark verbessert und hat sich alssehr stabil und zuverlässig erwiesen. Da NFS-Verbindun-gen auch dann (geringen) Netzwerkverkehr erzeugen,wenn keine Daten übertragen werden, wird auf allenClients „automount“ verwendet. Dabei laufen auf denUnix/Linux-Clients Dämonen im Hintergrund, die erstdann eine NFS-Verbindung herstellen (das gewünschteVerzeichnis mounten), wenn ein Zugriff darauf erfolgt.Nach einer (konfigurierbaren) Zeitspanne, in der keineDaten übertragen wurden, wird die Verbindung automa-tisch wieder abgebaut (umount des jeweiligen Verzeich-nisses).

Auch die meisten Anwendungen haben wir nicht aufden Clients, sondern nur zentral am Fileserver installiert(siehe Kap. 4.4.6). Dies vereinfacht und verkürzt die In-stallation enorm.

NFS Dienste sind ein beliebtes Ziel für Angriffe. Un-sere Firewall schützt uns vor derartigen Gefahren, daNFS-Verbindungen über die Firewall (in beiden Richtun-gen) unterbunden sind. Welche Probleme das (und dieVerwendung von IP-Masquerading) mit sich bringt, ist inKap. 5.6 beschrieben.

4.4.4 Samba

Damit auch Windows-PCs von der zentralen Speiche-rung der Daten profitieren, wurde am Fileserver ein Sam-ba-Server installiert [2]. Bei der Einrichtung eines neuenBenutzers wird auch gleich ein Samba-User angelegt undein entsprechendes Passwort festgelegt.

In unserem Netzwerk hat damit jeder Benutzer nurzwei Accounts und zwei Passworte, die aber problemlosident gewählt werden können: Ein Unix/Linux-Accountmit Passwort, mit dem er sich auf den Unix/Linux-Rech-nern authentifiziert, und ein Benutzername mit entspre-chendem Passwort für den Zugriff auf den Fileserverüber Samba. Werden der Benutzername und das Passwortauf den Windows-Rechnern ident mit jenen für den Sam-ba-Zugriff gewählt, erhält der Benutzer nach erfolgterAnmeldung an einem Windows-PC ohne weitere Pass-worteingabe Zugriff auf seine Daten am Fileserver. Da-mit die Samba-Passworte nicht im Klartext übertragenwerden, muss unter Windows die Übertragung unver-schlüsselter Passworte deaktiviert sein. Bei Windows 95erfolgt dies mit einem Patch von Microsoft, bei Win-dows 98 und Windows NT 4.0 ab SP3 werden die Pass-worte standardmäßig nur verschlüsselt übertragen [11].Letzteres kann durch einen Registry-Eintrag wieder auf-gehoben werden, ist aber natürlich nicht zu empfehlen.

Für Windows-Rechner sind vier Samba-Shares einge-richtet. Unter [home] finden unsere Benutzer alle home-

Verzeichnisse, von denen täglich ein Backup gezogenwird, wobei sie nur im eigenen Verzeichnis Schreibrechtehaben. Unter [scr] erhält jeder Benutzer Schreib- und Le-sezugriff auf seine Daten im Scratch-Bereich des Fileser-vers und Lesezugriff auf die Daten aller anderen.Zusätzlich wurde [groups] eingerichtet, das zwar physi-kalisch im Home-Directory des Fileservers liegt, jedochmit speziellen Optionen in der Samba-Konfiguration ver-sehen wurde. Diese führen dazu, dass die Dateien undVerzeichnisse, die unter Windows unter [groups] erstelltwerden, von allen Benutzern gelesen und beschrieben/modifiziert/gelöscht werden können. Damit wird unterWindows der gemeinsame Zugriff auf bestimmte Datenund beispielsweise das Erstellen und Bearbeiten von Do-kumenten in der Gruppe vereinfacht. Schließlich gibt esnoch einen [temp] Bereich (der physikalisch auf derScratch-Partition am Fileserver liegt), in dem ebenfallsjeder alle Rechte hat.

4.4.5 DQS

Als Queueing-System, das die Jobs automatisch an dieverfügbaren Rechner verteilt, verwenden wir DQS [12] inder Version 3.3.2. Wir haben in unserem Netz zwei bi-när-inkompatible Architekturen, nämlich Intel-kompatibleRechner (AMD Athlons) und Alphas. Diese haben wirtrotzdem in einem Queueing-System zusammengefasstund verwalten dieses mit nur einem „Queue-Master“.Dieser läuft am Fileserver und überwacht die einzelnenQueues und verteilt die Jobs.

DQS ermöglicht die Konfiguration mehrerer Zellen,die von mehreren Queue-Mastern verwaltet werden. DieTrennung der beiden Architekturen erfolgt aber einfacherdurch die Definition von sog. „complexes“. Diese sindim Wesentlichen Schlüsselworte, die bei verschiedenenQueues, die aus bestimmten Gründen zusammengefasstwerden sollen, definiert sind. In unserem Fall wurde fürdie Intel-kompatiblen Rechner das Schlüsselwort „intel“definiert und den Queues der entsprechenden Rechner zu-geordnet. Analog erhielten die sechs Queues der Alpha-Clones das Schlüsselwort „alpha“. Zusätzlich wurdendiese „complexes“ als „required“ konfiguriert, sodass derBenutzer beim Abschicken seines Jobs eines der beidenSchlüsselworte angeben muss. Damit ist der Benutzer ge-zwungen, sich für eine Architektur zu entscheiden, undes kann nicht vorkommen, dass ein Job unvorhergesehenauf der falschen Architektur (erfolglos) zur Ausführungkommt.

Spezielle Rechner, die für bestimmte Aufgaben reser-viert sind, wurden nicht in obiges Schema aufgenommen,sondern wurden im „complex“ „reserved“ zusammenge-fasst. Dazu gehören unsere DEC AlphaStation, die haupt-sächlich zum Kompilieren verwendet wird, die UP2000,die für besonders große Probleme verwendet wird, oderder Fileserver, auf dem keine Simulationen ausgeführtwerden, sondern der z. B. große Datenmengen in einemBatch-Job komprimieren kann. Letzteres ist natürlichdoppelt sinnvoll, da die Daten dann nicht zweimal überdas Netz laufen, sondern direkt am Fileserver kompri-miert werden.


4.4.6 Anwendungen

Alle Anwendungen, die zusätzlich zur RedHat-Stan-dardinstallation benötigt werden, werden ebenfalls zentralam Fileserver installiert.

Unsere Strategie soll am Beispiel des wissenschaftli-chen 2D-Plotprogramms Grace [13] demonstriert werden:

Nach dem Kompilieren des Quellcodes oder dem Aus-packen aus dem tar.gz- oder RPM-Archiv wird auf derPartition „/pd“ des Fileservers ein Unterverzeichnis„grace-5.1.3“ angelegt. Darin werden die Unterverzeich-nisse „bin“, „doc“, „include“, „lib“ etc. angelegt und dienotwendigen Dateien in das entsprechende Unterver-zeichnis kopiert. (Wenn man den Quellcode selbst kom-piliert, kann man als Option für „configure“ oder im„Makefile“ das gewünschte Installationsverzeichnis meistfrei wählen. In unserem Fall wäre dies „/pd/grace-5.1.3“.)Um die Installation späterer Updates zu erleichtern, wirdnoch ein symbolischer Link, der nur den Namen, aberkeine Versionsnummer enthält, auf das aktuelle Installa-tionsverzeichnis angelegt: „ln -s /pd/grace-5.1.3 /pd/grace“. Zuletzt wird die Anwendung in „/usr/local“ in-stalliert, indem symbolische Links auf die entsprechen-den Dateien angelegt werden: z. B. „ln -s /pd/grace/bin/grace /usr/local/bin/grace“.

Die Verzeichnisse „/pd“ und „/usr/local“ werden vomFileserver mit NFS exportiert und von allen (Intel-kom-patiblen) Clients gemountet. Die Umgebungsvariable„$PATH“ muss natürlich den Pfad „/usr/local/bin“ ent-halten und der dynamische Linker für „shared libraries“auch den Pfad „/usr/local/lib“ berücksichtigen (in „/etc/ld.so.conf“).

Die beschriebene Strategie hat mehrere Vorteile:

a) Anwendungen müssen nur ein Mal am Fileserver in-stalliert werden und stehen danach sofort allen Clientszur Verfügung.

b) Saubere Trennung von Standardinstallation und selbstinstallierten Anwendungen.

c) Dadurch einfache Installation und Einbindung neuerClients bzw. Neuinstallation oder Update des Betriebs-systems der Clients, da nur eine Standardinstallationmit „ein bisschen“ Anpassung der Konfiguration not-wendig ist.

d) Einfaches Update der Anwendungen durch Installationin ein neues Verzeichnis und Umsetzen des symboli-schen Links (z. B. „/pd/grace -> /pd/grace-5.1.4“).

e) Schneller Überblick über alle installierten Anwendun-gen durch ein zentrales Verzeichnis („/pd“).

4.4.7 Beowulf Tools

Wie lässt sich nun die Konfiguration und Administra-tion vieler gleichartiger Clients am einfachsten bewerk-stelligen?

Im Rahmen des Beowulf-Projekts [14] wurden einigeWerkzeuge entwickelt, die diese Aufgaben wesentlichvereinfachen. Wir verwenden vor allem „brsh“ [15], die

„Beowulf remote shell“, die wir zu einer „bssh“, „Beo-wulf secure shell“, umgeschrieben haben. Damit lässtsich der Reihe nach auf allen gewünschten Maschinenein Kommandozeilenbefehl ausführen, ohne sich auf je-der Maschine einzeln einzuloggen und den Befehl aus-führen zu müssen.

Die Clients müssen auf diese Art des Zugriffs vorbe-reitet sein, indem eine entsprechende „.rlogin“-Datei imHome-Verzeichnis von root angelegt wird, oder der öf-fentliche Schlüssel des Benutzers, der bssh aufruft, den„authorized_keys“ der Clients hinzugefügt wird. „brsh“ist nur ein einfaches Shell-Skript, das sich mittels rshoder ssh auf jeder Maschine einloggt, den gewünschtenBefehl ausführt und die Verbindung wieder beendet, ehemit der nächsten Maschine fortgesetzt wird.

Die Konfiguration und Administration der Clients be-steht meist in einem Editieren entsprechender Dateien.Von den Konfigurationsdateien (z. B. /etc/bashrc) habenwir beispielsweise eine Kopie auf dem Fileserver (z. B./pd/Athlon.config/etc/bashrc). Ist nun eine Änderungnotwendig, so wird die gewünschte Datei am Fileservereditiert und mit dem einfachen Befehl „bssh cp /pd/Athlon.config/etc/bashrc /etc/“ auf alle Clients kopiert.

Damit lässt sich ein Großteil der Administrationsauf-gaben für alle Clients „gleichzeitig“ durchführen und derAufwand ist unabhängig (!) von der Anzahl der Clients.

Natürlich ist die beschriebene Konfiguration nur in ei-nem (von einer Firewall) geschützten Netzwerk empfeh-lenswert. Andernfalls wird es einem Angreifer sehr leichtgemacht, nach einer kompromittierten Maschine auchnoch die Kontrolle über alle anderen zu übernehmen.

5 Probleme und Lösungen

5.1 Zugriff von außen

Hat man einmal so ein durch eine Firewall gesichertesNetzwerk aufgebaut, so war man bestrebt, alle Lücken,durch die ein Einbrecher in das Netzwerk eindringenkann, zu schließen. Hat man es wirklich gründlich ge-macht, dann sollte man auch selbst nicht mehr von außenin sein Netzwerk hineingelangen. Da es aber meist docherwünscht ist, authorisierten Personen den Zugang zu er-möglichen, muss man wohl oder übel wieder einen Wegöffnen.

Dafür gibt es wieder mehrere Möglichkeiten, die starkvon den jeweiligen Erfordernissen abhängen. Auf keinenFall sollte man ein Login direkt auf der Firewall erlau-ben. Die Firewall sollte vielmehr die Verbindung auf einebestimmte Maschine im Netz weiterleiten (z. B. durchPort-Forwarding), die dann die Authentifizierung durch-führt. Es ist damit sehr einfach und auch sehr empfeh-lenswert, die Anmeldungen im Netz zu protokollierenund zu überwachen.

In jedem Fall sollten nur verschlüsselte Verbindungenzugelassen werden, da sonst die Gefahr, dass Passwortebelauscht (gesnifft) werden, zu groß ist. Heute ist dasStandardwerkzeug für verschlüsselte Verbindungen „ssh“


[16]. Im Gegensatz zu telnet, ftp und pop werden alleübertragenen Daten (vor allem auch die Passworte!) ver-schlüsselt. Damit wird die Übertragung vertraulicher Da-ten über ein unsicheres Netzwerk möglich. Natürlichmuss die Verbindung vom Anfang bis zum Ende ver-schlüsselt sein. Die in der Praxis immer wieder verwen-dete Methode „Ich-hab-auf-Rechner-A-gerade-kein-ssh-darum-log-ich-mich-auf-Rechner-B-mit-telnet-ein-und-mach-dann-ein-ssh-auf-Rechner-C“ führt natürlichalle Sicherheitsmaßnahmen ad absurdum, da die Verbin-dung von Rechner A zu Rechner B nicht verschlüsselt istund damit alle Informationen auf dieser Verbindungsstre-cke belauscht werden können. Um solchen Situationenvorzubeugen, sind Werkzeuge wie Mindterm’s Java-Im-plementierung eines ssh Clients [17] hilfreich, da, auchwenn kein ssh installiert ist, fast immer ein Webbrowsermit Java-Unterstützung zur Verfügung steht.

Es gibt mehrere (auch freie) Implementierungen desssh-Protokolls (z. B. OpenSSH [18]), und in den meistenLinux-Distributionen ist die eine oder andere enthalten.

Wie bereits erwähnt, ist auch ftp ein unsicheres Proto-koll, bei dem Passworte im Klartext übertragen werden,und damit relativ einfach belauscht werden können. AlsErsatz bietet sich „scp“, „secure copy“, an, das Dateienüber einen verschlüsselten Kanal kopieren kann. Es bietetdie selbe Sicherheit und die selben Authentifizierungsme-chanismen wie ssh und ist in den meisten ssh-Paketenenthalten.

Natürlich gibt es auch für Windows-Rechner entspre-chende Programme. Wir verwenden als ssh-Client fürWindows Putty [19] und als ftp-Ersatz WinSCP [20] oderden iXplorer [21]. Weitere Implementierungen auch fürandere Plattformen findet man im WWW [22].

Idealerweise sollten für die Anmeldung von außen an-dere Benutzernamen und Passworte verwendet werdenals innerhalb des geschützten Netzes. Diese sollten vomAdministrator vorgegeben und so gewählt sein, dass sienicht leicht erraten werden können. Es sollten keine „nor-malen“ Wörter sein, sondern auch Ziffern und Sonderzei-chen enthalten. Damit ist man beispielsweise vor „bruteforce“ Angriffen, die einfach ganze Wörterbücher durch-probieren, sicher. Eine regelmäßige Änderung der Pass-worte ist ein weiterer bedeutender Sicherheitsfaktor.

Will man trotzdem auch den unverschlüsselten Zugangermöglichen, so bietet sich beispielsweise telnet mit (ma-schinengenerierten) Einmal-Passworten an. Jeder Benut-zer kann dann eine Liste mit solchen Einmal-Passwortenanfordern, die innerhalb eines bestimmten Zeitraums gül-tig sind und nur einmal verwendet werden können.

5.2 VPN

Ist ein einfacher ssh/telnet-Zugang von außen, wie imvorigen Kapitel beschrieben, nicht ausreichend, so kanndurch „virtual private networking“ eine sichere, ver-schlüsselte Verbindung aufgebaut werden, die eine völligtransparente Einbindung in das lokale Subnetz ermög-licht. Beim Aufbau eines VPN wird eine verschlüsseltePunkt-zu-Punkt Verbindung hergestellt, die einen Client

über ein unsicheres (öffentliches) Netzwerk (z. B. demInternet) mit einem VPN-Server und dem angeschlosse-nen privaten Netz verbindet.

Wir verwenden VPN für Fernwartung und „Telewor-king“. Im ersteren Fall erleichtert ein VPN unserem Lie-feranten notwendige Konfigurations- und Administra-tionsarbeiten und damit die Erfüllung des Wartungsver-trags. Durch die Einrichtung eines VPN kann man auchvon zu Hause über Modem-Dialin oder Teleweb in unse-rem Subnetz arbeiten, als wäre man direkt angeschlossen.Damit ist beispielsweise der direkte Zugriff auf unserenFileserver möglich.

In welcher Form VPN unterstützt wird, hängt von derFirewall und dem VPN-Server ab, der verwendet wird.Will man Windows-Rechner über VPN einbinden, sokann man dazu den „Microsoft Windows VPN Adapter“verwenden [23]. Abhängig von der Windows-Versionwerden verschiedene Verschlüsselungsalgorithmen mitverschiedenen Schlüssellängen unterstützt.

5.3 E-Mail

Sind die Standardprotokolle SMTP (zum Versenden)und POP bzw. IMAP (zum Abholen von E-Mails) aufder Firewall freigegeben, so kann man mit entsprechen-den Client-Programmen ganz normal auf E-Mail-Serverzugreifen. Probleme ergeben sich, wenn innerhalb desSubnetzes ein E-Mail-Server läuft, der E-Mails über dieFirewall nach außen senden will. Dieser verwendet alsDomain des Absenders nämlich die interne, die ja will-kürlich gewählt wurde. Eine vom Benutzer „scholz“ amFileserver weggeschickte E-Mail wird in unserem Netzmit dem Absender „[email protected]“ versehen. Die Do-main des Absenders wird von den meisten E-Mail-Ser-vern auf ihre Gültigkeit überprüft. Da es die Domain„lan“ natürlich nicht als offiziell registrierte Domain gibt,wird die E-Mail abgelehnt und kann nicht zugestellt wer-den. Dieses Problem kann durch Domain-Masqueradingumgangen werden [24]. Dabei wird die Domain des Ab-senders ersetzt (sinnvollerweise durch den offiziellen E-Mail-Server der Benutzer), sodass die E-Mails erfolg-reich zugestellt werden können.

5.4 WWW

Beim Zugriff auf das World Wide Web ergibt sich einanderes Problem. Der Standard-Port für das http-Proto-koll ist der Port 80. Ist dieser auf der Firewall geöffnet,so kann man problemlos auf das WWW zugreifen. Doku-mente, die nur über eine verschlüsselte https-Verbindungerreicht werden können, erfordern das Öffnen desPort 443 für das https-Protokoll.

Zu allem Überfluss gibt es aber viele Dienste imWWW, die über andere Ports aufgerufen werden. Dazuzählen z. B. der Online-Katalog des Österreichischen Bi-bliothekenverbundes (Port 4505) [25], das „HypertextWebster Gateway at UCSD“ (Port 5141) [26] und derMirror von „Scientific Applications on Linux“ am Goo-die Domain Service der TU Wien (Port 8050) [27]. Dieentsprechenden Ports für die gewünschten Rechner ein-


zeln auf der Firewall freizugeben, ist natürlich nicht prak-tikabel.

Eine elegante Lösung ist die Installation eines Proxy-Servers außerhalb des privaten Subnetzes. Für diesenmuss nur ein bestimmter Port auf der Firewall geöffnetwerden. Alle Anfragen des WWW-Browsers werden anden Proxy geschickt, der sie seinerseits an die gewünsch-te Maschine und an den gewünschten Port weiterleitet.Squid [28] ist so ein Proxy-Server, der auch noch als Ca-che fungieren kann, und die Protokolle http, https und ftpunterstützt.

Ist ein Proxy für das http-Protokoll ausreichend, sokann man auch den „webwasher“ [29] einsetzen. Dieserwurde eigentlich zum Filtern von Web-Inhalten entwi-ckelt und kann mit oder ohne diese Funktionalität betrie-ben werden. Mit sehr feinen Einstellungsmöglichkeitenkann man definieren, welche Web-Inhalte nicht weiterge-leitet werden sollen (z. B. Werbebanner, bestimmteURLs, Scripts, Animationen) bzw. welche Informationenan die Webserver weitergeleitet werden sollen („referers“,„cookies“).

5.5 Lizenzserver

Ein weiterer Dienst, der bei der Konfiguration der Fi-rewall berücksichtigt werden muss, ist die Anforderungvon Lizenzen bei Lizenzservern außerhalb des Subnetzes.

Einige Anwendungsprogramme (z. B. AVS, Patran),die im Rahmen von Campusverträgen vom ZID zur Ver-fügung gestellt werden, fragen die Lizenzen bei einemzentralen Lizenzserver im ZID ab. Damit diese Abfragefunktioniert, müssen die entsprechenden Ports auf der Fi-rewall geöffnet werden. Dies ist kein Problem, solangedie Kommunikation über fest vorgegebene Ports läuft.Der oft verwendete Lizenzmanager FLEXlm [30] erlaubtdiese fixe Einstellung.

Trotzdem ist es uns passiert, dass AVS eines Tagesnicht mehr laufen wollte, da es keine Lizenz mehr erhielt.Patran hingegen funktionierte weiter klaglos. Was warpassiert? Eine Stromabschaltung im gesamten Freihausder TU und damit auch im ZID erforderte die Abschal-tung des Lizenzservers. Nach dem erneuten Hochfahrenwurden auch die Lizenzserver mit den vorgegebenenPorts neu gestartet. AVS und Patran verwenden zur Ab-frage der Lizenz aber nicht nur einen Port (der beiFLEXlm vorgegeben werden kann), sondern zwei. Derzweite hat sich bei Patran (zufällig?) nicht geändert, beiAVS aber sehr wohl, wie eine Analyse mit tcpdump [31]gezeigt hat. Nachdem der neue Port geöffnet war, konnteAVS auch wieder gestartet werden.

Auch wenn die Firewall sonst die problemloseste Ma-schine in unserem Subnetz ist, solche Schwierigkeitensind nur mit einiger Erfahrung (zu der vielleicht auchdieser Artikel ein wenig beitragen kann) und mit Hilfegeeigneter Tools (wie tcpdump) zu lösen.

5.6 Campus- und Plattform-Software

Die Verteilung von Campus-Software erfolgt zumeistauf zwei Arten:

Windows-Software wird über den swd-Server verteilt,indem man unter Windows das entsprechende Netzlauf-werk verbindet und dann Zugriff auf sämtliche lizenzierteSoftware hat. Da beim Verbinden des Netzlaufwerks eineBenutzer-Authentifizierung mit Name und Passwort er-forderlich ist, ist sichergestellt, dass nur autorisierte Per-sonen Zugriff haben. Damit das funktioniert, müssen aufder Firewall einfach die entsprechenden Ports für SMB/NetBIOS-Verbindungen geöffnet werden.

Unix-Software wird meist durch NFS-Export der Ver-zeichnisse auf den entsprechenden Servern zur Verfü-gung gestellt. Da eine Benutzerauthentifizierung fehlt,muss genau festgelegt werden, welche Rechner die Ver-zeichnisse mounten dürfen. Da sich alle unsere Rechnermittels Masquerading hinter der Firewall verstecken,müsste als berechtigter Rechner die Firewall in den ex-ports-Listen eingetragen werden. Damit kann aber nichtsichergestellt werden, dass nur berechtigte Maschinen dieNFS-Verzeichnisse mounten. Damit ist es auch nichtmehr möglich, etwa Betriebssystemdokumentation auf denInstallationsservern zu belassen und nur bei Bedarf mittelsautomount verfügbar zu machen. Da es für diese Proble-matik im Moment noch keine universelle Lösung gibt, istbei jedem Zugriff auf die gewünschte Software Rückspra-che mit den Verantwortlichen im ZID notwendig.

6 Zusammenfassung

Unser Netzwerk ist seit vier Monaten im Vollbetriebund hat unsere Erwartungen bestens erfüllt. Die Firewallund der Fileserver laufen seit Beginn ohne Absturz undauch die Arbeitsplatzrechner verrichten trotz der Doppel-belastung (die vorhandene Rechnerkapazität wird mittler-weile voll genützt) sehr stabil ihren Dienst. Durch diezentrale Speicherung ist die Organisation der Daten starkvereinfacht worden und die regelmäßigen Backups habendie Gefahr von Datenverlust minimiert. Auch das dritteZiel, die Einbruchsicherheit, haben wir durch die sehr re-striktiv konfigurierte Firewall erreicht. Dabei ist es natür-lich wichtig, regelmäßig die Sicherheitsbulletins zu lesen(z. B. [32], [33]) und notwendige Patches einzuspielen.Trotz einer starken Erweiterung der Rechnerkapazität hatsich der Administrationsaufwand vereinfacht und ein aus-gezeichnetes Umfeld für unsere wissenschaftliche Arbeitgeschaffen.

7 Referenzen

[1] W. Scholz, D. Suess, T. Schrefl, J. Fidler, „Micro-magnetic simulation of structure-property relationsin hard and soft magnets“, Computational MaterialsScience, 18 (2000) 1-6.


[2] samba - opening windows to a wider worldhttp://www.samba.org/http://at.samba.org/samba/samba.html

[3] init.at informationstechnologie GmbHhttp://www.init.at/

[4] W. Selos, „Eine einfache Firewall-Lösung“,ZIDline Nr. 4, Dezember 2000http://linux.tuwien.ac.at/Firewall.html

[5] SuSE Linux AGhttp://www.suse.de/Mirror: http://gd.tuwien.ac.at/linux/suse.com/

[6] Reiserfshttp://www.namesys.com/

[7] Red Hat, Inc.http://www.redhat.com/Mirror: http://gd.tuwien.ac.at/linux/redhat/

[8] API NetWorks Inc.http://www.alpha-processor.com/products/up2000-board.shtml

[9] TUNET-Datenbankhttp://nic.tuwien.ac.at/tunetdb/

[10] ZID / DI Udo Linauerhttp://www.zid.tuwien.ac.at/mitteilungsblatt/mb02-2001.html#4

[11] Microsoft Supporthttp://support.microsoft.com/support/kb/articles/q165/4/03.asphttp://support.microsoft.com/support/kb/articles/Q166/7/30.asp

[12] DQS - Distributed Queueing Systemhttp://www.scri.fsu.edu/~pasko/dqs.html

[13] Gracehttp://plasma-gate.weizmann.ac.il/Grace/

[14] The Beowulf Projecthttp://www.beowulf.org/http://buweb.parl.clemson.edu/software.html

[15] The Beowulf Undergroundhttp://buweb.parl.clemson.edu/http://buweb.parl.clemson.edu/software.html

[16] SSH Communications Securityhttp://www.ssh.fi/

[17] MindTerm - pure java ssh Clienthttp://www.mindbright.se/

[18] OpenSSHhttp://www.openssh.org/

[19] PuTTY: A Free Win32 Telnet/SSH Clienthttp://www.chiark.greenend.org.uk/~sgtatham/putty.html

[20] WinSCP - secure data transmissionhttp://winscp.vse.cz/

[21] Secure iXplorer - Windows Front End for PSCPhttp://www.i-tree.org/ixplorer.htm

[22] SSH Clients für andere Betriebssystemehttp://www.openssh.org/windows.htmlhttp://www.openssh.org/unix.htmlhttp://www.at.openbsd.org/openssh/java.htmlhttp://www.at.openbsd.org/openssh/palmos.htmlhttp://opensores.thebunker.net/pub/mirrors/ssh-faq/ssh-faq-2.html#ss2.1

[23] Virtual Private Networkinghttp://www.microsoft.com/technet/win2000/win2ksrv/reskit/intch09.asp

[24] sendmail.org - Masquerading and Relayinghttp://www.sendmail.org/m4/masquerading.html

[25] Online-Katalog des Österreichischen Bibliotheken-verbundeshttp://bvzr.bibvb.ac.at:4505/ALEPH

[26] Hypertext Webster Gateway at UCSDhttp://work.ucsd.edu:5141/cgi-bin/http_webster

[27] „Scientific Applications on Linux“ am GoodieDomain Service der TU Wienhttp://gd.tuwien.ac.at:8050/

[28] Squid Web Proxy Cachehttp://www.squid-cache.org/

[29] webwasher.comhttp://www.webwasher.com/

[30] GLOBEtrotter Softwarehttp://www.globetrotter.com/

[31] tcpdumpftp://ftp.ee.lbl.gov/tcpdump.tar.Z

[32] CERT Coordination Centerhttp://www.cert.org/

[33] SANS Global Incident Analysis Centerhttp://www.sans.org/


CFX-TASCflow Version 2.10

und CFX-TurboGrid Version 1.5

Franz WingelhoferInstitut für Thermische Turbomaschinen und [email protected]

Neben den General Purpose CFD-Codes CFX, FIDAP und FLUENT steht seit Ende 2000 aufdem FE-CFD-Cluster (Applikationsserver für Strömungsdynamik und Finite Elemente) auch dasleistungsfähige Software-Paket CFX-TASCflow zur Verfügung.

Die beiden auf dem Finite-Volumen-Verfahren basie-renden CFD-Codes CFX und FLUENT finden auf Grundihrer implementierten Modelle für chemische Reaktionenin erster Linie in der Verfahrenstechnik Verwendung. FI-DAP hingegen, welches mit Hilfe der Finite-Elemente-Methode das Strömungsfeld berechnet, wird oft einge-setzt, wenn freie Oberflächen auftreten. Das auf dem Fi-nite-Volumen-Verfahren basierende CFX-TASCflow wirddagegen oft im allgemeinen Maschinenbau angewendet.

Der Preprocessor CFX-TurboGrid und der Postproces-sor CFX-TurboVisualizer sind speziell auf die Simulationder Strömung durch thermische bzw. hydraulische Turbo-maschinen zugeschnitten. Mit diesem Pre- und Postpro-cessor stellt CFX-TASCflow ein umfassendes Werkzeugfür die Berechnung und Visualisierung der Strömung

durch stillstehende und/oder rotierende dreidimensionaleReihen von Turbomaschinen dar.

Vernetzung des Strömungsgebietes:CFX-TurboGrid

Der Preprocessor CFX-TurboGrid ist ein auf Turbo-maschinen zugeschnittenes Werkzeug zur raschen undqualitativ hochwertigen Vernetzung des zu untersuchen-den Strömungsgebietes durch eine Reihe. Für die Netzto-pologie muss entsprechend dem zu vernetzenden Profilein vordefiniertes Template ausgewählt werden, dessenParameter den jeweiligen Profilquerschnitten angepasstwerden können. Auch die Vernetzung von Radialspaltenist mit diesem Werkzeug auf einfache Weise möglich.Abbildung 1 zeigt eine Blade-To-Blade-Ansicht eineraxialen Turbinenbeschaufelung.


Abbildung 1:Blade-To-Blade-Ansicht

einer axialen Turbinenbeschaufelung(CFX-TurboGrid)

Zusammenstellen des gesamten Strömungs-bereiches: CFX-TASCflow - BuildCase TurboPre

Mit CFX-TASCflow – BuildCase TurboPre können diemit CFX-TurboGrid erstellten Rechennetze zu einem Ge-samtnetz zusammengefasst und die Randbedingungen anden Wänden, am Ein- und Austritt vorgegeben werden.Die Kopplung der zusammengefügten Rechennetze er-folgt problemspezifisch, wobei mehrere Interfaces zurAuswahl stehen. Abbildung 2 zeigt das Gesamtnetz füreine Leit- und eine Laufreihe einer axialen Turbinenstufe.

Solver von CFX-TASCflow

Der Solver von CFX-TASCflow löst mit Hilfe der Fini-te-Volumen-Methode die instationäre, dreidimensionaleMassen-, Impuls- und nötigenfalls Energiebilanz. Für dieBerücksichtigung des turbulenten Charakters der Strö-mung werden außerdem noch die die Turbulenz beschrei-benden instationären, dreidimensionalen Bilanzgleichun-gen gelöst. Auf Grund der Nichtlinearität der Bilanzglei-chungen wird das Strömungsfeld iterativ berechnet. ImGegensatz zu den meisten anderen CFD-Solvern werdenhier die Massen- und Impulsbilanzen simultan gelöst.Dies hat zur Folge, dass eine geringere Anzahl von Itera-tionsschritten bis zum Erreichen eines Konvergenzkriteri-ums nötig und die Rechenzeit bei gleicher Genauigkeitkürzer ist.

Für eine hohe Robustheit der Rechnung sorgt die Ver-wendung eines algebraic multigrid-Algorithmus, bei demdas Rechennetz während der Rechnung automatisiert ver-feinert bzw. vergröbert wird.

Der Solver kann sowohl inkompressibles als auchkompressibles Fluid simulieren. Durch die optionale Ver-wendung von Stoffwertdatenbanken können auch Realga-se wie zum Beispiel Wasserdampf als Fluid verwendetwerden. Ebenso ist die Berechnung von mit dem Strö-

mungsfeld gekoppeltem Wärmeübergang an den Wändenmöglich.

Wegen des hohen Stellenwertes der Turbulenz bei derStrömung durch Turbomaschinen wird ein breites Spek-trum von Turbulenzmodellen angeboten. Bewährte Tur-

bulenzmodelle wie das Standard-k-ε-Turbulenzmodellsind ebenso verfügbar wie jüngere Turbulenzmodelle wie

das RNG-k-ε-Modell, k-ω-Modelle oder Reynolds-Stress-Modelle.

Durch die gleichzeitige Verwendung von ruhenden(Statoren) und rotierenden (Rotoren) Koordinatensyste-men, so genannte multiple frames of reference, kann eineStator-Rotor-Interaktion modelliert werden. Die zeitlicheDiskretisierung kann wahlweise erster oder zweiter Ord-nung genau erfolgen.

Postprocessing:CFX-TurboVisualizer und CFX-TASCtool

Der Postprocessor CFX-TurboVisualizer ist wie derPreprocessor CFX-TurboGrid ein auf Turbomaschinenzugeschnittenes Werkzeug für die Darstellung der Be-rechnungsergebnisse. Mit CFX-TurboVisualizer könnendreidimensionale Ansichten, Blade-To-Blade-Ansichtenund Meridianansichten interaktiv über ein GUI erstelltwerden.

Neben dem interaktiven Postprocessing über ein GUIkann das Postprocessing auch zeilenorientiert mit CFX-TASCtool durchgeführt werden. Im zeilenorientiertenPostprocessing können auf einfache Weise neue Größenberechnet, oft verwendete Befehlssequenzen in Macroszusammengefasst und Teile des Postprocessings automa-tisiert abgearbeitet werden. Abbildung 3 zeigt die Vertei-lung des statischen Druckes an der Nabe, an der Leit-und der Laufreihe einer axialen Turbinenstufe.


Abbildung 2:Gesamtnetz für eineLeit- und eine Laufreiheeiner axialen Turbinenstufe(CFX-TASCflow – BuildCase TurboPre)

Fazit

Gemeinsam mit dem Preprocessor CFX-TurboGridund dem Postprocessor CFX-TurboVisualizer stellt CFX-TASCflow ein umfassendes Werkzeug für die Berechnungund Visualisierung der Strömung durch stillstehende und/oder rotierende dreidimensionale Reihen von thermischenbzw. hydraulischen Turbomaschinen dar. Auf Grund derVerwendung eines algebraic multigrid-Algorithmus unddes simultanen Lösens von Massen- und Impulsbilanzenkann das Strömungsfeld in im Vergleich zu anderenCFD-Codes kurzer Rechenzeit mit ausreichender Genau-igkeit berechnet werden.

Referenzen

AEA Technology:http://www.software.aeat.com/cfx/

Online-Dokumentation am FE-CFD-Cluster:CFX-TASCflow:/appl/local/tascflow/TASCflow/Doc

CFX-TurboGrid:/appl/local/turbogrid/Doc


Abbildung 3:Verteilung des statischen Druckes

in einer axialen Turbinenstufe(CFX-TASCtool)

Betriebs- und Benutzungsordnungdes Zentralen Informatikdienstes (ZID)der Technischen Universität WienSenatsbeschluss vom 25. April 2001

Aufgaben

§ 1. (1) Der ZID ist eine Dienstleistungseinrich-tung gemäß § 75 UOG 1993. Die Aufgaben des ZID sindim § 77 UOG 1993 und in der Satzung der TechnischenUniversität Wien festgelegt.

Funktionen

§ 2. (1) Zur Koordinierung der Angelegenheitender Informationstechnologie hat der ZID insbesonderefolgende Funktionen wahrzunehmen:

• Erfassung des zukünftigen Informatikbedarfes;• Erstellung mittelfristiger Konzepte und Vorhabens-

planungen für den Bereich der Informationstech-nologie einschließlich der Netz- und Systemsicher-heit;

• Festlegung von Standards und Prozeduren zur Si-cherstellung von Kompatibilität, Konnektivität, In-teroperabilität, Netz- und Systemsicherheit.

(2) Die Planung, Schaffung und Sicherstel-lung einer leistungsfähigen Infrastruktur für die Informa-tions- und Datenverarbeitung der Universitätseinrich-tungen umfasst insbesondere folgende Informatikeinrich-tungen:

• Rechnersysteme und Software im zentralen Be-reich;

• Datennetz- und Telekommunikationseinrichtungenbis zur Anschlussdose;

• das zentrale Telefonsystem inklusive Endgeräte;• zentrale Interneträume für Studierende;• Campuslizenzen.

(3) Der ZID hat insbesondere folgende Dienstezu erfüllen:

• Beratung und Unterstützung aller Universitätsein-richtungen bei Planung, Beschaffung und Betriebvon Informatikeinrichtungen für Forschung, Lehreund Verwaltung;

• Beratung der Universitätsangehörigen in allen Be-langen der Informationstechnologie;

• Erteilung von Benutzungsbewilligungen und Zutei-lung von Informatikressourcen an zentralen Serverndes ZID;

• Software-Verteilung;• Unterstützung von dezentralen Systemen;• Netzdienste;• Telekommunikationsdienste;• Internetzugang.

(4) Der ZID hat als Dienstleistungseinrichtungentsprechend den zur Verfügung gestellten personellen

und wirtschaftlichen Ressourcen die Anforderungen undBedürfnisse aller Kunden nach zeitgemäßen Servicestan-dards zu befriedigen.

Kunden

§ 3. (1) Kunden des ZID sind die Universitätsange-hörigen gemäß § 19 UOG 1993 und weitere Angehörigevon Universitätseinrichtungen, soweit sie Informatikein-richtungen und Dienste des ZID verwenden, sowie jenePersonen außerhalb der Technischen Universität Wien,für die ein Benutzungsverhältnis über Informatikeinrich-tungen oder Dienste des ZID aufgrund gesonderter Ver-einbarungen nach § 3 (2) besteht.

(2) Nach Maßgabe vorhandener Kapazität kön-nen entsprechend vom Rektor getroffener Vereinbarun-gen auch Mitarbeiter anderer Universitäten, Hochschulen,Ministerien und der Akademie der Wissenschaften sowiederen Einrichtungen Informatikeinrichtungen und Dienstedes ZID in Anspruch nehmen.

(3) Vereinbarungen über die Inanspruchnahmevon Informatikeinrichtungen und Diensten des ZID wer-den für Angehörige von Universitätseinrichtungen mitdem Leiter der betreffenden Universitätseinrichtung ge-troffen.

Benutzungsbewilligung

§ 4. (1) Angehörige der Technischen UniversitätWien gemäß § 19 UOG 1993 haben zur Erfüllung ihrerAufgaben gemäß § 1 UOG 1993 Anspruch auf die Be-nützung der Informatikeinrichtungen und der Dienste desZID.

(2) Für bestimmte Leistungsbereiche oder fürabgrenzbare Projekte benötigen alle Kunden des ZID einevom ZID erteilte Benutzungsbewilligung, die auf schrift-liche Anmeldung erteilt wird. Ressourcenbedarf in einembesonderen qualitativen oder quantitativen Ausmaß istangemessen zu begründen.

(3) Eine Benutzungsbewilligung endet mit Ab-schluss des entsprechenden Projektes, durch Beendigungder Universitätszugehörigkeit, durch Abmeldung oderEntzug der Benutzungsbewilligung oder durch Ruhen derNutzung von Services über einen Zeitraum von minde-stens einem halben Jahr. Mit Ende der Benutzungsbewilli-gung werden alle gespeicherten Daten des Kunden gelöscht.Die Universitätseinrichtung des jeweiligen Kunden ist vorder beabsichtigten Löschung zu benachrichtigen.


(4) Eine Benutzungsbewilligung kann mit Be-gründung eingeschränkt, verweigert oder vom Nachweisspezieller Fachkenntnisse abhängig gemacht werden.

(5) Kunden, die ihnen zugeteilte Ressourcenfür andere als die in der Benutzungsanmeldung beschrie-benen Aufgaben verwenden oder eine projektfremde Ver-wendung verursachen, wird die Benützungsbewilligungdurch den Leiter des ZID entzogen. Dies kann auch dannerfolgen, wenn ein Kunde Informatikressourcen in einerstörenden Weise beansprucht oder Betriebsmittel nichtnach den Grundsätzen der Wirtschaftlichkeit, Sparsam-keit und Zweckmäßigkeit verwendet.

(6) Über Einsprüche gegen die Beschränkung,Verweigerung oder Entziehung der Benutzungsbewilli-gung entscheidet der Rektor nach Anhörung des Leitersdes ZID.

Rechte und Pflichten

§ 5. (1) Die Kunden und die Mitarbeiter des ZIDsind zur Einhaltung der Bestimmungen dieser Betriebs-und Benutzungsordnung und der gemäß § 11 veröffent-lichten ergänzenden Richtlinien und Benutzungsregelun-gen verpflichtet. Dienstverrichtungen zum Zweck derSicherheit und des Datenschutzes haben Vorrang vor an-deren Aufgaben.

(2) Der Kunde trägt die volle Verantwortungfür die Verwendung der Benutzungsbewilligung. EineWeitergabe an andere Personen ist nicht zulässig.

(3) Werden Kopien von Programmen und Da-ten, die der ZID dem Kunden zur Verfügung stellt, wi-derrechtlich angefertigt, haftet der Kunde gegenüber demLizenzgeber oder Eigentümer.

(4) Die Kunden haben die Einrichtungen desZID jeweils so zu hinterlassen, dass danach eine weitereordnungsgemäße Benützung durch andere möglich ist.

(5) Der Kunde erklärt sich bereit, bei der Un-tersuchung von unzulässigen Verwendungen oder Schä-den an Informatikeinrichtungen, den ZID und Orga-nisationen, die dabei mit dem ZID zusammenarbeiten, zuunterstützen.

(6) Beim Anschluss von Informatikeinrichtun-gen an die zentrale Kommunikationsinfrastruktur durchden Kunden sind die technischen Spezifikationen undVorgaben des ZID zu erfüllen.

(7) Die Öffnung des Netzzuganges für andereals die in § 3 genannten Kunden („Dritte“) ist nicht ge-stattet. Eine Nutzung des Netzes durch Dritte liegt im all-gemeinen dann vor, wenn diese über die vom ZIDbereitgestellten Informatikeinrichtungen nationale und in-ternationale Netze und Netzdienste erreichen, bzw. wennauf Informatikeinrichtungen der Universität Informations-dienste für Dritte betrieben werden.

(8) Der ZID hat die Kunden regelmäßig ausrei-chend zu informieren. Abweichungen vom Normalbetrieb(wie z. B. Abschaltungen, Umstellungen, Wartungsarbei-ten) sind den Kunden möglichst frühzeitig mitzuteilen.

Verwaltungsübertragung von Informatik-einrichtungen

§ 6. (1) Der ZID kann Informatikeinrichtungen ei-nem Kunden vorübergehend zur Verwaltung übertragen.Der ZID kann Informatikeinrichtungen von Kunden aufderen Antrag zur Verwaltung übernehmen. Vorausset-zung für eine Verwaltungsübertragung ist die Gewähr-leistung der Erfüllung der Aufgaben des ZID. DieÜbernahme bedarf der Schriftform und hat die genaueGerätebezeichnung, den Aufstellungsort, den Umfang derBetreuung und die Dauer der Übernahme zu enthalten.

Zuteilung von Informatikressourcen

§ 7. (1) Die Informatikeinrichtungen und Betriebs-mittel werden vom ZID nach Maßgabe der bewilligtenBudgetmittel zur Verfügung gestellt.

Verrechnung von Leistungen

§ 8. (1) Der ZID kann für Dienstleistungen im Rah-men einschlägiger Benutzungsregelungen (§ 11) eineKostenbeteiligung verrechnen. Die Höhe der Kostenersät-ze ist in geeigneter Form bekanntzumachen. Die Verrech-nung erfolgt auf die jeweiligen Kostenstellen des ZID.

Datensicherung

§ 9. (1) Der ZID führt in periodischen AbständenDatensicherungsläufe für die auf seinen zentralen Serverngespeicherten Daten durch. Diese Form der Datensiche-rung beinhaltet, dass nach aufgetretenen Fehlern die In-formationen (Dateien) von den Sicherungsbeständen desZID rekonstruiert werden können. Darüber hinausgehen-de Sicherungen und Archivierungen sind von den Kun-den selbst in eigener Verantwortung durchzuführen.

Beratendes Gremium für IT-Angelegenheiten undIT-Kontaktpersonen

§ 10. (1) Zur Unterstützung der notwendigen Kom-munikation zwischen den Fakuläten und dem ZID wirdein beratendes Gremium für IT-Angelegenheiten einge-richtet. Es besteht aus zwei vom Senat entsandten Mit-gliedern und je einem Mitglied aus den einzelnenFakultäten, das vom Dekan entsandt wird. Aus dem Se-nat ist je ein Mitglied aus dem Kreis der Studierendenund eines aus der Fakultät für Technische Naturwissen-schaften und Informatik zu entsenden. Dieses Gremiumist mindestens viermal im Jahr vom Vorsitzenden desBeirates einzuberufen.

(2) Die Leiter der Universitätseinrichtungenbenennen zur Unterstützung der notwendigen Kommuni-kation mit dem ZID eine Mitarbeiterin oder einen Mitar-beiter als IT-Kontaktperson.

Ergänzende Richtlinien und Benutzungsregelungen

§ 11. (1) Einschlägige Benutzungsregelungen (Poli-cies) für spezielle Informatikeinrichtungen des ZID (z. B.Datennetzinfrastruktur, Telefonanlage, Security Policy,...) sowie spezielle Richtlinien für Dienstleistungen desZID und für Datensicherheitsmaßnahmen werden nachVorschlag des Leiters des ZID vom Rektor erlassen undim Mitteilungsblatt der Technischen Universität Wienveröffentlicht.


Personelle Veränderungen


In Memoriam Günter Vollmann

Völlig unerwartet ist unser Freund und KollegeGünter Vollmann am 19. Dezember 2000 im 57. Le-bensjahr verstorben.

Geboren am 13. 10. 1944 in Wien, begann er 1966 alsOperator der Rechenanlage IBM 7040 am Institut für Nu-merische Mathematik der TU Wien bei Prof. Stetter.

Unser „Gundi“, wie wir ihn alle nannten, hat die Ent-wicklung der EDV an der TU Wien von den ersten An-fängen aus mitverfolgt und begleitet.

In den Jahren der „Lochkarten-EDV“ stand er denStudenten sowie den Kolleginnen und Kollegen der TUWien mit Rat und Tat zur Seite, wenn es galt, einen Lo-cher zu reparieren, den Papiersalat im Drucker zu behe-ben oder einige hundert Lochkarten neu zu sortieren.

In diese Zeit fallen auch seine sportlichen Höhepunk-te: Faustball war sein Leben, Meisterschaftsspiele im In-und Ausland, Spiele in der österreichischen National-mannschaft bestimmten nachhaltig sein Leben.

1975 wurde Günter Vollmann Chefoperator an denneuen Rechenanlagen von CDC und wurde zusammenmit einigen Kollegen und mir Mitte 1976 in den Perso-nalstand des neuen IEZ übernommen.

Im Herbst 1988 feierten wir die Vollendung des 25.Dienstjahres im öffentlichen Dienst, Anfang 1991 wurdeGünter Vollmann nach der Reorganisation und Zusam-menlegung der Abteilungen Digital-, Hybrid- und Pro-zeßrechenanlage sowie des IEZ in den Personalstand desneuen EDV-Zentrums der TU Wien übernommen.

In einer stillen Feier im Krematorium am Zentralfried-hof haben wir ihm am 28. 12. 2000 das letzte Geleit ge-geben.

Lieber Günter, wir werden Dich immer in Erinnerungbehalten.

Peter Berger

Veränderungen im Referat Internet-Räume

Am 15. April 2001 wechselte Herr Dipl.-Ing.Gerhard Schmitt an die Universität für AngewandteKunst und übernahm dort den Posten des Leiters desZentralen Informatikdienstes.

Herr Gerhard Schmitt war über 25 Jahre an der TUWien beschäftigt und leitete ab 1992 das Referat Inter-net-Räume (vormals Benutzerräume).

Wir wünschen ihm auf seinem weiteren Weg viel Er-folg und alles Gute.

Herr Dipl.-Ing. Martin Rathmayer wechselt aus demBereich der Systemadministration in dieses Referat undübernimmt die Referatsleitung (E-Mail: [email protected], Nebenstelle 42086).

Herr Michael Roth arbeitet seit 6. Dezember 2000halbtags als PC-Techniker am ZID (E-Mail: [email protected], Nebenstelle 42091). Er ist im Bereich Inter-net-Räume vor allem für die Hardwarebetreuung der PC-Arbeitsplätze zuständig.

Herr Philipp Kolmann unterstützt seit Anfang Maihalbtags die Abteilung Zentrale Services im Bereich derzentralen Applikationsserver.


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

Fingerprints der Test-CAs und der von ihnen ausge-gebenen Serverzertifikate:

Zertifikat der Root-Test-CA (PCA)gültig von Dec 30 1999 bis Dec 26 20140D: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 200903: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 20093C: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 20 2000 bis Nov 20 2001MD5 Fingerprint=

04:CE:1E:67:57:EB:80:A0:C1:EB:0D:11:05:12:52:99

Server-Zertifikat von stud4.tuwien.ac.atgültig von Nov 20 2000 bis Nov 20 2001MD5 Fingerprint=

DB:47:20:4A:A7:90:DE:5D:D5:2B:6C:BD:CF:02:D2:21

Server-Zertifikat von fbma.zserv.tuwien.ac.atgültig von Dec 5 2000 bis Dec 5 2001MD5 Fingerprint=

13:4C:C2:ED:7E:6A:F7:1D:24:48:D6:FB:5D:9E:00:DA

Server-Zertifikat von mail.zserv.tuwien.ac.atgültig von Dec 5 2000 bis Dec 5 2001MD5 Fingerprint=

89:10:25:A0:C1:5C:E7:30:D2:38:7C:5E:9C:40:ED:E2

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 bis Mar 1 2002

A0:FF:97:E3:25:5D:07:B9:20:CC:84:D6:88:05:EB:0F

Seit Anfang April 2001 ist Herr Tilman Linneweh inder Abteilung Kommunikation tätig. Sein Hauptaufga-bengebiet ist der Bereich Hardware-Wartung und -Fehler-suche sowie Installation im Access-Bereich des TUNET.

Wir wünschen allen neuen Mitarbeitern viel Erfolgund Freude bei ihrer Tätigkeit!

Frau Dipl.-Ing. Elisabeth Donnaberger verlässt nachmehr als 3 Jahren Tätigkeit leider den Zentralen Informa-tikdienst mit Anfang Juni. Frau Donnaberger war in ihrerTätigkeit für die Abteilung Standardsoftware unter ande-rem für den Software Server verantwortlich und hat indieser Aufgabe erfolgreich dazu beigetragen, dass dasCampus Software Service hochverfügbar den Kunden zurVerfügung steht. In der Abteilung Kommunikation warsie für die White Pages und den Mailrouter zuständig undvon dieser Tätigkeit her sicher vielen bekannt.Alle Mitarbeiter wünschen ihr weiterhin alles Gute.


Anzeige

ÖffnungszeitenSekretariat

Freihaus, 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

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://www.ben.tuwien.ac.at/InternetRaeume/

Operator-Ausgabe

Freihaus, 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.

http://www.ben.tuwien.ac.at/InternetRaeume/

Wählleitungen01 / 589 32 Normaltarif

07189 15893 Online-Tarif

(50 km um Wien)

Datenformate:

300 - 56000 Bit/s (V.90)

MNP5/V.42bis

PPP

ISDN Synchronous PPP

Auskünfte, Störungsmeldungen

Sekretariat

Tel.: 58801-42001

E-Mail: [email protected]

TUNET

Störungen

Tel.: 58801-42003


Rechneranmeldung


Telekom

Hotline: 08

(8.00-12.00 und 13.00-15.00 Uhr,

nur innerhalb der TU)


Chipkarten,

Abrechnung: 58801-42008

Netz- und Systemsicherheit


Service-Line Abt. Standardsoftware

Tel.: 58801-42004

Systemunterstützung

Computer Help Line 42124

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

Campussoftware


[email protected]

Zentrale Server, Operating

Tel.: 58801-42005


Internet-Räume

Tel.: 58801-42006



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: http://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]

Netz- und Systemsicherheit

U. Linauer 42026 [email protected]

Abteilung Zentrale Services

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

Leitung

P. Berger 42070 [email protected]

W. Altfahrt 42072 [email protected]

J. Beiglböck 42071 [email protected]

C. Bojer 42083 [email protected]

P. Deinlein 42074 [email protected]

P. Egler 42094 [email protected]

H. Eigenberger 42075 [email protected]

H. Flamm 42092 [email protected]

W. Haider 42078 [email protected]

E. Haunschmid 42080 [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]

A. Schulz 42081 [email protected]

E. Srubar 42084 [email protected]

Werner Weiss 42077 [email protected]

Abteilung Kommunikation

http://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]

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

http://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]

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]

P. Torzicky 42035 [email protected]


ZIDline 05

Documents

Transcript of ZIDline 05