Einschränkung der UNIX-Mail-Dienste

XMPP-Dienst

IdM-Portal

IBM Tivoli Storage Manager

JavaScript

01-02|16

ZEITSCHRIFT FÜR DIE KUNDEN DER GWDG

4 Einschränkung der UNIX-Mail-Dienste

„mailer.gwdg.de“ und „mailer.mpg.de“

6 XMPP-Dienst der GWDG 7 Kurz & knapp

8 Programmierschnittstelle zum Identity-

Management-Portal 12 A short Abstract on how

TSM works and the Principles behind it

16 JavaScript in der professionellen

Softwareentwicklung 19 Stellenangebot

20 Personalia 21 Kurse

ImpressumZeitschrift für die Kunden der GWDG

ISSN 0940-4686 39. Jahrgang Ausgabe 1-2/2016

Erscheinungsweise: monatlich

www.gwdg.de/gwdg-nr

Auflage:550

Fotos: © ra2 studio - Fotolia.com (1) © Spectral-Design - Fotolia.com (4) © ShkYo30 - Fotolia.com (8) © xiaoliangge - Fotolia.com (11) © Denlux - Fotolia.com (12) © mpmius - Fotolia.com (15) © Artur Manciniec - Fotolia.com (16) © Edelweiss - Fotolia.com (18) © nito - Fotolia.com (19) © MPIbpc-Medienservice (3, 20) © GWDG (2, 21)

Herausgeber: Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Faßberg 11 37077 Göttingen Tel.: 0551 201-1510 Fax: 0551 201-2150

Redaktion: Dr. Thomas Otto E-Mail: thomas.otto@gwdg.de

Herstellung: Maria Geraci E-Mail: maria.geraci@gwdg.de

Druck:Kreationszeit GmbH, Rosdorf

01-02|16

301-02|16

Liebe Kunden und Freunde der GWDG,

in dieser Ausgabe finden Sie einen Artikel zu einer Änderung beim Zugriff auf die UNIX-

Mail-Dienste der GWDG. Dieser Schritt war notwendig geworden, da der Dienst in

letzter Zeit leider immer wieder für Sicherheitsprobleme und zusätzlichen Betreuungs-

aufwand gesorgt hat. Die Änderung sollte keine funktionalen Einschränkungen für unse-

re Kunden mit sich bringen, da es einen bewährten alternativen Service auf Basis der

Exchange-Infrastruktur gibt.

Es ist uns bewusst, dass solche Schritte bei manchen Kunden auch zu Grundsatzfragen

bezüglich offener UNIX-Lösungen gegenüber kommerziellen Produkten – hier Microsoft

Exchange – führen. Wir sind bestrebt, möglichst unvoreingenommen geeignete Lösun-

gen für unsere Kunden bereitzustellen. Grundsätzlich bevorzugen wir dabei offene

Standards bzw. Open-Source-Lösungen und versuchen, diese im Rahmen unserer

Strategie zu fördern. Dennoch gibt es Bereiche, in denen kommerzielle Produkte zum

Einsatz kommen, weil sie aus individuellen Gründen vorteilhaft oder notwendig sind.

Wir versuchen, dies jeweils im Sinne des Kunden zu bewerten.

Die oben genannte Einschränkung des Zugangs zum UNIX-Mailer ist keine Entschei-

dung von grundsätzlicher Natur für oder gegen offene Lösungen. Sicherheitsfragen und

der notwendige Arbeitsaufwand sind die ausschlaggebenden Auslöser für diesen

Schritt, der aus Kundensicht letztlich keine funktionalen Nachteile mit sich bringt, aber

den E-Mail-Dienst insgesamt sicherer und leichter administrierbar macht.

Ich wünsche Ihnen viel Spaß beim Lesen dieser Ausgabe.

Ramin Yahyapour

GWDG – IT in der Wissenschaft

Prof. Dr. Ramin Yahyapour ramin.yahyapour@gwdg.de 0551 201-1545

401-02|16

WER IST WIE VON DER EINSCHRÄNKUNG DER UNIX-MAIL-DIENSTE BETROFFEN?

Zuerst sei angemerkt, das Exchange-Benutzer, die ihre stan-dardmäßige Outlook/OWA-Konfiguration nicht eigenständig geän-dert haben, von den hier beschriebenen Umstellungen und Neu-Registrierungen nicht betroffen sind.

Die derzeitige Verwendung von mailer.gwdg.de bzw. mailer.mpg.de lässt sich wie folgt unterteilen:

1. Viele Kunden nutzen, vermutlich aus historischen Grün-den, nach wie vor die UNIX-Server als Standard-SMTP-Server anstelle des eigentlich vorgesehenen Systems email.gwdg.de.

2. Einige Spezialsysteme, z. B. Multifunktionsdrucker, Moni-toring-Systeme, Messgeräte etc., unterstützen keine Benutzer-Authentifizierung bei der E-Mail-Einlieferung

Text und Kontakt:Stefan Teusch stefan.teusch@gwdg.de 0551 201-1866

WARUM WERDEN DIE UNIX-MAIL-DIENSTE EINGESCHRÄNKT?

Seit Jahren stellt Microsoft Exchange die Basis der E-Mail- und Groupware-Dienste der GWDG. Aus Gründen der Kompatibi-lität und des Benutzerkomforts wird parallel der vorherige UNIX-basierte SMTP-Dienst zusätzlich angeboten, der aus den Mail-servern mailer.gwdg.de bzw. mailer.mpg.de besteht. Hinsichtlich der Funktionalität spielen diese Systeme jedoch für die wenigsten Benutzer noch eine Rolle.

In letzter Zeit sind leider zunehmende Missbrauchsfälle und Angriffe auf bzw. über diese Systeme zu verzeichnen. Aufgrund der zentralen Rolle der UNIX-Mailer beim E-Mail-Transfer gefährdet dies den gesamten E-Mail-Dienst. In mehreren Schritten werden mailer.gwdg.de bzw. mailer.mpg.de daher zu ausschließlich inter-nen E-Mail-Verteilern umgebaut.

Einschränkung der UNIX-Mail-Dienste „mailer.gwdg.de“ und „mailer.mpg.de“

Für die von der GWDG parallel zum E-Mail-Hauptsystem „Microsoft Exchange“

betriebenen UNIX-Mailer sind aus Sicherheitsgründen Einschränkungen not-

wendig geworden: Die Zugriffe auf die SMTP-Server mailer.gwdg.de bzw.

mailer.mpg.de werden in den kommenden Wochen schrittweise eingeschränkt.

Reguläre Benutzer (natürliche Personen), die diese Systeme als E-Mail-Aus-

gangsserver verwenden, müssen diesen auf email.gwdg.de umstellen. Adminis-

tratoren von E-Mail-Servern oder Spezialsystemen müssen sich bis Ende Febru-

ar 2016 für eine weitere Nutzung der UNIX-Mail-Dienste registrieren.

501-02|16

und/oder versenden E-Mails mit unterschiedlichen Absenderadressen.

3. Für institutslokale dritte E-Mail-Server innerhalb als auch außerhalb Göttingens dienen mailer.gwdg.de bzw. mailer.mpg.de als Relay-Server innerhalb des E-Mail-Transportweges.

Die Anforderungen dieser Nutzergruppen an den SMTP-Dienst und damit die Bereitstellung des Dienstes unterschei-den sich recht stark und stehen teilweise auch im Widerspruch zueinander: Aufgrund der ersten Gruppe sind die E-Mail-Server weltweit erreichbar. Um Missbrauch vorzubeugen, müssen sich Benutzer bei GÖNET-externer E-Mail-Einlieferung authentifizieren. Wegen fehlender Funktionalität stellt diese Authentifizierung aber vor allem für die zweite Nutzergruppe eine unüberwindliche Hür-de dar. Diese Systeme müssen daher anhand vorheriger Registrie-rung durch die System-Administratoren explizit freigeschaltet wer-den. Im Laufe der Zeit haben sich hier äußert umfangreiche White-Listen ergeben.

Des Weiteren bestehen Unterschiede zwischen dem SMTP-Port 25 und dem Submission-Port 587. Über ersteren tauschen (eigentlich ausschließlich) E-Mail-Server ihre Daten aus; der zweit-genannte Port dient E-Mail-Programmen für die Ersteinlieferung der E-Mail in das aus den E-Mail-Servern bestehende Gesamtsys-tem. Technisch ist jedoch auch eine Ersteinlieferung von E-Mail via Port 25 möglich. Eine Unterbindung solcher Ersteingänge kann nur durch Abschottung des Ports gegenüber nicht bekannten Syste-men erreicht werden.

Die ersten Schritte zur Einschränkung der UNIX-Mail-Systeme mailer.gwdg.de bzw. mailer.mpg.de sehen die verschärfte Tren-nung der regulären Benutzer (Gruppe 1) und der Spezialsysteme (Gruppe 2 und 3) vor:

· Bereits seit dem 15.12.2015 werden nicht-authentifizier-te SMTP-Verbindungen auf Port 25 aus den Göttinger WLAN-Bereichen unterbunden.

· Seit dem 01.02.2016 werden nicht-authentifizierte SMTP-Verbindungen auf Port 25 aus den Göttinger VPN-Berei-chen unterbunden.

· Ab dem 01.03.2016 erfolgt die vollständige Abschal-tung (also auch authentifizierter) SMTP-Verbindungen auf den Ports 25 und 587 für nicht-registrierte Benutzer und Systeme.

WAS IST VON DEN BENUTZERN UND SYSTEM-ADMINISTRATOREN ZU TUN?

