zidline 13

36
Delta 3 Service Center Phoenix Cluster Nr. 13 / Dezember 2005 ISSN 1605-475X INFORMATIONEN DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Upload: vienna-university-of-technology

Post on 31-Mar-2016

216 views

Category:

Documents


1 download

DESCRIPTION

Die Zeitschrift des Zentralen Informatikdienstes der TU Wien.

TRANSCRIPT

Page 1: ZIDline 13

Delta 3

Service Center

Phoenix Cluster

Nr. 13 / Dezember 2005

ISSN 1605-475X

INFORMATIONEN DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Page 2: ZIDline 13

Seite 2 – Dezember 2005 – ZIDline 13

Inhalt

Das Service Center des ZIDzentrale Anlaufstelle für alle Services . . . . . . . . . . . 3

ZIDcluster2004 –gut Ding braucht Weile. . . . . . . . . . . . . . . . . . . . . . . 5

Phoenix Softwareund Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Korrekter Einsatz derCampus Software Lizenzen . . . . . . . . . . . . . . . . . . 11

Spam Catch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

PXE-Bootservice:Installation von Windows/Linuxüber PXE-Netboot . . . . . . . . . . . . . . . . . . . . . . . . . 16

Ansichtssacheein Vista Betatest . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Firewall-Regeln fürWindows Domain Controller . . . . . . . . . . . . . . . . . 22

Firewall-Lösung für Institute –neue Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Delta 3ein interuniversitäres Projekt zur Entwicklungund Umsetzung von e-Learning-/e-Teaching-Strategien an den Partnerinstitutionen . . . . . . . . . . 26

Arbeiten mit Solid Edge . . . . . . . . . . . . . . . . . . . . . . . . 31

Personalnachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Auskünfte, Störungsmeldungen:Service Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Telefonliste, E-Mail-Adressen . . . . . . . . . . . . . . . . . . . 35

Editorial

Der ZID richtet ein Service Center (andernorts auchHelpdesk genannt) als zentrale Anlaufstelle für Auskünf-te und Problembehebung ein. Mit dieser ZIDline stellenwir die neue Einrichtung vor, mit Beginn des Jahres2006 wird das Service Center offiziell in Betrieb gehen.

Über den neuen SUN HPC Cluster können wir bereitsausführlich berichten. Ihm ist auch das Titelbild dieserZIDline gewidmet.

Aus dem Bereich der Campus Software wird SolidEdge von einem Anwender vorgestellt. Bitte beachten Sieauch stets die Lizenzbedingungen für die Verwendungvon Produkten aus der Campus Software an der TUWien (siehe Seite 11).

Zusätzlich zur Spam-Markierung kann man nun aufWunsch die Zustellung von Spam-Mails blockieren las-sen. Lesen Sie dazu den Artikel „Spam Catch“.

Wir haben Vista Beta getestet und berichten überNeuigkeiten, Benchmarks und Applikationen-Kompatibi-lität des XP-Nachfolgers.

Die Installation von Windows/Linux über PXE-Net-boot sowie eine neue hardware-basierte Firewall-Lösungfür Institute werden vorgestellt.

Wie in der letzten ZIDline angekündigt, wurde dasProjekt Delta 3 zur Entwicklung und Umsetzung vone-Learning/e-Teaching-Strategien an Universitäten undFachhochschulen bewilligt. Wir danken den Projektver-antwortlichen für die Präsentation.

Auch allen anderen Autoren und Inserenten ein herzli-ches „Dankeschön“ für die Beiträge zu dieser ZIDline undfür die gute Zusammenarbeit.

Mit den besten Wünschen für ein erfolgreiches Jahr2006.

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, 42002Fax: (01) 58801-42099E-Mail: [email protected]/zidline/

Erstellt mit Corel VenturaDruck: Grafisches Zentrum an der TU Wien,1040 Wien, Tel.: (01) 5863316

Die ZIDline im Web:

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

Page 3: ZIDline 13

ZIDline 13 – Dezember 2005 – Seite 3

Das Service Center des ZIDzentrale Anlaufstelle für alle Services

Philipp Kolmann, Irmgard Husinsky

Durch Zusammenführung der bisherigen verschiedenen Ansprechpunkte zu einem einzigenService Center soll eine Verbesserung der Servicequalität für unsere Kunden erreicht werden.Das Service Center ist die erste Anlaufstelle für alle Kunden des ZID. Es hilft Ihnen bei allenFragen weiter, die Sie zu den diversen Services des ZID haben oder leitet Ihre Anfrage anentsprechendes Fachpersonal weiter. Ferner werden Störungsmeldungen entgegengenommenund die Behebung veranlasst. Sie können selbst vorbeikommen, die zentrale Hotline anrufen,eine E-Mail schicken oder das Service Ticket System verwenden.

Wie es bisher war

Die breite Palette an Services, die der ZID für Studie-rende und Mitarbeiter der TU Wien erbringt, erfordertneben dem täglichen Kundenkontakt besonders im Pro-blemfall eine rasche Hilfestellung.

Bisher waren die vorhandenen Ansprechpunkte und-personen für die erforderliche Hilfestellung räumlichund telefonisch unterschiedlich verteilt. Es gibt eine Rei-he verschiedener E-Mail-Adressen für Anfragen und Stö-rungsmeldungen.

So waren z. B. das Sekretariat, die ADSL-Beratungund die Telefonie-Zubehör-Ausgabe an verschiedenenOrten. Für manche Angelegenheiten waren direkte Büro-besuche bei den einzelnen Fachleuten notwendig.

Unterschiedliche Telefon-Hotlines gibt es z. B. für Se-kretariat, TUNET Störungen, STS Service Line, STSComputer Help Line, Operating, TU-ADSL-Beratung,Telefon-Hotline, Vermittlung.

Die richtige Ansprechstelle ist oft schwierig zu finden.Die Öffnungszeiten sind unterschiedlich und damit denKunden gegenüber nicht transparent. Beim direkten An-sprechen des Fachpersonals ist die Erreichbarkeit nichtimmer gegeben.

Die Zusammenführung

Die Einrichtung des Service Centers wurde in dem imHerbst 2004 beschlossenen Organisationsentwicklungs-plan für den gesamten ZID festgelegt und im laufendenJahr sukzessive vorbereitet. Umfangreiche Umbauten derRäumlichkeiten des ZID sowie Übersiedlungen von Mit-arbeitern waren dafür notwendig und sind jetzt abge-schlossen. Die notwendigen personellen Strukturenwerden ab 1. 1. 2006 Gültigkeit erlangen. Das ServiceCenter ist jedoch ab Erscheinen dieser ZIDline in Betriebund wir laden Sie herzlich ein, vorbei zu kommen.

Als erster Schritt wurde nach dem Umbau des Sekre-tariats die Vermittlung vom 1. Stock in den 2. Stock

Bitte wenden Sie sich bei allen Fragen und Problemen, die das Service-Angebot des ZIDbetreffen, zunächst an das Service Center.

Das Service Center ist die erste Ansprechstelle für alle angebotenen Dienste. Ihre Anfragekann entweder sofort beantwortet werden oder wird zum jeweils verantwortlichenFachpersonal weiter geleitet.

Service Center Hotline: 58801 - 42002

Page 4: ZIDline 13

(ZID Eingang 1) übersiedelt, dann folgte die TU-ADSL-Beratung, die von studentischen wissenschaftlichen Hilfs-kräften durchgeführt wird.

Alle Personen, die im Service Center arbeiten, wurdenentsprechend eingeschult. Sie haben Zugriff auf die aktu-ellen Informationen zu den ZID Services über TicketSystem, Web-Informationen, Datenbanken etc., um kom-petente Auskünfte geben zu können. Auch ZID-internwird das Service Center als wichtige Informationsquelledienen.

Die Internet-Raum-Betreuung durch wissenschaftlicheHilfskräfte (Tutoren) im Internet-Raum FH1 im Freihaus,Erdgeschoss bleibt als wichtige erste Anlaufstelle für denGroßteil der Studierenden erhalten.

Für den elektronischen Kontakt kommt bereits seit ei-niger Zeit erfolgreich ein Service Ticket System zumEinsatz (siehe auch ZIDline 12, Seite 3):https://service.zid.tuwien.ac.at/support/

Dieses System hat sich in den letzten Monaten sehrbewährt und den Arbeitsablauf bei den Anfragen verbes-sert. Hier können die Kunden den Status ihrer Anfragejederzeit verfolgen.

Das neue Service CenterBitte wenden Sie sich bei allen Fragen und Proble-

men, die das Service-Angebot des ZID betreffen, zu-nächst an das Service Center.

Das Service Center ist die erste Ansprechstelle für alleangebotenen Dienste. Ihre Anfrage kann entweder sofortbeantwortet werden oder wird zum jeweils verantwortli-chen Fachpersonal weiter geleitet.

Aufgabenbereiche

• Allgemeine Auskünfte über den Zentralen Informatik-dienst und seine Dienstleistungen.

• Rat und Hilfe bei TU-Wien-spezifischen EDV-Pro-blemen für Studierende und Mitarbeiter.First Level Support für alle ZID Services. Bei Spezialfra-gen wird an das jeweilige Fachpersonal weiter vermittelt.Kann das Problem nicht sofort geklärt werden, wird einService Ticket eröffnet.

• Entgegennahme von Service-Anforderungen zum Platt-form-Support (bei aufrechtem Wartungsvertrag).

• TU-ADSL-Beratung.Beratung, Ausgabe von Modems und Störungsannahme.

• Entgegennahme und Weiterleitung von Störungsmel-dungen. Koordination mit dem NOC (Network Opera-tion Center), Absetzen von Service Tickets.

• Accountvergabe / Passwortänderung.Behandlung aller Anfragen zu Benutzungsberechtigun-gen, insbesondere Setzen vergessener Passwörter. Aus-gabe und Annahme von Formularen.

• Telefon-Vermittlung, Auskünfte und Hotline für Tele-kommunikation.Außerhalb der Öffnungszeiten des Service Centers wirddie Telefon-Vermittlung an der TU von den Portierenübernommen.

• Administrative Aufgaben, Warenannahme (z.B. Liefe-rungen von Post und Botendiensten) und -ausgabe fürden ZID (ADSL-Modems, Telefonie-Zubehör, Chip-Karten, ...)

Öffnungszeiten

Außerhalb dieser Zeiten übermitteln Sie Ihre Anliegenbitte über das Service Ticket System, bzw. können Sieauf eine Sprachbox sprechen.

Kontakt

Adresse: 1040 Wien, Wiedner Hauptstraße 8-10Freihaus, 2.OG, gelber Bereich(ZID Eingang 1, wo bisher das Sekretariat zufinden war)

Telefon: 58801- 42002

Fax: 58801- 42099

E-Mail: [email protected], [email protected]

Web: Service Ticket System:https://service.zid.tuwien.ac.at/support/

Zur Selbsthilfe (FAQ): Support-Informationen zu eini-gen häufig gestellten Fragen und typischen Problemenfinden Sie auf der Webseite des Service Centers:

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

Seite 4 – Dezember 2005 – ZIDline 13

Lageplan Service Center:Freihaus, Wiedner Hauptstraße 8-10, 2. Obergeschoss

Page 5: ZIDline 13

ZIDline 13 – Dezember 2005 – Seite 5

ZIDcluster2004 –gut Ding braucht WeilePeter Berger

Die Turbulenzen um das neue Clustersystem ( „Phoenix aus der Asche“ – phoenix.zserv ) wurdenmit der Installation und der erfolgreichen Abnahme des SUN-Clusters Ende August 2005beigelegt. Mit der Aufnahme des Testbetriebes wurde nach einigen Softwareanpassungenbegonnen, das System läuft stabil und zufrieden stellend.

Hardwarekonponenten

1 Zugangsknoten bestehend aus:

SUN Fire V40z2 Prozessoren AMD Opteron 248 (2,2 GHz)4 GByte Hauptspeicher2 SCSI Platte 73 GB1 CDROM-Laufwerk2 Gigabit-Ethernet-Adapter (auf Mainboard)2 Gigabit-Ethernet-Adapter1 Fibre-Channel-Adapter (2 Gbit/s)1 InfiniBand-Adapter

(Hochgeschwindigkeits-Netzwerk, 10 Gbit/s)1 Serviceprozessor

65 Stück Clusterknoten (compute nodes) bestehend aus:

SUN Fire V20z2 Prozessoren AMD Opteron 250 (2,4 GHz)4 GByte Hauptspeicher1 SCSI Platte 73 GB1 CDROM-Laufwerk2 Gigabit-Ethernet-Adapter (auf Mainboard)1 InfiniBand-Adapter

(Hochgeschwindigkeits-Netzwerk, 10 Gbit/s)1 Serviceprozessor

1 Fileserver bestehend aus:IBM e325

2 Prozessoren AMD Opteron 246 (2,0 GHz)4 GByte Hauptspeicher2 SCSI Platte 73 GB1 CDROM-Laufwerk2 Gigabit-Ethernet-Adapter (auf Mainboard)1 Fibre-Channel-Adapter (2 Gbit/s)

Clusterweites Storage: SGI TP9300(zentrales FibreChannel Storage System)(2 Gbit FC, redundant am Fileserver undam Zugangsknoten angebunden)

Sonstiges:3 Stück 19"-Systemschränke inkl. PowerswitchesHP MSL6030, LTO2 Backup-Library

(am Fileserver angeschlossen)

Netzwerk

Hochgeschwindigkeits-Netzwerk:1 Stück MST14000 Mellanox InfiniBand-Switch(InfiniBand 10 Gbit/s; 72 Ports, max. 144 Ports)

Filetransfer-Netzwerk:3 Stück Cisco Catalyst 3750, stackable(Gbit-Ethernet-Switch), 72 Ports

Management-LAN:1 Stück HP ProCurve 2626(100 Mbit-Ethernet-Switch, 24 Ports)

TUNET-Zugang:Gbit-Anbindung über den Zugangsknoten

Systembeschreibung SUN Fire V20z

Das Kernstück des Clustersystems bildet der compu-te-node SUN Fire V20z, ein symmetrisches Multiprozes-sorsystem auf x86-Basis mit 2 AMD Opteron-CPUs.Diese Systeme sind rack-optimiert und nur 1U (1.69 inch/43 mm) hoch. Die AMD-Opteron CPU verfügt im Ge-gensatz zu „klassischen“ Intel-Architekturen nicht überdie Kopplung der CPU über die Northbridge zumMemory, es ist im Gegensatz dazu auf dem Chip ein

Page 6: ZIDline 13

integrierter Memory-Controller vorhanden, der dieAnbindung von DDR1 Memory Modulen mit 128 BitBreite ermöglicht.

Ein wesentlicher Bestandteil der CPU-Architektur ist dieAnbindung weiterer CPUs und der I/O-Systeme über denHyperTransport. Dieser 16 Bit breite und mit 800 MHz ge-taktete serielle Bus erlaubt eine Übertragungsrate bis zu 3,2GB/s pro Richtung (Bandbreite 6,4 GB/s).

Das I/O-Subsystem ist über einen HyperTransportLink angeschlossen, es wird ein so genannter Hyper-Transport PCI-X Tunnel eingesetzt, der einen Hyper-

Transport I/O Hub, 2 Gbit-Ethernet-Controller und einenSCSI-Controller versorgt.

Ein integrierter Serviceprozessor, der über 2x 10/100Mbit Ethernet-Anschlüsse verfügt, erlaubt das Manage-ment der Clusterknoten „Out-of-Band“, d. h. es steht eineigenes Management-LAN zur Verfügung. Da es sich beidiesen Ethernet-Anschlüssen um einen 3-Port Switchhandelt, können die Clusterknoten direkt zusammenge-schaltet werden; der Verkabelungsaufwand reduziert sichbeträchtlich.

Seite 6 – Dezember 2005 – ZIDline 13

Konfiguration ZIDcluster2004

AMD Opteron Processor Architecture

Clusterknoten Verkabelung

Page 7: ZIDline 13

Die AMD64-Architektur erlaubt es, vorhandene 32-BitApplikationen und Betriebssysteme zu verwenden. Durchdie Auslegung aller Register auf 64 Bit Breite ist es mög-lich, „echte“ 64-Bit Applikationen unter einem 64-BitBetriebssystem zu entwickeln.

Netzwerke – Zusammenschaltung der Cluster-knoten und Anbindung an das TUNET

Zur Kopplung der Clusterknoten und zum Anschlussan das lokale Netz der TU Wien sind vier unabhängigeNetzwerke installiert:

• Hochgeschwindigkeits-Netzwerk:MPI-Kommunikation (InfiniBand, 10 Gbit/s, full du-plex, siehe ZIDline Nr. 12)

• Filetransfer- und Datennetzwerk:NFS, Kommunikation zwischen den Knoten(1 Gbit/s Ethernet)

• Management-LAN:Clustermanagement, 100 Mbit/s

• TUNET-Anschluss:phoenix.zserv.tuwien.ac.at (1 Gbit/s)

Zugangsknoten

Der Zugangsknoten ist ein System SUN Fire V40z,das sowohl über einen Gbit-Anschluss zum TUNET ver-fügt wie auch in alle anderen Kommunikationsnetze ein-gebunden ist. Dieses System ist ebenfalls ein Doppel-prozessorsystem (gleiche Systemarchitektur wie dieV20z), verfügt jedoch über wesentlich mehr PCI-Steck-plätze und kann mit maximal 4 CPUs (AMD Opteron)bestückt werden.

Fileserver

