ZIDline 19

Mobil sein – WLAN nutzen

TISS – Das erste Projektjahr

HPC-Cluster Projekt

Nr. 19 / Dezember 2008

ISSN 1605-475X

ZEITSCHRIFT DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Seite 2 – Dezember 2008 – ZIDline 19

Inhalt

TISS – Planen der Straßen und Roden im DickichtDas erste Projektjahr. . . . . . . . . . . . . . . . . . . . . . . . . 3

Das HPC-Cluster ProjektEin Gemeinschaftsprojekt der Universität für Boden-kultur, der Universität Wien und der TU Wien . . . . 8

Mobil sein – WLAN nutzen . . . . . . . . . . . . . . . . . . . . . 11

DNS – (k)ein Anschluss unter dieser Nummer . . . . . . 14

TUphone – Status des Projekts. . . . . . . . . . . . . . . . . . . 18

Neues Verrechnungssystemfür die Telefongesprächsentgelte . . . . . . . . . . . . . . 21

u:books an der TU Wien . . . . . . . . . . . . . . . . . . . . . . . 23

Ein kleines Authentifizierungslexikon . . . . . . . . . . . . . 25

MoreSpace –Mehr Raum für die Lehre durch dynamischeereignisorientierte Simulation der Raumbelegung . 27

Systematisches Testen eines Constraint-Systems. . . . . 30

TUWELNews WS2008 & Moodle Konferenz 2009 . . . . . . 32

TISS Datenstruktur – Datenstruktur-Browser . . . . . . . 34

Backup für Windows PCs und Server . . . . . . . . . . . . . 37

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

Editorial

In der Juli-Ausgabe der ZIDline konnten wir das Pro-jekt TISS zur Entwicklung eines soliden Informationssys-tems für die TU Wien vorstellen. Als erster Schritt aufdem Weg zu einer Gesamtlösung ist nun das TU Adress-buch fertig, mit komfortablen Suchfunktionen und einemneuen Änderungsinterface. Weiters werden die nächsten,in Entwicklung befindlichen Applikationen beschrieben.Für technisch Interessierte wird die TISS-Datenstrukturmit dem Datenstruktur-Browser erläutert.

Das HPC-Cluster Projekt wird nach einer wechsel-vollen Geschichte bald zu einem guten Ende kommen.

Die TU Wien hat im Herbst erstmals an der u:book Ak-tion der Universität Wien teilgenommen. Das Angebotwurde sehr gut angenommen.

Zur Unterstützung der Mobilität wird die WLAN-Ver-sorgung aller TU-Gebäude laufend verbessert. Das Titel-bild zeigt die Ausbreitung der Funkwolke im BereichFreihaus, 1. OG, in Form einer so genannten Heat Map.Die umschließende Kurve symbolisiert die Anzahl dergleichzeitigen WLAN-Nutzer an einem typischen Tag imWintersemester, das kleine Diagramm die Anzahl übervier Wochen.

Wir berichten selbstverständlich auch wieder über denStatus des TUphone-Projekts. GSM-Mobiltelefone erset-zen bereits die ehemaligen DECTs. Das neue Verrech-nungsmodell wird vorgestellt.

Ein spezielles Thema dieser Ausgabe der ZIDline istdas DNS-Service in seiner Komplexität. In einem kleinenAuthentifizierungslexikon können Sie einige Grundbegrif-fe nachschlagen und lesen, was SAML und Shibboleth be-deuten.

Ferner berichten wir über MoreSpace, eine Simulationzur Hörsaalbelegung, und über eine Anwendung des Cam-pus-Grids, bestehend aus den PCs in den Internet-Räumenzu Idle-Zeiten.

Die Vorstellung eines Backup-Programms aus derCampussoftware und TUWEL News runden den Inhaltdieser ZIDline ab.

Ich bedanke mich sehr herzlich bei allen Autoren –ZID-Mitarbeiter und externe – für ihre Kooperationsbe-reitschaft und ihre interessanten Beiträge.

Mit den besten Wünschen für 2009

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, 1040 WienTel.: (01) 58801-42014, 42002Fax: (01) 58801-42099E-Mail: [email protected]: http://www.zid.tuwien.ac.at/zidline/

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

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

TISS – Planen der Straßenund Roden im DickichtDas erste ProjektjahrMonika Suppersberger, Stefan Bachl, Philip StaudAndreas Knarek, Wolfgang Kleinert

Das erste Projektjahr geht zu Ende und TISS bahnt sich weiter den Weg durch die bestehende,Schritt für Schritt abzulösende IT-Landschaft der TU Wien. Die ersten Erfahrungen sind lehrreich,viel Spannendes kam ans Licht und vieles wartet noch auf seine Entdeckung –ein erstes Resümee und ein Blick in die nahe Zukunft.

Projektziele 2009und der Prozess der laufenden Gewinnungvon Planungswissen der TU-Mitarbeiter

Die wachsenden Anforderungen an die IT-Landschaftder Technischen Universität Wien als innerbetrieblich undaußerbetrieblich verfügbares Verwaltungs- und Informa-tionssystem für die Bereiche Forschung, Lehre und Ver-waltung sowie die immer größer werdende Nachfragenach einer gemeinschaftlichen Architektur als Basis füreine flexible, rasche und kostengünstige Erweiterung derGesamtsystematik erfordern eine Ablöse der bestehenden„alten“ Einzelsysteme. Wie bereits in der Juli-Ausgabeder ZIDline berichtet wurde, stellt sich das Projekt TISS(„TISS“ steht für TU Wien Informations-Systeme und–Services) dieser Herausforderung und widmet sich derEntwicklung eines soliden Informationssystems, das nichtnur bestehende Einzelsysteme ablösen, sondern auch zahl-reiche neue Funktionen bereitstellen wird sowie eine lang-fristige technologische Basis für Neusysteme der kom-menden Dekade darstellt.

Das Projekt TISS wurde im Jänner 2008 begonnen undsteht unter der Leitung von Wolfgang Kleinert, dem Leiterdes ZID ([email protected]), der fachlich vonThomas Grechenig, dem Leiter der Forschungsgruppe fürIndustrielle Softwaretechnik (INSO, [email protected]), und seinem Team unterstützt wird. DasProjekt hat nunmehr seine frühen Projektphasen hintersich, die den Fokus auf einen iterativen Prozess zur Eta-blierung eines Fachkonzeptes sowie der Gewinnung derTechnologie-Basis und der IT-Architektur gelegt hat.

Das Fachkonzept als strukturierte Sammlungaller IT-relevanten administrativen Aktivitätenim Hause TU und deren Weiterentwicklung

Zum Zwecke der Erarbeitung und Evaluierung einerwirklich soliden, von den Usern, Mitarbeitern, Manage-ment ausgezeichnet mitgetragenen Gesamtlösung findenseit März 2008 in regelmäßigen Abständen fachlicheWorkshops zu jener breiten Palette von Themen statt, dieder Gesamtkomplexität des gut organisierten Hauses TUangemessen ist. Zu einzelnen Themen wurden dabei be-reits anschließende Iterationen zur Vertiefung der Analy-sen und zur Evaluierung der sich daraus entwickelndenPlanungskonzepte abgehalten. Das Kernziel dieser Work-shops ist die Einbindung sämtlicher Stakeholder, die Ein-ladung zur aktiven Mitwirkung und Mitgestaltung der zu-künftigen Workflows. – TISS soll ein IT-System des 21.Jahrhunderts sein: „von allen Mitarbeitern der TU Wienfür alle Mitarbeiter der TU Wien“.

Die bisherigen Workshops umfassten folgende Themen:

• Integration der bestehenden ZID-Services• SAP Schnittstellen• Personen und Organisationen• Gebäude und Räume• Studierendenverwaltung und Studierendenservices• Studienpläne• Lehrveranstaltungsmanagement• Alumnimanagement und TU Career• Integration und Schnittstellen TUWEL• Reporting und Statistiken• Kanzleiinformationssystem (KIS)

ZIDline 19 – Dezember 2008 – Seite 3

• Migration von Personendaten• Forschung (Projektdatenbank, Publikationsdatenbank)• Aleph Integration

Entwicklung der TISS-Infrastrukturund Development-Basis

Neben der Etablierung dieses Fachkonzeptes (es handeltsich dabei wie bemerkt um die Etablierung eines laufendenProzesses der Erfassung der Anwendererfordernisse, der inden kommenden zwei Jahren Entwicklungsarbeit aufrechterhalten bleiben wird) lag der Fokus auf der Schaffung ei-ner Technologie-Basis, der IT-Architektur sowie der Imple-mentierung von Basis-Systemfunktionen, auf denen dieverschiedenen Teilsysteme von TISS aufbauen werden. Einwesentlicher Teil der Entwicklungsarbeit bestand z. B. inder Formulierung und Implementierung eines umfassendenRollen- und Rechtesystems, mit dem sehr flexibel Struktu-ren und Hierarchien abgebildet und Rechte an andere Be-nutzer vergeben bzw. delegiert werden können. – Ein „Umund Auf“ in einem bewegten Haus wie der TU Wien.

Die Integrität der TISS Daten wird über ein eigens kon-zipiertes Datenmodell sichergestellt (siehe Artikel vonAndreas Knarek, Seite 34). Damit kann nicht nur der Zu-stand eines Datensatzes vor der letzten Aktualisierung,sondern auch zu jedem beliebigen Datum wiederherge-stellt werden. Die revisionssichere Protokollierung undVersionierung von Dateneingaben und -änderungen wirdauf diese Weise in TISS gewährleistet. Natürlich ist dasheute State-of-the-Art für moderne Informationsysteme,im zentralen Verwaltungsbereich unseres Hauses ist esjedoch und ab jetzt Standard für alle zukünftigen Systeme.

Das praxisbekannte Problem der reibungslosen schritt-weisen Ablöse der Altsysteme durch TISS und der dafürerforderliche Parallelbetrieb mitsamt dem Konsistenzbedarfbeider Systeme wird von einer speziell dafür etabliertenTISS-Expertengruppe gelöst. Der Technik-Fachbereich„Migration“ hat eine Planung der kurz-, mittel- und lang-fristigen Migrationsstrategie etabliert und setzt sie derzeitso um, dass die Anwender mit sehr hoher Sicherheit sichniemals im Laufe der Einführung von TISS vor dem Pro-blem von Datenverlust oder doppelter Eingabe von Infor-mationen in zwei Systeme sehen werden.

Ein erster, für den Anwender noch kaum spürbarerSchritt ist hier schon geschehen: die Migration der Perso-nendaten aus den „alten“ White Pages hinein in TISS istbereits erfolgt.

Das Adressbuch –der erste Schritt zur Gesamtlösung

TISS leistet als eine Teilaufgabe, ein solides, integrier-tes Informationssystem bereitzustellen, das die Funktionenvon TUWIS, TUWIS++, der Projektdatenbank, der Publi-kationsdatenbank, der ZID-Personendatenbank sowie denWhite Pages auf einheitlicher Basis integriert.

Als ersten user-wirksamen Schritt löst TISS demnächstdie bestehenden White Pages ab. Das Team erhofft sichhier rege Anteilnahme der Stakeholder und User, ja sogareine gewisse Menge an Fehlerfällen! Daraus kann dasTeam vortrefflich für die kommenden „größeren Brocken“lernen und sich vorbereiten. TISS leistet bei dieser Ablöse der

White Pages auch bereits mehr als die rein formale Ablösedes bestehenden Systems durch eine langlebigere technischeSystematik. So zeichnet sich das neue Adressbuch der TUWien u.a. für den Benutzer vor allem durch eine Reihe zu-sätzlicher Funktionen sowie eine drastisch erhöhte Suchge-schwindigkeit gegenüber den White Pages aus. Es ist z. B.nun möglich, ohne jede Einschränkung gleichzeitig in dendrei Bereichen „Mitarbeiter“, „Studierende“ und „Organisa-tionseinheiten“ zu suchen.

Ein neues, von den Anwendern gewünschtes Werkzeugist z. B. die ins Adressbuch integrierte phonetische Su-

che. Der zugrunde liegende Algorithmus zur Berechnungder Ähnlichkeiten entspricht der „Kölner Phonetik“ [1].Dadurch können erstmals die existierenden Daten zusätz-lich nach ähnlich klingenden Namen durchsucht werden,womit die Frage nach der Schreibweise bei bestimmtenNamen (Maier, Mair, Mayer, Mayr oder Meyer) und Ver-wandten im offiziellen TU Adressbuch hinkünftig dertechnischen Kraft unseres Hauses angemessen gelöst ist.

Besonderer Wert wurde z. B. auf das Design einer über-sichtlichen Präsentation der Suchergebnisse gelegt. Als Er-weiterung der Funktionalität der White Pages wird die An-zeige der Ergebnisse sortiert nach Relevanz dargestellt. Eineigenes Regelwerk für die Sortierung listet die Entspre-chung der Suchanfrage in einer definierten Reihenfolge auf.Die Reihung ist abhängig von der Stelle, an der die Such-eingabe mit einem Eintrag übereinstimmt. Die Ergebnissewerden in fünf Kategorien gegliedert, wobei sie innerhalbeiner Kategorie alphabetisch sortiert werden. Eine Überein-stimmung der Sucheingabe am Beginn von Nachnamen lis-tet die Ergebnisse an oberster Stelle. Mit absteigenderRelevanz werden danach Übereinstimmungen innerhalbvon Nachnamen, am Beginn von Vornamen, innerhalb vonVornamen und in weiteren Feldern bewertet und aufge-führt. Das klingt beim ersten Lesen natürlich kompliziert.Ist es aber nicht. Ausprobieren und genießen. Der Versuchmacht alles klar.

Neben der erweiterten Anzeige der Suchergebnissewurde auch die Darstellung der Daten einer Person bzw.der Organisationseinheiten überarbeitet und mit einemneuen Layout versehen. Dem persönlichen Eintrag imAdressbuch kann jetzt jeder selbst durch ein Foto seineindividuelle Note verleihen.

Innerhalb der Darstellung von Instituten und Abteilungenist es nunmehr möglich, die in einer Organisationseinheit be-schäftigten Personen nach einer von der TISS-Projektgruppe„Fachkonzept“ (J. Eberhardsteiner, J. Fröhlich, G. Stein-hardt, A. Hörmann, M. Kolassa, W. Sommer) definiertenund auch vom TISS Steering Committee gewünschtenGliederung oder alternativ einfach alphabetisch sortiert auf-


Abbildung 1: Visitenkarte

zulisten. Die alphabetische Sortierung stellt zusätzlichweitere Daten zu Personen, wie deren Funktion, Raumcodeund Telefonnummer dar, wodurch die wichtigsten Informa-tionen zu allen Mitarbeitern einer Organisationseinheit im-mer auf einen Blick ersichtlich sind.

Die individuelle Gestaltbarkeit stand auch bei der neu-artigen Titelkonfiguration als primäres Designprinzip imVordergrund. Diese TISS-Funktion ermöglicht jeder Per-son, die Reihung der erworbenen akademischen Grade imRahmen der gesetzlichen Vorschriften zu definieren.Nicht nur die Reihung der Titel kann nun von den Perso-nen selbst verändert werden, sondern auch z. B. die Formder Abkürzung der Titel „Diplomingenieur“ und „Doctorhonoris causa multiplex“. Möglich sind hier die Abkür-zungen „Dipl.-Ing.“ bzw. „DI“ und „Dr.h.c.mult.“ bzw.„Dr.mult.h.c.“. Die vielfältigen Möglichkeiten, Änderun-gen bei den Mail-Einstellungen vornehmen zu können,wurden vom TISS-Team in ein einheitliches Änderungs-In-terface integriert. Dem Unkundigen mag dieses Feature alsunbedeutend erscheinen, in der Vergangenheit ergab sichhier allerdings laufend Anpassungs- und Änderungsbedarf,dem wir mit einem Werkzeug Abhilfe verschaffen, das die-se Probleme ein für allemal nachhaltig löst.

Die bisher öffentlich zugängliche Anzeige von Studie-

rendendaten im TU Adressbuch wird im Sinne eines be-wussten Umgangs mit dem Thema Datenschutz nur nochinnerhalb des TU-Netzes oder nach erfolgter Authentifi-zierung in TISS verfügbar sein. Den Studierenden wirdzusätzlich die Möglichkeit der individuellen Entscheidungüber die interne Anzeige der einzelnen Daten geboten.Damit kann beispielsweise die Anzeige der E-Mail-Adres-se gezielt unterdrückt werden.

Eine der bedeutendsten Kriterien für die Akzeptanz ei-ner Suchmaschine und die Zufriedenheit von Seiten der Be-nutzer ist neben dem Liefern von möglichen Treffern dieGeschwindigkeit, mit der die Suchergebnisse vor allemunter starker Belastung angezeigt werden. Bei der Durch-führung von Performance-Tests im Probebetrieb wurdenbei 10-facher Last gegenüber der heutigen Last der WhitePages keinerlei Performance-Einbußen verzeichnet. Bereitsein Resultat der gut gewählten Architektur.

Erste neue relevante Servicesfür Mitarbeiter und Studierende

Im Fokus der Entwicklung stehen in den kommendenWochen Fallbeispiele von Anwenderbereichen, die durchdie Realisierung in TISS und der damit verbundenen Neu-konzeption Entlastung, eine komfortablere Arbeitsumge-bung und zusätzliche lange erwartete Features bietenwerden. Im Konkreten sind dies z. B. die Studierendenver-waltung, der Bereich Abschlussprüfungen, Mitteilungsblät-ter und interne Veröffentlichungen. Das TISS-Team siehtauch diese Lösungsbeispiele als Referenz-Lernobjekte für

die große Masse an System-Ablösen und -Wechseln in denJahren 2009 und 2010.

Studierendenverwaltung

Die Optimierung vorhandener sowie die Konzeptionneuer Studierenden-Services ist eine Kernvorgabe anTISS. Die erste Phase der Verbesserungen erreicht sowohldie Studierenden als auch die Studien- und Prüfungsabtei-lung der TU Wien. Im vergangenen Jahr mussten an unse-rer Universität über 150.000 Zeugnisse (!) ausgedrucktund entweder direkt an Studierende am Schalter ausgege-ben oder postalisch verschickt werden. TISS wirkt demnun entgegen und stellt allen Studierenden ab dem Som-mersemester 2009 einen Online-Ausdruck von Einzel-und Sammelzeugnissen sowie diversen Bestätigungen wiedem Studienblatt und der Studienbestätigung zur Verfü-gung. Wir sind uns alle sicher, dass dies rasch als Entlas-tung der Studien- und Prüfungsabteilung spürbar wird undnatürlich den Komfort für die Studierenden erhöht.

Die gesamte Stammdatenverwaltung der Studierendenwird ab dem kommenden Sommersemester in TISS abge-wickelt. Dabei greift das TISS-Team zum ersten Mal die„ältesten Eisen“ der Altsysteme an und entfernt die erstenTeile eines aus IT-Sicht schon ewigen Problems: die bis-herige Stammdatenverwaltung gehört zu einer Gruppe vonbis zu 40 Jahre alten COBOL-Applikationen, deren Ablö-se im Sinne der Wart- und Betreibbarkeit in der Zukunftoberste TISS-Pflicht ist.

Abschlussprüfungen

Erste Entlastung und Unterstützung durch neue Featu-res werden demnächst nicht nur die Mitarbeiter der Stu-dien- und Prüfungsabteilung erfahren. Ausgehend von denpositiven Erfahrungen in der Fakultät für Elektrotechnikund Informationstechnik wurden erste Prototypen undTeilsysteme entwickelt, um die Abwicklung der Ab-schlussprüfungen zu vereinfachen. Dahinter liegen heuteviele unterschiedliche, händische, halbautomatisierte teil-weise inkonsistente Prozesse. TISS baut dafür heute einegut handhabbare, flexible Plattform, die die Automatisie-rung einheitlich unterstützt. Von dieser Entwicklung wer-den im ersten Schritt die Mitarbeiter der Dekanate, dannauch die Studierenden profitieren. Letztere vor allem beimEinreichen der Unterlagen für den Abschluss des Studi-ums. Das händische Ausfüllen des Einreichbogens wird inZukunft nicht mehr nötig sein. Studierende werden onlinemittels der in TISS gespeicherten Prüfungsdaten eine ini-tiale Zuordnung der Lehrveranstaltungen zu den Prü-fungsfächern machen können, die im weiteren Schritt vonden Mitarbeitern des jeweiligen Dekanats bearbeitet undgegebenenfalls vervollständigt werden kann.

Die Dekanatsmitarbeiter sammeln bereits heute ersteErfahrungen im Testbetrieb der speziell auf sie zuge-schnittenen Prototypen. TISS ist im Sinne einer anwender-freundlichen Herangehensweise natürlich in der Lage, diehistorisch sehr unterschiedlich gewachsenen Mechanis-men und Erfordernisse der Abschlüsse in den Dekanantenzu unterstützen. Jedem Dekanat seine Vorgehensweise!Die Grundfunktionen decken sich bei den meisten Deka-naten und unterstützen Vorgänge wie das Erstellen undVerwalten von Prüfungsterminen mit allen zugehörigenDaten und Fristen, Prüfungskommissionen und insbeson-dere auch das Generieren von Dokumenten, die für die


Abbildung 2: Titelkonfigurator

Abwicklung und die Bestätigung der erfolgreich abge-legten Abschlussprüfungen nötig sind.

Eine Vereinheitlichung darf das TISS-Team den Fakul-täten allerdings nicht ersparen: im Zuge dieser Arbeitenwerden die teils sehr unterschiedlich gestalteten Bescheidesowie Zeugnisse sämtlicher Fakultäten in ein einheitlichesLayout übergeführt.

Mitteilungsblätter und interne Veröffentlichungen

Auch die Rechtsabteilung des Hauses wird schon sehrfrüh mit einer eigens auf sie zugeschnittenen Teilapplika-tion von TISS in Berührung kommen. Für die Erstellungder Mitteilungsblätter sowie auch von Mitteilungen wird aneiner Lösung gearbeitet, die bei Bedarf zu einem vollwerti-gen Redaktionssystem erweitert werden kann. Zusätzlich zuunterstützenden Tools für die Erstellung selbst bringt hiervor allem die Möglichkeit der Versionierung einen ent-scheidenden Vorteil gegenüber dem aktuellen System.