Alle regulären Benutzer müssen, sofern überhaupt erfor-derlich, ihren Standard-E-Mail -Ausgangsserver bis spä-testens Ende Februar 2016 auf das Exchange-System email.gwdg.de umstellen. Anleitungen finden sich auch auf den Webseiten der GWDG unter https://info.gwdg.de/dokuwiki/doku.php?id=de:services:email_collaboration:email_service:start.

Die nachfolgenden Erläuterungen und notwendigen Maßnah-men sind für die Betreuer der Systeme aus den Gruppen 2 und 3 relevant. Um eine wirksame Einschränkung des Benutzerbetriebs für die o. g. Gruppe 1 am 01.03.2016 zu ermöglichen, muss der SMTP-Service ab diesem Tag auf ausschließlich erlaubte Verbin-dungen auf Basis von White-Listen beschränkt werden. Da auf-grund von teils noch recht freizügigen Zugangsmöglichkeiten spe-ziell aus den Göttinger IP-Adressbereichen nicht alle E-Mail-Ser-ver bekannt sind und die bestehenden White-Listen dringend einer Aktualisierung bedürfen, werden wir alle White-Listen neu erstel-len und die bisher registrierten Systeme nicht übernehmen!

Bitte melden Sie dafür bis Ende Februar 2016 alle IP-Adressbereiche und Benutzerkonten zur Authentifizierung unter dem Betreff „Registrierung für UNIX-Mail-Service“ an support@gwdg.de.

E-Mail-Klienten, die bisher Port 25 mit Authentifizierung nut-zen, bitten wir, auf Port 587 umzustellen. Port 25 wird ausschließ-lich E-Mail-Servern (MTAs) zur Verfügung gestellt werden. Für Port 587 werden die bestehenden Ausnahmen von der Authentifizie-rungspflicht eingestellt.

Die weiteren Schritte bis zum vollständigen Umbau zu inter-nen E-Mail-Verteilern sind noch nicht terminiert. Um dies für alle Beteiligten zu vereinfachen, empfiehlt es sich, frühzeitig auf die SMTP-Dienste von Microsoft Exchange zu wechseln. Alle Syste-me, die eine Authentifizierung erlauben und E-Mails unter einer fixen Absenderadresse verschicken, können diesen Exchange-SMTP-Dienst (ggf. mit Hilfe eines Funktionsaccounts) nutzen. Bei wechselnden Absenderadressen kann ein Verschicken via Exchange ebenfalls bereits jetzt ermöglicht werden.

Restriction of the UNIX mail services “mailer.gwdg.de” and “mailer.mpg.de”

Due to security reasons, it is necessary to restrict the GWDG UNIX-Mailer that runs parallel to the main mailing sys-tem “Microsoft Exchange”. The access to the SMTP-Server mailer.gwdg.de as well as mailer.gwdg.de will be gradually restricted in the next coming weeks. Regular users (of course persons) who are using mailer.gwdg.de or mailer.mpg.de as their default SMTP outgoing server, must change to email.gwdg.de instead. System administrators (of e-mail ser-vers or special systems) who are willing to continue to use the UNIX mail services need to register until the end of Feb-ruary 2016.

Die einfachste und sicherste Methode ist dabei OTR. Beim Client sollte man darauf achten, dass OTR entweder per default oder über ein Plugin unterstützt wird. Im Gegensatz zu OTR sind bei PGP auch „Offline“-Nachrichten verschlüsselt, wohingegen bei OTR die Gesprächspartner online seien müssen, um die Daten ver-schlüsseln zu können. Zur Technik von OTR finden Sie Informatio-nen unter den Links am Ende dieses Artikels.

EINGESETZTE TECHNIK