Ein Fileserver (IBM 325) ist in das Gbit-Netz einge-bunden und stellt die Home-Directories der User überNFS zur Verfügung. An diesem Fileserver ist einRAID-Set eines zentralen FibreChannel Storage (SGITP9300, 2 Gbit/s FC) angeschlossen, derzeit stehen ca. 2TByte zur Verfügung. Der Zugangsknoten ist ebenfallsmit einer FC-Verbindung an das Storage angeschlossen,um eventuelle Systemausfälle rasch bereinigen zu können.

Betriebssystem, Compiler und Batchsystem

Als Betriebssystem ist Linux Fedora Core 3 im Ein-satz, auf die Installation von RedHat Enterprise AS wur-de aufgrund der inakzeptablen Preise für dieses Produktverzichtet.

Als Clustersoftware steht das „Cluster DevelopmentKit“ von Portland Group zur Verfügung, neben den PGICompilern (Fortran, C und C++) steht die Compilersuitevon PathScale und der Intel Compiler zur Verfügung(siehe Artikel auf Seite 8).

Als Batchsystem steht die SUN Grid Engine zur Ver-fügung.

Management-Software

Für das Clustermanagement sind neben einer Reihevon selbst entwickelten Scripts die Produkte NAGIOSund als Datensammel- und DarstellungssystemGANGLIA im Einsatz.

Das Finanzierungsmodell

Das vorgesehene Rückfinanzierungsmodell wurdenach intensiven Gesprächen zwischen der Universitätslei-tung, dem FWF und dem ZID den geänderten Gegeben-heiten angepasst. Für TU-interne Forschungsprojektesowie für die Nutzung des Clusters für Lehrveranstaltun-gen ist keine Direktfinanzierung durch das betroffene In-stitut erforderlich. Ebenso werden FWF-Projekte, solltendie für die Rechenzeit beantragten finanziellen Mittelnicht bewilligt werden, nicht direkt verrechnet.

Es wird eine Nachverrechnung (wie für alle Applika-tionsserver) erfolgen, die Account-Daten werden jährlichan die Universitätsleitung übermittelt und ein Teil der an-gefallenen Kosten (Investitionen abgeschrieben auf dreiJahre, kein Betriebs- und Personalaufwand) über dieBudgetzuteilung an die Fakultäten rückverrechnet.

Für die Verrechnung werden für jeden User zwei un-terschiedliche Kennzahlen herangezogen:

• für interaktive Jobs am Zugangsknoten: CPU-Zeiten

• Jobs, die über das Queueing-System abgesetzt werden:(endtime - starttime) * Anzahl der reservierten CPUs(slots)

Folgende Kosten werden nach Ende des Testbetriebes (ab1. 1. 2006) verrechnet:

Für TU-interne Forschungsprojekte:

• € 0,1 für die interaktive CPU-Stunde

• € 0,1 für die „Clusterstunde“ pro CPU

Projekte aus dem Drittmittelbereich werden im vollenUmfang (inkl. Raum- und Personalkosten) direkt mit denInstituten verrechnet:

• € 0,13 für die interaktive CPU-Stunde

• € 0,13 für die „Clusterstunde“ pro CPU

Links

ZID Phoenix Cluster:http://www.zserv.tuwien.ac.at/phoenix/

SUN Microsystems: http://www.sun.com/

AMD: http://www.amd.com/

HyperTransport Consortium:http://www.HyperTransport.org/

Mellanox: http://www.mellanox.com/

InfiniBand Trade Association:http://www.infinibandta.org/

ZIDline 13 – Dezember 2005 – Seite 7

Page 8: ZIDline 13

Seite 8 – Dezember 2005 – ZIDline 13

Phoenix Softwareund BenchmarksErnst Haunschmid

In den Sommermonaten wurde der neue Sun HPC-Cluster (phoenix.zserv) in Betrieb genommen.Während die Hardware bereits in früheren Artikeln vorgestellt worden sind, steht die Software imMittelpunkt dieses Artikels.

Betriebssystem

Auf allen Knoten ist derzeit Fedora Core 3 für AMD64 mit den aktuellen Updates installiert (Kernel 2.6.9).Ein Umstieg auf Fedora Core 4 ist derzeit nicht möglich,da die Mellanox Infiniband Software derzeit nur für Fe-dora Core 3 freigegeben ist. Prinzipiell können unterdiesem Betriebssystem auch 32 Bit Applikationen ausge-führt werden; in der Praxis treten aber häufig Problemeauf, da nicht immer alle benötigten Libraries auch als 32Bit Version vorliegen.

Compiler

Neben der GNU Compiler Collection (gcc) in derVersion 3.4.4 stehen die folgenden C, C++ und FortranCompiler zur Verfügung:

• PathScale EKOPath CompilerSuite (Version 2.2.1)

• Intel Compilers for Linux(Version 9.0)

• PGI Cluster Development Kit(CDK) (Version 6.0.5)

Alle genannten Compiler kön-nen Code für AMD64 bzw. EM64Terzeugen. Bei den durchgeführtenBenchmarks waren durchwegs diemit dem PathScale Compilern er-zeugten Codes am schnellsten.

Derzeit stehen zwei Lizenzender PathScale Compiler zur Verfü-gung. Von den PGI Compilern ste-hen fünf Lizenzen bis Ende Jänner2006 zur Verfügung; eine Verlän-gerung ist derzeit nicht geplant. Fürdie Intel Compiler besteht keinWartungsvertrag; sie stehen somitohne Limitierung zur Verfügung,wurden aber bisher kaum getestet.

InfiniBand Software

Die InfiniBand Hardware stammt von Mellanox; dermitgelieferte Software Stack IBGold ist sehr umfangreichund umfasst die in Abbildung 1 angeführten SoftwareLayer.

Der für den Benutzer interessante Teil ist derHPC/MPI Bereich. Verwendet wird mvapich (Version0.9.5), eine MPI-Implementierung der Ohio State Uni-versity. Wie in der Abbildung ersichtlich, nützt mvapicheinen user access layer (VAPI) um direkt und unter Um-gehung der Kernel Driver auf die HCA-Hardware zuzu-greifen. Dadurch sollen möglichst geringe Latenzzeitenerreicht werden.

Die Administration erfolgt über OpenSM.

Mellan

ox Te

chno

User

Kernel API(TSAPI)

InfiniBand Fabric

HCA Hardware

SDP

SocketsLayer

OpenSMuDAPLMPI

User Access Layer (VAPI)

IB Gold CD

LinuxApplications

Kernel

HPC Data Center Embedded Legacy

App TierSAP, PeopleSoft

VideoCommunications

IP/LANApps

IB Admin Tools

ManagementStorage

IP

Markets

Kernel VAPI Driver

OpenIB.org Access Layer

Kernel Bypass

IPoIB SRP

TCP UDP ICMP SCSI Mid Layer

libsdp

kDAPL

BlockStorage

FileSto-rage

User

Kernel API(TSAPI)

InfiniBand Fabric

HCA Hardware

SDP

SocketsLayer

OpenSMuDAPLMPI

User Access Layer (VAPI)

IB Gold CD

LinuxApplications

Kernel

HPC Data Center Embedded Legacy

App TierSAP, PeopleSoft

VideoCommunications

IP/LANApps

IB Admin Tools

ManagementStorage

IP

Markets

Kernel VAPI Driver

OpenIB.org Access Layer

Kernel VAPI Driver

OpenIB.org Access Layer

Kernel Bypass

IPoIB SRP

TCP UDP ICMP SCSI Mid Layer

libsdp

kDAPL

BlockStorage

FileSto-rage

Abb. 1: IBGD Stack

Page 9: ZIDline 13

Neben dem InfiniBand Netzwerk sind die einzelnenKnoten auch noch mit Gigbit Ethernet miteinander ver-bunden. Mittels IPoIB (Internet Protocol over InfiniBand) könnte aber auch NFS-Verkehr über das InfiniBand Netzwerk realisiert werden.

Damit eine MPI Applikation Infiniband nutzen kann,müssen bei der Erstellung des Codes entsprechende Op-tionen für das Kompilieren und Linken angegeben wer-den. Je nach verwendetem Compiler sind unter-schiedliche Optionen anzuwenden. Die IBGD-Softwareunterstützt derzeit die GNU, Pathscale und PGI Compi-ler. Mit und für jeden dieser Compiler wird die mvapichSoftware extra generiert und dem Anwender über ent-sprechende Scripts zur Verfügung gestellt (z. B. mpif90zum Kompilieren und Linken von MPI Fortran Program-men; die Scripts sollten aber mit absoluten Namen aufge-rufen werden, Details dazu finden sich in derDokumentation zum Cluster).

Optimierung

Alle Compiler stellen eine Vielzahl von Optimierungs-möglichkeiten zur Verfügung. Um dem Anwender dieAuswahl zu erleichtern, werden diese in Gruppen zu Op-timierungstufen zusammengefasst; je höher die Optimie-rungsstufe, desto mehr Optimierungsoperationen führtder Compiler durch. In der Theorie sollte man mit einerhöheren Optimierungsstufe auch eine bessere Laufzeit er-zielen. In der Praxis zeigt sich meist ein anderes Bild.

Eine höhere Optimierungsstufe ist keinesfalls ein Ga-rant für eine bessere Laufzeit: in vielen Fällen kannaggressives Optimieren zu schlechteren Laufzeiten, grö-ßeren numerischen Fehlern oder im Extremfall zu Pro-grammabbrüchen führen. Da in einem Compiler sehrviele Stufen (beim gcc z. B. über 100) jeweils Transfor-mationen am Code vornehmen, können verbesserte Opti-mierungen in einer bestimmten Stufe zu einem Outputführen, der für die nachfolgenden Stufen keine oder nurmehr eingeschränkte Optimierungen zulässt.

Grundsätzlich sollte während der Programmentwicklungauf (aggressive) Optimierung verzichtet werden; erst so-bald ein lauffähiger Code vorhanden ist, sollte die Opti-mierungsstufe gesteigert werden. Nach jedem Opti-mierungsschritt sollten die Laufzeiten und die Resultateverglichen werden.

Bibliotheken

Für numerisch intensive Applikationen im Bereich derlinearen Algebra gibt es seit Jahren einen defacto Stan-dard: LAPACK und BLAS. LAPACK bietet unter ande-rem Routinen zur Lösung linearer Gleichungssystemeund von Eigenwertproblemen. In der BLAS werden ein-fachere Routinen wie Matrizenmultiplikation zur Verfü-gung gestellt. Für die Generierung von effizientem Codeist die Verwendung von optimierten Versionen dieserBibliotheken notwendig:

ACML:die AMD Core Math Library enthält neben LAPACKund BLAS auch noch FFT-Routinen und ist von AMD

speziell auf AMD64 und Opteron Prozessoren opti-miert worden.

ATLAS:steht für Automatically Tuned Linear Algebra Subrou-tines und ist der Versuch, durch Testen und Bewerteneiner großen Anzahl möglicher Implementierungen au-tomatisch eine für die jeweilige Architektur optimalangepasste Version zu erstellen. ATLAS enthältBLAS und wenige Teile von LAPACK.

GotoBLAS:wärend sich viele Implementierungen effizienter Rou-tinen zur Matrizenmultiplikation bei der Optimierungauf die möglichst effiziente Ausnutzung der Speicher-hierarchie (im Wesentlichen der Level 1 und Level 2Caches) konzentrieren, steht bei der GotoBLAS dieMinimierung der Transition Lookaside Buffer (TLB)Misses im Zentrum (der TLB ist ein schneller Zwi-schenspeicher für oft benötigte Zuordnungen zwischenvirtuellen und physikalischen Speicheradressen; wirdeine Zuordnung nicht im TLB gefunden (TLB miss),muss aufwendig in entsprechenden Tabellen gesuchtwerden).Die GotoBLAS ist für die meisten aktuellen Architek-turen erhältlich und bietet in den meisten Fällen dieeffizienteste BLAS-Implementierung. Der Name rührtvom Hauptautor, Kazushige Goto, her.

MKL:in der Intel Math Kernel Library sind neben BLASund LAPACK auch iterative und direkte Methodenzur Lösung schwach besetzter linearer Gleichungssys-teme, FFT-Routinen sowie zusätzliche mathematischeund statistische Routinen vorhanden. Verfügbar ist dieMKL für alle gängigen Intel Prozessoren (Itanium-2,Pentium 4, Xeon) aber auch AMD Athlon64 und Op-teron Prozessoren.

Alle angeführten Bibliotheken sind am Sun Clusterverfügbar.

Performance-Tools

Unter Linux stehen eine Reihe von Tools zur Verfü-gung, die helfen, die Effizienz eines Codes zu beurteilen.

time/times:Mit den Kommando time bzw. dem System Call timeskann die Laufzeit vom Programmen bzw. Programm-teilen gemessen werden.

valgrind:Mit diesem Emulator kann das Verhalten eines Pro-grammes sehr genau analysiert werden; es bietet z. B.einen Cache Simulator, mit dem die Ausnutzung derCache Speicher ermittelt werden kann. Da der dafürnotwendige Aufwand sehr hoch ist, muss mit wesent-lich höheren Laufzeiten (mindestens Faktor 20!) ge-rechnet werden.Weiters gibt es einen so genannten „Memory Checker“,der die Allokierung und Freigabe von Speicherberei-chen analysiert und in der Praxis sehr hilfreich seinkann.

ZIDline 13 – Dezember 2005 – Seite 9

Page 10: ZIDline 13

Oprofile:Bei oprofile wird nicht nur ein einzelner Prozess, son-dern das gesamte System beobachtet. Daher ist es be-sonders prädestiniert zum Auffinden von performancebottlenecks im System. Entspechend der eingestelltenSampling Rate und der gewünschten Hardware Coun-ter wird eine Vielzahl von Daten akkumuliert, diedann mit opreport selektiert ausgegeben werden. Fürdas Starten/Stoppen des Profilings werden Root-Rech-te benötigt; am Cluster können interessierte Benutzerdies über sudo durchführen.

PAPI:Das Performance API (PAPI) spezifiziert ein standar-disiertes Interface für den Zugriff auf Hardware Coun-ter und bietet eine Reihe entsprechender Tools. PAPIbenötigt einen Kernel Patch, der derzeit mit der beste-henden Kernel-Konfiguration nicht kombatibel ist.

Benchmarks

Mit der Einführung der EM64T Technologie bietetauch Intel seit einiger Zeit 64-Bit Prozessoren imx86-Umfeld an. Intel EM64T Technologie ist fast voll-ständig mit der AMD64 Spezifikation kompatibel, sodasszum Beispiel Intel Compiler oder die MKL auch auf Op-teron Systemen eingesetzt werden können. Es gibt teil-weise sehr heftig geführte „Glaubenskriege“, welcherHersteller das bessere Konzept habe und dieleistungsfähigeren Prozessoren herstellen würde.

Durch die Integration des Memory-Controllers aufdem Prozessor Chip haben AMD Opteron-basierte Syste-me eine deutlich höhere Speicherbandbreite zur Verfü-gung als Intels Xeon Prozessoren, wo sich die beidenProzessoren einen gemeinsamen Speicherbus teilenmüssen. Dafür ist der Xeon Prozessor deutlich höher ge-taktet, wodurch Applikationen, die die SSE-3 Einheit ef-

fizient ausnutzen können, deutlich schneller laufen alsauf Opteron Prozessoren.

Von der Standard Performance Evaluation Corporati-on (SPEC) wird eine Reihe von Benchmarks herausgege-ben; für den HPC-Bereich ist der SPECfp2000-Wert vonInteresse, eine Sammlung von insgesamt 14 BenchmarkProgrammen. In den Tabellen werden ein Opteron Sys-tem (Sun V20z mit zwei Opteron 2.4 GHz) und ein XeonSystem (IBM x336 mit zwei Xeon 3.6 GHz und 1 MBL2 Cache) verglichen. Beim SPECfp2000-Wert liegt dasOpteron System deutlich vorne (1747 zu 1641), bei ein-zelnen Benchmarks ist aber dennoch das Intel Systemschneller (zum Beispiel liegt beim equake Benchmarkdas Xeon System mit 67,1 Sekunden zu 95,3 Sekundendeutlich voran).

Ein oft nicht erwähnter Faktor bei derartigen Verglei-chen ist die verwendete Software, speziell die verwende-ten Compiler und Bibliotheken. Die angeführten Resul-tate für die V20z wurden mit den PathScale Compilernerreicht, die Werte bei Verwendung der PGI Compilersind deutlich niedriger (1550).

Da beim SPECfp2000-Benchmark nur ein Prozessorbenutzt wird, kann man damit die maximal erreichbareSpitzenleistung eines Systems illustrieren, aber kaumAussagen über den Gesamtdurchsatz eines Systems tref-fen. Dazu dient der SPECfp2000_rate, bei dem die glei-chen Benchmark-Programme verwendet werden, aller-dings werden die Programme zeitgleich von allem Pro-zessoren ausgeführt. Hier kann das Opteron System dankseiner überlegenen Speicherbandbreite eine Wert von38.7 verbuchen, während das Xeon basierte System nureinen Wert von 28.6 erreicht.

Linpack-Benchmark

Die Top500 Liste ist eine Reihung der 500 leistungs-fähigsten Rechnersysteme weltweit. Als Bewertungskrite-rium wird der Linpack-Benchmark, das direkte Löseneines linearen Gleichungssystems, herangezogen. Mitdem Sun Cluster wurden beim Linpack Benchmark 530Gflop/s bei Verwendung von 130 CPUs erreicht. Um indie Top500 aufgenommen zu werden, ist mittlerweile eineLeistung von deutlich mehr als ein Tflop/s notwendig. Inder Liste vom November 1996 hätten 530 Gflop/s unan-gefochten für den ersten Platz gereicht, und im Novem-ber 2000 immerhin noch für Platz 29.