Fachkonzept-Workshops

Wie schon in der letzten Ausgabe der ZIDline berich-tet, fanden und finden im ersten Jahr der TISS Entwick-lung eine Vielzahl von fachlichen Workshops statt. Dabeiwerden einerseits die Anforderungen an TISS auf ihreVollständigkeit überprüft und andererseits wird mittelsEinbindung der Stakeholder eine optimierte Lösung basie-rend auf einem konsolidierten Vorschlag erarbeitet undevaluiert. Der Großteil der Themengebiete wurde inzwi-schen mit zumindest einer ersten Runde bedeckt, mehrereThemen wurden schon in Folge-Workshops vertieft. DieWorkshops sind sehr erfolgreich. Das Know-how der Trä-ger im Hause ist ausgezeichnet, es kommen hervorragendeVorschläge und jeder Bedarf und Wunsch mit Qualitätwird vom TISS-Team als Systemdesignvorschlag aufge-nommen. Mit dem Essen kommt der Appetit, mit der Dis-kussion über die Gestalt von TISS im jeweiligenFachbereich kommen die Ideen, Beispiele und Use-Casesder Fachspezialisten. So haben wir es uns gewünscht undso leben es die Mitarbeiter.

Es wird dabei immer deutlicher, dass die Ablöse undVereinheitlichung die Pflicht von TISS ist, die Verbesse-rung und Erweiterung die umfassende Kür.

Im Folgenden werden einige der Workshop-Ergebnisseim Überblick dargestellt.

Aus dem Workshop über Studienpläne

An der TU Wien werden derzeit 69 verschiedene Stu-dien (Bachelor- und Masterstudien) für insgesamt 16 Stu-dienrichtungen und 5 Lehramtstudien angeboten, die inebenso vielen Studienplänen (69!) definiert sind. Hinzukommen noch einige Studien, für die keine neue Zulas-sung mehr erfolgen kann, die von Studierenden aber nochbis zu einem definierten Zeitpunkt abgeschlossen werdenkönnen. Da es bisher keine definierte Struktur gibt, nachder Studienpläne aufgebaut werden sollen, entstand einwahrer Wildwuchs an unterschiedlichen Aufbauten undRegelwerken. Um all diese Studienpläne elektronischmöglichst schematisch abbilden und damit verbundenauch effektive IT-Services anbieten zu können, wurdevom TISS-Team „Fachkonzept“ ein übergreifendes Mo-dell erstellt. Dieses wird mit dem Vizerektor für Lehre in

mehreren Iterationen überarbeitet und geprüft. In weitererFolge soll das daraus entstehende Modell eine Vereinheit-lichung geänderter und neuer Studienpläne hinsichtlichder Struktur und der Regelwerke unterstützen. Ein weite-res Ziel dieses Modells ist es, eine effektive Abstraktionder Studienpläne zu etablieren, die mehr Flexibilität in derkonkreten Befüllung der Fächer durch Lehrveranstaltun-gen zulässt.

Ein Beispielservice, das hier u. a. entstehen wird, istetwa eine individuelle Studienverlaufsanalyse, in der jederStudierende seinen persönlichen Fortschritt beobachtenkann. Diese Verlaufsanalyse würde auch als Unterstüt-zung für die persönliche Semesterplanung dienen undorganisatorische Belange vereinfachen.

Fallbeispiel Kanzleiinformationssystem (KIS)

Seit dem Beginn der Neunzigerjahre wird primär in derKanzlei und für einige Themen auch in der Studien- undPrüfungsabteilung für die Erfassung, Weiterbearbeitungund Selektion von ein- und ausgehenden Schriftstücken dasso genannte Kanzleiinformationssystem (KIS) eingesetzt.Dabei werden heute alle Dokumente mit einer eindeutigenGeschäftszahl versehen, mit deren Hilfe die physischenExemplare identifiziert und die Verknüpfung zum Eintragim System hergestellt werden können. Elektronische Postwird ausgedruckt und wie alle anderen Papierdokumente inOrdnern abgelegt. Die Zuordnung und insbesondere dasWiederauffinden eines Dokuments sind dabei stark von deretablierten Konvention abhängig. TISS ist hier bemüht, inenger Zusammenarbeit mit den Anwendern ein Werkzeugzur Verfügung zu stellen, das zur Arbeitserleichterung bei-trägt und den Anforderungen der heutigen Zeit (moderneArchivverfahren) entspricht. Das TISS-Team wird die ge-wohnten Abläufe erhalten, aber neue flexiblere bereitstellen.

Das Beispiel KIS zeigt deutlich, dass man im Laufe derdetaillierten Anforderungserhebung für TISS auf eineVielzahl von Applikationen und Funktionen stößt, die sichüber Jahre kaum oder gar nicht verändert haben. Ungenü-gende Anpassungen von Systemfunktionen an veränderteAnforderungen bringen die User dazu, im Sinne einerdringlichen Notwehr, um das anstehende Problem zu lö-sen, das bereitstehende System zu „misshandeln“. Es ent-wickelt sich eine Eigendynamik, die in der Folge mittels„Umgehungen“ zu einer missbräuchlichen Verwendungder Applikation führen kann. Das Kanzleiinformationssys-tem etwa wird entgegen seiner eigentlichen Funktion fürstatistische Auswertungen herangezogen, da in bestimm-ten Fällen nur in diesem System die dafür benötigtenDaten gespeichert werden können. Leider ist das KISjedoch für derartige Auswertungen nicht gerüstet.

Im Zuge der Ablöse der Altsysteme müssen Missstän-de, die aus mangelndem Support entstanden sind, beseitigtund durch zweckmäßige Lösungen ersetzt werden. DasAufdecken von „Umgehungen“ alleine führt nicht gleich-zeitig zu einer konsolidierten Gesamtlösung. Die Neukon-zeption bei gleichzeitiger Erhaltung der bestehendenDaten und Systematiken ist, so auch im Falle des KIS, ins-besondere im Sinne einer „seamless“ Migration eine ganzbesondere Herausforderung an das TISS-Team.


Fallbeispiel „Paternoster“der Studien- und Prüfungsabteilung

Im Rahmen der Diskussion der Anforderungen der Stu-dien- und Prüfungsabteilung an TISS wurde nicht nurüber eine optimale Ablöse der bestehenden Systeme ge-sprochen, es traten natürlich eine Reihe neuer Anforde-rungen zu Tage. Als Beispiel sei der Bedarf nach einemneuen Dokumentenmangementsystem genannt, das bishermechanisch (!) eine Vielzahl von Akten erfasst und ver-waltet. In einem über 40 Jahre alten rotierenden Akten-schrank („Paternoster“) sind Dokumente unterschied-lichster Art über mehrere Jahrzehnte gelagert. Um denMitarbeitern der Studienabteilung den Zugriff auf dieseDokumente zu erleichtern, gehen die Überlegungennunmehr natürlich in Richtung einer digitalen Ablage.

Aber auch in anderen Bereichen, wie der AbteilungGebäude und Technik (GUT), der Rechtsabteilung undder Personalabteilung wurde der dringende Bedarf nacheinem Dokumentenmangementsystem festgestellt. Darausleitet sich das Erfordernis nach einem Gesamtkonzept fürein Dokumentenmanagement ab, das das TISS-Team der-zeit planerisch in Angriff genommen hat.

Integration und Schnittstellen zu TUWEL

Das System TUWEL stellt diverse Funktionalitäten zurAbwicklung von Lehrveranstaltungen auf einer e-Lear-ning Plattform zur Verfügung. Insbesondere die flexibleVerwaltung von Lehrveranstaltungsunterlagen und unter-schiedlichen Gruppen, die Möglichkeit, Foren zu nutzenoder Feedbackzyklen für diverse Abgaben in die Lehrver-anstaltung einfließen zu lassen, werden heute gerne ge-nutzt. TUWEL ist damit ein wichtiges Instrument füreinige Lehrende der TU Wien geworden. Deshalb ist TISSnatürlich bemüht, geeignete Schnittstellen anzubieten undinsbesondere die Funktionen, die von beiden Plattformenangeboten werden, geeignet aufeinander abzustimmen.

Beispiel dieser Abstimmung: die parallele Verwendungvon Kalendern. Sowohl TISS als auch TUWEL werdeneigene Kalender anbieten, wobei wir eine möglichst voll-ständige Synchronisation der Daten anstreben, da für diemeisten Anwender Termine aus beiden Systemen relevantsein werden. Um nicht mehr zwischen zwei Ansichtenwechseln oder die Termine in einem dritten, persönlichenKalender möglicherweise händisch zusammenführen zumüssen, wird derzeit an Konzepten gearbeitet, um den Da-tenabgleich zwischen den Kalendern von TISS undTUWEL sowie die Kommunikation mit externen Kalen-dern einfach zu ermöglichen.

Neben der Kalenderthematik wird insbesondere die Ab-stimmung der Bereiche Gruppenmanagement sowie Ver-waltung von Lehrveranstaltungsunterlagen für ein erfolg-reiches Docking von TUWEL an TISS von Bedeutung sein.

Beispielthema Forschungsverwaltung

TISS hat als Gesamtsystematik u.a. auch die Aufgabe,Hilfsmittel und Services zur Verfügung zu stellen, um dieForschungsdokumentation zu erleichtern. In diesen Be-reich fallen derzeit insbesondere zwei Systeme – die Pro-jektdatenbank und die Publikationsdatenbank. BeideApplikationen werden am Ende der Entwicklung zur Gän-ze Teil von TISS werden. Wie bei den anderen Themengeht es dabei nicht nur um die Migration der bestehenden

Systeme, sondern ebenso um zweckmäßige Erweiterungenund Optimierungen der Workflows. Ein ganz wesentlicherWunsch aller Stakeholder und insbesondere auch desTISS Steering Committees ist die Vermeidung von Mehr-facheingaben von Daten. Die Mitarbeiter sind heute mehr-fach mit der Situation konfrontiert, dieselben Daten inunterschiedlichen Systemen mehrfach erfassen zu müssen.Im Bereich Forschung werden sowohl die Projekt- alsauch die Publikationsdatenbank zur Erfassung von wis-senschaftlicher Dokumentation eingesetzt. Berücksichtigtman das Bibliotheksverwaltungssystem Aleph, sind esstreng genommen drei unterschiedliche, großteils vonein-ander unabhängige Systeme mit redundanter Informationund teilweise ähnlichen Inhalten. Durch die Integration inein einheitliches System sowie die saubere Definition vonSchnittstellen zur Anbindung externer Systeme wird auchin diesem Fall am Ende eine deutliche Vereinfachung fürdie Anwender zu spüren sein.

Ausblick in die nächsten Phasen

Das Jahr 2009 wird für TISS erfahrungsreich undschrittbestimmend. Gelingen die Ablösen wie geplant(rein technisch werden sie dies jedenfalls, betreffend derAkzeptanz wird die Zufriedenheit der Anwender entschei-den), dann hat das Team alle Kernrisiken derartiger Mi-grationsprojekte überwunden. Natürlich verbleibt dannsehr viel Arbeit bis Ende 2010 in der Perfektion, „Flä-chendeckung des Systems“ und Erweiterung, es werdenaber keine Überraschungen mehr aus professioneller IT-Sicht eintreten. Treten hier noch wesentliche neue Auf-wandstreiber auf (große Mengen neuer Anforderungen,Akzeptanz- und Zieldiskussionen), dann müssten die Bau-und Zeitpläne angepasst werden. Derzeit ist damit abernicht zu rechnen.

Im Fokus stehen 2009 die Ablösen weiterer Altsyste-me, die Integration der Felderfahrungen in die Entwick-lung sowie die Ergänzung und Erweiterung des Fachkon-zeptes nicht zuletzt aufgrund des gewonnenen Feedbacks.Die Schwerpunkte werden dabei auf dem Bereich desLehrveranstaltungsmanagements und in diesem Kontextverstärkt auf der Schaffung eines rasch agierenden, quali-fizierten Docking-Verhaltens für externe und interneNachbarsysteme liegen.

Die Vertiefung der bisherigen Erfahrungen in weiterenWorkshops mit den Facheinheiten wird auch im kommen-den Jahr integraler Bestandteil des Fachkonzept-Prozessessein. Mittels Preview werden die zukünftigen User die An-wendungen, beispielsweise in Form von Prototypen, einerPrüfung unterziehen. Mit dem Feedback und den Erfahrun-gen der Endnutzer können die Systeme dann optimal an dieBedürfnisse angepasst und weiterentwickelt werden.

Die ZIDline wird laufend in kommenden Ausgaben überdie aktuellen Zwischenstände und Ergebnisse berichten.Der interessierte Leser sei auf www.zid.tuwien.ac.at/tiss/verwiesen und dazu eingeladen, dem TISS-Team über dasKontaktformular (www.zid.tuwien.ac.at/ueber_tiss/kontakt/)oder jederzeit per E-Mail an [email protected] zu geben.

[1] Kölner Phonetik. http://de.wikipedia.org/wiki/Kölner_Phonetik. Abgerufen am 10.11.2008


Das HPC-Cluster ProjektEin Gemeinschaftsprojekt der Universität für Boden-kultur, der Universität Wien und der TU Wien

Peter Berger und Herbert Störi

Die drei Universitäten beabsichtigen, gemeinsam einen Hochleistungsrechner zu beschaffen.Das geplante System soll an der TU aufgestellt werden und international wettbewerbsfähig sein.

Frühere Hochleistungsrechnerin Österreich

Es war sicherlich schon in der Frühzeit der Computerklar, dass auch österreichische Universitäten Rechnerentsprechender Leistung brauchen, um vor allem in denNatur- und Ingenieurwissenschaften international konkur-renzfähig zu sein. Bei den damaligen exorbitanten Kostensolcher Maschinen und der Dotation der Universitäten, dienoch bescheidener war als heute, war dies ein schwierigesUnterfangen.

Im Jahre 1974 wurde daher in Wien als Kooperationzwischen Universität Wien, TU Wien und Akademie derWissenschaften das Interuniversitäre EDV-Zentrum (IEZ)gegründet und vom Ministerium auch entsprechend do-tiert. Es bleibt wohl Historikernüberlassen, zu beurteilen, warum dasIEZ letztlich zum bürokratisch-politi-schen Monster entartet ist und wohlnicht als Erfolgsgeschichte in Erin-nerung bleiben wird. Im Jahre 1991wurde es letztlich aufgelöst.

Trotzdem wurden in Österreich imLaufe der Jahre immer wieder inter-national einigermaßen konkurrenzfä-hige Großrechner installiert (Abb. 1),wie aus der seit Juni 1993 geführtenTop500 Liste (www.top500.org) her-vorgeht. Österreich war von 1993 bis2003 mit Unterbrechungen vertreten,meist auch mit Systemen an Universi-täten. Das Diagramm zeigt auch, dasseinzelne Universitäten nicht in derLage waren, eine Position gegen dieinternationale Konkurrenz einigerma-ßen zu halten, obwohl bis Anfang der90er Jahre vom Wissenschaftsminis-terium beachtliche finanzielle Mittelin leistungsfähige Rechner investiert

wurden. Beispielsweise betrugen die 5 Jahresraten für den1992 in Betrieb genommenen Vektorrechner S100 (Abb. 1)je etwa 20 Millionen Schilling. Korrigiert auf heutigenGeldwert wären das jährlich 2 Millionen €. Die jetzt ge-plante Investitionssumme beträgt einmalig 2 Millionen €.Anzumerken wäre auch, dass frühe Parallelrechner wie Pa-ragon (TU Graz) und Meiko (Universität Wien) zwar rela-tiv leistungsfähig waren, allerdings darunter litten, dass diedamaligen Methoden der Software-Parallelisierung für Sys-teme mit verteiltem Hauptspeicher eher als experimentelleinzustufen waren.

Es ist wahrscheinlich auch kein Zufall, dass seit 2004kein österreichischer Eintrag in der Liste mehr aufscheint.Mit Inkrafttreten des UG 2002 hatten die Universitätenandere (finanzielle) Sorgen als Hochleistungsrechner.


Abb. 1:Österreichische Hochleistungsrechner in den TOP500 Listen seit deren Einführung 1993.