Als XMPP-Software wird ejabberd (https://www.ejabberd.im) eingesetzt. In der Testphase wurde über einen längeren Zeitraum zusätzlich Openfire und für kurze Zeit Prosody als XMPP-Software getestet. Ejabberd erwies sich als äußerst stabil und bietet die nöti-gen Sicherheitseinstellungen, um den Dienst betreiben zu können. Der Server wird zur Zeit als Debian Linux VM bei der GWDG im ESX-Cluster betrieben.

WIE KANN MAN DEN DIENST NUTZEN?

Um den Dienst nutzen zu können, wird ein GWDG-Account benötigt. Die Anmeldung erfolgt über den jeweiligen XMPP-Cli-ent. Die Adresse des Benutzers, um für andere Nutzer erreichbar zu sein, lautet userid@jabber.gwdg.de. Die gängigen Clients sind in der Regel Open Source und für alle Betriebssysteme verfügbar.

Beispiel einer Konfiguration für den XMPP-Client PidginNach der Installation und dem ersten Start des Programms

öffnet sich ein Einrichtungs-Assistent, der durch alle Schritte der Account-Einrichtung führt. Mit einem Klick auf „Hinzufügen“ öff-net sich ein Fenster, welches um die Angabe der Verbindungsda-ten bittet (siehe Abb. 1).

Text und Kontakt:Thomas Linnemann thomas.linnemann@gwdg.de 0551 201-1844

WAS IST XMPP/JABBER?

XMPP (Extensible Messaging and Presence Protocol; http://xmpp.org) ist ein offener Standard eines Kommunikations-protokolls. Früher generell unter dem Begriff Jabber bekannt, nutzt man heute die Bezeichnung XMPP. Es dient hauptsächlich zum sogenannten Instanting Messaging oder einfach gesagt Chatten. Zwei oder mehrere Benutzer können sich damit in Echtzeit via Textnachrichten austauschen. Dabei kann sowohl mit einer Person als auch mit Gruppen kommuniziert werden.

Der Benutzer kann selbst entscheiden, welchen anderen Benutzern er seinen Online-Status mitteilen möchte. Im Gegen-satz zu anderen Anbietern (Google, Skype, ICQ, Facebook usw.) ist man dabei an keinen alleinigen Anbieter gebunden. Skurrile AGB gibt es bei XMPP nicht. Der dezentrale Ansatz schafft eine Unab-hängigkeit des Dienstes. Wer keinen externen XMPP-Anbieter nut-zen will, kann einfach selbst einen XMPP-Server aufsetzen und betreiben.

XMPP-DIENST DER GWDG

Die GWDG stellt seit einiger Zeit einen XMPP-Dienst zur Ver-fügung. Der XMPP-Server ist über LDAP an die zentrale Benut-zerverwaltung der GWDG angebunden; dadurch ist eine Nutzung für alle Benutzer der GWDG möglich. Zum Login wird dabei die Userid des Benutzers verwendet. Die Jabber-ID lautet userid@ jabber.gwdg.de. Diese Adresse ähnelt zwar einer Mailadresse, kann aber ausschließlich nur für die Kommunikation via XMPP genutzt werden.

WIE SICHER IST DIE KOMMUNIKATION?

Die Kommunikation zwischen XMPP-Client und -Server ist zwingend verschlüsselt. Wem diese Sicherheit nicht ausreicht, der kann außerdem eine clientseitige Verschlüsselung nutzen.

Die diversen Clients, die zur Auswahl stehen, bieten in der Regel verschiedene zusätzliche Verschlüsselungsmöglichkeiten. Die zwei gängigsten sind OTR (Off-the-Record) und PGP (Pretty Good Privacy). Bei beiden Techniken werden die Nachrichten vom Client ver- und entschlüsselt und übertragen, genau wie bei PGP-verschlüsseltem Mailverkehr. Dies bezeichnet man als eine Ende-zu-Ende Verschlüsselung, so dass auch XMPP-Dienstanbieter kei-ne Möglichkeit haben, die Nachrichten der Benutzer mitzulesen.

XMPP-Dienst der GWDG

Die GWDG stellt einen XMPP-Dienst für ihre Benutzer zur Verfügung. Dieser

Artikel stellt den Dienst vor und gibt Hinweise zur Konfiguration der Clients, um

den Dienst nutzen zu können. Der Benutzer hat durch die Vielfalt der Clients

auch die Möglichkeit, eine Ende-zu-Ende Verschlüsselung zu nutzen. Die Vortei-

le eines Nachrichtendienstes in Echtzeit werden bei der GWDG täglich genutzt.

GWDG XMPP serviceThe GWDG provides an XMPP service to its users. This

article describes the service and gives hints how to configu-re the variety of available clients. Along to the variety of cli-ents available, the users have the advantage to build (or to use) an end-to-end encryption. This real-time messaging ser-vice is already used extensively among the GWDG staff and many of its customers.

601-02|16

Um den XMPP-Server nutzen zu können, wählen Sie in der Auswahlbox mit dem Titel „Protokoll“ bitte den Punkt „XMPP“ aus. Bei „Benutzer“ muss die Userid (hier im Beispiel mmusterm) und bei Domäne jabber.gwdg.de eingetragen werden. Bei „Res-source“ kann eine beliebige Zeichenkette eingetragen werden. Die Ressource kann zum Beispiel anzeigen, mit welchem Gerät der Benutzer zur Zeit angemeldet ist (z. B. Linux-PC, Smartpho-ne oder Notebook). Dadurch besteht die Möglichkeit, mit demsel-ben Account mehrfach angemeldet zu sein. Der Gesprächspartner

kann damit auch entscheiden, an welche Ressource er die Nach-richt schicken möchte.

Ein neues Konto kann nicht angelegt werden, da der Account bereits in der Benutzerverwaltung der GWDG existieren muss. Nachdem „Hinzufügen“ angeklickt wurde, ist der Vorgang abge-schlossen. Der Benutzer ist nun via XMPP über die Adresse mmusterm@jabber.gwdg.de erreichbar und kann mit anderen Benutzern Nachrichten austauschen. Dies können auch Benutzer anderer XMPP-Anbieter sein.

HINWEISE

Diverse Clients haben anscheinend Probleme mit der erzwungenen Verschlüsselung des Servers. Clients wie Pidgin (https://pidgin.im), Psi+ (http://psi-plus.com) oder Audium (https:// adium.im) haben damit kein Problem. Der Dateiversand ist nicht vorgesehen, da es dabei, je nach Client und lokalen Netzwerk-regeln, leider immer wieder zu Problemen kommt. Weitere Infor-mationen finden Sie auch unter https://info.gwdg.de/docs/doku.php?id=de:services:email_collaboration:xmpp.

LINKS

· https://de.wikipedia.org/wiki/Extensible_Messaging_and_ Presence_Protocol

· https://wiki.ubuntuusers.de/XMPP · http://www.einfachjabber.de · http://wiki.xmpp.org/web/Jabber_Resources · https://de.wikipedia.org/wiki/Jabber_Identifier · https://otr.cypherpunks.ca

1_Eingabe der Verbindungsdaten

Kurz & knappPDF-XChange Pro nun auch für die Universität Göttingen – als Alter-native zu Adobe Acrobat

Nachdem die Max-Planck-Gesellschaft eine akademische Firmenlizenz des Software-Produkts PDF-XChange Pro der Fir-ma Tracker Software Products (http://tracker-software.com) beschafft hat, verfügt nun auch die Universität Göttingen (ein-schließlich UMG) über eine akademische Campuslizenz. Sie wurde von der Abteilung IT der Universität und vom Geschäfts-bereich IT der UMG finanziert, sodass auf die Institute keine Kosten zukommen, wenn die Software genutzt werden soll. Im Preis enthalten ist ein dreijähriger Upgrade-Service. Mithil-fe von PDF-XChange Pro lassen sich PDF-Dokumente erstellen, bearbeiten und in MS-Office-Produkte integrieren. Es ist damit eine ausgezeichnete und kostengünstige Alternative zu Ado-be Acrobat. Weiteres entnehme man auch den GWDG-Nach-richten 06/2015 oder dem URL https://info.gwdg.de/docs/doku.php?id=en:services:general_services:software_and_license_management:pdfxchangeuni.

Grieger

Einstellung des Foliendrucks zum 1. März 2016

Anders als noch vor einigen Jahren besteht heute nahezu kein Bedarf mehr an ausgedruckten Folien für Overhead-Pro-jektoren, da fast alle Benutzer ihre Präsentationen per Beamer halten. Aus diesem Grund hat die Nutzung des GWDG-Folien-druckers mittlerweile so stark nachgelassen, dass ein Weiter-betrieb dieses Gerätes wirtschaftlich nicht mehr sinnvoll ist. Zudem hat die Zuverlässigkeit aufgrund der geringen Nutzung aus technischen Gründen stark abgenommen. Bei dem Drucker handelt es sich nämlich um einen sogenannten Festtintendru-cker, der nicht mit Toner, sondern mit geschmolzenem Wachs druckt. Wird dieser Drucker längere Zeit nicht genutzt, führt das leider dazu, dass das geschmolzene und wieder ausgehärtete Wachs das Druckwerk verstopft.

Die entsprechenden Warteschlangen folie, transperancy, zcst4s84, zcsp4d84, zcsp4l84 und zcsp4s84 werden daher ab dem 01.03.2016 nicht mehr zur Verfügung stehen.

Nolte

701-02|16

angefügt wird. Zusätzlich zu der Signatur wird ein Zugangsschlüs-sel angefügt. Dieser wird verwendet, um auf dem Server den geteilten geheimen Schlüssel zu finden, die Signatur serverseitig erneut zu bilden und mit der empfangenen zu vergleichen.

Text und Kontakt:Sascha Klöppnersascha.kloeppner@gwdg.de 0551 201-2162

Björn Braunschweigbjoern.braunschweig@gwdg.de0551 201-2133

AUTHENTIFIZIERUNG

ÜberblickDie API wird in Form einer mit TLS (Transport Layer Securi-

ty) geschützten HTTP-REST-Schnittstelle (REST = REpresentatio-nal State Transfer) bereitgesellt. Für die Authentifizierung ist die Bil-dung einer Signatur in Form eines Keyed-Hash Message Authenti-cation Code (HMAC) erforderlich. Dieser Code wird mithilfe eines geteilten geheimen Schlüssels, Teilen des Requests und der aktu-ellen Uhrzeit erstellt. Die erstellte Signatur hat eine Gültigkeit von fünf Minuten. Die Bildung der Signatur ist notwendig, um die Inte-grität des Requests zu gewährleisten und z. B. sogenannte Man-in-the-Middle-Angriffe zu verhindern und somit eine Manipulation des Requests zu erkennen.

AblaufUm erfolgreich mit der API kommunizieren zu können, muss

der Client zunächst einen „Basis“-HTTP-Request erstellen. Aus den Daten dieses Requests (u. a. HTTP-Methode und URI) und einem geteilten geheimen Schlüssel wird mithilfe des HMAC-Ver-fahrens eine Signatur erstellt, welche dem Request im Header

Programmierschnittstelle zum Identity-Management- Portal

Die GWDG betreibt seit 2006 ein Identity-Management-System zur Verwaltung

von Accounts, Ressourcen, Berechtigungen und zur Automatisierung von Pro-

zessen. Für die dezentrale Administration wurde ein Identity-Management-Por-

tal (IdM-Portal) entwickelt. Um eine automatisierte Verwaltung zu ermöglichen,

wurde das IdM-Portal um eine Programmierschnittstelle (API) erweitert. Die API

enthält nahezu alle Funktionen der Webapplikation, bietet jedoch eine bessere

Suchmöglichkeit durch Angabe eines komplexen Suchfilters. Da es sich bei dem

IdM-System allgemein um eine sicherheitskritische Anwendung handelt, wurde

bei der API großer Wert auf eine sehr sichere Authentifizierung gelegt. Dieser

Artikel gibt einen kurzen Überblick über den dafür verwendeten Algorithmus.

A programming interface for the IdM portal

Since 2006 GWDG runs an Identity Management (IdM) System for the administration of accounts, resources, and privileges as well as the automation of processes. An IdM portal was developed to permit participating institutes to locally manage their accounts and resources. In compliance with the request of several institutes for extended automa-tion possibilities a programming interface (API) has been added. The API got almost all features of the web applica-tion. A benefit is that you can use complex search filters with the API. If you are interested in using the API or you have any questions, please contact the GWDG Service Hotline (support@gwdg.de).

801-02|16

1) Client erstellt Request

2) Client erstellt HMAC-Signatur

3) Client sendet Request + Signatur an Server

4) Server sucht geheimen Schlüssel

Request ------------------------ GET idm.gwdg.de:8081 /api/v2/workspaces

Request ------------------------ GET idm.gwdg.de:8081 /api/v2/workspaces

Request ------------------------ GET idm.gwdg.de:8081 /api/v2/workspaces ------------------------ X-AccessKeyId=456 X-Date=… X-Signature=abcabc

Request ------------------------ GET idm.gwdg.de:8081 /api/v2/workspaces ------------------------ X-AccessKeyId=456 X-Date=… X-Signature=abcabc

HMAC

API

Signature=abcabc

SecretAccessKey=123

SecretAccessKey = KeyPairs[‘456’]

SecretAccessKey=123

5) Server erstellt SignaturSiehe „Client erstellt HMAC-Signatur“.

6) Server vergleicht SignaturenSignatur (Server) == Signatur (Client)? Ja: Der Request ist authentifiziert und die Integrität ist sichergestellt.Nein: Der Request ist nicht authentifiziert.

7) SignaturbildungDer wichtigste Teil der Authentifizierung ist die Bildung der

Signatur. Nur wenn diese korrekt gebildet wird, kann der Request bearbeitet werden. Im Folgenden wird die Bildung der Signatur exemplarisch dargestellt.

901-02|16

8) CanonicalRequest

HTTPRequestMethod: POST, GET, DELETE usw.; Großschrei-bung beachten.Host: idm.gwdg.de:8081URI: Bsp.: /api/v2/workspace; Kleinschreibung beachten, ange-hängten Slash beachten.QueryString: Eventuell angehängt, wie z. B. bei GET http://idm.gwdg.de:8081/api/v2/workspace?test=123&foo=bar -> que-ryString = ?test=123&foo=bar. Wenn es keinen QueryString gibt, keine Daten anfügen -> ...++... RequestPayload: Bei einem POST-Request die Daten aus dem Body. Wenn es keinen Payload gibt, keine Daten anfügen -> ...+ HexEncode: Mit dem Format-String x2, so dass Kleinbuchstaben entstehen.

Beispiel:

9) Hash des CanonicalRequest erstellenDie Hash-Funktion muss dem Algorithmus des nachfolgen-

den StringToSign entsprechen. Beispiel: Wird als Algorithmus HMACSHA512 gewählt, muss als Hash-Funktion SHA512 gewählt werden.

10) StringToSign erstellen

Algorithm: Unterstützt werden derzeit HMACSHA256 und HMACSHA512; Großschreibung beachten.RequestDate: Im UTC-Format: YYYYMMDD‘T‘HHMMSS‘Z‘; z. B.: 20110909T233600Z

Beispiel:

11) Signatur erstellen

12) Request erstellenFolgende Header zum Request hinzufügen:

Beispiel:

KONTAKT

Interessierte Institutsadministratoren können sich für einen Zugang zum IdM-Portal sowie für Fragen rund um das Thema IdM gerne an die Service-Hotline der GWDG wenden (support@gwdg.de).