Links

ZID Sun Cluster: http://www.zserv.tuwien.ac.at/phoenix/valgrind: http://valgrind.org/oprofile: http://sourceforge.net/projects/oprofile/PathScale: http://www.pathscale.com/PGI: http://www.pgroup.com/GotoBLAS: http://www.tacc.utexas.edu/resources/software/MKL: http://www.intel.com/cd/software/products/

asmo-na/eng/ perflib/index.htmATLAS: http://math-atlas.sourceforge.net/PAPI: http://icl.cs.utk.edu/papi/SPEC: http://www.spec.org/TOP500: http://www.top500.org/

Seite 10 – Dezember 2005 – ZIDline 13

Sun MicrosystemsSun Fire V20z

SPECfp2000 = SPECfp_base2000 =

17471636

SPEC license #: 6 Tested by: Sun Microsystems, Santa Clara Test date: Feb-2005 Hardware Avail: Mar-2005 Software Avail: Feb-2005

BenchmarkReference

TimeBase

RuntimeBaseRatio Runtime Ratio 1000 2000 3000 4000

168.wupwise 1600 70.2 2280 65.6 2438

171.swim 3100 150 2069 147 2110

172.mgrid 1800 125 1445 115 1561

173.applu 2100 124 1689 112 1881

177.mesa 1400 78.6 1782 72.9 1922

178.galgel 2900 109 2650 109 2652

179.art 2600 116 2238 88.1 2950

183.equake 1300 97.5 1333 94.3 1378

187.facerec 1900 93.8 2026 88.8 2140

188.ammp 2200 165 1332 155 1420

189.lucas 2000 131 1521 126 1587

191.fma3d 2100 157 1334 153 1371

200.sixtrack 1100 144 766 137 805

301.apsi 2600 180 1441 175 1484

IBM CorporationIBM xSeries 336 (3.6GHz Xeon)

SPECfp2000 = SPECfp_base2000 =

16411625

SPEC license #: 11 Tested by: IBM Corporation Test date: Aug-2004 Hardware Avail: Aug-2004 Software Avail: Sep-2004

BenchmarkReference

TimeBase

RuntimeBaseRatio Runtime Ratio 1000 2000 3000 4000

168.wupwise 1600 55.4 2891 55.4 2887

171.swim 3100 160 1936 160 1936

172.mgrid 1800 119 1509 119 1512

173.applu 2100 145 1444 137 1533

177.mesa 1400 74.9 1869 74.9 1869

178.galgel 2900 136 2129 138 2101

179.art 2600 93.3 2785 93.3 2785

183.equake 1300 67.1 1937 67.1 1937

187.facerec 1900 108 1758 108 1758

188.ammp 2200 230 958 224 983

189.lucas 2000 109 1831 109 1831

191.fma3d 2100 144 1456 144 1456

200.sixtrack 1100 174 634 164 672

301.apsi 2600 215 1208 215 1208

Tabelle SPECfp2000 Benchmark

Page 11: ZIDline 13

ZIDline 13 – Dezember 2005 – Seite 11

Korrekter Einsatz derCampus Software LizenzenAlbert Blauensteiner

An der Technischen Universität Wien wird seit 1992Software für die Institute durch die Abteilung Standard-software des Zentralen Informatikdienstes in systemati-scher und flächendeckender Weise als Campus Softwareangeboten. Diese Software soll einerseits den allgemei-nen Bedarf an Standardsoftware mit möglichst allen stra-tegisch wichtigen Produkten abdecken, in dieser Formauch eine Produktvielfalt bezüglich der Hersteller, derSprachen und der Versionen und der Plattformen zulas-sen, andererseits durch einen Kostenersatz sowohl dasKostenbewusstsein als auch den tatsächlichen Bedarf desEinsatzes regeln. Zu diesem Zweck wurde dieses Servicelaufend ausgebaut und automatisiert, sodass nunmehr aufdem Software Server für die Verteilung der gewartetenProdukte etwa 6 TB Speicherplatz zu diesem Zweck zurVerfügung stehen. Sowohl das Bestellsystem als auchdas Abrechnungssystem ist online und automatisch. Umdie laufenden Verträge mit den Software-Herstellern zubedienen und zu aktualisieren, um die laufenden Updateszu aktualisieren und um den Einsatz technisch zu ermög-lichen ist ein signifikanter personeller und operativerEinsatz notwendig. Das Service ist campusweit anerkanntund sämtliche Organisationseinheiten machen Gebrauchvon diesem Service.

An den Instituten sind über 16.000 Lizenzen im Ein-satz, die mit etwa € 360.000,- Kostenbeiträgen zur Finan-zierung der vertraglichen Wartungs- und Lizenzkostenbeitragen, das sind knapp 50% der tatsächlich anfallen-den Lizenzgebühren.

Jeder, der eine Lizenz registriert hat, kann über denSoftware Server auf die lizenzierten Produkte zugreifen,und diese bei Bedarf auf seinen Zielrechner downloaden.Dieser Zugriff ist passwortgeschützt und eben nur auf dieProdukte beschränkt, die der Lizenznehmer registrierthat. Dabei ist es durchaus plausibel, dass Softwarepro-dukte mehrfach und auf verschiedene Rechensysteme he-runter geladen werden, was in der Praxis auch passiertund nicht eingeschränkt ist. Eine genaue Kontrolle, ob

ein lizenziertes Produkt nur in der tatsächlich lizenziertenAnzahl und von den registrierten Lizenznehmern einge-setzt wird, ist daher nicht eindeutig möglich. Selbst beiProdukten, die über Lizenzserver im Einsatz kontrolliertsind, ist eine genaue Kontrolle des rechtmäßigen Einsat-zes nicht möglich. Es wird im Allgemeinen davon ausge-gangen, dass die Lizenznehmer, die ja die Lizenz-bedingungen unterzeichnet haben und daher zu derenEinhaltung angehalten wurden, sich auch danach richtenund in diesem Vertrauen auch agieren. Das betrifft insbe-sondere den nicht registrierten Einsatz, den Einsatz ingrößerer Zahl als registriert und die Weitergabe von Pro-grammen. Insgesamt muss aber gesagt werden, dass ander Technischen Universität Wien ein hohes Bewusstseinder Lizenzbedingungen vorhanden ist und die Zahl derLizenzen insgesamt nach wie vor bemerkenswert ist.

Trotzdem gibt es einige Anzeichen dafür, dass dieseshohe Bewusstsein, insbesondere auch im Vergleich zuanderen Universitäten, nachlassen könnte. Das liegt inerster Linie daran, dass keinerlei aktive Kontrolle erfolgtund dadurch die Versuchung groß ist, die Lizenzbedin-gungen nicht unbedingt ganz genau zu nehmen. Das umso mehr, als die Finanzlage an den Instituten immer an-gespannter wird. Es ist daher unsere Pflicht, darauf hin-zuweisen, wenn die Lizenzbedingungen nicht immer allzu genau genommen werden.

Das Problem liegt neben der rechtlichen Situationauch darin, dass eine Unterlizenzierung dazu führt, dassdie korrekt agierenden Lizenznehmer relativ mehr fürihre Lizenzen bezahlen müssen als die anderen. DiePreispolitik ist bekanntlich daran ausgerichtet, die tat-sächlich anfallenden Lizenzkosten zu einem Teil zu sub-ventionieren, und den Rest auf die tatsächlichenLizenznehmer aufzuteilen. Je weniger also ein Produkt li-zenzieren, umso teurer wird der Einsatz von Lizenzen fürdie anderen. Und selbst bei den idealen Campus Softwa-re Verträgen, wo mit einer einzelnen Gebühr der Einsatz

Page 12: ZIDline 13

der gesamten Universität ermöglicht wird, führt eine Un-terlizenzierung dazu, dass es so erscheint, dass sich eingroßflächiger Campus Vertrag möglicherweise gar nichtrechnet. Eine ordnungsgemäße Lizenzierung aller Pro-dukte, die auch tatsächlich gebraucht und eingesetzt wer-den, führt also dazu, dass jeder damit rechnen kann, fürsein Produkt einen tatsächlich optimalen Preis für seinenEinsatz zu erzielen. Die Preisvorteile kann man tatsäch-lich auch real daran sehen, wenn man die Campus Soft-ware Preise mit den am Markt befindlichen Preisenvergleicht, selbst wenn Universitätsrabatt eingeräumtwird.

Damit sich die Situation des legalen Lizenzeinsatzesnicht so verschlechtert, dass ein Eingreifen möglicher-

weise zu spät ist, wurden zuletzt die allgemeinen Lizenz-bestimmungen zum Einsatz von Campus Software an derTechnischen Universität Wien adaptiert. Es handelt sichdabei um keine übertriebene exekutive Maßnahme, sollaber von der Gemeinschaft verstanden werden und eineschwache aber immerhin existente Lizenzkontrolle dar-stellen.

Die Abteilung Standardsoftware des Zentralen Infor-matikdienstes tritt nämlich den Herstellern gegenüberweiter in der Form auf, dass sie den rechtmäßigen undausschließlich auf Lehre, Verwaltung und Forschung be-zogenen Einsatz der Software Produkte garantiert und aufdie eigene Lizenzkontrolle verweist und externe Auditsder Hersteller selbst ablehnt.

Seite 12 – Dezember 2005 – ZIDline 13

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1993 07 01

1994 01 01

1994 07 01

1995 01 01

1995 07 01

1996 01 01

1996 07 01

1997 01 01

1997 07 01

1998 01 01

1998 07 01

1999 01 01

1999 07 01

2000 01 01

2000 07 01

2001 01 01

2001 07 01

2002 01 01

2002 07 01

2003 01 01

2003 07 01

2004 01 01

2004 07 01

2005 01 01

2005 07 01

Entwicklung Campus Software Lizenzen

IT Online-Kurse

jetzt auchin deutscher Sprache

http://sts.tuwien.ac.at/lss/

Page 13: ZIDline 13

Allgemeine Lizenzbedingungen

für die Verwendung von Produkten aus dem

Bereich der Campus Software an der TU Wien

(Stand vom 18. 10. 2005)

1. Gegenstand der Lizenzbedingungen ist die Einräumung des nicht ausschließlichen und nicht übertragbarenRechts der Benützung eines Software-Produktes aus dem Bereich der Campus Software durch den Lizenzneh-mer zu den unten angeführten Bedingungen.

2. Der Lizenznehmer verpflichtet sich ausdrücklich, den Lizenzbedingungen zu entsprechen und seinen Mitarbei-tern, die das Produkt verwenden, zur Kenntnis zu bringen.

3. Aus den Lizenzbedingungen ergibt sich für den Lizenznehmer die Verpflichtung, das Software-Produkt nur fürfolgende Zwecke zu benützen:

a) für die Lehreb) für die Forschungc) für die Entwicklung von Lehrsoftwared) für interne Verwaltungszweckee) für Software-Entwicklungsarbeiten betreffend Punkt a) bis d)

4. Dem Lizenznehmer ist es nicht gestattet, Dritten das Recht einzuräumen, Kopien des Software-Produktes oderder Dokumentation anzufertigen.

5. Wenn nicht ausdrücklich anderslautende Hinweise angegeben sind, ist für jede Installation bzw. Nutzung aufjeder Computer-Plattform eine eigene Lizenz erforderlich.

6. Die Verwendung der Campus Software Produkte ist auf den Zeitraum der registrierten Lizenzierung der Soft-ware Produkte begrenzt. Mit der Stornierung der Lizenz erlischt das Recht der Verwendung dieses Produktes.

7. Es ist nicht erlaubt, die Verzeichnisse bzw. deren Inhalte der Campus Software Produkte vom Software-Serverauf eigene Institutsserver zu übertragen und dort zu speichern (spiegeln).

8. Der Zentrale Informatikdienst trägt anstelle der Hersteller selbst Sorge in Bezug auf die Einhaltung der Lizenz-bestimmungen der Campussoftware. Wenn aufgrund von Statistiken, Protokollen oder Logs der Software Ser-ver oder Lizenz Server Auffälligkeiten zu Tage treten, wird der entsprechende Benutzer bzw. ein Freigabebe-rechtigter der Organisationseinheit schriftlich gebeten, die Angelegenheit zu überprüfen und die nötigen Maß-nahmen zu treffen, den ordnungsgemäßen Registrierungsstand der eingesetzten Software wieder herzustellen.Dies wird routinemäßig durch den Leiter der Abteilung Standardsoftware, in eskalierten Fällen durch den Lei-ter des Zentralen Informatikdienstes oder in schwerwiegendsten Fällen durch den Vizerektor für Ressourcenerfolgen. Für diese Rechensysteme, die Software beziehen und Auffälligkeiten zeigen, kann entschieden wer-den, dass von der Abteilung Standardsoftware eine Kontrolle des rechtmäßigen Einsatzes der darauf installier-ten Programme direkt am Rechensystem durchgeführt werden soll. Diese Überprüfung wird dann nach Infor-mation des Leiters der Organisationseinheit und nach Erklärung des Mechanismuses mit einem Verantwortli-chen für das Rechensystem vor Ort durchgeführt. Dabei sollten in der Regel keine Kopien angefertigt werdenoder Kontrollprogramme installiert werden müssen, hingegen muss es aber möglich sein, auch im Beisein Drit-ter protokollarisch die eingesetzten Programme festzuhalten.

9. Wenn durch die im Punkt 8 ermittelten Informationen oder in anderer Weise eine offensichtliche Lizenzverlet-zung nachgewiesen werden kann, stellt der Zentrale Informatikdienst mit der laufenden Abrechnung der Soft-ware Lizenzen für jedes nicht legal eingesetzte Software Produkt den tarifmäßigen Jahresbetrag der CampusLizenz Softwarekosten inklusive Einstiegsgebühr ohne besondere Zustimmung der Organisationseinheit inRechnung. Die dadurch betroffenen Produkte gelten den Software Herstellern gegenüber im Nachhinein als li-zenziert.

10.Der Lizenznehmer verpflichtet sich zur Bezahlung eines Kostenbeitrages in vereinbarter Höhe an den Zentra-len Informatikdienst. Die durch diese Kostenbeiträge erzielten Einnahmen sind zweckgebunden und werdenvom Zentralen Informatikdienst für Anschaffungen im Bereich der Campus Software verwendet.

Page 14: ZIDline 13

Seite 14 – Dezember 2005 – ZIDline 13

Spam CatchJohann Klasek

Zusätzlich zur Spam-Markierung eingehender E-Mails, gibt es nun die Möglichkeit, individuelleine weitere Behandlung der E-Mails wie Blockieren und Ignorieren abhängig von der Spam-Bewertung zu aktivieren.

Der Anfang

Seit geraumer Zeit verfügt die TU Wien über ein zen-trales Spam-Markierung-System, das eingehende E-Mailsmit einem Score zur Spam-Erkennung bewertet. Dabeikommen unterschiedlichste Methoden der Erkennungzum Tragen, unter anderem Bayesian Filter, DNS-basier-te Blacklists, Muster in E-Mail-Header oder E-Mail-In-halt, die zusammen in einen finalen Score münden.Dabei wird als feste Vorgabe von einer Grenze bei einemScore-Wert von 6,0 ausgegangen, die für sich noch nichtgenerell über Spam oder Nicht-Spam (gerne auch alsHam bezeichnet) entscheidet. Es wird lediglich eine ge-wisse Wahrscheinlichkeit angedeutet, dass es sich bei ei-ner E-Mail mit Score � 6,0 um eine Spam-Mail handelnkönnte. Diese wird durch entsprechende Ergänzungen imE-Mail-Header, unter anderem durch die Markierung desE-Mail-Betreffs, unterstrichen (um allen Mail-Clients dieMöglichkeit der Filterung basierend auf diesen Informa-tionen zu ermöglichen).

Soweit der bisherige Status. Die Markierung allein hataber gewisse Limitierungen, wie z. B. dass eine tatsächli-che Filterung erst direkt im Mail-Client, bestenfalls amServer der eingehenden Mailbox, erfolgen kann. E-Mails,ob Spam oder Ham, wandern ständig durch das TUNET.Speziell die Filterung auf einem eventuell sogar mobilenMail-Client (Handy, PDA) hat den Nachteil, dassSpam-Mails über eine eventuell bandbreitenschwacheVerbindung mitübertragen werden müssen.

Über die nun auf den zentralen Mailservern verfügba-ren Mail-Optionen kann jeder Benutzer E-Mails bei Errei-chen eines frei festlegbaren, individuellen Score-Wertesverwerfen lassen. Als Ergänzung steht auch noch zur Aus-wahl, ob man die – manchmal unerwünschte – Markie-rung „[SPAM?]“ im Betreff haben möchte oder nicht.

Seit 27. September 2005, gemäß ZIDnews-Ankündi-gung [2], steht nun das Setzen dieser zentralen Mail-Op-tionen (Dokumentation siehe [3]) zur Verfügung.

Wer kann diese Möglichkeiten nutzen?

• Sowohl Studenten und Personal als auch weitere Mitar-beiter (nicht in einem Dienstverhältnis zur TU Wien ste-hende Personen), die in den White Pages [4] einenEintrag besitzen.

• Für das Eintragen und Ändern ist das TU-Passwort [5]erforderlich.