Volle Symbole stellen Systeme an der TU Wien dar, offene Symbole an anderenösterreichischen Universitäten und Kreuze stellen sonstige Systeme dar. Eintragungendesselben Systems sind mit Linien verbunden. (Adaptiert von http://www.top500.org)

Der Antrag „The Green Cluster“

Im Herbst 2007 wurde im Zuge des Forschungsinfra-struktur IV Programms ein Projekt „The Green Cluster“von TU und BOKU ausgearbeitet, mit dem Ziel, ein Cluster-system für numerisch intensives Rechnen in einer Dimen-sion von etwa 2000 cores (z. B. 500 quad core Prozesso-ren) an der TU Wien aufzustellen. Die Koordination dereingereichten wissenschaftlichen Projektanträge wurdevon Herbert Störi (Inst. f. Allgemeine Physik) übernom-men, die technische Ausarbeitung wurde von Peter Berger(ZID) durchgeführt. Das dem Entwurf zugrunde liegendePrinzip war es, die Rechenleistung ohne die Infrastruktureines full-service Rechenzentrums zur Verfügung zu stel-len und auf diese Weise das Verhältnis der erzielten Rech-nerleistung zu den Gesamtkosten zu optimieren. Da denArbeitsgruppen im Allgemeinen lokale Systeme zur Ver-fügung stehen, auf denen auch Daten gehalten werden,wurde etwa auf ein Datensicherungssystem für die File-systeme der Nutzer verzichtet.

Das Besondere an diesem Projekt war die Kooperationmit der Universität für Bodenkultur (BOKU), mit der unseine jahrzehntelange gute Zusammenarbeit verbindet. DerProjekttitel „The Green Cluster Project“ sollte ein Zeichendafür sein, dass uns die Reduktion der hohen Energiekos-ten für Clustersysteme dieser Dimension (z. B. durch denEinsatz energiesparender Prozessoren) ein wichtiges An-liegen ist.

Eingereicht wurden über 10 wissenschaftliche Projekteaus fast allen Fakultäten der TU Wien sowie aus der Bio-informatik, der Meteorologie und der Bodenchemie. EineVorziehprofessur für Informatik (Parallele Systeme) er-gänzte diesen Antrag. Erstmals an der TU Wien sollteauch die Informatik in ein Hochleistungsrechner-Projekteingebunden sein. Diese Entscheidung ist natürlich mitder Hoffnung auf neue Synergien zwischen Informatikund Mathematik einerseits und Anwendern aus dem Be-reich der Natur- und Ingenieurwissenschaften andererseitsverbunden.

Die Ablehnung des Projektes„The Green Cluster“

Nach der Begutachtungsfrist (Ende Jänner 2008) wur-den wir vom BMWF darüber informiert, dass dieses Clus-terprojekt der TU Wien / BOKU sowie die ähnlichenClusterprojekte der Universität Wien, der TU Graz undder Universität Graz abgelehnt wurden. Die in unseremProjekt enthaltene Vorziehprofessur wurde jedoch geneh-migt. In der Stellungnahme der Gutachter ist zu lesen,dass eher ein österreichisches Hochleistungsrechenzen-trum mit einem Aufwand jenseits der hundert MillionenEuro anzustreben wäre. Eine Integration in das ProjektPRACE wäre ebenfalls wünschenswert.

Die folgenden Zitate aus dem allgemeinen Gutachtenzu allen vier abgelehnten Anträgen geben den Tenor derGutachten ganz gut wieder:

...It was puzzling that the proposals excluded data archi-ving and backup; comparable initiatives elsewhere hadrevealed a high requirement for storage facilities. A UPS

would be required to ensure data were not lost in theevent of power loss and this had also not been taken intoaccount....The panel commented that a significant, Europe-wide,visible HPC facility would require enormous infrastruc-tural investments (up to ca. 10 MW of cooling capability,which imposed vast constraints on its location: e.g. aircooling would be prohibitively loud, while water coolingcould heat to boiling point all the water flowing along amajor river)....The reviewers stated that it would be highly desirable tointerlink Austrian activities with those on the Europeanlevel. As an example, Austria was not a full partner in theEuropean PRACE effort, ... Other countries had alreadycommitted about €120-150 million to create facilities toenable them to enter the programme....

Da sofort klar war, dass Mittel in der vorgeschlagenenHöhe auch nicht annähernd zur Verfügung stehen würden,andererseits aber der Bedarf nach high-end Rechenleis-tung tatsächlich existiert und dessen Deckung für die Posi-tion der TU als Forschungsuniversität unabdingbar ist,musste eine andere Lösung gefunden werden.

Ein neuer Anlauf –die TU Wien / BOKU Lösung

Nach der Ablehnung der finanziellen Mittel für dasClusterprojekt (wobei aber die Vorziehprofessur bewilligtwurde) wurden wir von Vizerektorin Prof. Dr. Seidler(VR für Forschung) beauftragt, eine „Sparvariante“ zu-sammen mit der BOKU auszuarbeiten, wobei der Einsatz-schwerpunkt vor allem auf Projekte mit hohem Paralleli-sierungsgrad ausgerichtet werden soll. Für kleinere Pro-jekte stehen weiter die kleinen Clustersysteme am ZID zurVerfügung.

Nach einer neuerlichen Befragung der Nutzergruppenwurden die Spezifikationen für ein Clustersystem erarbei-tet und dem Rektorat der TU Wien am 30. Juni 2008 vor-gelegt. Die Beschlussfassung sieht nun einen Betrag von €1 Mio (inkl. Infrastrukturkosten wie elektrischen An-schluss, Klima, Raumadaptionen) vor, das Projektteamwurde mit der Erstellung eines Leistungsverzeichnissesfür eine EU-weite Ausschreibung beauftragt.

Die Zusammenarbeit mit derUniversität Wien

Im September 2008 gab es eine vorerst inoffizielle An-frage der Universität Wien, ob eine Beteiligung am ge-planten Cluster denkbar wäre. Inzwischen sind dieGespräche weit fortgeschritten und die Universität Wienplant, vorbehaltlich der noch ausstehenden Genehmigungder Investition durch den Universitätsrat der UniversitätWien, sich ebenfalls mit 1 Million € an diesem Projekt zubeteiligen. Dadurch wird zwar die ursprüngliche Dimensi-on des Projektes mit einem Cluster von etwa 2000 coreswieder erreicht, allerdings für eine wesentlich größere Be-nutzergemeinde.


Der geplante Aufstellungsort ist nach wie vor der zen-trale Rechnerraum des ZID der TU Wien im Freihaus. Al-lerdings sind die erforderlichen Adaptierungsarbeitenwegen der erwarteten Anschlussleistung in der Größen-ordnung von 120 kW deutlich umfangreicher. Überdieserfordert die Aufstellung die Demontage der Origin2000.Der Maschinenraum ist dann komplett ausgelastet. Sollteeine weitere Ausweitung geplant werden, was vom Bedarfher sehr wünschenswert wäre, wäre ein neuer Standort fürGroßrechner erforderlich.

Die Schwerpunkte der Ausschreibung

Ziel der Ausschreibung ist ein Rechnercluster mit einerKombination an hoher Gesamtleistung und hoher Durch-satzleistung. Um echte Paralleljobs rechnen zu können, isteine entsprechend leistungsfähige Kopplung, wahrschein-lich mit Infiniband DDR, vorzusehen. Abbildung 2 zeigtein Prinzipschema eines derartigen Systems. Randbedin-gungen sind eine Unterbringung im verfügbaren Raum undeine Anschlussleistung, welche sowohl elektrisch als auchklimamäßig mit vertretbarem Aufwand realisierbar ist.

Terminplan

Der nächste Schritt ist die am 5. Dezember geplanteEntscheidung der Universität Wien. Anschließend kanndie bereits fertiggestellte und unter den drei Universitätenvorabgestimmte Ausschreibung veröffentlicht werden. Beider Festsetzung der Fristen muss dabei neben den Erfor-dernissen des EU-Rechts auch auf unmittelbar bevorste-hende technologische Entwicklungen Bedacht genommenwerden. Realistischerweise kann mit einer Installation imLaufe der Sommerferien 2009 gerechnet werden. Wieauch im ursprünglichen Projekt angedacht, soll ein kleinerTeil der Projektsumme für einen Ausbau nach 6 Monaten

zurückgehalten werden, um das System dann an das tat-sächliche Belastungskollektiv anpassen zu können, alsoetwa entweder die Anzahl der Rechnerknoten oder dieGröße und Art des Massenspeichersystems erweitern zukönnen. Denkbar wären auch speziell ausgestattete Rech-nerknoten für spezielle Applikationen.

Workshop

Neben der Ausschreibung und Installation der Maschineist aber auch die Planung der Projekte und die Realisierungder oben angesprochenen Synergien ein wichtiges Anlie-gen. Zu diesem Zweck wird am 8. und 9. Jänner unter derLeitung von Prof. Scharam Dustdar (Institut für Informa-tionssysteme) ein Workshop zum Thema „Hochleistungs-rechnen“ veranstaltet, zu dem alle potentiellen Nutzer vonden drei Universitäten herzlich eingeladen sind.

Zusammenfassung und Ausblick

Es ist geplant, im Wiener Raum (wieder einmal) eineninternational halbwegs konkurrenzfähigen Hochleistungs-rechner zu installieren. Nachdem zwei Anträge im Rah-men von Uni-Infrastruktur IV abgelehnt wurden, mussdies aus Mitteln des Globalbudgets der drei beteiligtenUniversitäten erfolgen. Es ist dabei anzumerken, dass sichdie Finanzierungszusagen im Moment auf eine einmaligeAktion beschränken, was mittelfristig das Problem derNachhaltigkeit aufwirft (vgl. Abb. 1).

Es gibt allerdings Aussagen aus dem Wissenschaftsmi-nisterium, dass die Finanzierung einer wien- oder öster-reichweiten Lösung durchaus vorstellbar ist, soferngezeigt wird, dass die interuniversitäre Zusammenarbeit indiesem Bereich nunmehr mit geringen Reibungsverlustenfunktioniert. Eine solche zukünftige Lösung könnte auchdie gewünschte Nachhaltigkeit bieten.

Zuletzt wäre festzuhalten, dass diePositionierung eines Systems in derTOP500 Liste nicht das einzige Krite-rium ist. Sie gibt allerdings einen Hin-weis darauf, wie sich die Ressourcen,welche den eigenen wissenschaftli-chen Arbeitsgruppen zur Verfügungmit denen vergleichen, die Kollegenbzw. Konkurrenten zur Verfügungstehen. Ein wesentlicher weiterer Pa-rameter, der in letzter Konsequenzüber die Attraktivität des Systems fürdie Spitzenforschung entscheidet, istdas Verhältnis von Rechenleistungund Anzahl der Benutzer bzw. Jobs.Um in dieser Hinsicht eine vernünfti-ge Situation zu erreichen, ist es nachwie vor erforderlich, dass kleinereSysteme existieren, die für Programm-entwicklung und kleinere Jobs ver-wendet werden. Der zukünftigeEinsatz des Phoenix-Clusters fälltetwa in diesen Bereich.


60 TWIN-nodes960 cores

1 IB Switch(144 Ports)

3 Fileserver + SATA-Storage3x 24TB (3. Rack)

Strom: ca. 60KW

Kühlung: Luft oder Wasser

30x HPC TWIN-Node

z.B. 4x Intel Xeon 3 GHz, quad-core32GB, 2GB memory/coreInfiniband DDR

z.B. 30x HPC TWIN-Node

2x Cluster-Racks, 42 HE1x Fileserver-Rack, 42HE

InfiniBand LAN20 Gbit/s

zu weiteren Cluster-Systemen

Infiniband Switch144 Ports

60 x60 x

Fileserver + Storage(SATA-Platten, 24TB)

ArchivFileserver + Storage(SATA-Platten, 24TB)

Fileserver + Storage(SATA-Platten, 24TB)

Abb. 2:Prinzipschema eines vergleichbaren Rechnerclusters mit ca. 1000 cores in 120 Knoten.

Eine Skalierung bis zu etwa 280 Knoten ist problemlos, da kompakte Infiniband-Switchesmit bis zu 288 Anschlüssen angeboten werden und einige Anschlüsse für Front-ends

und Fileserver erforderlich sind.

Mobil sein – WLAN nutzenJohann Kainrath

Die Wireless LAN Technologie unterstützt eines der wichtigsten Kriterien des heutigenArbeitslebens: Mobilität. Der u:book Laptop oder andere innovative mobile Devices (vom normalenLaptop über den vielseitigen PDA bis hin zum ultramodernen iPhone) als fast ständige Begleiter(nicht nur am Campus der TU Wien, sondern weltweit) bei Lehrenden und Studierenden als auchim Verwaltungsbereich der Universität. Und immer besteht der Wunsch nach sicherem Zugriff aufpersönliche Daten bzw. einfach nur auf das WWW, um rasch und unkompliziert zu aktuellenInformationen zu kommen.

WLAN Technologie – Was dahinter steckt

Der im Jahr 2003 durch die Universitätsleitung ge-wünschte und damals vom ZID begonnene Ausbau derWLAN-Infrastruktur am Campus der TU Wien wird nachwie vor durch Einsatz neuester Technologie vorangetrie-ben. Ende 2009 soll das Vorhaben in einer zeitgemäß flä-chendeckenden Versorgung der wichtigsten Bereicheabgeschlossen sein, aber naturgemäß damit nicht enden.

Ein Access Point (AP) ist die Verbindung zwischenFunkmedium und drahtgebundener Netzinfrastruktur, qua-si eine Bridge. Bis Mitte dieses Jahres wurden alle APs imautonomen Modus betrieben. Jeder AP fungierte dabei alsunabhängige Netzwerk-Komponente und musste eigenskonfiguriert und softwaretechnisch gewartet werden. Mitsteigender Zahl von APs bedeutete dies immer mehr Auf-wand. Um diesen zu reduzieren, wurde Mitte 2008 aufeine zentrale Infrastruktur in Form von Wireless LANService Modul (WiSM) Einschüben, so genannte WLANController, in den vorhandenen Backbone Cisco Cat6509Switch Systemen umgestellt. Dabei werden die APs zen-tral vom Controller gesteuert, dort liegt im Wesentlichendie ganze Intelligenz. In der Literatur findet man solcheLösungen unter dem Begriff „Unified Wireless Network

Solution“. Ziele dieser Strukturanpassung sind, die rapidewachsende Anzahl von WLAN-Usern und damit das Ver-kehrsaufkommen auf Dauer zu bewältigen, den flächen-deckenden Ausbau (insbesondere in neuen Bereichen) zugarantieren und auf neue Anforderungen rasch undflexibel reagieren zu können.

Im Zuge der Implementierung musste jeder AP konver-tiert, d. h. mit einem neuen Betriebssystem versehen wer-den. Es erfolgte die Umstellung auf das LWAPP(Lightweight Access Point Protocol) Protokoll. Arbeitetder AP im Lightweight Modus, dann fungiert er im Prin-zip als mehr oder weniger unintelligente Sende- und Emp-fangseinheit, die sich bei einem Controller registrierenmuss. Zu diesem hält er dann über einen LWAPP-Tunnel

immer den Kontakt aufrecht, wobei dieser die globalenSteuerungsaufgaben übernimmt.

Durch den aufgebauten Tunnel geht der ganze Daten-verkehr encapsuliert zum Controller, wo dieser dann inden TUNET-10GE-Backbone übergeht. Dadurch wird einhöheres Maß an Sicherheit erreicht, da derzeit alle Datenzwischen dem Wireless LAN Client und dem AccessPoint (zumindest bei 802.1x) verschlüsselt sind. In einerder nächsten Software-Releases wird dann auch der Da-tenverkehr bis hin zum Controller verschlüsselt werdenkönnen. Die Infrastruktur dahinter, zwischen AP und demController, gilt als sicher.

Apropos Sicherheit: Ein AP im LWAPP Mode enthältkeinerlei Informationen über die TUNET-Infrastruktur.Ein Diebstahl in dieser Hinsicht lohnt sich also nicht, ohneController würde der AP auch gar nicht funktionieren.

Alle wesentlichen Wireless Security Protocols – wie802.11i, Wi-Fi Protected Access (WPA), WPA2 und802.1x sowie die gängigsten Extensible AuthenticationProtocol (EAP)-Arten – werden unterstützt. Die AccessPoints selbst ermöglichen alle Verschlüsselungsmethodenbis hin zum hardware-beschleunigten Advanced Encryp-tion Standard (AES).

Der Begriff WLAN-Controller steht für eine Netzwerk-Komponente (in unserem Fall ein Einschubmodul in einemBackbone Switch), welches zentralisiertes Management so-wie Kontrolle über alle (LWAPP) Access Points implemen-tiert. Hauptvorteil dieser Lösung ist die Verwaltung allerWLAN-Services von einem zentralen Punkt (dem Control-ler bzw. der zugehörigen Management Station) aus. Das al-les kann auch über eine Web-Oberfläche erfolgen. DiesesManagementsystem (WCS – Wireless Control System)bietet neben ausgedehnten Report-Funktionen auch SiteSurvey Planungsoptionen. Natürlich kann am lebendenWLAN-Service damit bei Bedarf auch jede Menge LiveMonitoring und Trouble Shooting erfolgen. So werdenalle APs dauernd bezüglich ihres Status überwacht und die


Ausbreitung der Funkwolke kontrolliert und dynamischan neue Bedingungen angepasst. Dies führt auch massen-weise zum Auffinden von nicht vom ZID betriebenen APs(so genannter Rogue APs), die sich im Empfangsbereichder TUNET Wireless LAN Services befinden. An dieserStelle sei nochmals der Hinweis angebracht, dass der Be-trieb eigener APs nicht gestattet ist. Bei Bedarf kontaktie-ren Sie bitte den ZID.

Ein Ziel aller Aktivitäten beim Ausbau der TUNETWLAN Infrastruktur ist die Steigerung der Ausfallssi-

cherheit. Die heute mehr als 300 betriebenen APs werdenderzeit von sechs aktiven Controllern im Freihaus, Karls-platz und Gußhaus gesteuert. Fällt ein Controller aus, soorientieren sich alle APs auf einen Backup Controller umund garantieren so weiterhin die reibungslose Funktionali-tät der TUNET WLAN-Services.

Ein Vorteil einer solchen Lösung ist die zentralisierteData-Forwarding Funktion. Damit ist gemeint, dass jegli-cher Verkehr über den Controller geht. Dort können an op-timaler Stelle neben der Authentifizierung für die WLAN-Benutzung auch alle weiteren Entscheidungen wie konkreteWeiterleitung der Datenpakete, Ausführen von QoSQueueing Mechanismen, VLAN-Zuweisung etc. erfolgen.

Bei der Authentifizierung gibt es im Prinzip zwei un-terschiedliche Szenarien. Entweder erfolgt diese über802.1x Mechanismen (z. B. bei eduroam) oder über einWebportal. Letztere, die so genannte Web-AuthenticationMethode, hat schon eine längere (und manchmal sowohlfür Benutzer als auch Systembetreuer auch leidvolle) Ge-schichte. Erste Erfahrungen wurden mit einem so genann-ten Universal Subscriber Gateway von der Fa. Nomadixgesammelt. Diese Lösung stieß sehr schnell an ihreGrenzen. Daher wurde eine von der Universität Wienentwickelte Eigenlösung (die so genannten PNS – PublicNetworks Services – Gateways) für die TU adaptiert. Mitte2008 war ob der enorm gestiegenen Anforderungen (mehrals 900 gleichzeitige WLAN-Benutzer in Spitzenzeiten)wieder Handlungsbedarf gegeben. Daher erfolgte nachEvaluierungen und Diskussionen der Umstieg auf die vor-hin beschriebene controller-basierte Lösung. Damit konn-te auch gleich die Benutzerauthentifizierung integrierterfolgen und die PNS-Gateways anderen Verwendungs-zwecken zugeführt werden.

Neue Standards im WLAN der TU Wien –802.11n Draft 2.0

In weniger als einer Dekade ist Wireless LAN von ei-ner interessanten Idee zu einer unverzichtbaren Technolo-gie für Millionen Benutzer geworden, die sich zudemrasant weiterentwickelt. Auch die letzte Generation vonHighspeed Wireless LAN Lösungen, basierend auf demIEEE Draft 802.11n Standard, wird an der TU Wien imRahmen der TUNET Wireless LAN Services bereits (seiteiniger Zeit) unterstützt.

Begonnen wurde die WLAN-Installation am Campusmit der damals verfügbaren Technologie 802.11b in Formvon Cisco APs der Serie 1230, welche Bruttodatenratenbis zu 11MBit/sec (netto ca. 5,5 MBit/sec) im 2,4 GHzBereich erlaubte (siehe ZIDline Nr. 12). Die im TUNETverbauten APs der nächsten Generation der Type 1240dehnten die WLAN-Services auf das 5 GHz Band

(802.11a) inkl. höherer Datenraten aus und verbessertenauch im 2,4 GHz Bereich (802.11g) den Datendurchsatzsowie die Anzahl unterstützter Clients.

Die aktuellen Cisco Access Point Modelle vom Typ1250 unterstützen 802.11a/b/g Clients und neue Wi-Fi802.11n Draft 2.0 zertifizierte Endgeräte. Diese APs sindmodulare Geräte und verfügen über zwei Radio Module.Dabei sitzt nicht nur mehr eine Antenne am Gehäuse, son-dern pro Sende/Empfangseinheit verrichten drei Antennenihren Dienst. Diese MIMO (Multiple Input / Multiple Out-put) Technologie garantiert ob ihrer Diversity bestmögli-chen Empfang auch unter schwierigen örtlichenVerhältnissen. Und dieser wiederum garantiert stabilereVerbindungen und höhere Datenraten beim Zugriff aufUniversitätsservices – und das für mehr gleichzeitigeUser. Diese Access Points der neuesten Generation sindsomit bestens geeignet für die Versorgung anspruchsvollerLokationen wie große Hörsäle und Bereiche, in denen sichviele Studierende aufhalten.

Derzeit sind 319 Access Points in Produktion. DasWLAN-Service wird sowohl im 2,4 GHz Bereich (802.11b/g/n Draft 2.0) als auch im 5 GHz Bereich (802.11a/nDraft 2.0) angeboten. Die zu beobachtende maximale An-zahl assoziierter Clients aller WLANs (SSIDs) geht gegen1000 User.

In der folgenden Abbildung sind die im TUNET einge-setzten AP-Typen zu sehen. 802.11g ist der momentan amweitesten verbreitete Standard. 802.11a wird vor allemvon neueren Endgeräten benutzt. 802.11n ist der neue de-facto Industriestandard und stark im Kommen, allerdingsnoch ein so genannter Draft Standard in der Version 2.0.Er wird einen signifikant größeren Datendurchsatz für Ap-plikationen als 802.11a/b/g bieten (siehe Tabelle).

Die IEEE 802.11 Task Group n (TGn) arbeitet seitSeptember 2003 an dem Standard. Nach der Einreichungvon 32 verschiedenen Proposals stellte sich bei der Ent-wicklung ein gewisser Deadlock ein. Im Oktober 2005


Die Normen-Familie für WLANs wird unter 802.11 beschrieben

1230er:alt aber gut(802.11b)

1250er:neueste Technologie

(802.11a/b/g/n)

1240er:zuverlässig

(802.11a/b/g)

wurde auf Initiative einiger Firmen (Gründung EWC –Enhanced Wireless Consortium) ein neues Proposal einge-reicht, dies wurde im Jänner 2006 von der IEEE als Basisfür den 802.11n Standard akzepiert. Dadurch konnte dieIndustrie beginnen, entsprechende Produkte zu produzie-ren und auf den Markt zu schmeißen. Moderne Geräte un-terstützen damit bereits den Draft 2.0 des 802.11nStandards, der in beiden Bändern (2,4 und 4 GHz) arbeitet.

Generell soll 802.11n die Performance verbessern, dieVerlässlichkeit der WLAN-Verbindung erhöhen, Rück-wärtskompatibilität mit 802.11a/b/g Standards garantie-ren, verbesserte Unanfälligkeit gegen Störgeräusche bie-ten sowie mehr gleichzeitige Clients durch erweitertesFrequenzspektrum und mehr verfügbare Kanäle unter-stützen.

Über die zentrale WLAN Management Station kanndie Ausdehnung der Funkwolke im 2,4 und 5 GHz Be-reich und damit die Versorgung des Campus mit WLANnäherungsweise dargestellt werden. Dazu wurden alle Ge-bäudepläne der TU Wien in das System eingepflegt. EinBeispiel für die Ausleuchtung des ersten Stocks desFreihauses zeigt eine so genannte Heat Map auf demTitelblatt.

Die aktuelle Versorgung entnehmen Sie bitte:www.zid.tuwien.ac.at/kom/tunet/wlan/versorgte_bereiche/

Welche WLANs gibt’s an der TU Wien –welche SSID ist die richtige im Wellenmeer

Der ZID betreibt derzeit drei unterschiedliche WLANsmit folgenden Kennungen/Eigenschaften:

• SSID „tunet“: unsicheres offenes WLAN für alle TU-Angehörigen und Gäste, Konferenzen, Authentifizie-rung über ein Webportal, optional mit VPN-Nutzung.

• SSID „eduroam“: gesichertes Netzwerk mit 802.1x, fürStudenten und Mitarbeiter der TU sowie für Personen,deren Heimat-Organisation am eduroam teilnimmt.

• SSID „wlanipsec“: WLAN Service aussschließlich fürTU-Mitarbeiter, VPN erforderlich.

Je nach SSID wird dem WLAN-Client dynamisch eineIP-Adresse aus einem Pool zugeweisen oder bei Verwen-dung von VPN auch fix zugeordnet.

Zugang zum WLAN –welche Accounts stehen zur Verfügung

Als Mitarbeiter der TU Wien ist man mit einem Mobil-Netzzugang (dem so genannten WLANDEMO-Account)am Puls der Zeit dabei. Es gibt keinen anonymen Zugangzum TUNET über die WLAN-Infrastruktur. Wohl gibt esfür Institute die Möglichkeit, WLAN-Gast-Accounts fürihre Gäste zu bekommen. Auch für Konferenzen könnenMassen-Accounts mit Zeitbeschränkung vergeben werden.

Überall am Campus, wo sich die WLAN-Funkwolke aus-breitet, kann man auf das dahinter liegende Datenangebotder Universität, seine Einrichtungen etc. zugreifen. Bestimm-te Accounts können auch weltweit verwendet werden, indemsie zu eduroam berechtigen (siehe dazu auch ZIDline Nr.16). Man kann einfach mit den Mobil-Account-Daten der

TU Wien die örtliche WLAN-Infrastruktur nutzen und musssich nicht um einen Gast-Account bemühen. Dies gilt natür-lich auch für alle Studenten-Accounts.

Um den WLAN-Boom (u:book) zu unterstützen und densteigenden Kapazitätsbedarf bei IP-Adressen, Bandbreiteund gleichzeitiger Benutzer-Logins abzudecken, waren diebeschriebenen Änderungen in der Infrastruktur erforderlich.Im Oktober erfolgte die Umstellung der Web-Authentifizie-

rung im unsicheren WLAN „tunet“ auf eine andere Platt-form. Dabei änderte sich die Webseite für dieAuthentifizierung (diese kommt nun direkt vom WLAN-System und nicht mehr von einem externen Webserver).Nach erfolgreichem Login landet man auf der ursprünglichangegebenen Webseite und kann das WLAN bis zu 8 Stun-den nutzen. Bei Inaktivität wird man nach Ablauf eines ent-sprechenden Timers automatisch aus dem WLANausgeloggt und man muss sich neuerlich validieren. Auch inden drahtgebundenen Hörsaal-Anschlüssen kommt dieserneue Authentifizierungsmechanismus zur Anwendung.Berechtigte Benutzer haben dort mit ihrem WLANDEMO-Account Zugriff auf alle TUNET-Ressourcen.

Bei der WebAuth-Methode ist zu beachten, dass derAufruf einer Webseite (ein so genannter http-Request aufPort 80) notwendig ist, um zum WLAN-Authentifizie-rungsportal zu gelangen. Achtung: Die Umleitung durcheinen https-Request (Port 443) funktioniert dabei nicht.Beim erstmaligen Zugriff auf die Authentifizierungs-Web-seite des WLAN-Systems ist derzeit das (vom HerstellerCisco Systems ausgestellte) Zertifikat mit IP-Adresse1.1.1.1 webauth.demo.tuwien.ac.at zu bestätigen.

Den Benutzern steht nun ein größerer Adressraum zurVerfügung, aus dem WLAN-Clients via DHCP eine IP-Addresse zugewiesen bekommen. Man sollte jedoch un-bedingt sicherstellen, dass der Rechner so eingestellt ist,dass er im WLAN seine IP-Adresse automatisch beziehenkann.

Clients –was ist bei der Anschaffung zu beachten

Man sollte sicherstellen, dassder eingebaute (bzw. externe)Adapter wenn möglich durch dieWi-Fi Alliance 802.11n Draft 2.0zertifiziert ist (siehe www.wi-fi.org). Man sollte ferner da-rauf achten, dass ein Software-Update möglich ist. Dieseswird ziemlich sicher notwendig, wenn der finale 802.11nStandard kommt. Realistischerweise können aber inte-grierte WLAN-Karten auf älteren Laptops nicht mehr ent-sprechend upgegradet werden. Für optimale 802.11nNutzung werden drei Antennen benötigt (die bei aktuellenLaptops im Gehäuse integriert sind). Adapter neuererBauart haben einen signifikanten Einfluss auf den er-zielten Performance-Level und ein wesentlich besseresRoaming-Verhalten, sie beeinflussen aber auch die Batterie-laufzeit wesentlich.

Sobald der endgültige 802.11n Standard (voraussicht-lich zu Beginn 2009) verabschiedet ist, wird dieser an derTU Wien durch entsprechende Upgrades in der WLAN-Infrastruktur unseren Benutzern zur Verfügung stehen.


DNS –(k)ein Anschluss unterdieser NummerJohann Klasek

DNS, ein Service, das erst dann auffällt, wenn es nicht funktioniert – hier wird der Bogen zu dieser„Internet-Auskunft“ von der Historie über die Implementierung bis zu jüngsten Vorkommnissen ander TU Wien gespannt.

Der Anfang

Erst kürzlich konnte sich das Domain Name System,kurz DNS, über das 25-jährige Bestehen freuen. Das mitden RFCs 882 und 883 von Jon Postel, Paul Mockapetrisund Craig Partridge ersonnene Protokoll hat in der Praxisbis heute nahezu unverändert überdauert. War es im Vor-läufer des heutigen Internets, dem ARPAnet, noch üblich,die IP-Adressen über eine lokale Datei auf Namen abzu-bilden (die dann in diversen Ausprägungen ausgetauschtwurden), zeigte sich spätestens 1983 – nicht zuletzt durchdas enorme Anwachsen bzw. die Zusammenschlüsse ver-schiedenster wissenschaftlicher und kommerzieller Netze–, dass ein globales Namenssystem unabdingbar war. DenWeg dafür hat im Grunde erst der Umstieg auf die wesent-lich besser für weltumspannende, verteile Netzwerke ska-lierende Protokollsuite TCP/IP bereitet, die zu diesemZeitpunkt eingeführt wurde.

Realisierung

Um zentralistische Konstruktionen zu vermeiden, hatdas DNS einen hierarchischen, verteilten Charakter. Wei-ters sollten Namensabfragen das Internet insgesamt unddie beteiligten Rechner möglichst schonen. Daher war dasProtokoll auf das verbindungslose datagramm-basierendeUser Datagram Protocol (UDP) zugeschnitten. EtwaigeVerschlüsselungsansätze zur Sicherung des Inhalts oderder Sicherstellung der Authentizität beteiligter Partnersucht man im ursprünglichen Ansatz vergeblich. Trotz al-ler Protokolleffizienz sind Caching-Verfahren auf den beiAbfragen beteiligten Nameservern unvermeidlich, machenaber das System umso effektiver. Die eigentlichen Teil-nehmer eines Netzwerks wie das Internet, seien es Ar-

beitsplatzrechner oder Server für Applikationen, Mailser-vice etc. sind hier als so genannte Clients die Nutznießerdes Systems. Lediglich eine IP-Adresse eines Nameser-vers (der Redundanz geschuldet sind es oft mehrere)reicht aus, um am weltumspannenden Namenssystem teil-nehmen zu können.

Anwendungen

Diente das Namensservice bis Ende der 90er Jahre vor-nehmlich dazu, Rechnernamen (Hostnamen) und E-Mail-Adressen aufzulösen (sowie auch umgekehrt, um voneiner IP-Adresse auf einen Hostnamen zu kommen), er-sann man auch die Verwendung des Systems für gänzlichandere Zwecke, die ihren Ursprung im ThemenkomplexE-Mail und Spam haben. Dabei wird nicht nach der zu ei-nem Namen gehörenden IP-Adresse gefragt, sondern dieExistenz des entsprechenden Eintrags gibt hier die ent-sprechende Auskunft. Dieser Weg bietet sich an, da DNS-Abfragen verhältnismäßig wenig „kosten“. Dazu „kodiert“man den Abfragewert in einen Pseudo-Domainnamen,dessen Auflösung via DNS dann das gewünschte Ergebnisliefert.

Eine Abfrage, ob die IP-Adresse 100.99.1.1 z. B. aufder RBL+ Blacklist eingetragen ist, wird auf den abzufra-genden Domainnamen 1.1.99.100.rbl-plus.mail-abuse.orgabgebildet. Die Abfrage ist positiv, wenn der Eintrag (dieretournierte IP-Adresse – meist eine 127.x.x.x Variante –klassifiziert gegebenenfalls das Ergebnis weiter) existiert.Auf diese Art lassen sich nicht nur IPv4-Adressen sondernauch IPv6-Adressen oder auch die Domain- oder Hostna-men aus Webadressen, wie sie in Spam-Mails verstreutwerden, einkodieren, abfragen und bewerten.


Eine weitere Entwicklung ist die Internationalisierungvon Domainnamen, die auf Unicode aufgebaut sind, wo-durch z. B. Umlaute in Domainnamen möglich sind. Diehierzu verwendete spezielle Kodierung (Punycode) nutztdie bisherige DNS-Infrastruktur ohne irgendeine Anpas-sung. Lediglich die an der Kommunikation beteiligtenPartner (z. B. Browser und Webserver) müssen dieser Ko-dierung gewahr sein und die Domainnamen entsprechend„umgestalten“.

Eine neuere Adaptierung des DNS der moderneren Artist die Telefonnummernauflösung (ENUM), um die im In-ternet erreichbaren Gerätschaften für typischerweise Voiceover IP -Dienste adressieren zu können.

Problemzonen

Die einfache und effiziente Gestaltung des DNS-Proto-kolls geht aber auch mit etlichen Schwachstellen einher,die auch im Laufe der letzten Jahre bei den am DNS betei-ligten Software-Produkten aber auch am Protokoll selbstheftige Diskussionen hervorgerufen haben. Sicherheitsre-levante Vorkommnisse haben jedoch nie das System ins-gesamt wesentlich in Bedrängnis gebracht. In Anbetrachtder möglichen Folgen für einen großflächigen oder totalenAusfall der Namensauflösung im Internet (aus lokalerSicht haben viele sicher die ein oder andere unangenehmeSituation erfahren) hat sich das System erstaunlich robustgezeigt.

Die bislang bedeutsamsten Probleme fallen in die bei-den Klassen

• Cache-Poisoning• Spoofing

Beide Klassen zielen darauf ab, einem Nameserverbösartig modifizierte Antworten unterzuschieben oder zu-sätzliche (bösartige) Informationen mit legitimen Antwor-ten „mitzuliefern“. Im betroffenen Nameserver landendiese „Veränderungen“ schlussendlich im Cache, welcherdann derart „vergiftet“ ist, dass die infolge stattfindendenAbfragen von Clients (die aus dem Cache bedient werden)auf völlig andere Ziele umgelenkt werden. Dies ist einetypische Variante, wie sie kaum idealer als Grundlage für„Phishing“-Angriffe Verwendung finden kann, der einBenutzer praktisch hilflos und völlig in Unwissenheit blei-bend ausgeliefert ist.

Verbesserungen verspricht langfristig nur das krypto-graphisch gesicherte DNSSec-Verfahren als Erweiterungzum bestehenden DNS-Protokoll. Das funktioniert abernur flächendeckend und ist leider in der Umsetzung undAkzeptanz weit hinter den Erwartungen zurück. Zwi-schenzeitlich behilft man sich mit immer neuen Detailver-besserungen, die Angriffe zwar erschweren, aber nichtvöllig abwenden können.

Typisch ist das neueste Angriffsszenario, das in Sicher-heitskreisen seit 9. Juli 2008 für Furore gesorgt hat (wirdin weiterer Folge auch im Detail behandelt). Dank immergrößerer verfügbarer Bandbreiten sind „brute-force“ An-griffe (sowohl von außerhalb, speziell aber auch von „in-tern“) machbar und zielen darauf ab, einer legitimen

Antwort zu einer Anfrage zuvor zu kommen, indem miteiner großen Anzahl von möglichen Antwortvariationenversucht wird, eine passende Anwort zu erraten. Erreichtdie eigentliche Antwort den unter „Beschuss“ stehendenNameserver zu spät (auch da gibt es Tricks, die Antwortetwas aufzuhalten), kann die untergeschobene Antwortbeliebige Nameservice-Daten manipulieren, die dann vor-übergehend im Cache liegend an alle anfragenden Clientsausgeliefert werden.

Namen aus dem TUNET

Unterschiedliche Sichten:

• TUNET innerhalb: für Arbeitsplätze und sonstige Rech-ner am TUNET

• TUNET außerhalb: für andere Nameserver, die nachtuwien.ac.at-Namen von außerhalb der TU Wien fragen

Zusätzliche Nameservices:

• Externe: An der TU Wien gehostete Domains, die nichtauf tuwien.ac.at enden aber dennoch einen entsprechen-den Bezug zur TU Wien aufweisen.

• Realtime Black/White-Lists (ISPA, RBL+): Die TUWien betreibt hierzu sekundäre Nameserver (vom Da-tenstand synchron), deren Cache die fremden Nameser-ver der jeweiligen Services und die Internet-Anbindungder TU Wien entlasten. Hauptkonsumenten dieser Listensind die zentralen Mailserver.

Wesentliche Punkte sind die Redundanz, Stabilität undSkalierbarkeit. Für die TU-interne Sicht stehen bekannt-lich zwei Nameserver (tunamea/b) zur Verfügung. Hinterdiesen verbergen sich jeweils mehrere Rechner, die einenredundanten Verbund bilden. Bei dieser Konstruktion„verstecken“ sich (derzeit) zwei Server hinter einer derbeiden bekannten IP-Adressen für die Nameserver. Sokönnen im Desasterfall bis zu zwei Server ausfallen, ohnedass Clients hiervon etwas davon bemerken (schlimmsten-falls in der Antwortzeit, sollte sich die Last auf den ver-bliebenen Servern allzu sehr konzentrieren). Die Leistung


tunameb

tunamea

TUNET Internet

Clients

DNS-Anfragen

DNS-Anfragen

Cache

Cache

tuwien.ac.at

Datenbank

Funktionsblöcke TU-internes Nameservice

der Nameserver kann problemlos und für Benutzer trans-parent durch Hinzufügen von weiteren Servern zu jedemVerbund einfach erhöht werden.

Eine Auflösung

Der Weg einer Anfrage durch einen Client nimmt wohlanfangs eine einfache Gestalt an, führt dann aber bei denbeteiligten Nameservern in der hierarchischen Auflösungauch bei kurzen Domainnamen zu zahlenmäßig doch rechtumfangreichen Abfragen, weil hier eine rekursive Kom-ponente maßgeblich beteiligt ist. Die im Zuge einer stu-fenweisen Auflösung ermittelten Nameservernamenmüssen nämlich ihrerseits wieder per neuerlicher Abfrageauf IP-Adressen abgebildet werden. Auf diese Weise „ex-plodiert“ das Abfragepensum vorerst und erst das durch-gängige Caching innerhalb eines Servers bewahrt einsolches System vor einem Kollaps. Die einmal in einemServer gespeicherten Resultate sind für eine gewisse Dau-er im Cache gültig. Darin begründet sich aber auch eineweitere Eigenschaft des DNS, die sich in einer gewissen„Trägheit“ hinsichtlich der Verbreitung von Änderungenbei bestehenden Namen niederschlägt. Typischer Fall istetwa die Umstellung eines Webservers auf eine neue IP-Adresse. Solange weltweit die „alte“ Adresse in den Ca-ches fremder Nameserver gültig ist (den Gültigkeitszeit-raum kann man aber zum Zeitpunkt der Datenabfragefestlegen), sind im gesamten Internet vorübergehend diealte und die neue Adresse in Verwendung.

Ein Vorfall

Erst kürzlich machten sich im TUNET Unregelmäßig-keiten im DNS-Service bemerkbar. Auslöser war die am9. Juli 2008 veröffentlichte Schwachstelle in den verschie-

densten Serverimplementierungen, unter anderem auch inder an der TU Wien eingesetzten ISC Bind Software. Hierzeigte sich, dass die infolge veröffentlichten Korrekturenund Anpassungen in einer Software trotz bester Absichtins Negative umschlagen können. Das Zusammenwirkenvon mehreren Faktoren hat in Kombination dann zu be-trächtlichen und vor allem merkbaren Einbußen bzw. Stö-rungen im Nameservice geführt. Die Auswirkungen warendabei vielfältig und offenbarten sich nicht immer gleichals typisches DNS-Problem: An die TU Wien gerichteteE-Mails verzögerten sich, wurden leider sogar fallweiseabgewiesen, weil plötzlich Namen von Mailzielen überandere Wege (welche nicht verwendet werden sollten)aufgelöst wurden und sich daraus keine brauchbaren Wei-terleitungen ergaben. Web-Surfen innerhalb des TUNETwurde zur Geduldprobe, obgleich kein Bandbreiteneng-pass im Netzwerk vorlag.

Alles nahm seinen Ausgangspunkt in der Änderung desModus, wie eine Namensauflösung erfolgt (mit dem ei-gentlichen Zweck, es einem Angreifer möglichst schwerzu machen, korrekte Antwortpakete zu erraten und einzu-schleusen). Abfragen werden dann intensiver und in je-dem Teilschritt der rekursiven Namensauflösungabgewandelt, dass ein Erraten statistisch möglichst un-wahrscheinlich wird. Der Nebeneffekt davon war, dass Li-mits an den diversen Firewalls der TU Wien, die dieNameserver und die Rechner am TUNET vor allerlei Un-gemach aus dem Internet schützen, auch diesen aufs Viel-fache angewachsenen DNS-Verkehr einschränkten – mitfatalen Folgen für den Auflösungsprozess: Anfragepaketewurden von den Firewalls verworfen, die DNS-Server er-hielten keine Antworten und versuchten, alternative Na-meserver zu kontaktieren, was noch mehr neue Abfragenproduzierte und die Firewall noch weiter an die künstlichgesetzten Grenzwerte drängte. Verschärft wurde diese Ab-fragesituation dann noch durch betriebssystemspezifischeLimits, die die plötzlich viel höheren gleichzeitig aktivenAbfragen nicht mehr im vollen Umfang akzeptierten. DieNameserver erstickten förmlich in ihren eigens produzier-ten Abfragen und konnten sich – einmal in diese Situationgekommen – wie ein festgefahrenes Auto im Schlammlochnicht mehr alleine aus der Situation befreien. Manchmalwar die Situation auch so grenzwertig, dass zu einem mehroder weniger unvorhergesehenen Zeitpunkt die Situationvom Normalbetrieb in eine kritische Phase „kippte“.

Ein Beispiel: Aus der Sicht der zentralen Mailserver(diese sind wegen der Vielzahl von Blacklist/Whitelist-Überprüfungen, SPF-Checks, MX-Auflösung, IP-Hostna-menauflösung im Zuge der Anti-Spam-Maßnahmen quasidie Hauptquelle des DNS-Datenverkehrs) erzeugte dieschlichte Abfrage des Domainnamens, beispielsweiseqmail.de (im Überlastfall, bei leerem Cache), eine Flutvon 850 Paketen, wovon knapp 800 verloren gingen undnur rund 50 Pakete davon fanden als Antwort (großteilsverspätet) den Weg zurück. Im Normalfall produziert einesolche Abfrage (bei leerem Cache) rund 200 Pakete (wo-bei 100 abgehende und 100 eingehende Pakete auftreten,sofern kein Paket verloren geht). Ähnliche Abfragen (inder gleichen Hierarchie) benötigen dann in Folge nur nochwenige Pakete (da die Zwischeninformationen bereits im


root-Server

A B M...

net

com

orgat

de

gv co

ac

tuwien

tunamec tunamed

www 128.130.35.76

.

at.

ac.at.

tuwien.ac.at.

www.tuwien.ac.at.

Legende

Zonen

Nameserver

...

...

Hierarchische Auflösungz. B. www.tuwien.ac.at.

Cache lagern). Bedenkt man, dass mit jeder eingehendenund akzeptieren E-Mail rund 20 bis 30 Namen aufgelöstwerden, verwundert der Umfang des DNS-Verkehrs nichtmehr weiter.

Nicht nur die Analyse und das Erfassen der Problema-tik waren für uns zeitraubend, auch war eine Reihe vonExperimenten notwendig, um für eine ausgewogene Kon-stellation bei den Parametern für Firewalls und Nameser-versoftware zu sorgen und trotzdem ein gewisses Maß anSicherheit zu gewährleisten bzw. das Missbrauchspoten-zial (von außerhalb des TUNET, aber auch von inner-halb) sinnvoll einzuschränken. Diese neue Qualität desAnspruchs erforderte zudem die Umstellung des gesam-ten tunamea/b Nameserver-Verbundes auf eine neue, leis-tungsfähigere Hardware.

ISC (Internet Systems Consortium) musste selbst fest-stellen, dass es Performance-Probleme in ihrer Softwaregab und hat dann im Laufe der Wochen nach und nach inder Bind-Software (Nameserver-Software) nachgebessert.Von unsere Seite waren immer wieder aufwändige Testsnotwendig, die aktuelle Software zu kompilieren, zu prü-fen (auf Solaris und Linux), wo die Betriebssystemlimitswaren, ob auf der jeweils aktuellen Hardware die Lastver-hältnisse akzeptabel blieben. Dabei war die Nameserver-installation auf 12 bis 14 Servern anzupassen/zu ersetzen.

Dass diese oder ähnliche Vorkommnisse nicht weltum-spannend zu Problemen führten, ist vermutlich der imGrunde saloppen und auch normalerweise risikoreichenuneingeschränkten Behandlung von UDP-Verkehr zu ver-danken (nicht aber an der TU Wien, aus anderer leidvollerErfahrung durch Attacken). Hinzu kommt, dass hier nursolche Nameserver betroffen waren, die normalerweiseisoliert agierend ein rekursives Namensservice für Clientsanbieten. Jene Nameserver, die entlang der hierarchischenAuflösung eines Domainnamens aktiv sind, sind hier pas-siv (nicht rekursiv) und von der ganzen Problematik prak-tisch nicht betroffen. Bildlich dargelegt: Das Geäst desDNS-Baumes war so gesehen immun und lediglich inmanchen Blättern raschelte es mehr oder weniger.

Abhängigkeiten

Im Kreis der Benutzer-Authentifizierung spielt DNSoftmals eine wesentliche Rolle. Nicht selten wird eine IP-Adresse auf den zugehörigen Namen abgebildet, um dannerneut zu überprüfen, ob tatsächlich der Name auch wie-der die ursprüngliche IP-Adresse liefert. Solche Maßnah-men setzt man oft und gerne bei Webmasken ein, die derAuthentifizierung dienen. Zum einen kann man so gleichvon vornherein einige unliebsame Quellen (eventuell Ro-bots, die Webangebote „abgrasen“) fernhalten. Anderer-seits hat man eine gewisse Sicherheit hinsichtlich desverbindenden Hostnamens, wenn dieser in das Authentifi-zierungsschema einfließt und deswegen eine gewisse Zu-

verlässigkeit aufweisen sollte. Als typischer Vertreter seihier das ZID Authentifizierungsservice/-portal genannt(siehe auch Seite 25). Hier offenbart sich aber auch gleichein neuer Problemkreis, der seinen Ursprung in diversenInkonsistenzerscheinungen im Nameservice fremder Pro-vider haben kann. Typische Fälle sind, dass die Nameser-ver eines Providers nicht synchron sind, wie z. B.

• eine IP Adresse löst einmal auf, ein anderes mal nicht• eine IP Adresse löst auf unterschiedliche Namen auf

Vom Fehlerbild schlägt dies leider bis zu den internenNameservern der TU Wien durch, die diesen wackeligenDatenstand weitergereicht bekommen. Nicht selten ent-steht dabei der Eindruck, es wären die TU Nameserver,die inkonsistente Daten aufweisen. Dies liegt aber schlichtdaran, dass die TU Nameserver (bei Daten, für die sienicht zuständig sind, üblicherweise tuwien.ac.at-fremdeDomainnamen) jeweils einen separaten Cache besitzen,dessen Einträge zu unterschiedlichen Zeitpunkten einge-tragen, von unterschiedlichen Nameservern geliefert wer-den und wieder zeitlich versetzt aus dem Cacheherausfallen. D. h. also, dass zwei Abfragen an tunameaoder tunameb auch zwei verschiedene Antworten liefernkönnen, ohne dafür verantwortlich zu sein.

Es bleibt im Grunde nur, sich dieser technischen Fein-heiten bewusst zu sein und gegebenenfalls den verant-wortlichen Nameservice-Provider auf die Inkonsistenzenin dessen Nameservice hinzuweisen (und auf eine Korrek-tur zu hoffen). Als technische Maßnahme hinsichtlichWebprogrammierung bleibt einem nur die IP-Adresse alszuverlässige Information.

Ausblick

Die Umstellung auf die neuen IP-Adressen der TU-in-ternen Nameserver tunamea/b ist ja schon seit längeremim Gange. Die Abschaltung des Nameservices auf den al-ten Nameserver-IP-Adressen zeichnet sich bereits ab unddessen Verwendung wird aktiv verfolgt, um die betroffe-nen Organisationseinheiten in der termingerechten Um-stellung zu begleiten.

Referenzen

RFC 882, RFC 883. http://www.ietf.org/

Where wizards stay up late: the origins of the internet,Katie Hafner, Matthew Lyon, 1996

Verbesserungen im Nameservice, Johann Haider, ZIDline17, Dezember 2007, http://www.zid.tuwien.ac.at/zidline/zl17/nameservice/

ZID Authentifizierungsservice: http://www.zid.tuwien.ac.at/sts/dateninfrastruktur/authentifizierungsservice/


TUphone –Status des ProjektsJohannes Demel

In der letzten ZIDline (www.zid.tuwien.ac.at/zidline/zl18/tuphone/) wurde über das Projekt einerneuen Telefonanlage für die TU Wien – TUphone – dessen Ziele und Randbedingungen bereitsberichtet. Heute soll hier der aktuelle Status dargestellt werden.

Projektmanagement

Anfang Sommer wurde das Projektmanagement defi-niert. Das Projekt gliedert sich in die klassischen Phasender Analyse, Konzeption, Beschaffung / Entwicklung undRollout. Die Projektorganisation ist aus der Abbildung er-sichtlich.

In der Analyse- und Planungsphase wird das Projekt vonder Firma DTN Datenkommunikation, Telekommunikationund Netzwerktechnologie Planungs GmBH im Bereich dertelekommunikationsspezifischen Fragen unterstützt.

Die Analysephase ist praktisch abgeschlossen und dieKonzeptionsphase bereits sehr weit gediehen.


TUphone Projektorganisation

Der prinzipielle Zeitplan des Projekts kann folgender Graphik entnommen werden:

Ersatz von DECT durch A1 Network GSMMobiltelefone

Im Sommer wurde von der Mobilkom bzw. der von ihrbeauftragten Firma mit der Errichtung der Inhouse-Ver-stärkung im GSM-Bereich (900 MHz) begonnen. Die Ar-beiten wurden Mitte Oktober abgeschlossen (der Bib-liotheksbereich folgt noch nach). Somit ist innerhalb derTU Wien ein guter Empfang für GSM/Sprache gegeben.Bitte beachten Sie, dass diese Inhouse-Versorgung nichtUMTS-Sprache und -Daten (dafür gibt es ja eine WLAN-Infrastruktur) umfasst. Man sollte daher auf einemUMTS-Handy das UMTS-Feature (zumindest für Spra-che) ausschalten.

Am 24. September fand eine sehr gut besuchte Veran-staltung zum Thema DECT-Ablöse durch GSM statt (dieFolien der Präsentation sind unter www.zid.tuwien.ac.at/kom/telefonie/tuphone/praesentationen/ zu finden). DasDECT-System wird Anfang 2009 außer Betrieb genom-men. Wir empfehlen, mit dem Antrag auf die neuen Gerä-te nicht erst bis Ende Dezember zu warten.

Seit Mitte Oktober erfolgt die Bestellung von SIM-Karten und Mobiltelefonen durch einen elektronischenWorkflow in der ZID-Datenbank (www.zid.tuwien.ac.at/kom/telefonie/a1_network/bestellinformation/). Die SIM-Karten und Mobiltelefone können dann nach Konfigura-tion bzw. Lieferung im Service Center des ZID abgeholtwerden.

Bezüglich der Verrechnungsaspekte bei Diensthandyssiehe den Artikel auf Seite 21.

Verrechnung

Es wurde ein vereinfachtes Verrechnungssystem konzi-piert, das auch für die existierende Telefonanlage mit1. 1. 2009 in Kraft treten soll. Details siehe Seite 21.

Infrastruktur-Maßnahmen

Ein sehr aufwändiger Bereich ist die Anpassung der In-frastruktur an die Anforderungen für ein VoIP-System.Diese muss in folgenden Bereichen erfolgen:

• Anpassung und Erweiterung der Verkabelungsinfra-struktur im Institutsbereich

• Anpassung der Versorgung der Etagenverteiler• Redundante Aufstellung der Gebäudeverteiler• Implementierung von Qualitiy-of-Service Mechanismen

im gesamten Netz• Errichtung der Stromversorgung mit entsprechender

Überbrückungszeit sowohl für die Gebäudeverteiler (inder Regel vorhanden) und der Etagenverteiler.

Diese Maßnahmen erfordern umfangreiche Analysender derzeitigen Struktur, die primär durch komplexe Aus-wertungen mit Hilfe der TUNET-Datenbank erfolgt. Teil-weise ist aber auch eine Untersuchung vor Ort notwendig.Darauf aufbauend muss dann der Bedarf für die nächstenJahre abgeschätzt werden. Zusätzlich müssen die Randbe-dingungen durch das „TU Univercity 2015“ Projekt be-rücksichtigt werden.

Bereits dieses Jahr wurde in der Gußhausstraße 25 derNachrichtentechniktrakt komplett neu verkabelt (dieserwar von der Generalsanierung des Gußhaus-Komplexesvor einigen Jahren nicht betroffen). Die 2007 begonneneNeuverkabelung der Bibliothek konnte dieses Jahr abge-schlossen werden. Derzeit finden die Planungen für eineneue Verkabelung der Trakte BI und BZ am Getreide-markt sowie des Freihauses statt. Hier existiert eine mehrals 10 Jahre alte Verkabelungsstruktur, die sowohl men-gen- als auch qualitätsmäßig den heutigen Anforderungensowohl der Daten- als auch der Telekommunikation nichtmehr entspricht.

Für den Standort Favoritenstraße findet derzeit die Pla-nung eines neuen Gebäudeverteilerstandorts statt (derzeitbefinden sich beide Gebäudeverteiler im gleichen Raum)sowie einer entsprechenden redundanten LWL-Versor-gung der Etagenverteiler und einer zentralen USV-Lösungfür die Etagenverteiler.


Am Karlsplatz wurde im Zuge der Sanierung des Mit-telrisalits ein neuer Gebäudeverteiler bautechnisch errich-tet. Dieser wird derzeit mit einer entsprechendenStromversorgung ausgestattet, mit der dann die Etagen-verteiler unterbrechungsfrei versorgt werden sollen. Da-nach kann mit der Besiedlung des Gebäudeverteilersbegonnen werden. Der zweite Standortverteiler Karlsplatzist in der Resselgasse vorgesehen, wo derzeit diePlanungen beginnen.

Für alle Standorte sind die Planungen für eine entspre-chende USV-Versorgung im Gange. Hier tritt das Problemauf, dass die VoIP-Telefone unterschiedlicher Hersteller(bei äquivalenter Ausstattung) sehr unterschiedlichenStrombedarf (Faktor 2) aufweisen. Dies hat große Auswir-kungen auf die Dimensionierung der USV-Systeme, aberauch auf die Anzahl der Switche, die notwendig sind (jenach Leistungsanforderung kann ein 48 Ports Ethernet-Switch 24 bis 48 Telefone mit Strom versorgen), unddamit auf die Kosten.

Anforderungen an die VoIP-Anlage

Im Zuge der Analyse des derzeitigen Bestands der Te-lefonanschlüsse wurde die Notwendigkeit von analogenAnschlüssen bei den Organisationseinheiten hinterfragt,da z. B. ISDN-Anschlüsse oder Modems mit einer VoIP-Anlage nicht oder nicht sinnvoll realisiert werden können.Auch für Faxanschlüsse ist eine Spezialbehandlung erfor-derlich, damit die Funktion über VoIP sichergestellt ist.Ausführlich untersucht wurde auch der gesamte Themen-komplex Unified Communications, den man heute in prak-tisch jeder Pressemeldung zum Thema Telefonie findet.

Aufbauend auf der Analyse wird einerseits ein Versor-gungskonzept inklusive Migrationsszenario erstellt undandererseits werden die konkreten Leistungsmerkmale

(gegliedert nach den unterschiedlichen Einsatzszenarieneines Telefons – Schlagworte Arbeitsplatzmodell und CallFlow) und Mengen festgelegt. Daraus ergibt sich dasPflichtenheft, das die Basis für das Beschaffungsverfahrendarstellt.

Nächste Aktivitäten

Die Schwerpunkte im 1. Halbjahr 2009 im Rahmen desTUphone-Projekts sind

• Ausschreibungsverfahren für die VoIP-Anlage

• Planung und Durchführung der Anpassung der Verkabe-lungsstruktur

• Schaffung der Strominfrastruktur

• Schaffung der Switch-Infrastruktur


Unified Communications (kurz UC) (englisch für „ver-einheitlichte Kommunikation“), oft auch Real-TimeCommunication (kurz RTC) (englisch für „Echtzeitkom-munikation“) genannt, beschreibt die Integration vonKommunikationsmedien in einer einheitlichen Anwen-dungsumgebung. Die Idee hinter Unified Communica-tions ist, durch eine Zusammenführung aller Kommu-nikationsdienste und die Integration mit Präsenzfunktio-nen, wie sie aus Instant Messengern bekannt sind, die Er-reichbarkeit von Kommunikationspartnern in verteilterArbeit zu verbessern und so geschäftliche Prozesse zu be-schleunigen. UC kann als Erweiterung von Unified Mes-saging verstanden werden; letzteres bezieht sich auf dieNachrichtenintegration in einem Portal und damit aufasynchrone Medien, während UC die Integration syn-chroner Medien zum Ziel hat. (Quelle: Wikipedia)

Neu als Campussoftware:

Avira AntiVir Professional

Avira AntiVir Professional schützt vor Viren, Würmern, Trojanern, Rootkits, Phishings, Ad- und Spyware,Bots sowie gefährlichen „Drive-by“-Downloads.

SolidWorks3D-CAD Software für den Maschinenbau. Zwei Konstruktionsanalysewerkzeuge werden mit dieser Softwareangeboten: COSMOSWorks – FEA: Finite-Elemente-Analyse, COSMOSFloWorks – CFD: numerische Strö-mungsmechanik (CFD) und thermische Analyse.

NI MultisimSoftware für Schaltungserfassung, interaktive SPICE-Simulation, Leiterplattenlayout und Designvalidierung.

www.zid.tuwien.ac.at/sts/arbeitsplatz_software/

Neues Verrechnungssystemfür die Telefongesprächs-entgelteFriedrich Blöser

Das derzeitige Verrechnungssystem der Telefongesprächsentgelte wurde im Anschluss an dieInstallation der Ericsson MD110-Telefonanlage im September 1998 eingeführt und ist seit 1999 inVerwendung. Zum Zeitpunkt der Planung dieses Systems waren die Verbindungsentgeltewesentlich höher als heute und so wurde damals die Lösung mit dem Chipkartensystemverwirklicht. Das unmittelbar davor installierte Chipkartensystem der Universität Wien mit je einerChipkarte für Dienst-, Privat- und Drittmittelgespräche wurde modifiziert, damit an der TU Wien nureine einzige Chipkarte für alle drei Gesprächsarten verwendet werden kann. Weiters wurdeversucht, möglichst genau die tatsächlichen Kosten eines Gesprächs an die Nutzer weiter zuverrechnen, auf Basis von Gebührenimpulsen oder auf Basis der Gesprächsdauer. Das Ergebniswar ein recht komplexes Verrechnungssystem.

In der Zwischenzeit hat sich jedoch vieles geändert.Die gesamten Gesprächskosten der TU Wien sinken seitJahren um rund 10% pro Jahr, einerseits auf Grund fallen-der Tarife, andererseits auch durch einen Rückgang derAnzahl der Gespräche. (Details zu den Untersuchungender Gesprächs- und Gesprächskostenentwicklung findetman im TUphone-Artikel der ZIDline 18.) Das derzeitigesehr komplexe und aufwändige Verrechnungssystem istden damit administrierten Gesprächskosten nicht mehr an-gemessen, das Aufwand-Nutzen-Verhältnis stimmt schonlänger nicht mehr. Hinzu kommt weiters, dass es praktischkeine Chipkartenleser mehr gibt, die als Ersatz für defektgewordene Leser installiert werden können.

Die derzeitige Chipkartenlösung – die es weltweit nuran der Universität Wien und an der TU Wien gibt – istweiters auf eine neue Nebenstellenanlage nicht eins zueins übertragbar. Für eine vergleichbare Lösung wäre ne-ben den laufenden Kosten wieder ein hoher Investitions-aufwand erforderlich.

Es wurde daher im Rahmen des Projekts TUphoneauch ein neues Verrechnungsmodell konzipiert, das demTUphone Steering Committee Anfang Dezember zur Be-schlussfassung vorgelegt wird. Die wichtigsten Neuerun-gen dieses Verrechnungsmodells sind:

Gebührenmodell mit einfacher Zoneneinteilung

Für Inlandsgespräche sind die folgendenvier Gesprächszonen vorgesehen:

Festnetz: alle ortsabhängigen und ortsunabhängigen (05,0720) Zielrufnummern sowie die Service-Line 0810

Diensthandy: alle Anrufe zur Corporate Number vonDiensthandys 0664-60 588 xxxx

Mobilprovider: alle österreichischen MobilrufnummernMehrwertnummern: Anrufe zu 0820 und zu erlaubten

0900-Nummern. Die 0900-Nummern werden gesperrtund nur in begründeten Ausnahmefällen freigeschaltet.Alle 0901- und 093x-Nummern sind generell gesperrt.

Zielrufnummern im Ausland werden invier Auslandszonen eingeteilt:

Ausland 1: im Wesentlichen alle Nachbarstaaten Öster-reichs, alle EU-Staaten sowie Russland, Israel, USA,Kanada, Japan, Australien und Hongkong

Ausland 2: Serbien, Kroatien, Ukraine, Türkei, China,Brasilien u.a.

Ausland 3: Indien, Ägypten, Georgien, Thailand,Tunesien, Mexiko u.a.

Ausland 4: Iran, Pakistan, Kuba, Myanmar, Palästina,Vietnam u.a.


Diensthandys als DECT-Ersatz

Die anfallenden Kosten für die Diensthandys (Grund-entgeltpauschale und zusätzliche Gesprächsentgelte) wer-den den Organisationseinheiten über die bei derMobilkom eingerichteten Rechnungsadressen direkt inRechnung gestellt. Für Gespräche von Nebenstellen derTelefonanlage der TU Wien zu einem Diensthandy soll(unabhängig von den tatsächlich anfallenden Kosten) einbesonders günstiger Tarif an die Organisationseinheitenverrechnet werden. Das setzt jedoch voraus, dass dasDiensthandy unter seiner dienstlichen Rufnummer (Cor-porate Number) 0664-60 588 xxxx angerufen wird. Alter-nativ dazu kann ein Diensthandy von einer Nebenstelleder TU Wien auch unter 90 xxxx angerufen werden (90 isteine Kurzwahl für 0664-60 588). Anrufe unter der physi-schen (tatsächlichen) Rufnummer des Handys werdennicht als Anruf zu einem Diensthandy registriert.

Auf Wunsch können mit einem Diensthandy auch Pri-vatgespräche geführt werden. Dazu ist ein schriftlicherAntrag mit einer Einzugsermächtigung erforderlich. AlleGespräche, bei denen das Präfix 98 vor der zu wählendenRufnummer gewählt wird, werden dann als Privatgesprä-che gewertet. Sie werden dem Nutzer von der Mobilkommit eigener Rechnung an die Privatadresse per Bankein-zug vom privaten Konto verrechnet.

Keine separate Abrechnung von Drittmittel-und Privatgesprächen

Die separate Verrechnung von Drittmittel- und Privat-gesprächen über die TK-Anlage der TU Wien wird einge-stellt. Die Amtsholungen 03 und 04 stehen nicht mehr zurVerfügung.

Wenn bestimmte Telefone bzw. Räume ausschließlichfür Drittmittelprojekte verwendet werden, so können sol-che Apparate und auch die Gespräche bestimmter Chip-karten einem eigenen Dienstgesprächskonto der Organi-sationseinheit zugeordnet werden.

Es ist hinkünftig – festgelegt in entsprechenden Be-triebsvereinbarungen zwischen dem Rektorat und den Be-triebsräten – nur eine geringfügige und in zeitlicher Hin-sicht maßvolle private Nutzung der Telefonanlage zulässig.Privatgespräche sind daher in Folge mittels privatemHandy, mittels Diensthandy mit Privatgesprächstrennung,über Softphone zu einem privaten SIP-Provider oder überCalling Cards zu führen. Solche Calling Cards gibt es etwavon der Telekom Austria, wobei hier z. B. je nach bevor-zugter Zieldestination die Telekom Austria Calling Card,die Calling Card Eco+, die Calling Card Osteuropa und dieCalling Card Afrika in Frage kommen. Diese Calling Cards

sind auf Postämtern aber auch in Trafiken erhältlich undbieten Tarife, die ins Ausland zum Teil günstiger sind alsdie BBG-Tarife für die TU Wien. Weitere Anbieter vonCalling Cards sind z. B. die Fa. Procard (www.procard.at)mit der Procard, der Pluscard sowie Spezialkarten für denBalkan, die Türkei und Polen sowie die Fa. Median Tele-kom (www.median-telecom.at) mit verschiedenen ServusPhonecards.

Erhöhung der Berechtigung mittels Chipkarteund / oder Berechtigungscode

Die Verrechnung der Entgelte für die Dienstgesprächeerfolgt vorerst weiter in der üblichen Form. Es ist vorgese-hen, für die bestehenden Ericsson-Apparate weiterhinChipkarten auszugeben, mit denen die Berechtigung einesChipkartenapparats angehoben werden kann (z. B. für ös-terreichweite oder weltweite Zielrufnummern). Allerdingswird es wegen Ersatzteilmangels eventuell nicht mehrmöglich sein, jeden gewünschten Apparat mit einemChipkartenleser auszustatten. Für solche Fälle wird es dieMöglichkeit geben, seinen persönlichen, mit der Chipkartevergebenen Berechtigungscode – nach Autorisierung mit-tels des eigenen TU-Passworts – einzusehen. Durch Ein-gabe einer bestimmten Tastenkombination und desBerechtigungscodes am Tischapparat kann dann der Ap-parat – wie beim Einstecken der Chipkarte – für die fest-gelegte Berechtigungsstufe freigeschaltet werden:

• Dritten Softkey drücken (dritte graue Taste von links un-terhalb des Displays)

• Berechtigungscode eintippen. Während der Eingabekann man mittels Softkey „<--“ einzelne Ziffern odermittels Softkey „ENTF“ alle bereits eingegebenen Zif-fern löschen.

• Softkey „EING“ zur Eingabe drücken.• Bei richtigem Code erscheint die Anzeige „Berecht.Code

gültig“. Es ertönt ein Wählaufforderungston (wie beimAbheben des Hörers) und man kann nun durch Eingabeder Amtsholung und der Rufnummer das gewünschteGespräch führen.

Gültigkeit des neuen Verrechnungsmodells

Auf Grund der Ersatzteilsituation bei den Chipkartenle-sern, um den Verrechnungsaufwand zu reduzieren und umeine gleiche Behandlung der Organisationseinheiten zugewährleisten, unabhängig davon, ob ihre Apparate nochan der bestehenden oder schon an der neuen Telefonanla-ge angeschaltet sind, soll das neue Verrechnungsmodellbereits am 1. 1. 2009 in Kraft treten.


u:booksan der TU WienWolfgang Meyer

Mobile Computer werden im flexiblen Arbeitsumfeld einer Universität immer wichtiger.Der ZID unterstützt Studierende und Mitarbeiter bei der Beschaffung von preiswerten Notebooksdurch die Teilnahme am Projekt u:book.

Vorgeschichte

Bereits im Jahr 1995 wurde zum ersten Mal vom dama-ligen EDV-Zentrum eine Beschaffungsaktion von Note-books für Mitarbeiter und Studierende durchgeführt. DieAusstattung damals war ein Prozessor 486DX2 mit 50MHz, 8MB Speicher und 510 MB Festplatte. Der Preisvon fast ÖS 30.000 war wahrscheinlich nur für wenigeStudierende erschwinglich. Durch die schnelle technischeWeiterentwicklung dieser Gerätetype sind heute Note-book-Computer für viele Studierende und Mitarbeiter zueinem allgegenwärtigen Werkzeug geworden, das aus dentäglichen Arbeitsabläufen nicht mehr wegzudenken ist.Dies war auch ein Punkt, der im Jahr 2007 in der Arbeits-gruppe Informationstechnologie des „TU Univercity2025“- Projekts zur Festlegung von Richtlinien für dieStandortentwicklung der TU Wien klar angesprochenwurde.

In der Folge wurden verschiedene Varianten diskutiertund Gespräche mit einzelnen Studiendekanen geführt.Parallel dazu wurde in Gesprächen mit potentiellen Liefe-ranten ausgelotet, welche Möglichkeiten einer günstigenund einfachen Beschaffung bestehen.

Das klare Ziel dieser Bemühungen sollte sein, den Stu-dierenden und Mitarbeitern durch Unterstützung bei derBeschaffung eines preiswerten Notebooks das mobile Ar-beiten am Campus der TU Wien ermöglichen.

Das Projekt Neptun an der ETH-Zürich

Im Projekt Neptun wird allen Studierenden an Schwei-zer Universitäten und angeschlossen Institutionen die Mög-lichkeit geboten, Notebooks zu besonders günstigenKonditionen zu beziehen. Die angebotenen Modelle wer-den einer rigorosen Evaluierung hinsichtlich verschiedenerKriterien unterzogen. Diese Kriterien umfassen:

• Rechenleistung,• Linux-Kompatibilität,• Batterielaufzeit,• Netzwerkanschlüsse,• Gewicht und mechanische Robustheit,• Auflösung und Qualität des Bildschirmes,• Schnittstellen,• Preis des Gerätes inkl. Optionen,• Lieferumfang,• Web-Support,• Helpdesk-Erfahrungen und Garantieabwicklung.

Ziel dieser Evaluierung ist nicht, möglichst billige Note-books anzubieten, sondern qualitativ hochwertige, aberpreiswerte, Geräte auszuwählen. Diese Geräte werden inzwei Verkaufsfenstern von jeweils 3 bis 4 Wochen Längeim Herbst und im Frühjahr angeboten.

Das Projekt u:book der Universität Wien

Basierend auf den Erfahrungen und in enger Koopera-tion mit dem Projekt Neptun der ETH Zürich wurde amZID der Universität Wien von Christian Marzluf das Pro-jekt u:book initiiert. In einem ersten Verkaufsfenster imFrühjahr 2008 wurden vorerst nur Studierenden und Mit-arbeitern der Universität Wien basierend auf den Evaluie-rungen des Projekts Neptun Geräte der Hersteller Apple,HP und Lenovo zum Kauf angeboten. Dieses erste Ver-kaufsfenster war mit insgesamt 1740 verkauften Gerätenein voller Erfolg. Dieser Erfolg war nicht zuletzt auch aufdie professionelle Organisation und Präsentation durch dieMitarbeiter am ZID der Universität Wien zurückzuführen.

In der Folge wurde allen österreichischen Universitätendie Teilnahme an der u:book Aktion angeboten.


u:book an der TU Wien

Mit diesem Angebot vom ZID der Universität Wienwurde aber aus der Sicht des ZID der TU Wien klar, dasses der beste Weg sein würde, die Beschaffung von

„u:books“, das sind Notebooks von hoher Qualität und miteinem umfangreichen Serviceangebot, die von Studieren-den, Mitarbeiterinnen und Mitarbeitern sowie Organisa-tionseinheiten zahlreicher österreichischer Universitätenzweimal jährlich günstig erworben werden können,

zu unterstützen.

Am Verkaufsfenster im Herbst 2008 nahmen insgesamt11 Universitäten teil. Die verhandelten Preise lagen zumTeil doch deutlich unter den billigsten, über Preissuchma-schinen ermittelbaren Preisen. Dabei ist auch zu berück-sichtigen, dass alle Modelle standardmäßig über drei JahreGarantie verfügen. Damit soll für Studierende, die am Be-ginn ihres Bakkalaureatstudiums ein u:book erwerben, fürdie Dauer des Grundstudiums der Bedarf an mobiler Com-puternutzung zuverlässig und in hoher Qualität abgedecktwerden. Da alle Modelle auch mit Wireless-LAN An-schlüssen ausgestattet sind und die TU Wien ein gut aus-gebautes Netzwerk für die Versorgung mit Wireless-LANan fast allen Standorten betreibt, sollen damit die Studie-renden in Hörsälen und Seminarräumen mit einem flexi-blen Zugriff auf Netzwerkressourcen bei ihren Arbeitenunterstützt werden; siehe auch Artikel von Johann Kain-rath über Wireless-LAN auf Seite 11.

Die erstmalige Durchführung der u:book Aktion wurdefür die neu teilnehmenden Universitäten von den Mitarbei-tern des ZID der Universität Wien in optimaler Weise un-terstützt. Alle Werbematerialien wie Plakate und Folderwurden angepasst an das Design der jeweiligen Universitä-ten bereitgestellt, sodass lokal nur mehr deren Verteilungund die Beschickung der Online-Medien zu organisierenwar. Wegen der räumlichen Nähe wurden die Interessentenfür die Besichtigung der Geräte an den professionell gestal-teten und von zahlreichen Mitarbeitern des ZID der Univer-sität Wien betreuten u:book Stand in der Aula desHauptgebäudes der Universität Wien verwiesen.

Die Bestellabwicklung erfolgte über Onlineshops derjeweiligen Distributoren bzw. bei Apple direkt. Hierzuwurde, um eine sichere Abwicklung zu gewährleisten,auch am ZID der TU Wien durch Georg Gollmann derAuthentifizierungsmechanismus SAML 2 implementiert(siehe auch Seite 25).

Zusätzlich zu den u:book Bildschirmputztüchern undden u:book DVDs mit Software für jeden Käufer, die vomZID der Universität Wien bereitgestellt wurden, erhielt je-der u:book Käufer an der TU Wien per E-Mail einen Gut-schein für IT Online-Kurse der Abteilung Standard-software.

Abwicklung und Probleme

An der TU Wien wurden insgesamt über 310 Note-books der Hersteller HP und Lenovo bestellt. Wenn mandie Anzahl der Bestellungen in Relation zur Gesamtzahlder Studierenden der jeweiligen Universität setzt, liegt dieTU Wien hinter der TU Graz an zweiter Stelle aller teil-nehmenden Universitäten. Über die Anzahl der Bestel-lungen von Organisationseinheiten und über die Anzahlder Bestellungen bei Apple liegen von den Lieferantennoch keine genauen Zahlen vor.

Der Modellwechsel während des Verkaufsfensters beiApple konnte dank engagierter Verhandlungen von Chris-tian Marzluf gut bewältigt werden. Die langen Lieferzei-ten bei einigen Modellen lösten aber vereinzelt Unmutaus. Die Lieferzeiten resultieren zum Teil aus der Tatsa-che, dass die in einem Verkaufsfenster angebotenen Mo-delle jeweils den aktuell neuesten Stand der Technologieeingebaut haben. Trotzdem sind die Hersteller gefordert,im nächsten Verkaufsfenster in diesem Punkt Verbesse-rungen anzubieten.

Ausblick

Das nächste Verkaufsfenster wurde vom ZID der Uni-versität Wien für das Frühjahr 2009 angekündigt. Für die-ses Verkaufsfenster werden noch die bisher ausgewähltenLieferanten beibehalten. Danach findet im Rahmen desNeptun Projekts an der ETH Zürich eine neue Evaluie-rung statt, deren Ergebnis laut derzeitigem Planungsstandwieder vom ZID der Universität Wien im Rahmen desProjekts u:book übernommen werden soll.

Damit soll sichergestellt werden, dass auch in Zukunftüber das u:book Projekt unter Federführung des ZID derUniversität Wien den Studierenden und Mitarbeitern derteilnehmenden Universitäten qualitativ hochwertige Note-books zum günstigen Preis angeboten werden können, ummobiles Arbeiten optimal zu unterstützen.

Links

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

http://www.ubook.at/

http://www.neptun.ethz.ch/

Aus 1 mach 11. Zweites u:book-Verkaufsfenster erfolg-reich abgeschlossen. Christian Marzluf. comment08/3, November 2008: http://comment.univie.ac.at/08-3/14/


Ein kleinesAuthentifizierungslexikonGeorg Gollmann

Eine technische Voraussetzung für die u:book-Aktion (siehe Seite 23) war der Betrieb einerAAI Federation auf Basis von SAML 2.0. Was ist mit diesem Kauderwelsch gemeint?Der folgende Artikel versucht eine Erklärung.

Grundbegriffe

AAIDas Akronym AAI steht für Authentifizierungs- und

Autorisierungs-Infrastruktur.

Federation

Der Begriff Federation bezeichnet einen organisations-übergreifenden Verbund. Im Fall der gerade abgelaufenenu:book-Aktion bestand er aus elf Universitäten und dreiHändlern. Für die Zukunft ist geplant, diesen ad hoc Ver-bund im Rahmen des ACOnet zu institutionalisieren(ACOnet-AAI). Aufgabe einer AAI Federation ist, ge-meinsame Richtlinien festzulegen und den gesichertenAustausch der Metadaten zu ermöglichen. Die Richtlinienumfassen z. B. technische Anforderungen, die Definitionder verwendeten Attribute, oder den Datenschutz.

Authentifizierung

Bei der Authentifizierung wird die Identität des Benut-zers von einem Identity Provider überprüft, üblicherweise

durch Benutzername und Passwort. Die Auswahl des zu-ständigen Identity Providers erfolgt über einen WAYFDienst.

Autorisierung

Autorisierung ist die Vergabe von Rechten. Sie findetdurch die Weitergabe von Attributen des authentifiziertenBenutzers vom Identity Provider an den Service Providerstatt. Unterschiedliche Service Provider können unter-schiedliche Sätze von Attributen erhalten.

Prinzipiell muss dem Service Provider die Identität desBenutzers gar nicht bekannt werden – es könnte z. B. ledig-lich bestätigt werden, dass der anonyme Benutzer Mitar-beiter der TU Wien ist.

Single Sign-On

Nach Anmeldung bei einem Identity Provider werdendie diesem bekannten Anwendungen freigeschaltet. Beisicherheitskritischen Anwendungen kann dies uner-wünscht sein, daher besteht die Möglichkeit, bei solchenAnwendungen immer eine explizite Anmeldung zu ver-langen.

Neben der Bequemlichkeit ist ein Vorteil von SingleSign-On, dass die Benutzer daran gewöhnt werden, ihrPasswort nur mehr an einer Stelle einzugeben. PhishingAttacken sollten dadurch weniger erfolgreich sein.

Single Sign-Off

Abmeldung vom Identity Provider und von allen geöff-neten Applikationen. Aber Achtung: durch die lose Kopp-lung der einzelnen Server über das Internet besteht keineGarantie, dass alle Abmeldungen tatsächlich bzw. sofortausgeführt werden. Der Benutzer sollte zumindest Rück-meldung bekommen, wo die Abmeldung funktioniert hatund wo nicht. Das öfter empfohlene Schließen desBrowsers kann helfen, lokale Daten der Sitzung zu lö-schen, ist aber auch dafür keine Garantie. Sitzungen aufden Servern sind von dieser Aktion ohnehin nicht berührt.


WAYF

Benutzer

Metadaten

IdP 1

IdP 2

IdP n

SP 1

SP 2

SP 3

SP m

AAI Federation

Für Fortgeschrittene

SAML 2.0

Die Abkürzung steht für Security Assertion MarkupLanguage. Es handelt sich um eine auf XML basierendeSpezifikation, um Authentifizierungsdaten, Rechte undAttribute von Benutzern zwischen Computern auszutau-schen. SAML ist eine umfangreiche Spezifikation, in derPraxis werden nur einzelne Teile („Profile“) benötigt.

Das Ziel von SAML ist, Authentifizierungslösungenverschiedener Anbieter miteinander kompatibel zumachen.

Identity Provider, IdP

Der Identity Provider prüft die Identität des Benutzersund gibt dem Service Provider die vorher vereinbarten Be-nutzerattribute weiter. Bei der u:book-Aktion hat jede teil-nehmende Universität einen Identity Provider betrieben.

Service Provider, SP

Der Service Provider bietet Dienste an, die auf be-stimmte Benutzergruppen eingeschränkt sind und daherAuthentifizierung und Autorisierung der Benutzer erfor-dern. Die Webshops und das u:book-Forum waren dieService Provider der u:book-Aktion.

Metadaten

Metadaten beschreiben und identifizieren die einzelnenProvider. Identity Provider und Service Provider müssensich für einen gesicherten Datenaustausch gegenseitig be-kannt gemacht werden. Zu diesem Zweck werden die Me-tadaten von der Federation gesammelt und den Teilneh-mern signiert zur Verfügung gestellt.

WAYF

Where Are You From. Ein Dienst, über den der Benut-zer seine Heimatorganisation und damit seinen IdentityProvider auswählt; oft ein einfaches Auswahlmenü.

Attribute

Attribute sind Aussagen über den authentifizierten Be-nutzer. Diese Merkmale können u. a. Name, E-Mail-Adresse oder Organisationszugehörigkeit sein. Zur Attri-butdefinition im akademischen Bereich gibt es verschiede-ne Standards, wie etwa eduPerson oder SCHAC.

User Consent

Aus Datenschutzgründen werden dem Benutzer die At-tribute angezeigt, bevor sie an den Service Provider über-mittelt werden. Wichtig im Single Sign-On Umfeld, dasonst diese Übermittlung erfolgen könnte, ohne dass demBenutzer bewusst wird, welche seiner Daten an welchenService Provider weitergegeben werden. Der Benutzergibt entweder die Übermittlung der Attribute an den Ser-vice Provider frei, oder er bricht den Anmeldevorgang ab.Damit der Benutzer bei wiederholten Besuchen eines Ser-vice Providers nicht immer wieder gefragt wird, kann erdie Zustimmung zur Weitergabe eines bestimmten Satzesvon Attributen beim Identity Provider speichern.

Implementierungen

Shibboleth

Eine verbreitete SAML Implementierung ist Shibbo-leth. Shibboleth deckt alle Bereiche des umfangreichenSAML Standards ab, ist dadurch aber aufwendig in derInstallation und Konfiguration. Shibboleth ist in Javaimplementiert.

simpleSAMLphp

Wie der Name andeutet, handelt es sich um eine PHPImplementierung. Die Installation und Konfiguration istrelativ einfach, ebenso die Anbindung an bestehende(PHP) Anwendungen. Es werden dafür nicht alle – seltenbenötigten – Aspekte des SAML Standards abgedeckt.

simpleSAMLphp kommt an der TU Wien für den Iden-tity Provider zum Einsatz.

Lokale Authentifizierung

Der ZID betreibt seit Jahren ein Authentifizierungs-service für Webapplikationen (siehe ZIDline Nr. 7).Mittlerweile sind 75 Anwendungen registriert, die imlaufenden Jahr bereits über 4 Millionen Authentifizierun-gen durchgeführt haben. Hauptnutzer ist mit großem Ab-stand TUWIS++, gefolgt von TUWEL.

In den letzten Monaten wurde dieser Dienst um einPortal erweitert, das neben Single Sign-On auch SingleSign-Off erlaubt.

Der Vorteil der lokalen Authentifizierung gegenüberSAML ist die sehr einfache Einbindung in eigene An-wendungen, potentieller Nachteil ist die Beschränkungauf lokale Benutzer und auf die reine Authentifizierung,d. h. Autorisierungsinformationen müssen aus anderenQuellen, etwa aus TUWIS++, geholt werden.

Die Zukunft

Derzeit ist nicht abzuschätzen, wie schnell die ACOnet-AAI abseits der u:book-Aktion in Schwung kommenwird. Bislang haben sich jedenfalls noch keine größerenuniversitätsübergreifenden Projekte aufgedrängt. Für loka-le Bedürfnisse stellt das gut eingeführte Authentifizie-rungsservice eine einfach zu benutzende Alternative dar.Deshalb werden vom ZID auf absehbare Zeit beide Schie-nen parallel angeboten werden.

ReferenzenACOnet-AAI: http://www.aco.net/aai.htmlACOnet-AAI Test SP: https://test-sp.aco.net/SAML: http://saml.xml.org/about-samlShibboleth: http://shibboleth.internet2.edu/simpleSAMLphp: http://rnd.feide.no/simplesamlphpeduPerson: http://www.educause.edu/eduperson/SCHAC:

http://www.terena.org/activities/tf-emc2/schacreleases.htmlZID Authentifizierungsservice:

http://www.zid.tuwien.ac.at/sts/dateninfrastruktur/authentifizierungsservice/

ZID Authentifizierungsportal:https://iu.zid.tuwien.ac.at/AuthServ.portal


MoreSpace –Mehr Raum für die Lehre durchdynamische ereignisorientierteSimulation der RaumbelegungFelix Breitenecker, Shabnam Tauböck, Institut für Analysis und Scientific ComputingGerald Hodecek, Karim Shebl, Gebäude und TechnikDietmar Wiegand, Sanja Mesic, Stefan Emrich, Inst. f. Städtebau, Landschaftsarchitektur u. EntwerfenNikolas Popper, „die Drahtwarenhandlung“ Simulation Services

„More Space“ ist ein Simulationsprojekt der etwas anderen Art. Die Abteilung Gebäude und Technikversucht dabei gemeinsam mit zwei ganz unterschiedlichen TU Instituten – Mathematikern undArchitekten – neue Lösungen im Bereich Simulation von Flächennutzung zu entwickeln. Grund: DasProjekt „TU Univercity 2015“ verlangt neben viel Umbauarbeiten und Neustrukturierungen auch neueKonzepte, wie mit Flächen effizient umgegangen werden kann. So sollen für alle Beteiligten mehrFlächen zur Verfügung stehen, um neue Nutzungen zu ermöglichen, ohne die Kosten zu erhöhen.Das Simulationsmodell soll dabei helfen. Möglich wird das durch ein innovatives Modell, das trotzder Komplexität gut mit den Daten identifizierbar ist, und durch neue Flächenmanagementansätze,die etwa flexible Raumstrukturen ermöglichen sollen.

Einleitung

Im Rahmen der Projektes „TU Univercity 2015“ wer-den neue, verbesserte Raumstrukturen auf dem Geländeder TU Wien geschaffen. Gebäude und Technik – GUT,Fachbereich Projektentwicklung und Projektmanagement– RED – am Institut für Städtebau, Landschaftsarchitekturund Entwerfen und Forschungsgruppe MathematischeModellbildung und Simulation – MMS/ARGESIM – amInstitut für Analysis und Scientific Computing arbeitenseit Beginn 2008 an einem Projekt zur Entwicklung einesSimulationstool auf DEVS Basis zur Auswertung der ak-tuellen Situation und Verbesserung der Auslastung undNutzung der Hörsäle und Seminarräume der TU Wien.

Eine dynamische Simulation der Raumbelegung an derTU Wien vereint die Möglichkeit der statischen Datenana-lyse der Raumbelegung, die auf Basis der zugrunde geleg-ten Eingangsdaten berechnet wird, mit der Auswertung derErgebnisse des dynamischen Simulationslaufes. Dieserkann sowohl zusätzlichen Aufschluss über die Raumaus-nutzung liefern, als auch das veränderliche Verhalten derStudenten mit einbeziehen um Schwankungen im Raumbe-darf (etwa im Semesterverlauf) zu berücksichtigen. Durch

das Verwenden verschiedener Strategien bei der Raumbu-chung können sehr schnell Vergleiche angestellt werden,um Vor- und Nachteile abzuwägen.

Szenarios und Experimente können auch auf Verände-rungen in den Basisstrukturen ausgedehnt werden, anRaumstruktur, an Lehrveranstaltungen, an Studentenzah-len kann „gedreht“ werden, um Auswirkungen zu beob-achten. Im Weiteren können auch die topologischenGegebenheiten miteinbezogen werden.

Konkrete Projektziele sind:

• Analyse und Verbesserung der Raumauslastung• Analyse und Verbesserung der Raumnutzung• Möglichkeit zum Vergleich unterschiedlicher

Buchungsstrategien• Aufzeigen von Engpässen und Potentialen• Einbeziehung von Wegezeiten (um die Wegezeiten im

gesamten TU Bereich zu berücksichtigen)• Unterstützung beim geplanten Umbau (flexible Planung

der Raumreduktion etc.)

Ziel ist es auch, die Ressourcenausschöpfung so weit zuoptimieren, dass die vorhandenen Räume und die Infrastruk-


tur vermehrt durch Studierende oder Dritte für zusätzlicheVeranstaltungen genutzt werden können. Die TU Wienkönnte so auch als studentischer Arbeitsort oder als Veran-staltungsort im Zentrum von Wien attraktiver werden.

Modellbildung

DEVS – Discrete Event Simulation – wird schon seitlangem in verschiedenen Bereichen zur Analyse und Ver-besserung der Ressourcenplanung und Ressourcenausnut-zung verwendet, wie z. B. in Produktion und Logistik, inder Kommunikationstechnik, im Chain Supply und auchim Krankenhausmanagement. Modellbildungsgrundlageist das Entity-Ressourcen bzw. Entity-Flow Konzept: En-tities (z. B. zu bearbeitende Werkstücke, zu verarbeitendeDatenpakete, zu liefernde Waren bzw. zu behandelnde Pa-tienten) suchen ihren Weg durch den Prozess zu ihrenRessourcen – z. B. zu Bearbeitungsrobotern, zu Servern,zu Distributoren bzw. zu Ambulanzen, wobei Events – Er-eignisse – dabei diesen Weg steuern.

Relativ neu hingegen ist DEVS im Bereich des Mana-gements von Raumressourcen und generell im Bereich desFacility Managements. Während Ressourcen eindeutig mitden zur Verfügung stehenden Räumen identifiziert werdenkönnen, sind für Entities verschiedene Ansätze möglich.

Im Prinzip ist es der Bedarf, der Räumefür bestimmte Aufgaben reserviert. DerBedarf wiederum kann mit einer bestimm-ten Arbeit, an der z. B. Personengruppenbeteiligt sind, identifiziert werden, oderumgekehrt mit Personengruppen, die imRaum eine bestimmte Aufgabe erledigenwollen.

Für die Modellbildung und Simulationder Hörsaalbelegung bzw. Raumbelegungan der TU Wien wurde der letztere Ansatzgewählt, wobei die Personengruppe biszum einzelnen Studenten zerlegt wird –ein sehr aufwändiger aber komplexitätsbe-dingt notwendiger Ansatz. Vereinfachtgesagt, suchen sich Studenten (= Entities)mit einem gemeinsamen Auftrag – ihremSemesterstudienplan (= Steuerungslogik)– den Weg durch Hörsäle (= Ressourcen),wo sie andere Ressourcen bzw. andereEntities (= Vortragende) treffen. Je nacherforderlichem Komplexitätsgrad sind die-se Wege einfach „zeitverbrauchend“ oder

selbst dynamische Ressourcen wie z. B. (zu) engeStiegenhäuser oder zu passierende Ampeln zwischenFreihaus und Getreidemarkt.

Und – wieder je nach erforderlichem Komplexitätsgrad– sind die Ressourcen – die Räume – statisch, mit maxi-maler Belegungszahl, oder dynamisch teilbar und kombi-nierbar.

Eine genauere Darstellung dieser Zusammenhängezeigt das Entity-Relationship Diagramm mit den Basisele-menten Student, LVA und Raum (Abbildung 1).

Implementierung – Simulator

Für DEVS steht heute eine Vielzahl von Simulatorenzu Verfügung, die mehr oder weniger auf ein bestimmtesAnwendungsgebiet spezialisiert sind. Das Projekt verwen-det Enterprise Dynamics (ED), das trotz des zielgerichte-ten Namens eher ein General Purpose DEVS Simulatorist, wenn – wie hier – mit der Basisbibliothek (LogisticSuite) gearbeitet wird. Teure Spezialbibliotheken (Manu-facturing Suite, Airport Suite, Contact Center Suite etc.)erweitern ED zu speziellen Anwendungssimulatoren. ED– bei MMS/ARGESIM seit Jahren erfolgreich im Einsatz– umfasst eine Entwicklungsumgebung und eine eigeneProgrammiersprache.


RAUM Kapazität

Kategorie

LVA

AnzahlPrüfungen

BeginnDatum

EndeDatum

BeginnUhrzeit

EndeUhrzeit

LVA-Typ

LVA -Modus

Studienzweig

belegt

StudentStudienzweig

Semester

besucht

Semester

(1,n)

1 Name

LVANummer

Name

Abbildung 1: Entity-Relationship Modell für Basisobjekte Student, LVA, Raum

Abbildung 2: ED Model Layout (Räume Hauptgebäude TU), automatisch erzeugt aus TUWIS++-Daten

ED bietet auch Basisfunktionen für die Auswertung vonSimulationsergebnissen, allerdings hat sich hier die Auswer-tung in Excel eher bewährt, da sowohl die Anwendungs-freundlichkeit höher ist als auch der Umfang der Mög-lichkeiten. ED verfügt über diverse Datenbankschnittstel-len und ermöglicht so einfachen Datenaustausch.

Klassische Modellbildung besteht in ED im Erstellendes Prozesslayouts mit Drag-and-Drop aus Bibliotheks-elementen, was im gegenständlichen Fall – alle Hörsäleund Seminarräume der TU Wien sind Einzelressourcen –unmöglich ist.

Das Projekt verwendet zur ED-Modellbildung ein beiMMS/ARGESIM entwickeltes Modul zur automatischenModellerzeugung aus Datenbanken, hier aus TUWIS++-Hörsaaldaten, sowie eine speziell für dieses Projekt ent-wickelte Library an Modellbausteinen. Abbildung 2 zeigtein derart automatisch erzeugtes Modell-Layout für einenBereich von Räumen im TU Hauptgebäude, wobei Stu-denten gerade Seminarräume bzw. den Schütte-LihotzkyHörsaal belegen (Momentaufnahme aus der Simulation,Belegung Mai 2007).

ED bietet auch eine simulationsparallele Pseudo-3D–Animation an, die mit einigem Aufwand auch topolo-gisch korrekt aus CAD-Daten abgebildet werden kann.Abbildung 3 stellt einen Snapshot, ähnlich wie in Abbil-dung 2, in einer einfachen Animation, automatisch ausdem Modell-Layout generiert, dar. Echte 3D-Animationund VR kann über Datenbanken angekoppelt werden.

Die Implementierung des Simulationstools wurde sodurchgeführt, dass eine höchstmögliche Flexibilität desSimulationsmodells erhalten bleibt. Dazu wurde eineTrennung zwischen den zugrunde liegenden Daten unddem Simulationsmodell strikt eingehalten.

DynoSpace – Erste Ergebnisse

Das Basisprojekt DynoSpace – Dynamische Analyseund Simulation der Raumbelegung im Hauptgebäude derTU Wien – wurde von Jänner 2008 bis August 2008durchgeführt: Hörsäle und Seminarräume im Hauptgebäu-de, Stundenplan / Studienplan Architektur und Bauingeni-eurwesen. Ergebnisse der Basissimulation stimmenqualitativ mit TUWIS++-Buchungsdaten überein.Ergebnisdaten sind u. a..:

• Raumauslastung der Räume als Ergebnisdes dynamischen Studentenverhaltens

• Effizienz der Raumausnutzung – Studierende versusRaumkapazität

• Art und Zahl von Fehlbuchungen = nicht erfolgreicheSimulationsbuchungen

Mit dem Simulationstool konnten nun verschiedeneSzenarien untersucht werden, die mögliche Strukturän-derungen vergleichen:

• Änderungen in Raumstruktur• Änderungen im Flächenmanagement• Änderungen im Buchungsmanagement• Erhöhung der Studentenzahl

Bei diesen Strukturänderungen fließen Arbeiten vonRED zum flexiblen Flächenmanagement ein, die sich be-reits bei der flexiblen Raumplanung für Schulprojektebewährt haben.

Verschiedene Szenariorechnungen beleuchten u. a. dieAuswirkungen eines neuen (großen) Hörsaales im Haupt-gebäude, die Hinzunahme kleinerer Seminarräume fürLVAs mit wenigen Studenten, „on-the-fly“-Änderung derRaumstruktur bei Engpässen (z. B. Raumteilung) undNachvollziehen der TUWIS++-Überbuchung.

DynoSpace hat gezeigt, dass mit DEVS Simulation dieRaumbelegung an der TU Wien effizient analysiert wer-den kann, und dass Änderungen im Flächenmanagementund in Buchungsstrategien in der Simulation analysiertund bewertet werden können.

TU-weite Simulation – MoreSpace

Der Erfolg mit dem Anlaufprojekt DynoSpace – dyna-mische Analyse und Planung der Raumsituation im Haupt-gebäude – führte zum Folgeprojekt MoreSpace, Oktober2008 bis Oktober 2009. Der Name MoreSpace soll ver-deutlichen, dass durch dynamische Raumplanung mehrRaum für alle LVA-Arten bereitgestellt werden kann, wassich ansatzweise bereits im Anlaufprojekt DynoSpace ge-zeigt hat.

MoreSpace enthält im Wesentlichen folgende Erweite-rungen und neuen Elemente:

• Modellerweiterung auf (fast) alle Gebäude der TU Wien• Modellerweiterung für (fast) alle Studienrichtungen• Modellierung topologischer Komponenten (Wege

zwischen Stockwerken, Gebäuden etc.)• Modellierung zur möglichen Szenarienrechnung

verschiedener Buchungsstrategien• Modellierung von Ersatzraumstrategien (Umbau-

unterstützung)• Flexibilisierung der Raumsituation• Simulation von Grundbuchungen für Raumzuordnung

zu bestimmten Studienrichtungen• Unterschiedliche Szenarien für die Studentenzahl-

entwicklung• Schnittstellen zu den neuen Buchungssystemen

Erste Ergebnisse von MoreSpace können voraussicht-lich zu Beginn 2009 in die Planungen für den Umbau amKarlsplatz und in den Prozess der Verbesserung der In-formatikdienste (TISS) eingebracht werden.


Abbildung 3: Pseudo-3D-Animation in ED,automatisch erzeugt aus TUWIS++-Daten

Systematisches Testeneines Constraint-SystemsUlrich Neumerkel, Institut für Computersprachen

Die Studenten-PCs in den Internet-Räumen des ZID sind mittels CONDOR zu einem Campus-Grid(WINZIG) zusammengefasst, dessen beachtliche Rechenleistung zu Nacht- und Wochenendzeitenfür Scientific Grid-Computing genutzt werden kann. Dieser Grid wird vom Institut fürComputersprachen zum Testen der CLP(FD)-Implementierung von SWI-Prolog eingesetzt.

Im letzten Jahr wurde das Constraint-System CLP(FD)von SWI-Prolog [0] – einem frei verfügbaren System –von Markus Triska innerhalb seiner Masterarbeit [1] ent-wickelt und seitdem kontinuierlich verbessert. Dabei wur-de versucht, die Beschränkungen bestehender Systemeaufzuheben [2], um Constraints auch in der Lehre [3] undin neuen Anwendungsbereichen wie Verifikation, Pro-grammanalyse [4] und Diagnose einsetzen zu können. Ge-rade in diesen Bereichen kommt der Korrektheit desSystems eine zentrale Bedeutung zu. Traditionell warenConstraint-Systeme eher auf größtmögliche Effizienz füreinen sehr eng ausgelegten Anwendungsbereich optimiert.Neue Verwendungen führen in bestehenden Systemen oftzu falschen Ergebnissen oder Nichttermination.

Um die Entwicklung von CLP(FD) für SWI-Prologbestmöglich zu unterstützen, habe ich systematische Testsentwickelt, die laufend an das System angepasst werden.Anfänglich wurden die Tests auf den Institutsrechnerndurchgeführt, bis schließlich der von WINZIG [5] verwal-tete Condor-Grid des ZID zum Einsatz kam. Seit mehr alseinem halben Jahr und über mehr als 90 CPU-Jahre hin-weg wird nun die CLP(FD)-Implementierung von SWI-Prolog getestet. Dabei konnten viele Fehler gefunden wer-den – einige sogar in zentralen Teilen des Systems undselbst im darunter liegenden SWI-Prolog.

Die Adaptierung und der effektive Betrieb der Testläu-fe erforderten beträchtliche Umstellungen, die ich im Fol-genden nach einer kurzen Beschreibung der Tests erörternmöchte.

Testkriterien

Beim systematischen Testen [6] wird nach der Verlet-zung von algebraischen Eigenschaften – wie Monotonieoder Kommutativität – gesucht. Es wird nicht gegen einevollständige Spezifikation getestet, die ja ihrerseits wiederfehlerbehaftet sein könnte, sondern man beschränkt sichauf „unmittelbar ersichtliche“ Eigenschaften. So sollten

etwa die folgenden Anfragen aufgrund der Kommutativi-tät der Konjunktion zum gleichen Ergebnis führen.

?- X in 0..2, 0/X #= 0,X = 1.

?- X = 1,X in 0..2, 0/X #= 0.

In diesem Fall scheiterte aber die erste Anfrage, wäh-rend die zweite eine Lösung fand. Allein aufgrund diesesUnterschieds kann man bereits sagen, dass eine der beidenAnfragen fehlerhaft ist – möglicherweise sogar beide. Esist also nicht erforderlich, die Eigenheiten der involviertenKonstrukte – etwa der Division – zu kennen. Lediglich dieVertauschung der Ziele ist hier von Relevanz. Die weitereDiagnose, welche Anfrage nun wirklich richtig ist – indiesem Falle letztere – wird einer manuellen Bearbeitungüberlassen, schließlich treten derartige Fehler sehr seltenauf und ziehen ohnehin entsprechende Programmiertätig-keiten nach sich.

Ein systematisches Testen muss nun mögliche Kandi-daten in geeigneter Weise aufzählen. Der Suchraum isthier dermaßen groß, dass weitere Einschränkungen von-nöten sind. So wird nur der Wertebereich -3...3 betrachtet.Auch werden gezielt Fälle mit gemeinsamen Variablenbetrachtet, da diese erfahrungsgemäß eine nie versiegendeFehlerquelle sind. Es hat sich als günstig erwiesen, nur ei-nen Teil der Formel zu generieren, und dann durch Erwei-terungen die eigentlichen Kandidaten zu erzeugen. DerFormelteil wird fortlaufend durchnummeriert. So lassensich Testläufe einfach durch Angabe der Nummer repro-duzieren.

Bei den ersten Testläufen am Institut wurde die Mengeder Formeln auf eine fixe Zahl von vorhandenen Threadsaufgeteilt. Mittels der Formelnummer konnte jeder Pro-zess für sich ohne weiteren Kommunikationsaufwand sei-nen Teil abarbeiten. Leider führte diese Aufteilung zueiner besonders schlechten Auslastung. Manche Prozessewaren rasch fertig, während anderen Prozessen die gesam-te Rechenarbeit zufiel. Dies rührt daher, dass die Zeit zur


Überprüfung der Kandidaten einer Formel sehr stark vari-iert – zwischen Sekundenbruchteilen und einer Woche.Auch durch die recht unzuverlässige Stromversorgung amInstitut wurde die Rechenleistung geschmälert.

Condor

Der Condor-Grid unter WINZIG macht die Nutzungnoch etwas komplizierter.

• Die meisten Rechner sind nur in den Nachtstunden ver-fügbar.

• Durch andere Nutzer mit höherer Priorität werden Pro-zesse selbst in dieser Zeit unterbrochen.

• Rechner fallen im Betrieb unangemeldet aus.• Rechner liefern falsche Resultate – wahrscheinlich be-

dingt durch Speicherfehler.• Transiente Fehler – wie das Fehlen des Filesystems.• Hoher Verwaltungsaufwand pro Prozess. Jeder Prozess

sollte i.d.R. zumindest 5 Minuten benötigen.• Bei geringerer Rechenzeit übersteigt bald der Verwal-

tungsaufwand den Nutzen.• Es sollten insgesamt nicht mehr als 5000 Prozesse gleich-

zeitig von Condor verwaltet werden. Mehr Prozessedürften die Verteilungseinheit überfordern.

• Der Speicherbedarf eines Prozesses ist sehr stark limi-tiert.

• Die Mechanismen für Checkpoints sind zu aufwändigund unzuverlässig.

Diesen Nachteilen stehen die folgenden Vorteile ge-genüber

• Derzeit bis zu 300 parallele Threads.

• Zuverlässige Prozessverwaltung und Reproduzierbar-keit über Jahre hinweg.

Die folgenden Anpassungen waren erforderlich, um dieTestläufe effizient durchführen zu können.

Auf den Condor-Rechnern stehen Prozessen ausschließ-lich der Hauptspeicher zur Verfügung. Es gibt keinenSwap-Space. Prozesse, die zu viel Speicher benötigen,brechen mit einer entsprechenden Fehlermeldung ab. Esgibt hier praktisch keine Möglichkeit, diese Limitation zuumgehen. Die vorhandenen Programme müssen also not-falls inhaltlich umgeschrieben werden, um unter dieseneingeschränkten Bedingungen zu funktionieren.

Erhöhung der Granularität

Es werden derzeit 100 Formeln in einen Prozess zu-sammengefasst. Dadurch reduziert sich der Verwaltungs-aufwand für sehr kurze Prozesse auf ein Hundertstel.

Checkpoints

Da der bestehende Checkpoint-Mechanismus sich alsweder zuverlässig noch effizient herausstellte, wurde eineigener Mechanismus entwickelt. Nach jeder Formel undan bis zu 100000 Stellen innerhalb einer Formel wird einCheckpoint in das NFS-Filesystem geschrieben. Dabeiwerden ausschließlich die Formelnummer sowie zweiähnlich geartete Nummern für Zwischenzustände angege-

ben. Die Gesamtgröße dieser Datei beträgt nur wenigeBytes. Um sicherzustellen, dass nicht zu oft geschriebenwird, werden Zwischenzustände höchstens alle 2 Minutengeschrieben. Die anderen Zwischenzustände werden nichtgesichert und sind ggf. als roll-back zu verbuchen.

Prozessverwaltung

Die Prozessverwaltung ist in Condor sehr mächtig. Al-lerdings ist zu beachten, dass Prozesse, die einmal aus derVerwaltung ausscheiden, nicht mehr zurückgeholt werdenkönnen. Aus diesem Grund empfiehlt es sich, nur Prozes-se mit erfolgreichem ExitCode aus der Verwaltung zu ent-lassen. Alle anderen Prozesse, also jene, die mit einemFehlercode abbrechen oder zu einem Bus-Error oder ähn-lichem geführt haben, sollen im Wartezustand verharren.Nach eingehender Untersuchung oder Korrektur könnendiese wieder gestartet oder gelöscht werden. Mit folgenderZeile im Submission-File wird dies bewerkstelligt.

on_exit_hold = ExitBySignal || ( ExitCode != 0 )

Im Condor-Manual wird empfohlen, bei fehlerhaftemAbbruch eines Prozesses diesen sogleich erneut zu starten.Dies scheint nicht wirklich sinnvoll, weil dadurch fehler-hafte Prozesse das gesamte System lahmlegen könnten.

Schluss

Im Nachhinein erscheinen die für Condor erforderli-chen Adaptierungen gar nicht so exotisch, wie sie anfangsaussahen. Auch in anderen Kontexten ist es sinnvoll, ei-nen Checkpoint-Mechanismus zu verwenden und sichüber den Verwaltungsaufwand von Prozessen Gedankenzu machen. Mittlerweile verwenden alle Testläufe den an-fangs für Condor entwickelten Mechanismus, selbst wennsie nicht unter Condor laufen.

Ich möchte mich bei Herrn Philipp Kolmann für dieviele Rechenzeit und perfekte Wartung des WINZIG-Sys-tems bedanken.

Referenzen

[0] http://www.swi-prolog.org/

[1] M. Triska, Solution Methods for the Social GolferProblem. Masterarbeit, TU Wien, 2008.

[2] M. Triska, U. Neumerkel, J. Wielemaker. A Gene-ralized Finite Domain Constraint Solver for SWI-Prolog. WLP 2008.

[3] U. Neumerkel, M. Triska, J. Wielemaker. Declarati-ve Language Extensions for Prolog Courses. FDPE2008.

[4] A. Prantl, J. Knoop, M. Schordan, M. Triska. Con-straint solving for high-level WCET analysis.WLPE 2008.

[5] Ph. Kolmann. University Campus Grid Computing,Diplomarbeit, TU Wien, 2005.

[6] M. Triska, U. Neumerkel, J. Wielemaker. BetterTermination for Prolog with Constraints. WLPE2008.


TUWELNews WS2008 &Moodle Konferenz 2009Katarzyna Potocka, Andreas Hruska, Franz ReichlE-Learning Zentrum der Technischen Universität Wien

Durch die ständig wachsende Zahl der Benutzerinnen und Benutzer von TUWEL und die stetigsteigende Anzahl von unterstützten Lehrveranstaltungen mit speziellen Anforderungen wird sichdas E-Learning Zentrum in Zukunft auf die Verbesserung und Erweiterung der TUWEL-Funktionalitäten und die Mitwirkung an der Weiterentwicklung von Moodle konzentrieren.

Standortwechsel des Servers

Das Hosting der TUWEL-Server wurde deshalb vomE-Learning Zentrum an den ZID übergeben. Die Serversind nun direkt in den zentralen ZID-Serverräumlichkeitenuntergebracht und werden zur weiteren Verbesserung vonSicherheit, Verfügbarkeit und Performance durch das er-fahrene ZID-Service-Personal betreut.

Das E-Learning Zentrum kann sich dadurch ganz aufdie zentrale Aufgabe des TUWEL-Benutzersupports unddie Weiterentwicklung der TUWEL-Services konzentrie-ren, denn für 2009 ist ein großer Sprung mit vielen nützli-chen Neuerungen im Moodle-Core auf die nächsteMoodle Mayor Release 2.0 geplant.

Schneller & einfacher – Update

Um Lehrenden das Erstellen von TUWEL-Kur-sen bzw. den Einsatz von anderen E-Learning-Ele-menten zu erleichtern, wurde die Anbindung anTUWIS++ erweitert. Das Erstellen Ihres TUWELKurses für das neue Semester ist mit nur zweiKlicks rasch und einfach erledigt. Auch die Nut-zung von anderen E-Learning-Elementen kann nunin TUWIS++ eingetragen und für Studierendesichtbar gemacht werden.

Mit dem Wintersemester 2008 wurde das Up-date von TUWEL auf die Moodle Release 1.9.2+realisiert. Mit diesem Umstieg kommen ein erwei-tertes Bewertungssystem und die Funktion derGruppierung zum Einsatz. Zusätzlich wurden eini-ge neue Erweiterungen wie z. B. die Namenskon-vention und Dateitypfilterung bei Aufgaben sowiedie Möglichkeit eines Zip-File Downloads allerAufgabenabgaben implementiert.

Neues Bewertungssystem

Das neue Bewertungssystem ermöglicht eine detaillier-tere Übersicht und Nachbearbeitung von Punkten einzel-ner Lernaktivitäten eines Kurses. Dadurch haben Sie dieMöglichkeit, für einzelne Teilnehmer(innen) die Punkteeiner Aufgabe nach dem Abgabetermin im Administra-tionsblock zu verändern. Weiters gibt es die Möglichkeit,logische Verknüpfungen zwischen einzelnen Elementeneines Kurses zu erstellen, um eine gemeinsame, von meh-reren Elementen abhängige Bewertung zu ermöglichen(z. B.: Die besten vier von fünf Übungsabgaben tragen40% zur Gesamtnote bei – der Durchschnitt der bestenzwei von drei Test muss mindestens 60% der zu errei-chenden Punkte betragen und trägt dann mit 30% zur Ge-samtnote bei und die mündliche Prüfung muss absolviertwerden und trägt dann 20% zur Gesamtnote bei).


Gruppen und Gruppierungen

Seit dem Update auf die neue Moodle Release 1.9.2+gibt es die Möglichkeit, mit Hilfe von Gruppierungen undentsprechend zugewiesenen Gruppen bestimmte Lernakti-vitäten speziellen Gruppen zur Verfügung zu stellen. Da-durch bieten Sie Ihren Teilnehmern eine bessere, auf fürsie relevante Informationen optimierte Kursansicht. JederTeilnehmer / jede Teilnehmerin sieht nur seine / ihre grup-pierungsspezifischen Lernaktivitäten.

Zip-File Download der Aufgabenabgaben

Sie haben seit diesem Semester innerhalb der AufgabenIhres Kurses die Möglichkeit, ein Zip-File aller abgegebe-nen Dateien der Kursteilnehmer(innen) zu erstellen. Die-ses Zip-File befindet sich nach der Erstellung in derDateiablage Ihres Kurses und kann dort jederzeitabgerufen werden.

Aufgaben mit Upload-Filter und Dateinmamens-konvention

Bei allen TUWEL-Aufgaben wurde die Upload-Mög-lichkeit um die Parameter Dateityp und Standarddateina-me erweitert. Lehrende können so vorgeben – und vorallem automatisch prüfen lassen –, dass nur die gewünsch-ten Dateitypen, z. B. pdf, jpg, zip, dwg, doc, ... abgegebenwerden können.

Zusätzlich kann für die Abgabedateien automatisch einStandarddateiname aus im System vorhandenen Informatio-nen zusammengesetzt werden (z. B. [idnumber]-[lastname]-[firstname]-[assignmentname]). So erhält man eindeutig un-terscheidbare Dokumente mit „Matrikelnummer-Nachna-me-Vorname-Recherchenaufgabe1.pdf“ anstatt wie bisherz. B. mehrere Dateien mit Namen Aufgabe1.pdf.

Folgende Standardeingaben stehen zur Verfügung:[firstname] = Vorname[lastname] = Nachname[idnumber] = Matrikelnummer[fullname] = Vorname Nachname[assignmentname] = Aufgabenname[group] = Gruppe[aggroup] = Arbeitsgruppe

Multimediale Dokumentationen im Kurs TUWELTutorials

Im Kurs „TUWEL Tutorials“ (immer aus der TUWEL-Toolbox erreichbar) wurden Ihnen 13 neue multimediale Tu-torials zur Verfügung gestellt, um Ihnen den Umgang mitTUWEL zu erleichtern. Diese Online-Hilfen mit Bild undTon behandeln neben der Übersicht, wie ein TUWEL-Kursentsteht, alle wichtigen Schritte zum eigenen TUWEL-Kursim Detail. Jedes Tutorial dauert ca. 3 - 5 Minuten.

Support

Auf jeder Seite in TUWEL finden Lehrende und Studie-rende in der TUWEL-Toolbox den Link zu den „TUWELTutorials“. Dort finden Sie die Tutorials, Dokumentatio-nen und Erläuterungen zur Lösung der häufigsten Fragen.Zusätzlich können Sie in der Change-Log Datenbank dieWeiterentwicklung von TUWEL mitverfolgen:https://tuwel.tuwien.ac.at/course/view.php?idnumber=tuweltutorials

Das Team des E-Learning Zentrums bietet spezifischesKnow-How für alle Teilschritte bei der Integration von E-Learning in Ihre Lehrveranstaltung an. Dabei werden Siebei der Entwicklung und Umsetzung Ihres Konzeptsunterstützt.

Ein spezielles Angebot stellen die individuellen Bera-tungen auf Institutsebene dar. Hier wird speziell auf dieWünsche und Anforderungen des Instituts eingegangen,um individuelle Konzepte erfolgreicher umzusetzen.

Kontakt: [email protected]

E-Learning Award 2009

Das Rektorat der TU Wien schreibt zum dritten Malden mit 10.000.- Euro dotierten E-Learning Award füralle Lehrveranstaltungen im Sommersemester 2008 undWintersemester 2008/2009 aus, mit dem exzellente Leis-tungen in der Lehrentwicklung unter Nutzung digitalerMedien ausgezeichnet werden. Die Preisverleihung wirdim Rahmen des 5. E-Learning Tags am 20. März 2009stattfinden.

Weitere Informationen:http://elearning.tuwien.ac.at/el-award09/

6. International Austrian Moodle Conference 2009

Das E-Learning Zentrum der TU Wien ist Gastgeberder 6. internationalen Österreichischen Moodle Konferenz2009 am 24. und 25. September 2009 an der TechnischenUniversität Wien. Der Leitspruch des Moodle-BegründersMartin Dougiamas: „The main value of an online courseis not the content, but the human interaction and activitiesthat take place around it!” kann als Motto für diese Kon-ferenz verstanden werden. Im Rahmenprogramm der Kon-ferenz wird es neben der Möglichkeit, sich mit anderenTUWEL/Moodle-Nutzerinnen und -nutzern auszutauschen,auch spezielle Workshop-Programme geben.

Wir laden Sie herzlich zur kostenlosen Teilnahme ander Konferenz ein!

Weitere Informationen:http://elearning.tuwien.ac.at/http://www.moodlemoot.at/moodle/


TISS Datenstruktur –Datenstruktur-BrowserAndreas Knarek

Ruby on Rails (kurz RoR oder Rails, www.rubyonrails. org) ist ein modernes, agiles Webframeworknach dem MVC-Prinzip, wobei MVC für die Aufteilung in die drei Schichten

(Templates für HTML, PDF etc.) und

Datenbankzugriff

Die Grundanforderung für ORM ist der einfache Zugriffauf die Datenbank der Applikation. Da moderne Softwaremeist objektorientiert entwickelt wird, sollen auch Datenals Objekte dargestellt werden. Der Entwickler soll nichtgenötigt werden, sich um den SQL-Zugriff auf eine Daten-bank kümmern zu müssen.

Rails kapselt die Datenbanktabellen in ActiveRecord-Klassen, wobei Tabellenspalten als getter/setter-Methodenabgebildet werden. Diese Methoden müssen allerdingsnicht – wie in anderen Sprachen meist üblich – definiertoder konfiguriert werden, sondern die Applikation liest dieTabellenstruktur beim ersten Zugriff aus, und erzeugt proSpalte dynamisch eine entsprechende getter- und setter-Methode.

Mittels der Methode „find“ kann man Datensätze la-den, über die getter und setter auf deren Attribute zugrei-fen und mittels „save“ wieder zurück in die Datenbankspeichern. Daneben gibt es auch Methoden zum Löschen,direkten Updaten und Massenupdate von Datensätzen.

Nachfolgendes Beispiel zeigt eine Tabelle „person“,die zugehörige ActiveRecord-Klasse und ein paar Bei-spielzugriffe auf die Tabelle:

Tabelle person:

id integer

vorname varchar2(100)

nachname varchar2(100)

nationalitaet_id integer

Daten:

id vorname nachname nationalitaet_id

1 Max Mustermann 1

2 Miss Musterfrau 1

# ActiveRecord-Klasseclass Person < ActiveRecord::Baseend

# Beispielp = Person.find(1) # Lade Datensatz mit ID 1p.vorname=> Maxp.nachname # Getter-Zugriff=> Mustermannp.vorname = "Test" # Setter-Zugriffp.save # speichert in die Datenbank

Suchen nach bestimmten Daten

Ein „find“ kann natürlich nicht nur über die ID erfol-gen, sondern auch über Suchkriterien. Die folgende An-weisung sucht nach Datensätzen mit Vornamen „Miss“und liefert den ersten gefundenen Satz zurück:

p = Person.find( :first, :conditions=>["vorname = ?","Miss"] )

Will man alle Datensätze bekommen, auf die die Ein-schränkung zutrifft, kann man anstatt „:first“ ein „:all“ an-geben.

Dynamische Finder

Da man in Rails bestrebt ist, sehr lesbaren Code zuschreiben, ermöglicht ActiveRecord auch den Datenzu-griff über so genannte dynamische Finder. Diese erlaubenAbfragen wie zum Beispiel:


p = Person.find_by_vorname "Miss"p = Person.find_by_vorname_and_nachname "Max","Mustermann"

Durch die Anwendung von dynamischen Findern wirdder Programmcode um einiges kompakter und lesbarer.

Validierung von Daten

Ein wichtiger Aspekt eines ORM sind Datenvalidierun-gen. Hier geht es darum, neue / geänderte Daten nicht un-geprüft in die Datenbank zu schreiben. Dazu gehören zumBeispiel Not-Null-Checks, Textlängen-Validierungen,Wertebereichs-Validierungen bei Zahlen / Datum etc.

Damit die Validierungen nicht von einzelnen Applika-tionsteilen irrtümlich übergangen oder vergessen werdenkönnen, werden diese Vorgaben zentral in den Models im-plementiert. Diese werden immer dann ausgeführt, wennein Objekt gespeichert wird. Bei Fehlern wird das Spei-chern verhindert und eine entsprechende Fehlermeldungan die Controller / Views zurückgegeben.

Beispiele:

class Person < ActiveRecord::Basevalidates_presence_of :nachnamevalidates_length_of :vorname, :within=>10..20validates_numericality_of :nationalitaet_id

end

Neben einigen vordefinierten Validierungen könnenauch ganz individuelle Codesegmente verfasst werden, diebeim Speichern durchlaufen werden sollen. Somit istgrößtmögliche Flexibilität gewährleistet.

Abbildung von Relationen

Relationen zwischen Objekten (also Tabellen) werdenebenfalls in den Models definiert. RoR unterstützt folgen-de Relationsarten:

• 1:1Ein Objekt besitzt kein oder maximal ein Kindobjekt.z. B.: ein Mitarbeiter hat keinen oder genau einen Dienst-ausweis.

• 1:nEin Objekt besitzt kein, ein oder mehrere Kindobjekte.z. B.: eine Person hat keine, eine oder viele Telefonnum-mern.

• n:mEin Objekt besitzt kein, ein oder mehrere Kindobjekte,welche gleichzeitig auch anderen Objekten gehören kön-nen.z. B.: eine Person kann in mehreren Räumen einen Ar-beitsplatz haben, wobei auch andere Personen in diesenRäumen arbeiten können.

• polymorphic 1:nEin Kindobjekt ist zu einem Objekt beliebiger Art zuor-denbar.z. B.: nicht nur eine Person kann eine / mehrere Adressenhaben, sondern auch eine Organisationseinheit, ein Ge-bäude etc. Adresse wird jedoch nur ein einziges Mal defi-niert.

• polymorphic m:nAnalog zu „polymorphic 1:n“

Fügen wir als Beispiel zu unserer Person noch eineKlasse Nation (Tabelle mit Spalte ID und NAME) hinzu,und verknüpfen diese beiden:

class Person < ActiveRecord::Basebelongs_to :nation, :foreign_key=>"nationalitaet_id",:class=>"Nation"

end

class Nation < ActiveRecord::Basehas_many :personen, :foreign_key=>"nationalitaet_id",:class=>"Person"

end

Durch diese „Verknüpfung“ werden dynamisch imHintergrund etliche Methoden erzeugt, um auf die in Be-ziehung stehenden Objekte zugreifen zu können, direktneue Objekte anzulegen, Objekte zu zählen etc.

Beispiele:

# Neue Nation anlegenn = Nation.create(:name=>"Österreich") # bekommt die ID 1# Person laden, und Nation zuordnenp = Person.find(1)p.nation = n # ident mit p.nationalitaet_id = n.idp.save

# Person neu auslesen, Nationalität abfragenp.reloadp.nation.name=> Österreich

# Nation laden, und alle zugehörigen Personen auslesenn = Nation.find(1)n.personen.count=> 13n.personen=> #Array von Personen

Callback-Methoden

Eine weitere wichtige Funktionalität eines ORM sindso genannte Callback-Methoden. Im Wesentlichen handeltes sich dabei um Observer, die Änderungen an Objektenregistrieren und beliebige Methoden aufrufen können.

Die nachstehenden Callback-Methoden sind die viergebräuchlichsten, es sind jedoch noch weitere vier in RoRverfügbar:

• before_validationWird direkt nach einem „save“ aufgerufen, noch bevordie Daten validiert werden.

• after_validationWird unmittelbar nach der Validierung aufgerufen, so-fern der Datensatz gültig war und gespeichert werdenkann.

• before_saveWird aufgerufen, bevor der Datensatz letztlich in die Da-tenbank zurück geschrieben wird. Somit die „letzteChance“, noch Zusatzdaten wie Datum der letzten Ände-rung, ID der ändernden Person etc. zu setzen.

• after_saveWird aufgerufen, nachdem der Datensatz erfolgreich inder Datenbank gespeichert wurde. Hier können zum Bei-spiel Zähler inkrementiert werden.


In TISS werden zum Beispiel per Default in fast allenModels Änderungshistorien geschrieben. Dazu kann proModel ein Mixin (Modul) hinzugeladen werden, das Än-derungen (Anlegen, Ändern, Löschen) automatisch in ei-ner History-Tabelle mitprotokolliert. Dieses Mixinverwendet dazu die before_save Callback-Methode.

Überblick durch Datenstruktur-Browser

Neben all diesen Punkten sind noch viele weitereFunktionen wie z. B. Internationalisierung und Unit-Testsin unsere Model-Schicht implementiert und werden in Zu-kunft auch noch weiter angereichert werden.

Um hier als Software-Entwickler den Überblick zu be-halten – aktuell sind in TISS bereits über 140 Models vor-handen – haben wir ein Modul namens „Datenstruktur-Browser“ implementiert. Wie der Name schon sagt, kannman sich damit durch die Datenstruktur „durchklicken“.Man kann sich so auf ganz einfachem Weg ansehen, wel-che Tabellenspalten ein Model hat, welche Relationen zuanderen Models bestehen und welche Callback-Methodenverwendet werden.

In der Administrator-Version ist über diesen Weg auchein direkter Zugriff auf die vorhandenen Daten möglich.

In einer Zwischen-Release wird der Datenstruktur-Browser in eingeschränkter Form für die TU-Mitarbeiterfreigegeben werden. Das soll in erster Linie dazu dienen,Wissbegierigen einen kleinen Einblick in die Grundzügedes Systems zu geben. Außerdem kann er auch eine wert-volle Unterstützung für die Benutzer sein, die gewisse Be-rechtigungen für diverse Datenauswertungen erhalten.

Die nebenstehenden Beispiele zeigen die Models „Mit-arbeiter“ und „Dienstverhaeltnis“, die zueinander in einer1:n-Beziehung stehen.


Backup für Windows PCsund ServerAndreas Klauda

ist die neueste Generation des Festplatten-Image und -Backup-Programms derFirma Acronis. Dieses Programm kann von TU-Instituten über die campusweite Software günstiglizenziert werden. Im Folgenden werden die Vorteile und Eigenschaften von True Image Echo kurzbeschrieben.

True Image Echo ermöglicht, ganze Festplatten, Partitio-nen und auch einzelne Dateien in so genannte Images zu si-chern. Diese können auch auf externe Datenträger(Festplatten oder DVDs) und sogar auf Server über dasNetz (LAN) gesichert werden. Aus den Festplatten-Imageskann man natürlich auch einzelne Files wiederherstellen.

Mit dem Zusatzprodukt Universal-Restore könnenImages auch auf andere Hardware – z. B. nach einemRechnertausch – zurückgespielt werden. Bei diesem Vor-gang wird während der Wiederherstellung die Hardware-Information (HAL) angepasst und das Betriebssystem istdann auch auf der geänderten Hardware lauffähig.

Auch bootfähige Notfallmedien (CDs) können erstelltwerden, mit diesen kann dann ein Rechner ohne installier-tes Betriebssystem gestartet werden, damit hat man dannZugriff auf seine Backups. Diese erstellten CDs beruhenauf einem kleinen Linux-System. Es gibt aber auch dieMöglichkeit einer Windows-Variante, und zwar mit Hilfevon Bart PE (www.nu2.nu/pebuilder/). Das dafür notwen-dige Modul (PE Plugin) ist im Lieferumfang enthalten.

Live Data Format

Acronis True Image Echo arbeitet hardware-unabhän-gig und zwischen physischen und virtuellen Umgebungen.Die Bausteine der zuverlässigen Datensicherung (AcronisRings of Reliability) illustrieren, wie Acronis mithilfe sei-ner abbild-basierten Technologie die Daten nahtlos zwi-schen Systemen bewegt. Erreicht wird diese Unab-hängigkeit durch die Abstraktion der Daten von der Platt-form-Architektur.

Die Technologien in Acronis True Image Echo setzenauf das Live Data Format als den kleinsten gemeinsamenNenner zwischen Systemen und den zugrunde liegendenPlattformen. Abbilder von bestehenden Systemen werdenin das Live Data Format gebracht und sind fortan nichtmehr von der zugrunde liegenden Hardware abhängig.Durch diese Unabhängigkeit ist eine Migration des Sys-tems zu anderen physischen oder virtuellen Plattformen

problemlos möglich. Das Live Data Format ist sowohl derSicherungs- als auch der Transport-Container für Server-und Workstation-Systeme und verschafft im Desaster-Falleinen wichtigen Zeitvorteil, da hardware-unabhängig aufvirtuellen oder physischen Maschinen wiederhergestelltwerden kann.

True Image Echo gibt es für Windows PCs (Worksta-tions) und für Windows Server.

True Image Echo Workstation:

• Backup von PCs im Netzwerk• Sicherung einzelner Dateien und Verzeichnisse• Bare-Metal Restore• Sicherung in eine virtuelle Maschine (optionales

Zusatzmodul Acronis Universal Restore erforderteigene Lizenz)

• Managementkonsole und Gruppenverwaltung


(aus: Acronis True Image EchoUnternehmenslösungen. Datenblatt)

True Image Echo Server für Windows:

• Sicherung im laufenden Betrieb, Unterstützung für Da-tenbanken

• Bare-Metal Restore, Disaster Recovery sowie Wieder-herstellung einzelner Daten

• Wiederherstellung auf abweichende Hardware mit Acro-nis Universal Restore (Optionales Zusatzmodul AcronisUniversal Restore erfordert separate Lizenz)

• Software Development Kit

In der Serverversion ist es auch möglich, die Images invirtuelle Datenträger zu konvertieren, um z. B. einen be-stehenden Rechner zu virtualisieren.

Im Rahmen der Systempflege für Arbeitsplatzrechnerund Server (auf der Basis von Wartungsvereinbarungen)unterstützen wir Sie unter anderem bei der Konzeptionvon Backup-Lösungen.

Für Rechner (Arbeitsplätze,) auf denen sich häufig et-was ändert, empfehlen wir ein tägliches Backup, wobei

hier natürlich nur die Änderungen gesichert werden, undeinmal im Monat ein Full Backup, wo die ganze Plattegesichert wird.

Am besten ist eine Backup-Form die auch eine gewisseHistory bietet, denn es kann ja sein, das man z. B. ein Filewieder herstellen möchte, wo die Löschung ein paar Tagezurück liegt. Wenn man jedoch immer nur einen aktuellenStand sichert – sprich die alten Backups überschreibt – istin so einem Fall das ganze Backup sinnlos.

Als Backup-Medium sollte man eine eigenständigeFestplatte (extern USB oder intern) oder einen Serverwählen, damit im Falle eines Hardwaredefekts die Datenerhalten bleiben.

Campusweite Software an der TU Wien: www.zid.tuwien.ac.at/sts/arbeitsplatz_software/software_liste/

Systempflege: www.zid.tuwien.ac.at/sts/systempflege/


Übersicht Features (siehe auch www.acronis.de/enterprise/products/ATISWin/comparison.html)

True Image Echo Workstation True Image Echo Server für Windows

• Dual Destination Backup – Sicherung in dieAcronis Secure Zone und ein weiteresSpeichermedium

• Import und Export von Archiven in denAcronis Backup Server aus externenSpeicherorten

• Konvertierung von Abbildern zu virtuellenFestplatten (VMDK, VHD, HDD)

• Ereignisbasierte Sicherung – Sicherung beiAn/Abmeldung, im PC-Leerlauf, beiÄnderung des freien Speicherplatzes

• AES-Verschlüsselung

• Wake on LAN – Start ausgeschalteter, WOL-fähiger Rechner zur Sicherung

• Image und File Backup – Sicherungvollständiger Datenträger und einzelnerDateien und Verzeichnisse, inkrementell unddifferenziell

• Ausschluss von Dateitypen

• Hot Imaging / Hot Backup – Sicherung imlaufenden Betrieb mit Acronis SnapshotTechnology

• Passwort-Schutz für die Acronis Secure Zone

• Mount Images – Einbinden von Abbildern imLese-/Schreibmodus

• Lese- und Schreibzugriff auf Archive –Veränderungen werden als inkrementelleSicherung gespeichert

• Erstellung von CDs mit bootfähigenAbbildern, PXE-Paketen und ISOs fürbootfähige Notfallmedien

• Erstellung bootfähiger Notfallmedien mitWinPE und BartPE

• Taskplaner für die regelmäßige Ausführungvon Sicherungen (Automatisierung)

• Benachrichtigungen per E-Mail, WindowsPopup und SNMP

• Unterstützung dynamischer Datenträger

• Multiple inkrementelle Zuwachssicherungen an einem Tag

• Ereignisbasierte Sicherung bei An-/Abmeldung, Leerlauf, Änderung des freienSpeicherplatzes

• AES-Verschlüsselung

• Multi Volume Snapshots – Verteilte Daten können in ein Abbild gesichert undverteilt wiederhergestellt werden

• Dual Destination Backup – Sicherung in die Acronis Secure Zone und ein weiteresSpeichermedium

• Raw Imaging und Raw Restore – Sicherung und Widerherstellung trotz beschädigterFestplatten-Sektoren

• Konvertierung von Abbildern zu virtuellen Festplatten (VMDK, VHD, HDD)

• Konsolidierung von Archiven – Erstellung von synthetischen Voll-Backups

• Image und File Backup – Sicherung vollständiger Datenträger und einzelner Dateien undVerzeichnisse, inkrementell und differenziell

• Ausschluss von Dateitypen

• Hot Imaging / Hot Backup – Sicherung im laufenden Betrieb mit Acronis SnapshotTechnology

• Sicherung von Datenbanken im laufenden Betrieb – beispielsweise Microsoft ExchangeServer, Microsoft SQL Server, Oracle

• Wiederherstellung im laufenden Betrieb mit Acronis Active Restore

• Mount Images – Einbinden von Abbildern im Lese-/Schreibmodus

• Lese- und Schreibzugriff auf Archive – Veränderungen werden als inkrementelleSicherung gespeichert

• Regelbare CPU- und Netzwerk-Auslastung

• Erstellung von CDs mit bootfähigen Abbildern, PXE-Paketen und ISOs für bootfähigeNotfallmedien

• Erstellung bootfähiger Notfallmedien mit WinPE und BartPE

• Taskplaner für die regelmäßige Ausführung von Sicherungen (Automatisierung vonBackups)

• Individuelle Vor- und Nach-Befehle (auch Skripte)

• Benachrichtigung per E-Mail, Windows Popup und SNMP

• Protokollierung (Logging) per Acronis Event Log und Windows Ereignisprotokoll


Zentraler Informatikdienst (ZID)der Technischen Universität Wien

Wiedner Hauptstraße 8-10 / E0201040 WienTel.: (01) 58801-42002Fax: (01) 58801-42099Web: www.zid.tuwien.ac.at

Leiter des Zentralen Informatikdienstes:Dipl.-Ing. Dr. Wolfgang Kleinert

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.

58801-1040 Wien, Wiedner Hauptstraße 8-10, Freihaus, 2.OG, gelber BereichMontag bis Freitag, 8 bis 17 Uhr

Ticket SystemOnline-Anfragen: 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] Netz- und [email protected] Systemunterstü[email protected] [email protected] IT [email protected] Operating zentrale [email protected] [email protected] Internet-Rä[email protected] TUWIS++

Service CenterWo: 1040 Wien, Wiedner Hauptstraße 8-10

Freihaus, 2. OG, gelber Bereich

Wann: Montag bis Freitag, 8:00 bis 17:00 UhrTelefon: 58801 - 42002

Online-Anfragenrund um die Uhr(Ticket System):https://service.zid.tuwien.ac.at/support/

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

Documents

ZIDline 19