CanonicalRequest = HTTPRequestMethod + ‘+‘ + Host + ‘+‘ +URI + ‘+‘ + QueryString + ‘+‘ + HexEncode(Hash(RequestPayload))

CanonicalRequest = GET+idm.gwdg.de:8081+/api/v2/workspaces++

HashedCanonicalRequest = HexEncode(Hash(Canonical Request))

StringToSign = Algorithm + ‘+‘ + RequestDate + ‘+‘ + HashedCanonicalRequest

Signature = HexEncode(HMAC(SecretAccessKey, StringToSign))

X-Algorithm=HMACSHA512X-Date=<date> (Gleiches Datum wie bei der Erstellung des StringToSign)X-AccessKeyId=<key> (Repräsentiert den Zugangsschlüs-sel und wird genutzt, um serverseitig den geteilten geheimen Schlüssel zu finden.)X-Signature=<signature> (Im vorherigen Schritt berechnete Signatur anhängen)

GET https://idm.gwdg.de:8081/api/v2/workspaces HTTP/1.1host: idm.gwdg.de:8081Accept: application/xmlAccept-Language: de-DEX-Algorithm=HMACSHA256X-Date=20141017T113145ZX-AccessKeyId=123123123X-Signature=4e497d7cc98ef3a921e14bfd0363459fb3a5c541eba31bfa8d09c5fbf288afdd3c38cfad151bb04d8be2f8351db18a7c45c8c064b825941c 43cf2f295b6d28e9

StringToSign = HMACSHA512+20141017T113145Z+d49e24f4c829e5e29e9c58dc32239b5f6265a0c7906bf07115 6d8094b5333196082656f5f6702b77c2ed802b0a1ce953fb42 38d660704ece678f31b961821cea

1001-02|16

IP-Adress-ManagementsystemIP-ADRESS-VERWALTUNG LEICHT GEMACHT!

Ihre Anforderung Sie möchten Ihre IP-Adressvergabe, DNS- und

DHCP-Dienste (IPv4 und IPv6) zentral und profes-sionell verwalten. Sie möchten die Pflege der IP-, DNS- und DHCP-Daten an eigene Administratoren delegieren. Sie möchten DNS- und DHCP-Dienste über Appliance-Technologie hochverfügbar realisie-ren.

Unser Angebot Wir bieten Ihnen die Mitnutzung unseres man-

dantenfähigen IP-Adress-Managementsystems (IPAM-Systems) an. Die Adressbestände und DNS-Namensräume können dabei von einem Administrator oder mehreren gepfl egt werden. Die Synchronisation der Daten in den zugehöri-gen DNS- und DHCP-Diensten erfolgt periodisch oder unmittelbar auf Anforderung. DNS- und DHCP-Dienste können über zentral verwalte-te Appliances lokal erbracht werden. Wir bieten Schulung Ihrer Administratoren durch GWDG-Spezialisten an.

Ihre Vorteile> Die IPv4- und IPv6-Adressbestände werden pro-

fessionell verwaltet.

> Die Konsistenz der Daten im Adress- und Na-mensraum wird sichergestellt.

> Die Pfl ege über die WWW-Schnittstelle ist ohne große Einarbeitung und ohne großes Experten-wissen über DNS- und DHCP-Dienste sowie Be-triebssysteme seitens Ihrer Mitarbeiter möglich.

> Die Delegation der Verwaltung von Teilbereichen des Adress- und Namensraums an verschiedene Sub-Administratoren wird ermöglicht.

> DNS- und DHCP-Dienste können bei Einsatz von Appliance-Systemen vor Ort hochverfügbar er-bracht werden (optional).

> Nutzung der DNS-Server der GWDG für öffent-liche DNS-Datenbestände (ohne Notwendigkeit, dafür einen eigenen Server zu betreiben; optio-nal)

Interessiert?Wenn Sie unser IPAM-System nutzen möch-ten, werfen Sie bitte einen Blick auf die u. g. Webadresse. Ihr Institut muss einen oder meh-rere erforderliche Administratoren benennen. Für DNS-Dienste ist die Integration vorhandener DNS-Server oder der Einsatz einer lokalen Ap-pliance nötig. DHCP-Dienste erfordern immer eine lokale Appliance. Lokale Appliances müs-sen vom Institut beschafft werden (optional; ab-hängig von den Anforderungen des Instituts).

www.gwdg.de/ipam

well in the conclusion summary in the log file of a client below [ex-traction of a log file of a medium sized client (4.6 million objects, 8.6 TByte, 531 MByte new files)]:

As the transmission took just a few seconds (13.06 sec), the entire backup took nearly 1.5 hours (01:21:33 h). Most of the time the client was identifying changed files. This discrepancy is also shown in transmission rates. While the ”Network data trans-fer rate” is at about 40 MByte/sec, the ”Aggregate data transfer rate” (average transfer rate of “total size of backup files” divided by “total backup time”) is much less at 107.5 KByte.

In the past IBM focused on the problem of low bandwidth (keywords ”data compression” and ”deduplication”[4]). Since cli-ent version 6.3 IBM started to focus on what is called the ”seek time” or ”lookup time”. For Windows and Linux systems a func-tion (journal-daemon/service) was added. The function is monito-ring the local mass storage and lists all changes made after the last backup. The TSM client is capable of reading the list and is

Text und Kontakt:Bjørn Nachtwey bjoern.nachtwey@gwdg.de 0551 201-2181

Wolfgang Hitzler (IBM TSM Pre Sales Engineer)

BASIC PRINCIPLES

The IBM Tivoli Storage Manager (TSM) follows, like most backup solutions, the ”client server principle”. The backup client is going to be installed on the client machine. We will refer to the backup client software and the backup client machine as ”client”. The client will transfer the backup data to the TSM server. The ser-ver is then writing the data to a low-cost but secure storage medi-um. Depending on the actual requirements either magnetic tapes or disc systems can be used. At this point the similarities between all backup solutions end. Identifying backup data, transferring the data to the server, and processing the data on the server can vary sometimes considerably with each backup solution. This article won´t do a comparison of backup solutions, our focus lies on the description of how GWDG’s TSM works.

TSM CLIENT MECHANISM: FILELEVEL-BACKUP

The TSM client is making a backup based on the file space. First, the client requests a list of changes of the files to backup and their attributes (metadata) from the TSM server. It then creates a virtual directory tree directly in the client memory from the reques-ted data. Using the file and directory attributes the TSM client then compares the virtual directory tree and their physical counterparts. Files and directories that differ regarding the attributes are trans-mitted to the server. TSM uses an incremental backup strategy [2], since only changed files and metadata are transmitted. TSM backups are not designed to perform full backups. Therefore IBM names this backup principle ”incremental forever” [3].

Searching through the drives and partitions is likely to be much more time consuming then the actual data transfer. This varies greatly depending on the amount of data. For the search process the size of data is of less importance than the number of files and directories (summed as ”objects” by TSM). This can be seen very

A short Abstract on how TSM works and the Principles behind it

Talking to customers and colleagues about backup and restore, many of them

know the basic principles, but nearly nothing of the way the IBM Tivoli Sto-

rage Manager (TSM) implements those principles. This document gives a

short overview on ”how TSM works” without having to read the whole exten-

sive documentation IBM offers for TSM [1]– well, many details we do not

mention will be found there, of course. The original German text has been

co-authored by Wolfgang Hitzler, an IBM TSM Pre Sales Engineer.

Total number of objects inspected: 4,629,154Total number of objects backed up: 2,134Total number of objects updated:4 4Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 454Total number of objects failed: 10Total number of bytes inspected: 8.64 TBTotal number of bytes transferred: 513.64 MBData transfer time: 13.06 secNetwork data transfer rate: 40,269.79 KB/secAggregate data transfer rate: 107.49 KB/secObjects compressed by: 0 %Total data reduction ratio: 100.00 %Elapsed processing time: 01:21:33

1201-02|16

selecting only those files which have changed according to the list.Unfortunately this function is not available for network mass

storages (e.g. Linux: NFS; Windows and Mac: SMB, CIFS), as changes and backups can be made from other devices as well. Continuously monitoring the network drives would not be less expensive than a usual incremental TSM backup. However, an option exists for a few NAS filers (e.g. NetApp FAS series running ONTAP 7.3 or higher, IBM SONAS) to generate the list of changed files on the filer itself and to provide it to TSM. IBMs very own file system GPFS is supporting this function as well. EMC Isilon sys-tems can detect file changes. However, due to the use of different charsets the evaluation of the file list is expensive and prone to error. At this time a comparable function is not supported by more simple file systems.

In addition to file backups a full partition can be transferred as well. The so called ”image backup” is a kind of full backup; in fact the entire partition is transferred. The operating system or servi-ces providing the file spaces need to support a pause or copy func-tion for the entire file space, as a writing process during the back-up might cause data inconsistency.

TSM CLIENT MECHANISM: API BACKUP

TSM provides the possibility to use application APIs (SQL, Exchange) in addition to the ”File-Level-Backup”. Some special TSM clients are provided to use different APIs.

Examples: · TSM for Databases (for Oracle DB’s incl. RAC MS SQL

Server) · TSM DataProtection Client / DB2 (for DB2 databases, this

license is included in the DB2-license) · TSM for Virtual Environments (Plugin in VMware vCenter,

VADP inter- face is used here) · TSM for Mail (Backup for MS Exchange and Domino)

In general, the way the API clients work can be summarized as: The files which need a backup are identified by the client. Once it collected all files they are transferred to the TSM server. An incre-mental data transfer is possible but it is depending on the API cli-ent implementation.