• Die Bearbeitung erfolgt über Daten ändern des persönli-chen White Pages Eintrages.

Auch nach Ablauf des Dienstverhältnises, also wenneine Person nicht mehr in den White Pages aufscheint,bleiben die generische E-Mail-Adresse und alle mit derPerson verbundenen E-Mail-Optionen ein Jahr lang aktiv.

Auf welche E-Mail-Adressen wirkt sich das aus?

Die Einstellungen können für verschiedenste Varian-ten der persönlichen E-Mail-Adresse gesetzt werden:

• Alle Formen der generischen (auch allgemeine)E-Mail-Adressen endend auf @tuwien.ac.at [email protected].

Page 15: ZIDline 13

• Sonstige TU Wien-Adressen der Form *@*.tuwien.

ac.at, die üblicherweise direkt die Mailbox auf Mailser-vern innerhalb des TUNETs adressieren. Das ist z. B.jene, die in den White Pages als Zustelladresse (Weiter-leitungsadresse für die generische Adresse) über das At-tribut Mail angegeben wurde. Aber auch andere, nicht inden White Pages sichtbare E-Mail-Adressen können be-rücksichtigt werden. 1

• Adressen von speziellen, am ZID registrierten, externenMail-Domains (die nicht auftuwien.ac.at enden), dieüber die zentralen Mailserver der TU Wien abgehandeltwerden. 1

Z. B. haben derartige Angaben bei gmx.at-Adressen (dienicht über die TU Wien geleitet werden) keinen Effekt.

Bei der Angabe von nicht generischen Adressen wirddie Richtigkeit der eingetragenen E-Mail-Adresse durchein Challenge-Response-Verfahren verifiziert, um einenMissbrauch „fremder“ Adressen zu vermeiden, aber auchum die Korrektheit der Adresse zu überprüfen. Dazuwird – nur bei erstmaliger Angabe – der E-Mail-Adresseeine „Challenge“-E-Mail an eben diese gesendet. Dieseenthält eine URL, die man aufrufen muss („Response“).Erst dann werden die Einstellungen zur E-Mail-Adressetatsächlich übernommen.

Wie sonst auch bei Mailrouting-Änderungen üblichwirken sich diese auf den Servern binnen 10 Minuten aus(unter gewissen, eher seltenen Umständen könnte es auchlänger dauern, aber sicher nicht länger als eine Stunde).

Generell müssen die einzutragenden E-Mail-Adressenimmer real existierenden E-Mail-Adressen entsprechen.Die Angabe von Mustern oder Wildcards ist nicht mög-lich. Lediglich die generische Adresse subsummiert alleimpliziten Varianten einer generischen Adressen (siehedazu [6]).

Welche Einstellungen sind möglich?

• Blockieren:Mit einem Score-Wert für das Blockieren können damitbewertete E-Mails an den zentralen Mailservern abge-wiesen werden. Dies passiert dann in einer Art, dass derAbsender in Form einer Bounce-Mail von der Abwei-sung informiert werden sollte.Eine Einschränkung tritt allerdings ein, wenn in einerübermittelten E-Mail mehrere Empfänger adressiert sindund diese Empfänger unterschiedliche Blockierungsein-stellungen haben. Dann ist nämlich der höchste Score-Wert aller Empfänger ausschlaggebend (wenn nichtexistent, dann entspricht das dem Score-Wert „unend-lich“ und die E-Mail kann stets passieren). Somit wirktsich die Blockierung nicht immer zwingend aus.

• Ignorieren:Hier führt die Überschreitung des angegebene Score-Wertes immer dazu, dass die E-Mail für einen persönlichunterdrückt wird. Allerdings merkt ein Absender prin-zipbedingt davon nichts, hat also keine Kenntnis, dass dieE-Mail verworfen wurde. Daher ist der dafür vorgesehe-ne Score-Wert entsprechend vorsichtig zu wählen, daFalse-Positives stillschweigend untergehen könnten.

• Markierungsoption:Die Vorgabe ist, dass im Betreff eine Markierung„[SPAM?]“ eingefügt, wenn der Score einer E-Mail 6,0erreicht bzw. überschreitet. Daher ist diese Option in derVoreinstellung angehakt. Entfernt man die Anwahl, wirdversucht, die Markierung zu unterlassen. Auch hier trittder Nebeneffekt auf, dass bei mehreren Empfängern alledie Markierung unterdrückt haben müssen, damit sichdies auswirkt (d. h. im Zweifelsfall bleibt die Markierungerhalten).Es bleibt der Spam-Status an anderen zusätzlich vomSpam-Markierungsservice [7] hinzugefügten Mail-Hea-dern erkennbar.

Die Optionen Blockieren und Ignorieren sind noch ineinigen kleinen Details miteinander verbunden. Fehltetwa die Angabe eines Blockierwertes, wird dieser impli-zit auf den Ignorierwert gesetzt. Ebenso wenn es z. B. beiallen Empfängern einer E-Mail zu einem Ignorieren kom-men sollte, wird daraus ein Blockieren (für den Einzel-empfänger ist ein Ignorieren eigentlich immer einBlockieren!). Damit versucht das Mailsystem, wenn im-mer es geht, die sicherere Variante (nämlich die zu einemBounce beim Absender führt) zu verwenden.

Typischer Anwendungsfall

Ausgangspunkt der Überlegungen ist der zentral vor-gegebene Score-Wert von 6.0. Mit einem Blockierwertvon 8.0 hat man etwas Spielraum für überbewertete regu-läre E-Mails. Zusätzlich kann man dann je nach bisher-igen Erfahrungen einen Ignorierwert von z. B. 12.0angeben, womit die „schweren“ Spam-Fälle tatsächlichsang- und klanglos verschwinden und das Risiko, einereguläre E-Mail zu erwischen, schon recht gering ist.

Ist man mutiger, z. B. etwa bei Zusatzadressen, dienicht primär genutzt werden, kann man sich auf die An-gabe eines Ignorierwertes von 9.0 (ohne Blockierwert)festlegen. Wie oben erwähnt, wirkt sich ein Ignorieren,für den Einzelempfänger einer E-Mail sowieso, ohnehinals Blockieren aus.

Weitere Informationen sind unter [3] verfügbar, wodas Konzept im Detail, eine Übersicht und ein Fra-gen-Antworten-Abschnitt zu finden sind.

Referenzen:

[1] Spam-Markierung Artikel ZIDline 8, S. 6:http://www.zid.tuwien.ac.at/zidline/zl08/spam.html

[2] Ankündigung „Benutzerspezifische Anti-Spam Einstel-lungen“ in den ZIDnews:http://www.zid.tuwien.ac.at/zope/zidnews/aktuell_detail_html?newsid=341.341

[3] Mailservice: E-Mail-Optionen:http://nic.tuwien.ac.at/services/mail/options/

[4] White Pages: http://whitepages.tuwien.ac.at/[5] TU-Passwort FAQ:

http://www.zid.tuwien.ac.at/passwortFAQ.html[6] White Pages Dokumentation:

http://nic.tuwien.ac.at/services/white/#mail-adressierung[7] Spam-Markierungsservice

http://nic.tuwien.ac.at/services/mail/spam-markierung/

ZIDline 13 – Dezember 2005 – Seite 15

1 nur für TU-externe Absender wirksam

Page 16: ZIDline 13

Seite 16 – Dezember 2005 – ZIDline 13

PXE-Bootservice:Installation von Windows/Linuxüber PXE-Netboot

Martin Holzinger

Zum Aufsetzen von Rechnern, die über kein Floppy- bzw. CD/DVD-Laufwerk verfügen, wurde dieMöglichkeit einer Installation über Netzwerk untersucht. Der Bootvorgang erfolgt dabei mittelsPXE (Preboot Execution Environment ). Über einen temporär im Subnetz gestarteten DHCP-Serverwird der zu installierende Client zu einem TU-internen Boot-Server weiter geleitet.

PXE-Boot und Setup von Linux über Netzwerk istschon seit längerer Zeit Standard und soll hier nur kurzbeschrieben werden:

Vor dem eigentlichen Boot-Vorgang sendet die Netz-werkkarte des Client DHCP-Requests aus und bekommtvom Server zunächst seine Koordinaten im Netzwerk(IP-Adresse, Subnet-Mask, Gateway, Domain-Name etc.)zugewiesen. Über den Netboot-Loader pxelinux.0 wirdein Willkommens-Bildschirm präsentiert, nach Auswahleiner Option erfolgt der eigentliche Boot-Vorgang durchTransfer einer Boot-Image-Datei mittels TFTP (Port 69).Ab hier übernimmt der Linux-Kernel in gewohnter Wei-se das Setup.

Hinsichtlich des Setups von Windows-Betriebssyste-men nehmen nun folgende Überlegungen Rücksicht aufdie speziellen Gegebenheiten im TUNET:

• Die Möglichkeit eines Redirect mittels der next-server-Option bedeutet, dass ein TU-weiter Boot-Server reali-siert werden kann. Ein DHCP-Server ist hingegen stetsim Subnetz erforderlich und temporär zu betreiben, daDHCP-Requests nicht geroutet werden.

• RIS (Remote Installation Service), die Microsoft-Lösungzum Setup von Windows, kommt für einen TU-weitenBetrieb nicht in Frage, der Zugang zu den Installa-tions-Bits soll auf jeden Fall über den Software-Distri-butionsserver (Solaris) unter Passwort-Validierung er-folgen.

• Es kann problemlos von Floppy-Images in ein 16-Bit-DOS mit Netzwerkunterstützung gebootet werden. Nachanschließendem Mounten des Software-Distributions-servers lassen sich dann alle Windows-Versionen außerXP installieren.

• Windows XP hat in der Campus-Version den Aktivie-rungskey eingearbeitet, aus diesem Grund muss die Setup-

Prozedur aus einem 32-Bit Betriebssystem heraus auf-gerufen werden. Microsoft stellt hier mit WINPE (Pre-installation Environment) eine solche Umgebung zurVerfügung, der Bootvorgang von WINPE über pxelinuxist jedoch schwierig zu realisieren und lässt an Komfortzu wünschen übrig.

BartPE