DATA EXCHANGE BETWEEN SERVER AND CLIENT

The data transfer between a TSM client and a TSM server is implemented using a TSM own protocol based on TCP/IP. Usually all data is sent as a plain stream. But TSM provides security fea-tures which can be combined:

1. Transport encryption via SSL The TSM server holds an SSL certificate [5] (similar to a webserver) to authenticate to the TSM client. Both the server and the client are arranging a cryptographic token for the actual data transfer. The data is decrypted at the server and processed (for example writing to tape) as plain data. With SSL encryption comes higher security but a not to neglect work load for clients and especially for servers. Therefore, the TSM server of the GWDG is not supporting the SSL functionality.

2. Complete data encryption The client is encrypting the entire data before it is trans-ferred to the server. The TSM server then processes the data as ”plain”, unencrypted data even though it is enc-rypted. The data than is compressed and written to the LTO tapes. Due to the encryption, the compression will not be as effective as it would be for data in the clear.

The GWDG highly recommends the complete encryption as it protects data from unauthorized access at the TSM servers / tape libraries and during the transmission.

TSM SERVER MECHANISM: DATA MANAGEMENT

Different approaches are used on TSM servers to optimize data management. The most important ones are described below:

Management Classes, Policy Sets and CopygroupsThe parameters set in a management class define several set-

tings such as storage location, retention period or number of ver-sions. The default management class can be overwritten by provi-ding special “include exclude” rules to the client. Please contact us to determine which class suits your needs best.

Storage AreasTSM is using a so called ”Storage Pool” to store the data

transferred by a client. A ”Storage Pool” is a storage area most likely abstracted and not bound to a single physical storage medi-um, such as tape or disc. TSM requests tapes from a tape library or container files from an operating system on demand. ”Storage Pools” always consist of storage media with identical properties, but still it can store up data with different requirements.

Cache ”Staging Pools”A continuous stream of new data on a 10 Gb network inter-

face would be needed to write directly on tape without interrupti-on. However, some points of the previous statement do not apply in practice:

· The transmission of the data is done partially and is inter-rupted by the lookup time.

· Only few clients have a 10 Gb connection. · The amount of data from a single client is quite low in

IBM Tivoli Storage Manager – ein Überblick zur Arbeitsweise von TSM

Wie bereits im ursprünglichen Artikel (vgl. die GWDG-Nachrichten 11/2014) beschrieben, fällt im Gespräch mit TSM-Nutzern auf, dass zwar das Prinzip, wie eine Sicherung („Backup“) und eine Wiederherstellung („Restore“) funktio-nieren, bekannt ist, die Umsetzung, sprich das Konzept und die Arbeitsweise des von der GWDG genutzten Programm-paketes „IBM Tivoli Storage Manager (TSM)“, jedoch nicht oder nur rudimentär. Nachdem zunächst die Funktionsweise in einem deutschen Text zusammengefasst dargestellt wur-de, folgt in dieser Ausgabe der GWDG-Nachrichten eine eng-lische Übersetzung, um möglichst viele Nutzer zu erreichen. Eine Kopie dieses Textes ist auch wieder auf unseren Web-seiten zu finden.

1301-02|16

comparison to the total data processed on the TSM server.

Current tapes have high writing throughput of data [6]. There-fore, writing data directly to the tapes would cause a stop-and-go state whenever a drive cache is emptied. This stop-and-go state would decrease the performance of the tape and shorten its life-time as the tape must be moved back and forth.

TSM optimizes the usage of the tapes by collecting the data in the ”Staging Pool”, which is a fast storage area connected to the TSM server. TSM then writes the data collectively on the tapes. During the recreation of the TSM environment (see ”GWDG-Nach-richten” 8/2014) it is planned to expand the cache as much as nee-ded to bridge even maintenance work at the tape libraries. All data sent to the TSM server during the maintenance work is then held in the cache until the library can write again. Errors such as ”ANS... Server out of space” should belong to the past. A restore will be faster while the data is held in the cache as no time for the tape mount is required.

Active Data Storage AreasIn TSM environments all data representing the client state at

the time of the last backup are called “active data”. Due to the ”incremental forever” approach of TSM, unchanged files and just rarely changed are transferred to the TSM server only once or infre-quently. As consequence it can be seen that, with a high probabi-lity the active data is spread over different tapes. Multiple mounts have to be made to perform a restore. The tape mounts take a lot of time and delay other internal processes as restores have a high-er priority than a backup.

Special ”Active Data Pools” can be defined for entire clients, just for a special file space, and for multiple file spaces. It can be defined exclusively as the only storage destination or as an additi-onal copy, too. These new defined destinations are used to keep copies of the latest change only. This concept massively improves the speed of a restore. As disadvantage the significantly higher price due to a rising need of resources has to be mentioned. The need for resources is caused by using normal hard drives instead of tape libraries for ”Data Pools”.

Considering the costs and the need of resources, the GWDG refused the concept of ”Active Data Pools”. But we are, in coope-ration with our customers, in the process of evaluating the requi-rements as ”Active Data Pools” and the concept of local mirroring can become, at least partially, economical.

Virtual Full BackupTSM is using an ”incremental forever” approach for the back-

ups. A full backup is not made. However, the TSM server can use all the different client backups made [7] to combine the data for a specific point in time into one virtual full backup. Just as if a full backup would have been done at that time. The virtual full backup can be saved as ”BackupSet” within TSM or on an external sto-rage device (e.g. USB drive). The retention period for a backup set can differ from the standard backup retention. This is a way the GFS principle [8], known from other backup solutions, can be emu-lated without the need to perform a full backup frequently.

The functionality to define ”BackupSets” in addition to the

usual retention period has not been supported by the GWDG so far, because of a typically large number of tape mounts needed if the data is spread over multiple tapes. These tape mounts compe-te against the restores and writing on tape, and may take several days in some cases. Using the ”Active Data Pools” the costs for creating ”BackupSets” drop and can be done with only little effort. Please get in touch with us if you are interested in that topic.

Deleting Data from TapeThe data on the hard drives and tapes is deleted only indirect-

ly. Data is marked as ”deletable” but stays physically on the sto-rage device. Compared to a hard drive these marked sectors are not simply overwritten but reduce the usable capacity of the tape. When a minimal capacity is reached, the unmarked data is copi-ed to a new tape to free the partially used one. The limit for the redensification (”Reclamation”) is usually chosen low. Therefore, a single tape can be used to store data of multiple tapes.

The tapes freed by the ”Reclamation” will hold the data until it is overwritten and it is therefore still readable. Recovering dele-ting data is just a theoretical issue as, a really large amount of time is needed (The TSM server needs to be restored to an earlier sta-te in order to read the skipped data).

MECHANISM ”RESTORE”

In addition to the description of client and server, no sepa-rate description is given. Generally multiple restore scenarios are possible:

1. The user selects the data for the restore from within the GUI or via client command line interface. The server recei-ves the request and collects the data to hand it over to the client.

2. The user selects entire partitions or folders to restore. Due to the ”Incremental Forever” approach the needed data is spread across targets. The server must then go back and forth on a tape or it even has to mount multiple tapes to gather the data.

3. The restore of files, folders and entire partitions can be performed for any point in time [9] in the past. Here as well the data has to be collected from different locations.

High latency can occur during all restore operations, as multip-le tape mounts might be needed or the tape has to be moved back and forth to the correct position. The high latency can only be avoi-ded if the restore data is still in the server’s disk cache. The ”Active Data Pools” would increase the speed of a restore of the last ver-sion significantly as no tape mounts would be needed. The resto-re time for older versions is not or only slightly improved by ”Active Data Pools” as tape mounts would still be needed for older data.

Analogously to backups, the TSM server will sum up data to larger packets to improve the usage of the bandwidth.

All restore processes have a higher priority compared to all other TSM operations. Caused by the time needed by tape mounts and tape movement, still a lot of time is needed to do a restore. The time waiting for the first response is, in most cases, signifi-cantly longer than the time needed to send the entire data.

1401-02|16

FOOTNOTES AND REFERENCES

[1] See http://pic.dhe.ibm.com/infocenter/tsminfo/v7r1/topic/com.ibm.itsm.client.doc/b_ba_guide_unx_lnx.pdf (Linux/UNIX, 750 Pages) or see http://pic.dhe.ibm.com/infocenter/tsminfo/v7r1/topic/com.ibm.itsm.client.doc/b_ba_guide_win.pdf (Windows, 808 Pages)

[2] For differences between multiple backup strategies see https://en.wikipedia.org/wiki/Backup

[3] Of course there are exclusions possible. Using the opti-on ”ABSOLUTE” a full backup can be forced. But we highly recommend not to use it. A full backup comes with a dispro-portionate effort and TSM offers to create virtual full backups (details following).

[4] Deduplication is looking for duplicated files or file parts and replaces them with a reference to the already existing file (part). See also https://en.wikipedia.org/wiki/Data_deduplication

[5] SSL (Secure Socket Layer), see https://en.wikipedia.org/wiki/Secure_ Sockets_Layer

[6] LTO-6 with up to 160 MB/sec, Jaguar5 with up to 350 MB/sec, the minimal speed requirement is still at 40 MB/sec (LTO-5, LTO-6)

[7] As data versions will forfeit due to the period for retention, vir-tual full backups are possible within the period for retention only.

[8] ”Grandfather Father Son Principle”; The period for retention differs by the type of backup. E.g. end of the week, end of the month, end of the year, see also https://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son

[9] If the “point in time“ is well within the period for retention only.

We like to thank Thomas Ripping and Peter Chronz for trans-lating this article.

1501-02|16

Ihre AnforderungSie möchten auf das weltweite OpenSource-Softwareange-bot zentral und schnell zugreifen. Sie benötigen Handbücher oder Programmbeschreibungen oder Listings aus Computer-zeitschriften. Sie wollen Updates Ihrer Linux- oder FreeBSD-Installation schnell durchführen.

Unser AngebotDie GWDG betreibt seit 1992 einen der weltweit bekanntes-ten FTP-Server, seit sieben Jahren mit leistungsfähigen Res-sourcen für schnellen Service

Ihre Vorteile> Großer Datenbestand (40 TByte), weltweit verfügbar> Besonders gute Anbindung im GÖNET

> Aktuelle Software inkl. Updates der gebräuchlichsten Linux-Distributionen

> Unter pub befindet sich eine aktuell gehaltene locatedb für schnelles Durchsuchen des Bestandes.

> Alle gängigen Protokolle (http, ftp, rsync und nfs) werden unterstützt.

Interessiert?Wenn Sie unseren FTP-Server nutzen möchten, werfen Sie bitte einen Blick auf die u. g. Webseite. Jeder Nutzer kann den FTP-Dienst nutzen. Die Nutzer im GÖNET erreichen in der Regel durch die lokale Anbindung besseren Durchsatz als externe Nutzer.

>> www.gwdg.de/ftp-server

FTP-Server Eine ergiebige Fundgrube!

1601-02|16

Laufzeit angelegt sind, auf solch schnelllebige Technologien setzen kann. Der Autor dieses Artikels hat dies getan und möchte nun von seinen Erfahrungen berichten.

Eingesetzt wurde der sogennannte MEAN-Stack, nur nicht im ursprünglichen Sinne. Der eigentliche MEAN-Stack besteht aus den Komponenten MongoDB als Datenbank, Express, Angu-larJS und Node.js. Statt MongoDB wurde jedoch eine MySQL-Datenbank eingesetzt. In den folgenden Abschnitten werden die JavaScript-Technologien AngularJS und Node.js sowie Express näher beleuchtet.

Text und Kontakt:Ralph Krimmel ralph.krimmel@gwdg.de 0551 201-1821

EINLEITUNG

Lange wurde in der Fachpresse dazu geraten, JavaScript im Browser abzuschalten. Doch aktuell kommt kaum eine moderne Webseite ohne diese Scriptsprache aus. Machen Sie den Selbst-versuch: Deaktivieren Sie JavaScript oder installieren sie ein Brow-ser-Plugin wie NoScript und besuchen Sie Ihre üblichen Seiten! Sie werden nach fünf Minuten lieber zu einem guten Buch greifen, das kein JavaScript benötigt.

Der Omnipräsenz von JavaScript zuträglich sind auch die vie-len Bibliotheken und Frameworks, die es Entwicklern ermögli-chen, bestimmte Funktionalitäten innerhalb kürzester Zeit umzu-setzen. Fast monatlich findet man neue Ankündigungen zum neuen JavaScript Framework, welches alles anders und besser macht. JQuery, AngularJS, Ember, React, Meteor, Backbone oder Node.js: Die Entwicklung ist rasend schnell und was heute noch die Plattform ist, auf die sich die Entwicklergemeinde stürzt, kann morgen schon wieder durch das nächstbessere Framework obso-let gemacht werden.

Wird das Framework weiterhin gepflegt und mit Updates ver-sorgt, mag dies noch akzeptabel sein. Im schlimmsten Fall jedoch stirbt das Projekt, und die Entwickler, die dieses einsetzen, ste-hen vor einem großen Problem. Nun stellt sich die Frage, ob man für Projekte, die im Umfang etwas größer und auf mehrere Jahre

JavaScript in der professionellen Softwareentwicklung

Die Programmiersprache JavaScript hat einen langen Weg hinter sich. Einst nur

dazu gedacht, Webseiten etwas mehr Dynamik zu verleihen, breitet sich die

etwas mehr als 20 Jahre alte Sprache in immer mehr Bereiche jenseits von

Firefox, Chrome, Safari und Internet Explorer aus. Aber auch am eigentlichen

Einsatzort, dem Browser, haben wir dieser Sprache viel zu verdanken. Zusam-

men mit HTML5 hat JavaScript bzw. der Standard „ECMAScript“ es geschafft,

dass wir heute auf Browser-Plugins wie Flash, Silverlight oder JavaApplets

größtenteils verzichten können. In diesem Artikel soll der Einsatz von JavaScript

in der Softwareentwicklung beleuchtet werden.

Using JavaScript in professional software development

The JavaScript programming language has been around for 20 years now. Originally it has been designed to impro-ve dynamic websites in Firefox, Safari, Internet Explorer and the like. Since then there has been a lot further develop-ment in different directions, especially concerning browsers: Together with HTML5, JavaScript respectively the Standard “ECMAScript“ allowed to relinquish/renounce browser plug-ins like Flash, Siverlight or JavaApplets. This article is about using JavaScript in professional software development.

1701-02|16

ANGULARJS