BartPE (für nähere Informationen siehe http://www.nu2.nu/pebuilder/) ist mehr als eine Alternative zuWINPE von Microsoft. Während WINPE lediglich einedürftige 32-Bit Command-Shell mit englischem Tastatur-treiber präsentiert, handelt es sich bei BartPE um einThin-Client-Windows mit automatischer Netzwerkkonfi-guration (über DHCP), Anpassungsmöglichkeit der Bild-schirmauflösung und des Tastatur-Layouts sowie vielenweiteren Tools wie File Managern (A3 und Total Com-mander), VNC, Putty, Remote-Desktop-Verbindung,Web-Browser und anderes mehr. Auch können weiterekommerzielle Tools eingearbeitet werden: Backup-Soft-ware wie Ghost oder Acronis, Viren-Scanner etc.

Der Willkommens-Bildschirm

Page 17: ZIDline 13

Zum Vorbereiten der Festplatte steht diskpart zur Ver-fügung. Der Nachfolger von fdisk ermöglicht das Anle-gen von NTFS-Partitionen im Terabyte-Bereich. DieSyntax ist etwas gewöhnungsbedürftig: Um beispielswei-se auf einem leeren Datenträger eine primäre NTFS-Par-tition mit 10 GB anzulegen und als Laufwerk C: zuaktivieren, verfährt man folgendermaßen:

Sel DIS 0

Clean

CRE PAR PRI SIZE=10240

ASSIGN LETTER C:

ACT

Nach dem Formatieren des Datenträgers (etwa in derDOS-Shell) kann dann in gewohnter Weise eine Samba-Verbindung zum Software-Distributionsserver (swd.tuwien.ac.at) aufgebaut werden �. Die Installation desgewünschten Betriebssystems geschieht durch Aufruf vonsetup.bat im jeweiligen Installationsverzeichnis �.

Eine elegante Lösung:BartPE über Netzwerk booten

Es liegt nun der Versuch nahe, BartPE (anstatt wievom Entwickler vorgesehen von CD) über PXE zu booten.Als Prototyp des Boot-Servers fungiert dabei eine disk-less-Linux-Variante (bootet von CD und lädt die PE-In-stallationsdateien ins Ramdrive), Devil-Linux 1.2.3, vgl.http://www.devil-linux.org/.

Eine detaillierte Anleitung zur erfolgreichen Realisie-rung findet sich unter http://oss.netfarm.it/guides/pxe.php,im Wesentlichen sind folgende Punkte zu beachten:

• Voraussetzungen: Der Client muss über eine PXE-boot-fähige Netzwerkkarte verfügen und im BIOS muss dieseBootoption aktiviert sein �. Ein DHCP-Server ist imSubnetz mit der next-server-Option (redirect auf denBoot-Server�) zu starten, der dem Client eine IP-Adres-se mit gültigem DNS-Eintrag (notwendig für die Verbin-dung zum Software-Distributionsserver) zuweist�. AmInstitut ist demnach ein weiterer Rechner erforderlich.Die TFTP-Root des Boot-Servers wird nach dem Bootvon CD in den Arbeitsspeicher kopiert und der TFTP-Daemon wird gestartet.

• Etwas trickreich ist das chain-loading: Der original Net-workloader von Microsoft wird mit einem Hexeditor et-was modifiziert und von pxelinux.0 als default Loaderpräsentiert. Per TFTP werden (die ebenfalls hinsichtlichder Dateistrukturen modifizierten Windows-Loader)ntldr und ntdetect.com geladen und exekutiert.

• Zur Erkennung der Netzwerkkarte (etwa 1500 werdenunterstützt) muss am Boot-Server ein weiteres Servicepermanent gestartet sein: Der Boot Information Negotia-tion Layer (BinL-Service) ist dem Original von Micro-soft in Python nachprogrammiert.

• Nach erfolgreichem Erkennen der Netzkarte werden aufdem Client SMB-Treiber geladen und die Datei winnt.sifverarbeitet. In ihr finden sich Informationen bezüglichComputername und Ort der Installationsdateien. Ab die-sem Zeitpunkt geht der Datentransfer von TFTP zu SMBüber, am Boot-Server muss also auch ein SMB-Service(mit anonymous login) gestartet sein.

• Der restliche Boot-Vorgang gleicht dem von CD �.• Um mehreren Clients gleichzeitig das Booten zu ermög-

lichen, müssen unterschiedliche Computernamen verge-ben werden. Dazu wurde das Python-Script (also derBinL-Server) dahingehend modifiziert, dass nach jedemerfolgreichen Boot die Datei winnt.sif mit anderem Com-puternamen neu generiert wird.

Zu bemerken ist, dass der Boot-Vorgang in einem100 MBit-LAN etwa um einen Faktor 5 schneller erfolgtim Vergleich zum Booten von BartPE über CD-Lauf-werk. Dies ist vor allem auf den Umstand zurückzufüh-ren, dass ein Datentransfer RAM-LAN-RAM vomBoot-Server zum Client erfolgt.

Es ist geplant, das PXE-Bootservice im Rahmen desPlattform-Supports zu unterstützen.

ZIDline 13 – Dezember 2005 – Seite 17

BartPE: Ein 32-Bit Thin-Client mit allen notwendigen Add-Ons

SWD ZID� Installations-Bits

Boot-Server ZID� SMBD

TFTPD

BinL-Server

PE-Bits

SUBNETZ

InstallationNetzlaufwerk verbinden

Redirect

Boot-Image+ Preinstallation-Environment

IP-Adresse + Konfiguration

PXE: DHCP Request

Zu installierender Client Temporärer DHCP Server

1

56

3

4

2

Der schematisierte Boot-Vorgang

Page 18: ZIDline 13

Seite 18 – Dezember 2005 – ZIDline 13

Ansichtssacheein Vista BetatestMartin Holzinger

Wir haben im Zuge von Tests Build 5112 rei vistae näher betrachten dürfen und einigeNeuigkeiten des geplanten XP-Nachfolgers entdeckt. Die frühe Beta-Version soll mit Ende 2006zur Finalversion gereift sein, die Server-Version Anfang 2007. Am Campus kann man nachheutigem Stand diese Dekade sicher und stabil mit XP SP2 zu Ende fahren.

Systemvoraussetzungen und Strukturen

Über die Hardware-Voraussetzungen herrscht noch ei-nige Konfusion, unser schwächster Testrechner weist dieEckdaten 20/512/1,2 (GB HDD/MB RAM/GHz) auf undkann ohne Probleme und mit vernünftiger Geschwindig-keit mit Vista betrieben werden. Die Installation kann inder vorliegenden Version (Offset 00253C40 von setup.exevermeldet Windows Version 6.0 Build 5112) ausschließ-lich durch Booten von DVD gestartet werden, der Daten-träger ist mit 2,5 GB erschreckend voll. EineVervierfachung im Vergleich zum XP-Installationsmedi-um erklärt sich vor allem durch ein 1,3 GB-Treiberver-zeichnis.

Dem neugierigen Auge fallen auf dem Medium dieDateien boot.wim (dem Pendant zu WINPE) und install.wim (wird beim Setup auf die Harddisk kopiert) im Ver-zeichnis sources auf. Windows Imaging nennt sich dieneue Technologie, im Zuge der Windows Automated In-stallation (WAIK) können mit einem Tool namens XIma-ge die beiden hochkomprimierten Dateien gemountet,modifiziert und wieder eingepackt werden. Womit derEinarbeitung des – seit XP obligatorischen – Aktivie-rungskeys nichts im Wege stehen wird, die unbeaufsich-tigte Installation, die ja auch in der Campus-Version vonXP Verwendung findet, wird erweitert und basiert aufXML.

In bis zu 7 Produktversionen soll Vista übrigens aufden Markt kommen, von der Starter bis zur Ultimate Edi-tion reicht das Spektrum. Zusätzlich sind 64-Bit-Versio-nen verfügbar und wurden in die Tests einbezogen, dieLonghorn-Server komplettieren das Sortiment.

Setup

Markant vermeldet der graphische Boot-Manager (mitMaus-Unterstützung!), dass nur wenige einfache Schrittenotwendig sind (die Eingabe des 25-stelligen Keys aufeiner deutschen Tastatur bei geladenem englischen Tasta-tur-Driver ist einer davon), um die Installation erfolg-reich zu komplettieren. Zusätzliche Harddisk-Treiberkönnen vor der Partitionierung und Formatierung (nurNTFS) gegebenenfalls über Floppy, CD-Laufwerk oderUSB bereitgestellt werden, die Konfiguration des Netz-werkes ist zu diesem Zeitpunkt nicht vorgesehen. Brichtman die Installation ab, so wird dennoch versucht, mitder IP-Adresse 131.107.113.76 („sqm.msn.com“) Kontaktaufzunehmen.

Nach etwa 90 Minuten ist die Installation komplett,dabei werden durchgehend DHCP-Broadcasts gesendetund versucht, Microsoft zu kontaktieren. Auffällig auch,dass Router auf IPv6-Tauglichkeit überprüft werden.Nach einem Reboot nach Beendigung der Installationbraucht man sich gar nicht erst einzuloggen, es wird au-tomatisch ein Administrator-Account ohne Passwort an-gelegt, sehr bequem. Wir verpassen dem Administratordennoch ein Passwort, weil von Interesse ist, ob ein Li-nux-Tool in der Lage ist, dieses wieder zu löschen. Inder Tat, Lesen und Schreiben am neuen Hive hat funktio-niert.

Binnen 4 Tagen verlangt das System nach einer Akti-vierung bei Microsoft, sonst wird mit eingeschränkterFunktionalität gedroht. Nach Durchführung der Aktivie-rung ziehen wir ein Acronis-Image, um das System nachden diversen Tests und Software-Installationen im Zugevon 20 Minuten wiederherstellen zu können – sowohlGhost als auch Acronis funktionieren per Boot CD.

Page 19: ZIDline 13

Einige Neuigkeiten in Kürze

Das graphische Erscheinungsbild ist mit Sicherheitnoch nicht in der endgültigen Version vorliegend, dasDefault-Design AERO mithin Geschmacksache, bringtaber transparente Fenster und skalierbare Icons. Nicht imBuild enthalten die geplante Sidebar, in der so genannteGadgets eingebunden werden können (sie zeigen Uhrzeit,Temperatur, Nachrichten, …). Völlig unbrauchbar derExplorer in seiner Default-Einstellung, das Layout lässtsich aber immerhin wieder auf klassisch trimmen undgibt dann auch die Sicht in die Systemverzeichnisse frei.Die gesamte Benutzeroberfläche wurde von bitmap- aufvektorbasiert umgestellt – dies lässt vermutlich die Instal-lation des Cisco-Client (notwendig für SAP!) scheitern.

In Sachen Sicherheit wird sich Einiges ereignen, dieintegrierte Firewall sollte auch ausgehende Datenpaketefiltern können (davon war noch nichts zu bemerken, au-ßerdem war das Firewall-Logging nicht zu aktivieren).Network Access Protection überprüft auf den aktuellenPatch-Level und blockiert gegebenenfalls den Zugangzum LAN. Wichtig ist hier die Feststellung der vollenFunktionalität von Vista im Zusammenspiel mit demTU-internen Update-Server msus, zwar gibt es klarerwei-se keine Patches für die Beta, die Service-Packs für dieOffice-Familie konnten aber durchwegs reibungslosbezogen werden.

Der Internet Explorer wartet in der Version 7 mit eini-gen Neuerungen auf, es wird einen Safe Mode geben,endlich kommt auch Tabbed Browsing, es wird einenPhishing Filter geben. Und das Erfreulichste: Ausdruckeaus IE7 werden endlich nicht mehr seitlich abgeschnitten,Frames lassen sich individuell ausdrucken. Dies wurdeunter verschiedenen Druckern überprüft und verifiziert.Die gängigen Internet-Checks zur Browser-Security mel-den wenige bis keine Schwachstellen.

Mit NTFS 6 kommt ein transaktionelles Filesystem(TxF) zum Einsatz, WinFS wurde auf einen späteren

Zeitpunkt verschoben. Man redet von einem „selbsthei-lenden Filesystem“, das versucht (falls korrupt), sichselbst und online zu reparieren. Die Kompatibilität zuXP, aber auch zu Linux, ist dabei voll gegeben. Neuauch die Möglichkeit von symbolischen Links, in derCommand-Line gibt man dazu den Befehl mklink.

Für Entwickler noch erwähnenswert die auf .NET ba-sierende Programmierschnittstelle WinFX mit der Win-dows Presentation Foundation (vormals Avalon) und derWindows Communication Foundation (vormals Indigo).

Viel wird dabei umgerüstet auf XML, so wurde bspw.der Event-Viewer (Start-Ausführen: compmgmt.msc)zum auf XML basierenden „Windows Event Viewer“,der eine massive Erweiterung erfahren hat.

Überzeugend für eine Beta-Version die Vorstellungvon Build 5112 hinsichtlich Software-Kompatibilität (Vi-renscanner und Backup-Software haben erwartungsge-mäß Probleme), es ist bereits volle Kompatibilität zuMicrosoft-Produkten wie der Office-Familie gegeben.Reibungslos funktioniert die Connectivity im Netzwerk,verschiedene Tests unter Einbeziehung diverser Client-Server-Konfigurationen (Server2003/Vista Server als Do-main Controller mit verschiedensten Clients) gaben kei-nen Anlass zur Klage. Ohne Probleme alle Verbindungenper Samba, egal ob hin zu Linux-, Unix-, Windows- oderNovell-Servern. Und ein Benchmark weist Vista bereitsjetzt nur um Nuancen schwächer im Vergleich zu XPSP2 aus.

Applikationen-Kompatibilität

Im Zuge der Tests wurde Vista – neben einem Bench-mark – speziell auf die Verträglichkeit mit am TU-Cam-pus verfügbaren Software-Produkten untersucht. In derTabelle sind die Testergebnisse des Vista Beta-Test-Teams (A. Blauensteiner, M. Holzinger, N. Kamenik, A.Klauda, M. Selos, W. Selos) angeführt.

Die Roadmap soll uns noch im Dezember 2005 dieBeta 2 bescheren, nach RC0 im April und RC1 im Juniist RTM im August 2006 angesagt und die Finalversionim November 2006 geplant. Wir werden sehen.

ZIDline 13 – Dezember 2005 – Seite 19

Nicht jedermanns Sache: Der Explorer

Hardlinks, symbolische Links und Verknüpfungen in Vistas NTFS 6

Page 20: ZIDline 13

Seite 20 – Dezember 2005 – ZIDline 13

Software Bemerkung

x86 Client AMD-Athlon 1.2

Druckerinstallation HP Lj 4345 - lpr-inst.? (tcp/ip lostconnection)

Benchmark-Software SANDRA - error 1752

EvID4226Patch223d-en - falscher tpcip.sys (nachset perm. in \drivers) 2

BitTornado-0.3.13-w32install + keine Limitierungfeststellbar (150 seeds)

MS Technet 2005 (DVD01) + full + Europe 2 (deutsch)

MS Digital Image Suite 2006EN - full

+

SAP - Cisco Systems VPNClient 4.0.3

- minimum screenresolution of 800x600required 3

Matlab 7 Rel. 14 SP2 + v.a. Demos und eigene3D-Grafiken OK

SigmaPlot 9 STW von CD +

Passmark Performance Test v6.0x86 P4 2.8 GHz/512 MB Pundit

XP Pro Vista

CPU - Integer Math 57.6 55.7 MOps./Sec.

CPU - Floating Point Math 285.4 266.0 MOps./Sec.

CPU - Find Prime Numbers 207.5 200.9 Operations per second

CPU - SSE/3DNow! 1290.4 1235.2 Mill. Matrices/Sec.

CPU - Compression 1971.3 2006.6 KBytes/Sec.

CPU - Encryption 13.9 13.2 MBytes/Sec.

CPU - Image Rotation 214.1 206.0 Rotations/Sec.

CPU - String Sorting 676.0 661.1 Thousand Strings/Sec.

Graphics 2D - Lines 103.5 101.9 Thousand Lines/Sec.

Graphics 2D - Rectangles 42.4 82.1 Thousand Images/Sec.

Graphics 2D - Shapes 39.1 35.6 Thousand Shapes/Sec.

Graphics 2D - Fonts and Text 93.6 60.8 Operations per second

Graphics 2D - GUI 200.6 86.5 Operations per second

Graphics 3D - Simple 98.6 137.1 Frames per second

Graphics 3D - Medium 17.8 20.4 Frames per second

Graphics 3D - Complex 2.8 2.8 Frames per second

Memory - Allocate Small Block 1141.4 826.9 MBytes/Sec.

Memory - Read Cached 1866.2 1698.5 MBytes/Sec.

Memory - Read Uncached 1283.8 1236.4 MBytes/Sec.

Memory - Write 709.7 697.1 MBytes/Sec.

Memory - Large RAM 89.3 68.9 Operations per second

Disk - Sequential Read 51.7 47.0 MBytes/Sec.

Disk - Sequential Write 52.2 49.7 MBytes/Sec.

Disk - Random Seek + RW 2.5 2.4 MBytes/Sec.

CPU Mark 387.6 373.0 Composite average

2D Graphics Mark 321.8 301.1 Composite average

Memory Mark 376.3 334.7 Composite average

Disk Mark 384.9 358.4 Composite average

3D Graphics Mark 38.1 51.3 Composite average

PassMark Rating 299.0 281.0 Composite average

Software Bemerkung

x86 Server AMD-Athlon 1.2 1

MS Project 2003 von CD + Lesefehler ASUS E616,Philips RW1208 ok

Maple 9.5 von CD - hängt kommentarlos

Maple 10 von SWD - java.lang.NullPointerException

LabVIEW 7.0 EN ~ Windows installer hasstopped working 4

SigmaPlot 9 von CD +

Applikationen-Kompatibilität

1 Der Gerätemanager hat in den System Devices ein gelbesRufzeichen neben IPMI Device Driver. Könnte mit Monitoring/Power Management zusammenhängen.

2 Was zu erwarten war: Von Interesse ist, ob die Anzahl der gleich-zeitigen Verbindungen wie bei XP SP2 auf 10 limitiert ist ?!http://www.lvllord.de/?lang=de&url=tools

3 bei einer Auflösung von 1024x768. Die Vista-Graphik ist nunvektor- statt bitmaporientiert.

4 LV lässt sich aber dennoch starten. Beispiele ok.

Status:+ voll funktionsfähig- fehlgeschlagen~ bedingt funktionsfähig

Page 21: ZIDline 13

ZIDline 13 – Dezember 2005 – Seite 21

Software Bemerkung

x86 Client P4 2.8 Pundit

Sophos Antivirus remote (‘neu’) - hängt bei paket 2

Benchmark-Software SANDRA - error 1752

j2re-1_4_2_05-windows-i586-p.exe + Java Runtime Env. ausZID-ADD

Offline NT-Passwort-Hack + Passwort auf Blank ok

Druckerinstallation HP Lj 4345 - lpr-inst.? (tcp/ip lostconnection)

Visual Studio .NET 2003 EN + von Original-CDs, ohneMSDN

MS Office 2003 EN full + von SWD

MS Project 2003 Pro EN +MUI-Italian

+

MS Visio 2003 Pro EN +MUI-Hung.

+

MS Office 2003MUI-Pack:German+Hindi

+

AU-GUI zum Setzen auf msus + msus: Office/Project/Visio-Updates OK

Symantec Antivirus CorporateEd. V10

- BSOD (0x8E)BAD_POOL_CALLERsavrt.sys

MS Visio 2003 +

MS Visio 2003 von CD + Lesefehler ASUS E616,Philips RW1208 ok

Maple 9.5 von CD - hängt kommentarlos

Maple 10 von SWD - java.lang.NullPointerException

LabVIEW 7.0 EN ~ Windows installer hasstopped working 6

MS Word 2003 + SP2 +

x86 Client P4 VM-Ware

FreeAV (www.freeav.de) + läuft, updates ok

CorelDraw 12 + öffnen, bearbeiten OK

Adobe PhotoShop CS2 (9.0) +

Acronis True Image 8 - Beim Backup bleibt eshängen (100% CPU)

Adobe Acrobat 7.0 (inkl.Designer)

+

AutoCad 2006 deutsch ~ manuelle installation von.Net Framework 7

Outlook Express + ist die ganz normaleVersion 6.0 wie XP!

Mozilla FireFox (deutsch) +

Mozilla Thunderbird (deutsch) +

Java RunTime 5.0 +

Status:+ voll funktionsfähig- fehlgeschlagen~ bedingt funktionsfähig

Software Bemerkung

x64 Client Xeon 3.0

MS Visual Studio .NET2003 EN

+ von SWD, wsus_logs.exe OK

MS Office 2003 EN full + von SWD

HP Laserjet 8000 PS + integrierter Windows-Treiber

AU-GUI zum Setzen aufmsus

+ Office-Updates OK

Mathematica 5.2 auflserver

+ Zahnsimulation ok

Sandra 2005.7.10.60 - Startet nicht (Host Connectreq.)

SAP für TU Installation - VPN Client uninstallierbar(800x600 Resolutionrequested)

Adobe Acrobat 7 ~ Warning 20225 - No PDFPrinter Appears 5

x86 Client P4 VM-Ware

Dreamweaver MX2004 +

Symantec Client Securityv3.0 deutsch

- beim Starten stürzt Vista ab

Adobe Golive v8.0cs2 - kann Setup nicht starten

Macromedia Authowarev7.1 englisch

+

Eudora v6.12 +

Adobe InDesign v4.0cs2deutsch

+

Diskeep v9.0 - kann Setup nicht starten

Northon Ghost v8.0_corp/deutsch

- kann Setup nicht starten

Northon Ghost v8.0_corp/englisch

+

Norton Commander v2.0/englisch

+

Macromedia Homesitev5.0/ englisch

+

5 ist 64-Bit spezifische Fehlermeldung,vgl. http://www.adobe.com/support/techdocs/321546.html

6 LV lässt sich aber dennoch starten. Beispiele ok

7 Es war nur ein Sprachenkonflikt. AutoCad hat eine deutsche Ver-sion von Dot.Net FrameWork in den englischen Vista installierenwollen und die hat einen Fehler verursacht. Nach dem Downloadund Install der englischen Version hat AutoCad nur mehr das deut-sche Sprachpaket für .Net installiert und dann ging auch der Rest.

Page 22: ZIDline 13

Seite 22 – Dezember 2005 – ZIDline 13

Firewall-Regeln fürWindows Domain Controller(und diesbezügliche Erfahrungen mit Vista)

Walter Selos

Da öfters der Wunsch besteht, den Domain Controller hinter einen Firewall zu stellen, um ihnsowohl von außen, wie auch vor den Domain Members zu schützen, haben wir im Zuge derVista-Betatests eine Konfiguration getestet, bei der der Domain Controller hinter einem „bridgingFirewall“ (siehe Seite 24) betrieben wird.

Die folgenden Hinweise gelten sowohl für Windows2000/2003 Domains als auch für die Betaversion vonVista.

Zuerst müssen folgende Ports des Domain Controllerserreichbar sein:

Port Protokoll Name135 tcp rpc-portmapper389 tcp + udp ldap636 tcp ldap ssl

3268 tcp ldap gc326 tcp ldap gc ssl53 tcp + udp dns88 tcp + udp kerberos

445 tcp smb137-139 tcp + udp (smb für Windows NT)

Für Remotemanagement u.a.m. (DCOM) müssten außer-dem alle UDP-Ports geöffnet werden (sie werden dyna-misch vergeben). Das ist natürlich für eine Firewall-Konfiguration untragbar. Eine gewisse Abhilfe schafftein Registry-Eintrag am Server :

• HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc• Key „Internet“ erstellen• Values:

Ports: REG_MULTI_SZ: 5000-5100PortsInternetAvailable: REG_SZ: YUseInternetPorts: REG_SZ: Y

Damit ist der Portrange auf 100 Ports beschränkt, beikleineren Domänen kann man auch weniger angeben.

Dann braucht man nur diesen UDP-Portrange am Fire-wall zulassen. Auch das Protokoll icmp muss zugelassensein.

Bei der Beta-Version von Vista war es damit aller-dings nicht getan.

Das Domain-Logon von einem Vista Member zu ei-nem Vista Domain Controller funktionierte nicht, vonWindows XP Members zu ebendiesem Domain Control-ler allerdings schon.

Das lag daran, dass die beiden Vista-Maschinen denUDP-Transfer mit oben genannten dynamisch vergebe-nen Ports via IPv6 bewerkstelligen, welcher Transferüber das IPv4-Protokoll 41 getunnelt wird, also muss amFirewall noch das IP-Protokoll 41 zugelassen werden.

Das ist zwar eine schönere Lösung als die Portranges,man sollte sich aber dessen bewusst sein und weitere si-cherheitsmäßige Implikationen berücksichtigen.

Tests mit Sniffern haben auch ergeben, dass Vistaversucht, mit Routern über IPv6 Kontakt aufzunehmen.Das sind alles keine Sicherheitslücken, solange man esweiss und die Router das Protokoll nicht können. Zu-künftige Hacker und Virenprogrammierer könnten aller-dings jenen, die das nicht wissen, das Leben schwerermachen, vor allem was die Verteilung von Viren undBackdoors zwischen Rechnern anbelangt, welche nichtdurch Firewalls geschützt oder durch nicht IPv6-fähigeRouter getrennt sind. Es ist zu hoffen, dass bei der Pro-duktionsversion von Vista die Paketfilter des systemeige-nen Firewalls auch IPv6 voll berücksichtigen werden.

Page 23: ZIDline 13

Hier noch eine Beispielkonfiguration für den „bridging Firewall“ mit iptables:

iptables-Beispiel für funktionierende win2003/vista-Domain:(in diesm Beispiel ist 128.131.36.49 der Domaincontroller, Zugriffe sind nur vom Subnetz 128.131.36.0erlaubt, dazwischen ist der Firewall)

Chain FORWARD (policy DROP)target prot opt source destinationACCEPT 41 — 128.131.36.0/24 128.131.36.49ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpts:137:139ACCEPT udp — 128.131.36.0/24 128.131.36.49 udp dpts:5000:5100ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:3389ACCEPT icmp — 128.131.36.0/24 128.131.36.49ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:445ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:88ACCEPT udp — 128.131.36.0/24 128.131.36.49 udp dpt:88ACCEPT udp — 128.131.36.0/24 128.131.36.49 udp dpt:53ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:53ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:3269ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:3268ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:636ACCEPT udp — 128.131.36.0/24 128.131.36.49 udp dpt:389ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:389ACCEPT tcp — 128.131.36.0/24 128.131.36.49 tcp dpt:135ACCEPT all — 0.0.0.0/0 0.0.0.0/0 PHYSDEV match –physdev-is-bridged state RELATED,ESTABLISHEDACCEPT all — 0.0.0.0/0 0.0.0.0/0 PHYSDEV match —physdev-in eth1 —physdev-out eth0state NEWACCEPT all — 0.0.0.0/0 0.0.0.0/0 PHYSDEV match —physdev-in eth2 —physdev-out eth0state NEWREJECT tcp — 0.0.0.0/0 0.0.0.0/0 PHYSDEV match –physdev-in eth0 tcp dpt:113reject-with icmp-port-unreachableREJECT udp — 0.0.0.0/0 0.0.0.0/0 PHYSDEV match —physdev-in eth0 udp dpt:113reject-with icmp-port-unreachable

ZIDline 13 – Dezember 2005 – Seite 23

NEU als Campus Software:

Origin Pro 7.5für Windows

Programm zurDatenanalyse,Datenerforschung,Datenvisualisierung

sts.tuwien.ac.at/css/

auch als Studentensoftware erhältlich (sts.tuwien.ac.at/sss/)

Page 24: ZIDline 13

Seite 24 – Dezember 2005 – ZIDline 13

Firewall-Lösung für Institute –neue VersionWalter Selos

Die bewährte, auf Linux basierende Firewall-Lösung (mit CD und Konfigurationsdiskette) wurdegründlich überarbeitet und verbessert. Sie läuft jetzt unter Kernel 2.6 auf einem modifiziertenSlackware-Linux.

Ziel war es, wie bisher, ohne Konfigurationsarbeitenauf den zu schützenden Computern auszukommen, sowiedie Möglichkeit zu schaffen, routinemäßige Konfigura-tionsarbeiten am Firewall (Setzen von Filterregeln) übereine einfache, gesicherte Web-Oberfläche durchzuführen.Diese ist passwortgeschützt und nur von vordefiniertenNetzwerkadressen über https erreichbar. Für nicht routi-nemäßige Arbeiten ist von ebendiesen Rechnern auch einssh-Zugang möglich.

Besonderes Augenmerk wurde bei der Implementie-rung auf die Verwendung von Standardkomponenten ge-legt, sodass man ohne spezielle Kernelpatches undsonstige Modifikationen auskommt. Dies erleichtert auchdie Weiterentwicklung.

Als wesentliche Neuerung wurde vom bisherigenproxy-arp-Mechanismus abgesehen und die gleicheFunktionalität mit „bridging“ realisiert, welches ebenfallsüber den Packetfilter (netfilter/iptables) steuerbar ist. DieRealisation als Ethernet-Bridge erfüllt die hier gestellteAufgabe wesentlich eleganter, da keine arp-Broadcastsmehr nötig sind und auch nicht alle dahinter angeschlos-senen Rechner sich mit derselben MAC-Adresse amRouter melden, was die Fehlersuche, insbesondere dieRückverfolgung von IP-Paketen, nun wieder erleichtert.

Eine weitere Neuerung stellt die Möglichkeit dar, dieSoftware auch auf einer „embedded“-Hardwareplatt-

form laufen zu lassen (Soekris net4801, siehe http://www.soekris.com/net4801.htm). Das ist ein kleiner Pen-tium-kompatibler Computer mit 266 MHz, 128 MBRAM und einer Compact-Flash-Disk (256 MB in diesemFall). Das Gerät ist mit 3 100 Mbit-Ethernetports ausge-stattet, läuft mit einer Versorgungsspannung von 6-24 VDC mit einer Stromaufnahme von ca. 1.5 A. Es besitztkeine beweglichen Teile wie Lüfter, Harddisk etc. und istsehr robust gebaut, inkl. Gehäuse. Als Konsole dient eineserielle Schnittstelle, die braucht man aber nur, um insBIOS zu gelangen, z. B. zur anfänglichen Konfigurationoder im Fehlerfall. VGA-Anschluss gibt es keinen.

Beide Versionen sind sehr flexibel gestaltet und eslassen sich, je nach Konfigurationsdiskette oder (bei derSoekris-Variante) mit einem symbolischen Link auf einKonfigurationsverzeichnis auch andere Varianten undBetriebsmodi „maßschneidern“, z. B.: ADSL/xDSL-An-bindungen, IP-Masquerading (ein privates Netzwerkversteckt sich hinter einer einzigen IP-Adresse), NAT,DHCP-Server, VPN-Server usw.

Weiters ist es möglich, über die Firewall-Regeln auchdas Logging bestimmter IP-Pakete zu ermöglichen und viaNetzwerk auf den Syslog-Daemon eines anderen Unix/Linux-Rechners zu schicken und dort zu sammeln. Damitkönnte man eine rudimentäre „Intrusion Detection“ reali-sieren.

Die Aktivierung eines eingebauten DNS-Caches kannfür die Namensauflösung hilfreich sein, nur muss dieIP-Adresse des Firewalls dann auf den dahinterliegendenRechnern als DNS-Server konfiguriert sein (und natür-lich muss der Zugriff am Firewall erlaubt werden).

Die Firewall-Regeln können mittels einer Web-basie-renden Oberfläche (https) verändert werden. Dazu müs-sen zuerst die Computer, von denen aus administriertwerden soll, in eine Datei am Firewall eingetragen wer-

Soekris net4801

Page 25: ZIDline 13

den, nur dann ist mittels https und ssh ein Zugriff aufden Firewall möglich, der noch zusätzlich mit Benutzer-name und Passwort geschützt ist.

Das Web-Interface ist absichtlich einfach und über-sichtlich gehalten, und dient dazu, die am häufigsten vor-kommenden Administrationsaufgaben zu bewerkstelligen.Damit ist in erster Linie die Manipulation der Firewall-Regeln der „FORWARD-Chain“, also jene Regeln, dieauf jene IP-Pakete wirken, die durch den Firewall durch-geschleust werden.

Dies geschieht zuerst temporär, und wenn man damitzufrieden ist, kann man die momentan gültigen Regelnabspeichern, die bei einem Neustart dann wieder aktiviertwerden. Ein Informationsmenu liefert außerdem wichtigeInformationen über das System und die Netzwerkkonfi-guration.

Komplexere Aufgaben, die allerdings selten und meistnur bei der Installation vorkommen, muss man jedoch viassh erledigen (übliche Unix-shell).

Im Rahmen unseres Plattform-Supports (http://sts.tuwien.ac.at/pss_support.php) können wir für den „brid-ging-Firewall“ Installation und Fernwartung übernehmen,es sollte allerdings eine Ansprechperson am Institut ge-

ben, die über die dort vorhandene Netzwerktopologie unddie Rechner-Konfigurationen Bescheid weiß.

Vor der Installation muss die Abteilung Kommuni-

kation des ZID kontaktiert werden und eventuelle Ände-rungen an der Verkabelung und VLAN-Konfigurationvorgenommen werden. Ebenso muss die IP-Adresse fürdas Management-Interface im DNS der TU Wien ange-meldet werden (nur eine Adresse, die über alle Ethernet-ports des Firewalls erreichbar ist, der Firewall kämetheoretisch auch ohne jegliche IP-Adresse aus, nur istdann kein Remote-Management mehr möglich).

Die CD-Version kann man via http://linux.tuwien.ac.at/fwcd2.6/ downloaden.

Sollten Sie dazu Fragen haben oder an der Soekris-Version interessiert sein, wenden Sie sich bitte an:Walter Selos, Kl. 42031E-Mail: [email protected]

ANZEIGE

Page 26: ZIDline 13

Seite 26 – Dezember 2005 – ZIDline 13

Delta 3

ein interuniversitäres Projekt zur Entwicklungund Umsetzung von e-Learning-/e-Teaching-Strategien an den Partnerinstitutionen1

Johannes Fröhlich2, Ilona Herbst3, Franz Reichl4

3 Partner (Technische Universität Wien, Universität für Bodenkultur, Akademie der bildenden KünsteWien) fokussieren durch Weiterentwicklung und Synergien in 3 Kompetenzgebieten (Didaktik, Technik,Design/Usability) ihre Strategien für den Einsatz „Neuer Medien“ auf 3 Zielgruppen (Lehrende,Studierende in Aus- und Weiterbildung, Öffentlichkeit): interne sowie interuniversitäre Kooperation undTransdisziplinarität bewirken über expertisen-orientierte Verknüpfung zwischen den Eckpunkten der3 o.g. „e-Learning-Dreiecke“ den Auf- und Ausbau von „Public Awareness of Science and Arts“.

Ausgangspunkt:e-Learning-Aktivitäten an der TU Wien

Der Einsatz von e-Learning-Methoden in der Lehreverbreitert das Spektrum der Möglichkeiten in der Lehreund bietet Lehrenden und Studierenden großen Nutzen,wenn das didaktische Design gut gewählt wird. Lehrendeund Institute der TU Wien haben in den letzten Jahrenzahlreiche erfolgreiche Projekte und Aktivitäten im e-Learn-ing durchgeführt. Als Beispiele für an der TU Wien an-gewendete und (mit-)entwickelte Anwendungen im Be-reich e-Learning/e-Teaching seien genannt:

• iChemLab5, ein Internet-basiertes, im Studium der Tech-nischen Chemie fest verankertes Laborinformations-und –managementsystem6 zur Abwicklung chemischerPraktika;

• der virtuelle Campus Architekturlehre MODULOR7 un-terstützt den kritischen Umgang mit Lehr- und wissen-schaftlichen Materialien;

• MobiLearn8 beinhaltet eine komplexe Kommunikations-komponente (auch mobiles Lernen mit PDAs). Interakti-ve Beispiele in Kombination mit Animationen macheneinen wesentlichen Teil von MobiLearn aus;

• die Virtual Euro Laser Academy (VirtuELA)9 bietet u.a.Simulationen zur virtuellen Manipulation eines Lasersfür verschiedene Anwendungen;

• vor allem für Weiterbildung wurden am Beispiel desUniversitätslehrganges ECODESIGN10 an der TU Wieninnovative didaktische Modelle mit Schwerpunkt auf In-teraktion entwickelt und eingesetzt (Kombination ausBlended Learning mit aktiver Lernbegleitung der online-Lernphasen).

1 www.delta3.at2 Dekan der Fakultät für Technische Chemie; Delta 3-Projektkoordinator und Vorsitzender des Beirates des e-Learning-Zentrums der TU Wien3

Delta 3-Projektmanagerin4 Leiter des e-Learning-Zentrums der TU Wien5 siehe auch ZIDline 10, Juni 2004 und ZIDline 12, Juni 20056 www.ichemlab.at7 modulor.tuwien.ac.at8 www.mobilearn.at9 www.argelas.org10 Die Entwicklung des Universitätslehrgangs für „Umweltgerechte Produktgestaltung / Ecodesign“ wurde aus Mitteln des Europäischen Sozialfonds

und aus Mitteln des Bundesministeriums für Bildung, Wissenschaft und Kultur gefördert.www.ecodesign.at/ulg

Page 27: ZIDline 13

Eine Zusammenstellung von e-Learning-Aktivitäten ander TU Wien kann auf der Website des e-Learning-Zen-trums der TU Wien11 dem Download-Bereich zum „Erstene-Learning-Tag an der TU Wien“ entnommen werden12.

Im e-Learning Strategie-Projekt Delta 3, welches imRahmen der Ausschreibung „Entwicklung und Umset-zung von e-Learning/e-Teaching-Strategien an Universi-täten und Fachhochschulen“ des bm:bwk eingeworbenwerden konnte, werden die Erfahrungen der e-Learning„Pioniere“ an der TU Wien, der Universität für Boden-kultur und der Akademie für Bildende Künste nun ge-nutzt und gebündelt sowie Support-Strukturen aufgebaut.Ziel der Projektumsetzung an der TU Wien ist es, demGebot der Ausschreibung des bm:bwk folgend, einenachhaltige „e-Strategie“ zu initiieren, e-Learning-Metho-den flächendeckend an der TU Wien einzuführen und al-len Lehrenden geeignete Support-Strukturen dazuanzubieten.

Entwicklung und Umsetzung vone-Learning- und e-Teaching-Strategien

An der TU Wien wurde im Jahr 2004 im Rahmen derUmsetzung des UOG 2002 am Außeninstitut das e-Learn-ing-Zentrum als operative Einheit zur Vernetzung derAktivitäten innerhalb der TU Wien und für den Aufbauspezifischer Serviceleistungen für den zukünftigen Ein-

satz von e-Learning/e-Teaching im Organisationsplan13

verankert. Es ist dem Vizerektor für Lehre unterstellt. Eine-Learning-Beirat mit Vertretern aus verschiedenen Fach-gebieten und Fakultäten übernimmt strategische und be-ratende Aufgaben14.

Die e-Learning-/e-Teaching-Strategie soll zu einer Bün-delung aller bisherigen Initiativen sowie zur Entwicklungspezifischer Expertise auf gesamtuniversitärer Ebeneführen und damit die bisherigen Erfahrungen und Ent-wicklungen nachhaltig machen. Langfristiges Ziel ist eineuniversitätsweite Etablierung von e-Learning-/e-Teaching-Methoden im alltäglichen Lehr- und Lernbetrieb.

Das e-Learning-Zentrum wird zukünftig Serviceleis-tungen zur Unterstützung der Lehrenden an der TUWien, die e-Learning/e-Teaching-Methoden in ihrenLehrveranstaltungen einsetzen wollen, anbieten.

Die für die Initiierung dieses Vorhabens notwendigenRessourcen wurden in einem Universitätenkonsortium15

gemeinsam mit der Universität für Bodenkultur und derAkademie der bildenden Künste als Partner im ProjektDelta 3 im Rahmen der vom bm:bwk vorgenommenenAusschreibung „Entwicklung und Umsetzung von e-Learn-ing-/e-Teaching-Strategien an Universitäten und Fach-hochschulen“16 erfolgreich eingeworben.

Die Kooperation zwischen diesen drei Universitätensoll einerseits mögliche Synergien nutzbar machen, an-dererseits vor allem auch durch die an den Institutionenvorhandene Komplementarität der Expertisen derenBandbreite erweitern und somit Transdisziplinarität för-dern. In der Zusammenarbeit gilt es vorhandene Ressour-cen durch die Partner optimal und möglichst übergreifendzu nutzen sowie vorgenommene Investitionen über Ver-ankerung der Projektergebnisse in den Strategien der je-weiligen Institutionen nachhaltig zu sichern.

Entsprechend der o.g. Strategieausschreibung wird dieÜberprüfung der Nachhaltigkeit der geförderten Projekteim Rahmen der Leistungsvereinbarungen zwischen Uni-versitäten und dem bm:bwk ab 2007 ein Thema sein, an-dererseits bieten gerade diese eine Chance, für denweiteren Ausbau der e-Learning/e-Teaching-Aktivitätenim Rahmen einer universitären Profilbildung Globalbud-get zu lukrieren.

Ziele

Die an Delta 3 beteiligten Universitäten unterstützenzeitgemäße Lernformen, didaktische Konzepte und Bil-dungsangebote. Sie fördern individuelles, flexibles Ler-nen und die selbstgesteuerte AuseinandersetzungStudierender mit Lerninhalten auf allen Stufen derGrundausbildung und Weiterbildung.

ZIDline 13 – Dezember 2005 – Seite 27

3- Strategie für e-Learning und e-Teaching

Die

TU Wien

Boku Akademie

Lehrende

ÖffentlichkeitStudierende in Aus- undWeiterbildung

Technik

Didaktik Design und Usability

interuniv. Kooperation& Strategie

interneKooperation& Strategie

Awareness of Science & Arts

Transdisziplinarität

Public

11 elearning.tuwien.ac.at12 www.ai.tuwien.ac.at/elearning/past.html13 www.tuwien.ac.at/zv/recht/info_orgplan.shtml14 Vorsitzender: Univ.Prof. Dr. Johannes Fröhlich, Mitglieder: ao.Univ.Prof. Dr. Gerald Futschek, Dr. Wolfgang Kleinert,

ao.Univ.Prof. Dr. Christian Kühn, ao.Univ.Prof. Dr. Hans Lohninger, ao.Univ.Prof. Dr. Heinz Oberhummer15 Projektverantwortliche seitens der Konsortialpartner - Boku: DI Claus Rainer Michalek (Zentrum für Lehre / e-Learning);

Akademie: Mag. Andreas Spiegl (Vizerektor für Lehre und Forschung), Univ.Ass. Mag. Bettina Henkel (Staff Scientist für Kunstund digitale Medien und Leiterin des Medienlabors), Susanna Kirisits (ZID-Leiterin)

16 strategie.nml.at

Page 28: ZIDline 13

Die derzeitige Nutzung von e-Learning an den betei-ligten Universitäten im Allgemeinen und deren Studien-richtungen im Speziellen ist sehr unterschiedlich. Die amProjekt beteiligten Universitäten streben insgesamt einesignifikante Erhöhung des Anteils an online- sowie onli-ne-unterstützten Lehrangeboten an – durch den Einsatzvon e-Learning und e-Teaching auf unterschiedlichenEbenen:

• elektronische Unterstützung konventionell abgehaltenerLehrveranstaltungen mittels Verwaltungstools und elek-tronischer Lehrmaterialien durch Implementierung einere-Learning-Plattform;

• Einsatz von IKT-gestützten Feedback-, Kommunika-tions- & Kollaborationstools;

• spezielle Problemlösungen, spezifisch gestalteter Con-tent, Verwendung spezifischer Tools für z.B. Simulatio-nen, Multimedia, spezielle Datenbanken, interaktiveLehrsysteme;

• Einsatz von e-(Self)assessment.

Durch die angestrebte Etablierung von e-Learning unde-Teaching im alltäglichen Lehrbetrieb und in der damiterzielbaren Außenwirkung wird vielfältiger Nutzen er-wartet, z.B.:

• Qualitätsverbesserung bei gleichzeitiger Effizienzsteige-rung in der Lehre;

• Erhöhung der Transparenz in der Lehre;• Gender und IT: Genderspezifische Aufbereitung von

e-Learning-Inhalten, genderbewusste Partizipations-strukturen in e-Learning-Angeboten;

• Erreichen einer größeren Anzahl besser vorbereiteterStudienanfängerInnen (mit realistischeren Erwartungenan das gewählte Universitätsstudium);

• Vereinfachung und Verbesserung der Lehradministra-tion durch bedarfsgerechte gemeinsame technische Lö-sungen mit Schnittstellen zu bestehenden Anwendun-gen;

• Synergien in Fortbildung, Kundenakquisition im For-schungsbereich und Öffentlichkeitsarbeit sowohl für Uni-versitätsangehörige als auch externe InteressentInnen;

• langfristiger Beitrag zum Return of Investment durchkommerzielle Nutzung elektronisch aufbereiteter Lern-inhalte (auch jener der Bachelor- und Master-Stufen) v.a.in der Weiterbildung;

• Profilbildung und Steigerung der Attraktivität der betei-ligten Universitäten, stärkere Vernetzung in der Scienti-fic Community;

• Bereitstellung von einfachen und intuitiv nutzbarenTools und Unterstützungsangeboten zur Anwendungvon e-Learning wie bspw. Beratung, Coaching, Support,Training und Tutoring aus einem Pool zentral aufgebau-ter und zugänglicher Expertise;

• Vernetzung der Lehrenden (Aufbau einer „e-LearningCommunity“);

• Intensivierung des Lernprozesses für Fächer mit großenStudierendenzahlen („Massenlehrveranstaltungen“),Kapazität für die Individualisierung der Lehre;

• transparentere Qualifikationsanforderungen für Studie-rende durch e-Selfassessments;

• verständlichere Vermittlung komplexer Lerninhaltedurch elektronisch aufbereitete Lehrmaterialien;

• unmittelbares Feedback auf Lösungen im Übungsbetrieb(z.B. konstruktive Aufgaben) in virtuellen Umgebungen;

• Möglichkeit der virtuellen Teilnahme an Speziallehrver-anstaltungen von herausragenden internationalen Expert-Innen („e-Bologna“);

• Erhöhung der Flexibilität, Einbindung sonst benachtei-ligter Studierender.

Maßnahmen zur Umsetzung der Strategie

Im Rahmen des Projekts Delta 3 sind zahlreicheMaßnahmen und Aktivitäten zur Steigerung des Einsat-zes und der Effizienz von e-Learning in der Lehre vorge-sehen.

Zentrale e-Learning-/e-Teaching-Support-Services:

Für Lehrende und Studierende werden am e-Learn-ing-Zentrum der TU Wien zentrale e-Learning-/e-Tea-ching-Support-Services implementiert und ausgebaut.

Zur Ausweitung der Unterstützung durch die zentralenEinrichtungen wird das Netz mit e-Teaching-Ansprech-partnerInnen auf Fakultäts- beziehungsweise Studienrich-tungsebene erweitert. Damit soll jene Nähe zu denLehrenden geschaffen werden, welche durch den damitentstehenden persönlichen Kontakt direkte, rasche undeffiziente Beratungsarbeit garantiert und das Eingehenauf die spezifischen Bedürfnisse gewährleistet.

Die interuniversitäre Kooperation und Vernetzung derAntragsteller sowie Kooperationen mit externen Partnernwie fnm-Austria17 unterstützen die Strategieentwicklungund tragen zur Bildung von Synergien bei technologi-schen, didaktischen und organisatorischen Fragestellun-gen bei.

Qualifizierung und Anreiz:

Lehrende, die ihren Unterricht durch Nutzung derNeuen Technologien neu gestalten wollen, dürfen nichtsich selbst überlassen bleiben. Im Rahmen von Delta 3

sollen Weiterbildungs- und Unterstützungsangebote imBereich Neuer Medien die Umstiegsphase erleichtern.

Ein mehrstufiges Support-Netzwerk wird vorhandeneExpertisen bündeln, weiterentwickeln und breiter nutzbarmachen, wobei der Schwerpunkt insbesondere auf fol-gende Aktivitäten gelegt wird: Aufbau einer e-Learn-ing-Plattform, aktive Unterstützung und Beratung, Tuto-ring und Coaching; „Train the Trainers“-Seminare undWorkshops für Lehrende; Entwicklung eines e-Learn-ing-Starter-Kit, e-Learning/e-Teaching-Guidelines, Repo-sitory of Best Practice; Verbreitung, Integration und(Weiter-)Entwicklung von e-Media assisted Tools.

Eines der wichtigen Vorhaben des Projektes Delta 3

ist der Aufbau einer aktiven „e-Learning Community“ anden drei Universitäten, welche Inhalte für die Studieren-den in notwendiger Qualität und Quantität nachhaltig be-reitstellt.

Seite 28 – Dezember 2005 – ZIDline 13

17 insbesondere in Zusammenhang mit dem von fnm-Austria eingereichten Antrag im Rahmen der selben Ausschreibung; fnm-Austria:Forum Neue Medien in der Lehre Austria, http://serverprojekt.fh-joanneum.at/sp/index.php?n=fnm

Page 29: ZIDline 13

Dabei kommt Anreizsystemen mit ideellen und mater-iellen Komponenten eine wichtige strategische Funktionzu; in Delta 3 sollen dafür Vorschläge zur Implementie-rung im Rahmen der universitären Profilbildung ausgear-beitet werden.

Content und Technische Infrastruktur:

Delta 3 zielt auf eine erweiterte Contentbasis ab:Content-Erstellung, Content-Pflege, Content-Austausch,verbesserte Content-Zugänglichkeit und breite Content-Nutzung werden bspw. durch Thesaurus-Metasuchfunkti-on, Nutzung von Medien- und Wissensdatenbanken, Wi-kipedia-Funktionalität, Suchmaschinenfreundlichkeit undRich-Site-Summary-Funktionen ermöglicht und erleich-tert. Durch Mehrsprachigkeit und Interkulturalität sowiedurch die Möglichkeit der Einbindung von Lehrveranstal-tungen renommierter ausländischer WissenschafterInnenschafft die Strategie von Delta 3 sowohl für die Ent-wicklungszusammenarbeit als auch für die im Bologna-Prozess geforderte Internationalisierung der Lehre ent-scheidende Vorteile.

An den beteiligten Universitäten wird als Angebot fürdie Lehrenden und Studierenden eine e-Learning-Platt-form eingerichtet, gemeinsame Infrastruktur, zentraleTools und zentrale Dienstleistungen werden zur Verfü-gung gestellt und unterstützt. Bereits bestehende Lernsys-teme sollen selbstverständlich weiter genutzt undOptionen für deren Integration in die Lernplattformerarbeitet werden. Zum Einsatz wird die Open Sourcee-Learning-Plattform Moodle18 kommen und zentral un-terstützt werden (durch Bündelung von Beratung, Train-ing, Templates, Server, Operating, Update, Backup, ...).Insbesondere „Neueinsteigern“ in e-Learning soll damitder rasche und einfache Eintritt in die „e-Learning Com-munity“ ermöglicht werden.

Standards und Qualität:

Für e-Learning spielen eine Vielzahl unterschiedlicherStandards eine wichtige Rolle, die sich u.a. auf die tech-nische Gestaltung der Lernsysteme, Learning Manage-ment Systems und Metadaten für Learning Objectsbeziehen (z.B. LOM, SCORM). Da in Folge dieses Pro-jekts auch universitätsübergreifend Unterrichtsmaterialienerstellt werden, ist die Verwendung derartiger Standardsin der Contententwicklung besonders wichtig, um in Zu-kunft sowohl die Content-Erstellung als auch die gegen-seitige Nutzung zu vereinfachen.

Qualitätsstandards spielen im e-Learning ebenfallseine große Rolle; diese werden im Rahmen des ProjektsDelta 3 im Sinne eines Total Quality Managements ex-

plizit formuliert und den Lehrenden transparentvermittelt.

Öffentlichkeit:

Es wird ein interuniversitär eingerichtetes Portal „Pub-lic Awareness for Science and Arts“ aufgebaut, das sichan die Öffentlichkeit wendet und Einblick in die Leistun-gen der Universitäten gibt. Das Portal unterstützt dasZiel, das Verhältnis der Universität zur Öffentlichkeit zuverbessern und die Vermittlung universitärer Leistungenauch über e-Learning-Features zu intensivieren. In weite-rer Folge wird innerhalb dieses Portals auch eine Infor-mationsplattform für Aktivitäten der Konsortialpartner imvoruniversitären Bereich aufgebaut, bspw. um Kindernund Jugendlichen Interesse an Kunst und Technik zu ver-mitteln, früh den Einblick in das universitäre Leben zuermöglichen, zukünftige Studierende bei der Auswahl dergeplanten Studienrichtungen durch „sneak previews“ indie Fachgebiete, Curricula und universitären Abläufe zuunterstützen und für unterschiedliche Fächer entwickelteProgramme/Projekte in Verbindung mit Schulen anzubie-ten sowie bereits existierende einzubinden/auszubauen.Beispiele für letztgenannte Aktivitäten an der TU Wiensind YO! Einstein19, das Projekt „Kids and Science“20 so-wie die „TU-Mitmachtlabors“21 in der Fakultät für Tech-nische Chemie, die Projekte NUPEX (Nuclear PhysicsExperience)22 und CISCI (Cinema and Science)23 aus derFakultät für Physik, math.space24 oder PC-Hardware-Workshops für Schülerinnen25 im Rahmen der von der Fa-kultät für Informatik organisierten Initiative Admina.at26.

Gender Mainstreaming und Frauenförderung:

Zusätzlich werden im „Science and Arts-Portal“ spe-ziell junge Frauen angesprochen, um sie für eine natur-wissenschaftlich-technische Ausbildung zu interessieren;existierende frauenspezifische Lehrveranstaltungen wer-den im Rahmen des Portals vernetzt; darüber hinaus wer-den neue genderspezifische Angebote entwickelt. Ziel ist,geschlechtsspezifische Unterschiede im Zugang zu I&K-Technologie zu verkleinern und dafür zu sorgen, dassFrauen durch die Einführung von e-Learning nicht be-nachteiligt werden.

Die Etablierung von e-Learning an Universitäten stelltan Lehrende neue Anforderungen. Ziel ist, die Anforde-rungen in einer geschlechtersensiblen Ausbildung in denTrain-the-Trainer-Programmen zu berücksichtigen. Diespezifischen Lernformen von Frauen und Männern sollenthematisiert werden und exemplarische Lösungen für dieBerücksichtigung von weiblichen Bedürfnissen (z.B.durch geeignet gestaltete Kommunikationssysteme) dar-gestellt werden.

ZIDline 13 – Dezember 2005 – Seite 29

18 www.moodle.org19 www.yo-einstein.at; www.tuwien.ac.at/pr/news/news_050621a.shtml;

www.tuwien.ac.at/pr/events/events_yo.shtml; www.tuwien.ac.at/pr/pa/pa_03_11.shtml20 www.kidsandscience.org21 www.tuwien.ac.at/pr/pa/pa_04_43.shtml; mitmachlabor.tuwien.ac.at22 www.nupex.org23 www.xplora.org/ww/de/pub/xplora/nucleus_home/cisci.htm24 math.space.or.at25 www.tuwien.ac.at/pr/news/news_040617a.shtml; wit.tuwien.ac.at/admina.at/schuelerinnen/hardware/index.html26 wit.tuwien.ac.at/admina.at/index.html

Page 30: ZIDline 13

Die Bearbeitung des entsprechenden Workpackagesin Delta 3 erfolgt in enger Kooperation mit der Koordi-nationsstelle für Frauenförderung und Genderstudies derTU Wien27 und den Arbeitskreisen28 für Gleichbehand-lung an den Partneruniversitäten sowie durch Einbindungvon bestehenden Aktivitäten wie FIT (Frauen in dieTechnik)29 und bspw. die Initiativen Admina.at (Adminasteht für die weibliche Kurzform von Systemadministra-tor) und giTi (girls IT information) innerhalb des WIT(Wissenschafterinnenkolleg für Internettechnologien)30.

e-Habitus:

Neue Technologien und die Methoden des e-Learningverändern den Lehr- und Lernprozess nachhaltig bzw.haben dies bereits bewirkt, wo sie in Anwendung sind.

Diesem Umstand und für Koordination, Auf-/Ausbau,Servicierung und Nachhaltigkeitssicherung des Einsatzes„Neuer Medien“ wurde durch die Etablierung von e-Learning Zentren an den Universitäten Rechnung getra-gen. Im Projekt Delta 3 stehen nun Ressourcen zur Ver-fügung, um die Lehrenden durch die Bereitstellung vonSupport-Strukturen zu unterstützen und Weiterbildungs-Veranstaltungen mit Schwerpunkt e-Learning im univer-sitären Alltag anzubieten.

Delta 3 wird auf diese Weise dazu beitragen, dass derEinsatz grundlegender Instrumente des e-Learnings/e-Teachings bald für alle Lehrenden an den beteiligtenUniversitäten als Mehrwert für ihre Lehrtätigkeiten aner-kannt sein wird.

Delta 3 – Status und nächste Schritte

Im Oktober 2005 wurden am e-Learning Zentrum dieVorbereitungsarbeiten zum Aufbau der e-Learning/e-Teaching Support-Strukturen für die Technische Uni-versität Wien aufgenommen.

In der ersten Projektphase von Delta 3 werden folgen-de Aktivitäten aus den Workpackages prioritär umgesetzt:

• Aufbau der nötigen technischen Infrastruktur sowie Im-plementierung der e-Learning-Plattform Moodle an derTU Wien;

• Einbindung von e-Learning-AktivistInnen für die Aus-wahl von Moodle-Pilotprojekten;

• Integration bestehender e-Learning/e-Teaching-Aktivi-täten in Moodle; ggf. Anpassung an spezifische Anforde-rungen und Schaffung von Moodle-Erweiterungs-modulen sowie nötigen Schnittstellen zur Anbindung deretablierten Projekte;

• Vereinfachung der Lehradministration: durch Schnitt-stellen werden vorhandene Tools so aufeinander abge-stimmt, dass originäre Daten im Regelfall nur mehreinmal erfasst werden müssen;

• Evaluierung von Lehrveranstaltungen nach 3 Kategoriendes Einsatzes von e-Learning und e-Teaching:

• „basic“: strukturierte elektronische Unterstützungkonventionell abgehaltener Lehrveranstaltungenmittels der e-Learning-Plattform Moodle bspw.durch die Einbindung elektronischer Lehrmateria-lien; Verwaltungstools;

• „advanced“: zusätzlicher Einsatz von Kommunika-tions- & Kollaborationstools, Blended-Learning,Feedback;

• „special“: studienspezifisch gestalteter/organisierterContent, Entwicklung fachspezifischer Tools (z.B.Simulationen, Multimedia, spezielle Datenbanken,interaktive Lehrsysteme), e-Assessment;

• Entwicklung eines Schulungs- und Tutoringprogrammsfür AnwenderInnen von Moodle, zusammen mit entspre-chender Dokumentation („Basic e-Learning Kit“) –Workshops zur Hilfestellung beim Einstieg in e-Learn-ing und e-Teaching und dessen Implementation in eige-nen Lehrveranstaltungen;

• Errichtung eines Science and Arts Portals, Integration ei-ner „Public and Junior Academy for Science and Arts“:Schaffung der Voraussetzungen (Technik, Design, Usa-bility); redaktionelle Aufbereitung und Einbindungbestehender Inhalte/Projekte;

• Gender Mainstreaming und IT: Identifizierung, Akqui-rierung sowie Vernetzung bestehender Angebote und In-itiativen der Partnerinstitutionen zur Einbindunggeeigneter Inhalte in das Portal der „Public and JuniorAcademy for Science and Arts“;

• Entwicklung erster Konzepte intrauniversitärer Anreizsys-teme für Lehrende betreffend den Einsatz von e-Learn-ing/e-Teaching sowie die Content-Produktion.

Im März 2006 wird das Projekt Delta 3 im Rahmendes zweiten „e-Learning-Tages an der TU Wien“ denLehrenden präsentiert und es werden erste Ergebnissevorgestellt. Termin und Programm werden auf der e-Learning Homepage der TU Wien und auf der Delta 3

Homepage bekannt gegeben.

Kontakt

TU Wien – Außeninstitut – e-Learning-Zentrum

Leiter: Dr. Franz ReichlTel.: 58801-41512E-Mail: [email protected]://elearning.tuwien.ac.at/

Delta 3

Projektmanagerin: Maga. Ilona HerbstTel.: 58801-41560E-Mail: [email protected]://www.delta3.at/

e-Learning-Beirat der TU Wien

Vorsitzender: Univ.Prof. Dr. Johannes FröhlichProjektkoordinator Delta 3 undDekan der Fakultät für Technische ChemieTel: 58801-10000E-Mail: [email protected]

Seite 30 – Dezember 2005 – ZIDline 13

27 frauen.tuwien.ac.at28 info.tuwien.ac.at/akgleich/main.htm29 www.fitwien.at30 www.wit.at

Page 31: ZIDline 13

ZIDline 13 – Dezember 2005 – Seite 31

Arbeiten mit Solid EdgeAndreas Astleitner, Institut für Sensor- und Aktuatorsysteme

Warum gerade Solid Edge?

Seit Bestehen der Abteilung MikroSystemTechnik(vor 2004 des Institutes für Mikro- und Feinwerktechnik)gab es auf Grund der fachlichen Ausrichtung des Institu-tes den Bedarf an Konstruktionsarbeit – entweder für dieAdaption von Prüfgeräten oder auch für Firmenpartner,welche Lösungen für ihre konstruktiven Probleme such-ten. All diesen Problemen gemeinsam war die Forderungnach Einzelteilzeichnungen, Baugruppenzeichnungen,Bewegungssimulationen, Einbau- und Kollisionsbetrach-tungen sowie eventuell eine Datenübergabe an FE-Syste-me zwecks weiterer Berechnungen. Bis Mitte der80er-Jahre wurden die beiden erstgenannten Problememit klassischen (handwerklichen) Methoden, d.h. inForm von Werkzeichnungen, gelöst. Mit dem Aufkom-men der ersten CAD-Systeme wurden die Arbeiten dannauf PCs verlagert, ein Arbeiten im dreidimensionalenRaum war damit aber trotzdem nicht möglich. Alternati-ve zu PC-Systemen gab es damals schon einige, dieseschieden auf Grund der hohen Anschaffungs- und War-tungskostenkosten sowohl für die Software als auch fürdie dazu benötigte Hardware aus. Ende der 90er-Jahregab es allerdings einen Entwicklungsschub bei PC-basie-renden CAD-Systemen in Richtung 3D-Funktionalität,sodass eine Menge der oben gelisteten Probleme mit ver-tretbarem Aufwand mit diesen „neuen“ Systemen gelöstwerden konnten. Nach Auswertung einer Marktrecherchestießen wir auf das Produkt Solid Edge von UGS, wel-ches sämtliche Problembereiche abdeckt.

Allgemeines

Solid Edge ist ein „echtes“ 3D-CAD-System, welchesaus Modulen für die Konstruktion von Volumskörpern,zur Erstellung bzw. Ableitung von 2D-Zeichnungen(Werkzeichnungen), zur Erstellung von Schweißkon-struktionen und zur Erstellung von Baugruppenkonstruk-tionen besteht. Die Stärken von Solid Edge liegeneindeutig in der Interoperabilität dieser Module. DieseModule sollen nun im Einzelnen kurz vorgestellt werden.

Volumskörper

Zum Modellieren von Körpern stehen dem Konstruk-teur eine Menge an Funktionen zur Erstellung eines Tei-les auf Basis von geometrischen Primitiven zur Ver-fügung. Ein wichtiger Punkt ist dabei die Möglichkeitder Parametrisierung der geometrischen Elemente – auchin mathematischer Abhängigkeit zueinander mittels einer

Variablentabelle, in welcher auch VisualBasic-Routinenverarbeitet werden können. Ebenso können zuvor erstell-te Körper assoziativ (als Konstruktionselemente) zurWeiterbearbeitung eingefügt werden. Auch Bool’scheOperationen lassen sich damit durchführen. Eine dritteMöglichkeit der Verknüpfung ist jene der „Inter-Part-Ko-pie“. Damit ist es möglich, Geometrien oder Parametervon Teil A mit jenen von Teil B zu verknüpfen. Eineweitere Möglichkeit der Körpererstellung ist jene mittelsFlächen. Damit ist eine sehr flexible Erstellung von Bau-teilen möglich. Durch Definition der Materialeigenschaf-ten ist eine Kalkulation des Bauteilgewichtes, desVolumsschwerpunktes, des Masseschwerpunktes, derMassenträgheitsmomente und der Hauptträgheitsmomentemöglich.

Bild 1: Zahnradkonstruktion mittels Variablentabelle

Bild 2: Konstruktion mittels Teilekopie,Flächen und Bool’schen Operationen

Page 32: ZIDline 13

Blechteile

Eine besondere Art von Körpern sind Blechteile. NachDefinition der Blechstärke können Blechteile aus denElementen Lasche, Lappen und Konturlappen erstelltwerden. Die Art der Eckausklinkung und der Freistellungkönnen für jeden Bug separat eingestellt werden. AufKnopfdruck kann die Abwicklung erstellt werden. Fürdie Berechnung der gestreckten Länge kann entweder dieFormel zu Berechnung der neutralen Faser oder ein kon-stanter Wert herangezogen werden. Für die Weiterbear-beitung gibt es Funktionen zur Konstruktion von Sicken,Profilen und Lüftungsschlitzen. Eine interessante Funkti-on ist jene der Erstellung von Blechteilen aus Volums-körpern. Ebenso können Materialeigenschaften definiertund die damit zusammen hängenden physikalischen Ei-genschaften errechnet werden.

Schweißteilerstellung

Bei Schweißteilkonstruktionen werden die beteiligtenTeile zunächst in einer Baugruppe platziert. Diese istdann Basis für die Erstellung der Schweißkonstruktion.

Als Schweißnahtformen stehen derzeit allerdings nurKehlnähte zur Verfügung. Für die Berechnung derphysikalischen Eigenschaften gilt das Gleiche wie beider Teileerstellung. Schweißkonstruktionen werden inBaugruppen wie Einzelteile behandelt.

Baugruppen

Baugruppen können aus Volumskörpern, Blechteilen,Schweißkonstruktionen, Teilen aus Bauteilbibliotheken(einige Schrauben, Muttern und Scheiben werden bei So-lid Edge standardmäßig mitgeliefert) sowie Baugruppenbestehen. Damit ist es möglich, einen strukturierten Auf-bau durchzuführen. Die Einbaubedingungen können freizugeordnet, die verbauten Teile können auf Freiheitsgra-de untersucht werden. Auf Basis dieser Einbaubedin-gungen ist es möglich, Bewegungssimulationen und Kolli-sionsbetrachtungen durchzuführen. Diese können aufge-zeichnet werden und als Video im AVI-Format abge-speichert werden. Durch Einführen von Sensoren und Gren-zen können diese Untersuchungen noch verfeinert werden.

Seite 32 – Dezember 2005 – ZIDline 13

Bild 3: Blechteil

Bild 4: Blechteil - Abwicklung

Bild 5: Schweißteil

Bild 6: Baugruppe in Schnittansicht

Page 33: ZIDline 13

Zeichnungserstellung

Zeichnungen werden mittels des Moduls „DRAFT“erstellt. Zwei Erstellungsarten sind damit möglich: Einer-seits Ableitungen von zuvor erstellten Körpern / Bau-gruppen / Schweißteilen – bei Änderung an den zuGrunde liegenden Konstruktionen sind die abgeleitetenZeichnungen lediglich per Knopfdruck zu aktualisieren –andererseits die Erstellung von 2D-Werkzeichnungenmittels der Zeichenfunktionen ohne Verbindung zu ande-ren Konstruktionen. Bei dieser Methode sind die Ver-knüpfungsfunktionen von Solid Edge eine echte Hilfe,Maße können ebenfalls zueinander in Beziehung ge-bracht werden. Bei abgeleiteten Zeichnungen könnensämtliche errechneten physikalischen Eigenschaften über-nommen und im Schriftkopf weiter verwendet werden.

Zusammenfassung

Das Produkt wird nun schon seit einigen Jahren zurvollen Zufriedenheit am Institut eingesetzt. Ein Punkt,welcher von Anfang an überzeugend war, ist jener der

leichten und schnellen Erlernbarkeit – dies auch durchdie hervorragenden Online-Tutorials und die kontextbe-zogene Hilfefunktion. Einfachere Teile lassen sich mitSolid Edge schon nach wenigen Stunden Lernzeit erstellen.

Seit das Programm in der Campus-Liste aufscheint,haben es Institute quer durch alle Fakultäten lizenziert –nicht nur Maschinenbauer. Diese Software wird mit fol-gendem Hintergrund auch als Studentenversion zur Ver-fügung gestellt: sollte ein Institut die Software imLehrbetrieb einsetzen, dann sollen auch die Studenten indie Lage versetzt werden, diese zu Hause für die Weiter-bildung, Hausübungen, Projekte, ... verwenden zu dürfen.Als letzten Hinweis für eine mögliche Nutzung der Soft-ware möchte ich noch die Gruppe der Lehrer für Darstel-lende Geometrie in Österreich erwähnen, welche SolidEdge auf Grund der Fähigkeiten im 2D-Bereich in ihremUnterricht einsetzen.

Für Fragen und nähere Informationen stehe ich gerne un-ter [email protected] bzw. 58801x36683zur Verfügung.

ZIDline 13 – Dezember 2005 – Seite 33

Bild 7: Baugruppe mit Volumkörpern und Blechteilen

Bild 8: Baugruppe - Explosionsdarstellung

Bild 9: Zeichnungsableitung Volumskörper

Bild 10: Zeichnungsableitung Explosionsdarstellung

Page 34: ZIDline 13

Seite 34 – Dezember 2005 – ZIDline 13

PersonalnachrichtenMit 1.1.2006 wird Herr Dipl.-Ing. Philipp Kolmann,

der seit 1999 als wissenschaftliche Hilfskraft (Tutor) amZID tätig ist, ganztags am ZID angestellt und die Leitungdes neuen Service Centers übernehmen. Wir gratulierenzum abgeschlossenen Studium.

Im Service Center werden das bisher in der Vermitt-lung tätige Personal, das Sekretariatspersonal sowie diebisher für die STS Computer Helpline als geringfügigBeschäftigte eingesetzten Mitarbeiterinnen arbeiten. Wei-ters werden wissenschaftliche Hilfskräfte vor allem dieTU-ADSL-Beratung innerhalb des Service Centers wahr-nehmen.

Anfang September hat Herr Christoph Schwarz inder Abteilung Kommunikation zu arbeiten begonnen(halbtags). Er ist der Nachfolger von Herrn TilmannLinneweh und übernimmt dessen Agenden: WLAN-Sen-der sowie TUNET Access-Infrastruktur.

Ende 2005 tritt unser Kollege Heinz Eigenberger sei-nen wohlverdienten Ruhestand an. Herr Eigenberger ar-beitete seit Anfang 1977 als Chefoperator sowohl am IEZ

und in den Folgejahren am EDV-Zentrum bzw. ZID derTU Wien. Wir haben ihn in den langen Jahren alsFreund, guten Kollegen und verantwortungsvollen Mitar-beiter schätzen gelernt und wünschen ihm für seinen neu-en Lebensabschnitt vor allem Gesundheit und alles Gute.

Zur Betreuung der Internet-Räume und im ServiceCenter sind am ZID wissenschaftliche Hilfskräfte ange-stellt:

Ch. AlbrechtC. FellingerJ. GreilbergerM. HoferM. HuxholdM. JarosH. JudtP. KotikP. LischkaCh. ScholzT. WojcikK. WongM. Wögerbauer

Auskünfte, Störungsmeldungen:

Service CenterBitte wenden Sie sich bei allen Fragen und Problemen,die das Service-Angebot des ZID betreffen, zunächst an das Service Center.

Telefon: 58801-

Adresse: 1040 Wien, Wiedner Hauptstraße 8-10, Freihaus, 2.OG, gelber Bereich

Ticket System: https://service.zid.tuwien.ac.at/support/

E-Mail-Adressen: [email protected] allgemeine Anfragenfür Auskünfte und [email protected] TUNET StörungenStörungsmeldungen [email protected] TUNET Rechneranmeldung

[email protected] [email protected] TU-ADSL [email protected] Netz- und [email protected] Systemunterstü[email protected] Operating zentrale [email protected] [email protected] Internet-Rä[email protected] TUWIS++

Page 35: ZIDline 13

Telefonliste, E-Mail-AdressenZentraler Informatikdienst (ZID)der Technischen Universität WienWiedner Hauptstraße 8-10 / E020, 1040 WienTel.: (01) 58801-42002Fax: (01) 58801-42099Web: www.zid.tuwien.ac.at

Leiter des Zentralen Informatikdienstes:W. Kleinert 42010 [email protected]

Administration:

S. Freisleben 42015 [email protected]

A. Müller 42015 [email protected]

M. Weiss 42017 [email protected]

Öffentlichkeitsarbeit

I. Husinsky 42014 [email protected]

Service Center

Leitung:

Ph. Kolmann 42011 [email protected]

Th. Pitlik 42012 [email protected]

H. Ehrhardt 42066 [email protected]

S. Geringer 42065 [email protected]

M. Markowitsch 42062 [email protected]

S. Bachinger [email protected]

K. Pegac [email protected]

D. Sabounji [email protected]

A. Sorger [email protected]

ADV-Abteilungwww.zid.tuwien.ac.at/adv/

Leitung:

E. Dvorak 41070 [email protected]

M. Beer 41077 [email protected]

B. Borovali 41072 [email protected]

J. Divisch 41079 [email protected]

U. Faustmann 41071 [email protected]

F. Glaser 41074 [email protected]

S. Gründlinger 41194 [email protected]

D. Lyzczarz 41076 [email protected]

W. Niedermayer 41195 [email protected]

A. Rajkovats 41073 [email protected]

R. Vargason 41196 [email protected]

M. Wograndl 41078 [email protected]

Abteilung Standardsoftwarests.tuwien.ac.at

Leitung

A. Blauensteiner 42020 [email protected]

Ch. Beisteiner 42021 [email protected]

J. Donatowicz 42028 [email protected]

G. Gollmann 42022 [email protected]

M. Holzinger 42025 [email protected]

I. Jaitner 42037 [email protected]

N. Kamenik 42034 [email protected]

A. Klauda 42024 [email protected]

H. Mastal 42079 [email protected]

H. Mayer 42027 [email protected]

Th. Mikulka 42023 [email protected]

E. Schörg 42029 [email protected]

R. Sedlaczek 42030 [email protected]

W. Selos 42031 [email protected]

B. Simon 42032 [email protected]

A. Sprinzl 42033 [email protected]

W. Steinmann 42036 [email protected]

P. Torzicky 42035 [email protected]

Abteilung Kommunikationnic.tuwien.ac.at

Leitung

J. Demel 42040 [email protected]

F. Blöser 42041 [email protected]

G. Bruckner 42046 [email protected]

Th. Eigner 42052 [email protected]

Th. Gonschorowski 42056 [email protected]

J. Haider 42043 [email protected]

P. Hasler 42044 [email protected]

G. Kittel 42042 [email protected]

J. Kainrath 42045 [email protected]

J. Klasek 42049 [email protected]

W. Koch 42053 [email protected]

I. Macsek 42047 [email protected]

F. Matasovic 42048 [email protected]

W. Meyer 42050 [email protected]

J. Öttl 42057 [email protected]

Ch. Schwarz 42055 [email protected]

R. Vojta 42054 [email protected]

Walter Weiss 42051 [email protected]

Abteilung Zentrale Serviceswww.zserv.tuwien.ac.at

Leitung

P. Berger 42070 [email protected]

W. Altfahrt 42072 [email protected]

J. Beiglböck 42071 [email protected]

P. Deinlein 42074 [email protected]

P. Egler 42094 [email protected]

H. Eigenberger 42075 [email protected]

C. Felber 42083 [email protected]

H. Flamm 42092 [email protected]

W. Haider 42078 [email protected]

E. Haunschmid 42080 [email protected]

M. Hofbauer 42085 [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]

D. Sonnleitner 42087 [email protected]

Werner Weiss 42077 [email protected]

ZIDline 13 – Dezember 2005 – Seite 35

Page 36: ZIDline 13