AngularJS (https://angularjs.org) ist ein bei Google Inc. ent-wickeltes Open Source Framework aus dem Jahr 2009, welches beim Internetgiganten auch im Produktiveinsatz ist. Es ist darauf ausgelegt, sogenannte Single Page Applications zu entwickeln, also Webseiten, die nur aus einer HTML-Datei bestehen und bei Bedarf notwendige Inhalte nachladen.

Ein besonderes Merkmal von AngularJS ist das Two-Way Databinding. Hierbei werden Daten und deren Anzeige – man spricht auch vom Model und View – logisch miteinander verknüpft. Änderungen in einem spiegeln sich auch immer im anderen wie-der. Der Entwickler braucht sich nicht mehr um eine Synchronisie-rung zu kümmern. Konkret bedeutet das, dass z. B. eine Variable, die den Inhalt eines Textfeldes repräsentiert, ihren Wert ändert, sobald ein Benutzer Text in dieses eingibt. Gleichermaßen wird aber auch das Textfeld automatisch aktualisiert, sollte die Pro-grammlogik den Wert der Variable ändern.

Ein weiteres, sehr mächtiges Werkzeug von AngularJS sind Direktiven. Mit diesen lässt sich das HTML-Vokabular der Anwen-dung um eigene Komponenten erweitern. Da sich Direktiven gut isolieren und als Einheit testen lassen, kann man solche Kompo-nenten auch in weiteren Anwendungen einsetzen. Für sehr viele Standardanforderungen gibt es inzwischen fertige Direktiven, die man in wenigen Schritten in die eigene Anwendung integrieren kann. Jedoch ist auch hier wieder darauf zu achten, dass man sich vor dem Einbau einer solchen Direktive anschaut, wie gut und häu-fig diese noch mit Updates versorgt wird. Gerade bei einem größe-ren Sprung der AngularJS-Version kann es vorkommen, dass die verwendeten, externen Module zur neuen AngularJS-Version nicht mehr kompatibel sind.

In die Zukunft blickend kann man vermuten, dass AngularJS in den nächsten Jahren zunehmend Verwendung finden wird, da die Entwicklung aktiv von Google vorangetrieben wird. Allerdings hat uns die Vergangenheit gelehrt, dass Google durchaus regel-mäßig Dienste einstellt, die nicht mehr zur aktuellen Firmenpolitik passen. Durch die Open-Source-Lizenzierung und die relativ gro-ße Entwicklergemeinde ist ein Fortbestand der Technologie auch ohne Google wahrscheinlich.

NODE.JS UND EXPRESS

Mit Node.js (https://nodejs.org/en) hat JavaScript Einzug auf der Serverseite erhalten. Die von Ryan Dahl 2009 entwickelte Lauf-zeitumgebung für JavaScript basiert auf Googles JavaScript Engi-ne V8, welche auch im Browser Chrome zum Einsatz kommt. Die Besonderheit von Node.js ist, dass im Gegensatz zu den sonst

serverseitig verwendeten Sprachen auf Parallelität verzichtet wird. Der Anwendung steht also nur ein Thread zur Verfügung.

Der Vorteil dieser Architektur ist, dass der Programmierer nicht auf Thread Safety achten muss. Es ist also nicht nötig, den Zugriff auf gemeinsam genutzte Ressourcen zu synchronisieren oder kri-tische Abschnitte, in denen sich nur jeweils ein Thread aufhalten darf, zu definieren. Um dennoch möglichst viele Anfragen „gleich-zeitig” bearbeiten zu können, setzt Node.js auf asynchrone Aufru-fe: Es wird nach Aufruf einer Funktion nicht auf das Zurückkehren gewartet, sondern eine sogennante Callback-Funktion übergeben, welche nach durchgeführter Aufgabe wieder angesprungen wird.

Nun ist Node.js prinzipiell erstmal nur eine Laufzeitumgebung für JavaScript. Möchte man damit serverseitige Anwendungen schreiben, muss man noch auf eines der vielen verfügbaren Pake-te zurückgreifen. Diese lassen sich sehr bequem über den Paket-manager npm installieren.

Ein sehr häufig verwendetes Paket ist der Express Server (http://expressjs.com). Mit diesem lassen sich in wenigen Zeilen REST-Endpunkte definieren, welche als Rückgrat z. B. einer Angu-larJS-Anwendung fungieren können. Auch für andere, fundamen-tale Funktionalitäten einer Webanwendung stehen Pakete bereit: Cookie und Session Managment, Authentifizierung oder Daten-bankanbindung zu allen gängigen Datenbanken, um nur einige wenige zu nennen.

Zur Zukunftssicherheit von Node.js lässt sich anmerken, dass RedHat seit Oktober 2015 das Projekt finanziell unterstützt. Sie befinden sich dabei in guter Gesellschaft: Auch IBM, Intel, Joyent Microsoft und PayPal fördern die Entwicklung von Node.js.

NÜTZLICHES

Zusätzlich zu den großen Frameworks gibt es unzählige kleine Helfer und Tools in der npm-Paketverwaltung, die es dem Entwick-ler einfacher machen. Will man es sich z. B. ersparen, die komplet-te Projektstruktur eines Angular-Projekts selbst anzulegen, kann man zum Programm yeoman (http://yeoman.io) greifen. Dieses kann eine Vielzahl von sogenannten Generatoren bedienen, um ganz bequem alle benötigten Ordner, Dateien und ein Buildsystem anhand von Templates zu erzeugen.

Gerade in größeren Projekten ist dies eine enorme Hilfe. Man muss sich jedoch einige Zeit in das Buildsystem einlesen, um alle durchgeführten Schritte zu durchblicken. Neben dem einfachen Starten des Node Servers bringt z. B. der Generator angular-full-stack (https://github.com/angular-fullstack/generator-angular-full-stack) u .a. auch Minification und eine komplette Testinfrastruk-tur mit.

ServervirtualisierungDER EINFACHE WEG ZUM SERVER!

Ihre Anforderung Sie benötigen zur Bereitstellung eines Dienstes

einen Applikations- oder Datenbankserver. Ihnen fehlen Platz, Hardware, Infrastruktur oder Man-power. Gleichzeitig soll der Server möglichst hochverfügbar und performant sein.

Unser Angebot Wir bieten Ihnen die Möglichkeit des Hostings

von virtuellen Servern für Ihre Anwendungen ba-sierend auf VMware ESX. Sie können Ihre eige-nen virtuellen Maschinen verwalten, die in unse-rer zuverlässigen Rechnerinfrastruktur gehostet werden, die unterschiedliche Verfügbarkeits-grade unterstützen. Unsere Installation hält die Best-Practice-Richtlinien von VMware ESX ein. Sie bleiben Administrator Ihres eigenen virtuellen Servers, ohne sich mit der physikalischen Aus-führungsumgebung beschäftigen zu müssen.

Ihre Vorteile> Leistungsfähiges VMware-Cluster mit zugehöri-

gem Massenspeicher

> Hohe Ausfallsicherheit und Verfügbarkeit durch redundante Standorte und Netzwerkverbindun-gen sowie USV-Absicherung

> Bereitstellung aller gängigen Betriebssysteme zur Basisinstallation

> Umfassender administrativer Zugang zu Ihrem Server im 24/7-Selfservice

> Möglichkeit der automatisierten Sicherung des Servers auf unsere Backupsysteme

> Zentrales Monitoring durch die GWDG

> Große Flexibilität durch Virtualisierungstechnolo-gien wie Templates, Cloning und Snapshots

> Schutz vor Angriffen aus dem Internet durch leis-tungsfähige Firewallsysteme sowie ein Intrusion Prevention System

Interessiert?Jeder Nutzer mit einem gültigen Account bei der GWDG kann das VMware-Cluster nutzen. Um einen virtuellen Server zu beantragen, nutzen Sie bitte die u. g. Webadresse.

www.gwdg.de/virtuelle-server

1901-02|16

StellenangebotDie GWDG sucht ab sofort zur Unterstüt-zung der Arbeitsgruppe „IT-Infrastruktur“ eine/n

Ingenieur/in Elektrotechnik

mit einer regelmäßigen Wochenarbeitszeit von 39 Stun-den. Die Vergütung erfolgt nach dem Tarifvertrag für den öffentlichen Dienst (Bund); die Eingruppierung ist je nach Qualifikation bis zu TVöD E 13 vorgesehen.

Zu Ihren Aufgaben gehören · Koordination der Belegung und des Betriebs

der GWDG-Serverräume sowie Betreu-ung und Erweiterung des bestehenden GWDG-Techniknetzes.

· Planung, Überwachung und Auswertung aller technischen Betriebsparameter der GWDG-Ser-verräume unter Berücksichtigung von Aspekten der Nachhaltigkeit und Energieeffizienz, v. a.

› der Stromversorgung (inkl. USV), der Strom-qualität und des Stromverbrauchs,

› der Klimatechnik und der Kühlsyste-me sowie der Kontrolle deren korrekter Funktion.

› Erfassen und Überwachen von Messwer-ten v. a. zu Stromlasten, Betriebstempera-turen und Kühlwasserqualität sowie Tests und Integration neuer Messgeräte und -verfahren.

› die Erstellung jeweiliger Anforderungsprofile. › die Festlegung von Verfahrensanweisungen

bei Überschreitung von Grenzwerten. · Planung, Koordinierung und Überwachung tech-

nischer Installationsarbeiten, insbesondere eines Rechenzentrum-Neubaus. Dies beinhaltet v. a. die aktive Arbeit in Workshops und die Mitwir-kung bei der Erstellung der ZBau (Gebäude, Strom, Kühlung, Lüftung, IT-Infrastruktur).

· Die Beratung, die Planung und die Begutach-tung (Dritter) technischer Infrastruktur von Rech-nerräumen u. a. von (physischen) Datenüber-tragungsnetzen inkl. Auslegung der passiven Netzwerkkomponenten.

· Die CAD-gestützte Erstellung und Modifikation technischer Pläne (Basis: AutoCAD) u. a. Gebäu-depläne, Raumbelegungspläne, Stromlaufpläne.

Fragen zur ausgeschriebenen Stelle beantworten Ihnen:

Herr Stefan Teusch Tel.: 0551 201-1866 E-Mail: stefan.teusch@gwdg.de oder

Herr Herbert Witt Tel.: 0551 201-1536 E-Mail: herbert.witt@gwdg.de

Sie verfügen über · ein abgeschlossenes Ingenieurstudium im

Bereich Elektrotechnik, · eine selbstständige Arbeitsweise und über min-

destens drei Jahre Berufserfahrung im Betrieb der technischen Infrastruktur eines modernen Rechenzentrums,

· ein freundliches und kompetentes Auftreten, · sehr gute Kommunikations- und Teamfähigkeit, · ein ausgeprägtes Verhandlungsgeschick, Durch-

setzungsfähigkeit und sehr hohe Belastbarkeit, · sehr gute analytische, methodische und konzep-

tionelle Fähigkeiten, · sehr gute Kenntnisse in (Auto-)CAD, · gute Sprachkenntnisse in Wort und Schrift in

Deutsch und Englisch sowie · die körperlichen Voraussetzungen für die Arbeit

in schwer zugänglichen bzw. schlecht begehba-ren Bereichen, wie z. B. Baustellen.

Die GWDG will den Anteil von Frauen in den Bereichen erhöhen, in denen sie unterrepräsentiert sind. Frau-en werden deshalb ausdrücklich aufgefordert, sich zu bewerben. Die GWDG ist bemüht, mehr schwerbe-hinderte Menschen zu beschäftigen. Bewerbungen Schwerbehinderter sind ausdrücklich erwünscht.Wir bitten interessierte Damen und Herren um eine Bewerbung bis zum 22.02.2016 bevorzugt über das Online-Formular unter https://s-lotus.gwdg.de/gwdgdb/agi/20151209.nsf/bewerbung. Alternativ rich-ten Sie Ihre Bewerbung postalisch an die Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttin-gen, Am Faßberg 11, 37077 Göttingen.

ABSCHIED VON KHAWAR MUNIR ABBASI

Herr Khawar Munir Abbasi hat zum 30. November 2015 die GWDG verlassen. Er war in der Arbeitsgruppe „eScience“ (AG E) schwerpunktmäßig im Bereich

„Software Defined Networking“ tätig. Herr Abbasi hat dabei im Rahmen des Projektes NEPHELE gemeinsam mit Industrieunternehmen an Methoden zur effizienten Vernet-zung von Cloud-Rechenzentren geforscht und Software entwickelt. Herr Abbasi ist jetzt für ein führendes, internationales IT-Unternehmen tätig und beschäftigt sich weiterhin mit netzwerkbezogenen Themen. Wir danken Herrn Abbasi für seine Arbeit bei der GWDG und wünschen ihm beruflich wie privat weiterhin viel Erfolg und Freude. Wieder

NEUER MITARBEITER TIMO JANSSEN

Seit dem 1. Dezember 2015 verstärkt Herr Timo Janßen die Arbeitsgruppe „Anwendungs- und Informationssysteme“ (AG A) als studentische Hilfskraft.

Herr Janßen studiert an der Georg-August-Universität Göttingen im Master-Studiengang Physik. Sein Aufgabenbereich bei der GWDG wird in der Mitarbeit in der Bioinformatik liegen. Herr Janßen ist per E-Mail unter timo.janssen@gwdg.de erreichbar. Heise

NEUER STIPENDIAT BO ZHAO

Seit dem 15. Dezember 2015 ist Herr Bo Zhao als Stipendiat in der Arbeitsgruppe „eScience“ (AG E) tätig und arbeitet im Bereich „High Performance Computing“

(HPC). Nach einem Bachelor-Abschluss am Fachbereich „Informatik und Technologie“ an der Tsinghua University Peking im Jahr 2011 wechselte Herr Zhao an das „National Digi-tal Switching System Engineering & Technological Research Center“, Zhengzhou, Henan, China in die Forschungsgruppe von Professor Rongcai Zhao. Dort schloss er 2014 sein Master-Studium mit Auszeichnung ab. Seitdem gehört er dieser Einrichtung als Dokto-rand an. Über ein Stipendium des „China Scholarship Council“ wird Herr Zhao die nächs-ten vier Jahre bei der GWDG bleiben und neben der Mitarbeit in Forschungsprojekten sein Doktoranden-Studium an der Universität Göttingen fortführen. In Göttingen wird Herr Zhao an seine bisherigen Forschungen im Bereich HPC anknüpfen und sich spezi-ell mit Programmanalyse und Parallelisierung sowie Anwendungs-Containern und Deep Learning für Netzwerkanalysen befassen. Herr Zhao ist per E-Mail unter bo.zhao@gwdg.de erreichbar. Wieder

Personalia20

01-02|16

2101-02|16

KURS VORTRAGENDE/R TERMIN ANMELDEN BIS AE

GRUNDLAGEN DER BILDBEAR-BEITUNG MIT PHOTOSHOP

Töpfer 03.02. – 04.02.2016 9:30 – 16:00 Uhr

27.01.2016 8

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 11.02.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

04.02.2016 4

INDESIGN – GRUNDLAGEN Töpfer 17.02. – 18.02.2016 9:30 – 16:00 Uhr

10.02.2016 8

HIGH-LEVEL, HIGH-PERFOR-MANCE TECHNICAL COMPU-TING WITH JULIA

Chronz 25.02.2016 9:15 – 16:30 Uhr

18.02.2016 4

EINFÜHRUNG IN WINDOWS 10 Buck 03.03.2016 9:00 – 12:30 Uhr

25.02.2016 2

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 10.03.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

03.03.2016 4

PHOTOSHOP FÜR FORTGE-SCHRITTENE

Töpfer 15.03. – 16.03.2016 9:30 – 16:00 Uhr

08.03.2016 8

INDESIGN – AUFBAUKURS Töpfer 05.04. – 06.04.2016

9:30 – 16:00 Uhr

29.03.2016 8

MAC OS X IM WISSEN-SCHAFTLICHEN ALLTAG

Bartels 13.04. – 14.04.2016 9:30 – 16:30 Uhr

06.04.2016 8

USING THE GWDG SCIENTIFIC COMPUTE CLUSTER – AN IN-TRODUCTION

Dr. Boehme, Ehlers 18.04.2016 9:30 – 16:00 Uhr

11.04.2016 4

PARALLELRECHNERPRO-GRAMMIERUNG MIT MPI

Prof. Haan 19.04. – 20.04.2016 9:15 – 17:00 Uhr

12.04.2016 8

INFORMATIONEN:support@gwdg.de 0551 201-1523

Kurse

Februar bis Dezember 2016

2201-02|16

KURS VORTRAGENDE/R TERMIN ANMELDEN BIS AE

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 21.04.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

14.04.2016 4

EINFÜHRUNG IN DIE STATIS-TISCHE DATENANALYSE MIT SPSS

Cordes 27.04. – 28.04.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

20.04.2016 8

HIGH-LEVEL, HIGH-PERFOR-MANCE TECHNICAL COMPU-TING WITH JULIA

Chronz 10.05.2016 9:15 – 16:30 Uhr

03.05.2016 4

ADMINISTRATION VON PCS IM ACTIVE DIRECTORY DER GWDG

Buck 12.05.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

05.05.2016 4

ANGEWANDTE STATISTIK MIT SPSS FÜR NUTZER MIT VOR-KENNTNISSEN

Cordes 18.05. – 19.05.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

11.05.2016 8

EINFÜHRUNG IN DAS IP-AD-RESSMANAGEMENTSYSTEM DER GWDG FÜR NETZWERK-BEAUFTRAGTE

Dr. Beck 24.05.2016 10:00 – 12:00 Uhr

17.05.2016 2

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 26.05.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

19.05.2016 4

UNIX FÜR FORTGESCHRITTE-NE

Dr. Sippel 30.05. – 01.06.2016 9:15 – 12:00 und 13:15 – 15:30 Uhr

23.05.2016 12

OUTLOOK – E-MAIL UND GROUPWARE

Helmvoigt 02.06.2016 9:15 – 12:00 und 13:00 – 16:00 Uhr

26.05.2016 4

QUICKSTARTING R: EINE AN-WENDUNGSORIENTIERTE EIN-FÜHRUNG IN DAS STATISTIK-PAKET R

Cordes 08.06. – 09.06.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

01.06.2016 8

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 16.06.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

09.06.2016 4

DATENSCHUTZ - VERARBEI-TUNG PERSONENBEZOGENER DATEN AUF DEN RECHENAN-LAGEN DER GWDG

Dr. Grieger 22.06.2016 9:00 – 12:00 Uhr

15.06.2016 2

STATISTIK MIT R FÜR TEILNEH-MER MIT VORKENNTNISSEN – VON DER ANALYSE ZUM BE-RICHT

Cordes 06.07. – 07.07.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

29.06.2016 8

HIGH-LEVEL, HIGH-PERFOR-MANCE TECHNICAL COMPU-TING WITH JULIA

Chronz 01.09.2016 9:15 – 16:30 Uhr

25.08.2016 4

GRUNDLAGEN DER BILDBEAR-BEITUNG MIT PHOTOSHOP

Töpfer 06.09. – 07.09.2016 9:30 – 16:00 Uhr

29.08.2016 8

INSTALLATION UND ADMINIS-TRATION VON WINDOWS 10

Buck 15.09.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

08.09.2016 4

INDESIGN – GRUNDLAGEN Töpfer 20.09. – 21.09.2016 9:30 – 16:00 Uhr

13.09.2016 8

2301-02|16

KURS VORTRAGENDE/R TERMIN ANMELDEN BIS AE

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 29.09.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

22.09.2016 4

PHOTOSHOP FÜR FORTGE-SCHRITTENE

Töpfer 19.10. – 20.10.2016 9:30 – 16:00 Uhr

12.10.2016 8

MAC OS X IM WISSEN-SCHAFTLICHEN ALLTAG

Bartels 26.10. – 27.10.2016 9:30 – 16:30 Uhr

19.10.2016 8

INDESIGN – AUFBAUKURS Töpfer 02.11. – 03.11.2016 9:30 – 16:00 Uhr

26.10.2016 8

EINFÜHRUNG IN DIE STATIS-TISCHE DATENANALYSE MIT SPSS

Cordes 08.11. – 09.11.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

01.11.2016 8

EINFÜHRUNG IN DAS IP-AD-RESSMANAGEMENTSYSTEM DER GWDG FÜR NETZWERK-BEAUFTRAGTE

Dr. Beck 15.11.2016 10:00 – 12:00 Uhr

08.11.2016 2

ADMINISTRATION VON PCS IM ACTIVE DIRECTORY DER GWDG

Buck 17.11.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

10.11.2016 4

QUICKSTARTING R: EINE AN-WENDUNGSORIENTIERTE EIN-FÜHRUNG IN DAS STATISTIK-PAKET R

Cordes 23.11. – 24.11.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

16.11.2016 8

UNIX FÜR FORTGESCHRITTE-NE

Dr. Sippel 28.11. – 30.11.2016 9:15 – 12:00 und 13:15 – 15:30 Uhr

21.11.2016 12

OUTLOOK – E-MAIL UND GROUPWARE

Helmvoigt 01.12.2016 9:15 – 12:00 und 13:00 – 16:00 Uhr

24.11.2016 4

HIGH-LEVEL, HIGH-PERFOR-MANCE TECHNICAL COMPU-TING WITH JULIA

Chronz 06.12.2016 9:15 – 16:30 Uhr

29.11.2016 4

ANGEWANDTE STATISTIK MIT SPSS FÜR NUTZER MIT VOR-KENNTNISSEN

Cordes 07.12. – 08.12.2016 9:00 – 12:00 und 13:00 – 15:30 Uhr

30.11.2016 8

DIE SHAREPOINT-UMGEBUNG DER GWDG

Buck 15.12.2016 9:00 – 12:30 und 13:30 – 15:30 Uhr

08.12.2016 4

Teilnehmerkreis Das Kursangebot der GWDG richtet sich an alle Mitarbeiterinnen und Mitarbeiter aus den Instituten der Universität Göttingen und der Max-Planck-Gesellschaft sowie aus einigen anderen wissen-schaftlichen Einrichtungen.

Anmeldung Anmeldungen können schriftlich per Brief oder per Fax unter der Nummer 0551 201-2150 an die GWDG, Postfach 2841, 37018 Göt-tingen oder per E-Mail an die Adresse support@ gwdg.de erfolgen. Für die schriftliche Anmeldung steht unter https://www.gwdg.de/antragsformulare ein Formular zur Verfügung. Telefonische Anmel-dungen können leider nicht angenommen werden.

Kosten bzw. Gebühren Unsere Kurse werden wie die meisten anderen Leistungen der GWDG in Arbeitseinheiten (AE) vom jeweiligen Institutskontin-gent abgerechnet. Für die Institute der Universität Göttingen und der Max-Planck-Gesellschaft erfolgt keine Abrechnung in EUR.

AbsageSie können bis zu acht Tagen vor Kursbeginn per E-Mail an support@gwdg.de oder telefonisch unter 0551 201-1523 absagen. Bei späteren Absagen werden allerdings die für die Kurse berech-neten AE vom jeweiligen Institutskontingent abgebucht.

KursorteAlle Kurse finden im Kursraum oder Vortragsraum der GWDG statt. Die Wegbeschreibung zur GWDG sowie der Lageplan sind unter https://www.gwdg.de/lageplan zu finden.

Kurstermine Die genauen Kurstermine und -zeiten sowie aktuelle kurzfristige Informationen zu den Kursen, insbesondere zu freien Plätzen, sind unter https://www.gwdg.de/kursprogramm zu finden.