RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Rekonstruktion von Dateisystemrechten in Linux

English Version

Ein Linux tut immer was man ihm sagt. Und wenn es erstmal fertig ist, gibt’s kein zurück. Das ist in den meisten Fällen keine schlechte Sache, denn man ist sich ja eigentlich immer sicher, dass man dies und das wirklich tun möchte 😉 Hin und wieder kann es jedoch vorkommen, dass einem Fehler unterlaufen und ein ‘Rückgängig’ ist nirgends zu finden. Um so einen Fall geht es nun hier. Ich wollte lediglich einem Verzeichnis und dessen Unterverzeichnissen Rechte auf alles (Lesen, Schreiben und Ausführen) geben. 

chmod -R a+rwx DIR

Im ersten Versuch wurde ich noch nett gewarnt, dass das nicht ginge, weil mir das Verzeichnis nicht gehört. Kein Problem, da gibts ja noch den Superuser Account. Angemeldet, Befehl nochmals ausgeführt und zu spät bemerkt, dass sich das Terminal nach der Anmeldung als root im Wurzelverzeichnis / befand. Richtig dumm gelaufen. Jetzt können alle Benutzer Dinge lesen, schreiben und ausführen, auf die sie keinen Zugriff haben sollen. Rückgängig machen kann man das auch nicht. Also was tun? Eine Linux-Konsole ist ja bekanntlich das Schweizer Taschenmesser unter den Terminals, daher gibts bestimmt eine Möglichkeit. Dem ist auch so in Form von getfacl und setfacl. Alles was man noch tun muss, ist einen Rechner zu finden, der einigermaßen die gleiche Distribution und eine möglichst große Menge an gleich installierter Software besitzt. Danach meldet man sich am gesunden System an und sichert die Rechte auf die zu reparierenden Verzeichnisse:

getfacl -R DIR > /tmp/DIR.acl

Die DIR.acl enthält dann die ‘normalen’ Zugriffsrechte des Verzeichnisses ‘DIR’. Diese Datei muss dann aufs zu repariendene System übertragen werden. Dann dort anmelden und per

setfacl --restore=/tmp/DIR.acl

die Rechte in DIR rekonstruieren. Fehlende Dateien und Verzeichnisse werden natürlich ignoriert. Fertig. Alles wieder gut.

Reconstructing Data access rights in Linux

Linux always does as it’s told. And when it’s done, it’s done. Normally, that’s not a bad thing, after all, you know what you’re doing, don’t you? Every now and then, however, it might happen that you make a mistake, and there’s no ?Undo? Button in sight. That is what this article is about. Originally, all I wanted to do is grant access rights (read, write, execute) to one directory and all its subdirectories. 

chmod -R a+rwx DIR

When I first tried this, I was warned that I couldn’t do it because the directory wasn’t mine. No problem, there’s still the Superuser Account. Logged in, executed the command and then realized too late that the the terminal was in the root directory after logging on as root. Tough luck. Now every user can read, write and execute whatever he wants. And there’s no way to undo it either. So what now? A linux console is, as is well known, the swiss army knife of terminals, so surely there’s a way to do it. And of course there is: getfacl and setfacl. All that is left to do is find a computer with roughly the same distribution and as much of the same software as possible. Log onto the ?healthy? system, save the rights for the directories in question:

getfacl -R DIR > /tmp/DIR.acl

DIR.acl now contains the ?normal? access rights for the directory ?DIR?. This file can be transferred to the system that needs repairing. Now log in there and use 

setfacl --restore=/tmp/DIR.acl

to reconstruct the rights in DIR. Missing files and directories will be ignored, of course. And all is well again.

Inside FAU.ORG 2.0

English Version

Der neue Kern von FAU.ORG zeichnet sich durch moderne Technologien, schlankeres Design, verbesserte Modularität und neue Interoperabilität aus. Dieser Artikel stellt die neuen Kernkomponenten aus technischer Sicht vor und gibt einen kleinen Einblick in die Entwicklungsarbeit mit modernen Softwarekonzepten bei P&P.

 

Ein Dinosaurier in neuem Gewandt

Der neue FAU.ORG Kern setzt auf längst Bewährtes auf: relationale Datenbanken. Mit dem Java Content Repository System Jackrabbit als Persistierungs-Backend hatte man zwar Versionierung und dynamische Schemata, es ließen sich Versionen jedoch nur chronologisch geordnet erzeugen. Anders formuliert war es nicht ohne Weiteres möglich in der Vergangenheit zu arbeiten, insbesondere Änderungen der Vergangenheit auf die Gegenwart auswirken zu lassen.

Daher wurde für den neuen Kern ein Konzept entwickelt, was man aus der Videokodierung kennt. Hier werden nicht für jedes Bild (oder auch Frame) des Videos ganze Bilder (Keyframe) gespeichert, sondern nur in bestimmten Abständen. Alle dazwischen liegenden Frames speichern lediglich Änderungungsinformationen von einem Bild zum nächsten. Damit lassen sich die darzustellenden Informationen verlustfrei komprimieren.
In FAU.ORG findet das gleiche Prinzip seine Anwendung.
Der aktuelle Tag liegt immer als vollständige Information in einem klassischen Relationenschema vor. Dabei wurde schlicht davon ausgegangen, dass die meisten Zugriffe auf die Organisationsstruktur zum aktuellen Tag stattfinden und nicht in der Vergangenheit oder Zukunft. Alle Änderungen an Organisationseinheiten werden lediglich als Änderungsinformationen gespeichert. Im Gegensatz zu einem Videocodec allerdings mit dem neuen und dem alten Wert, damit man Zustände von Organisationseinheiten sowohl zeitlich vorwärts als auch rückwärts berechnen kann. Mit dieser Methode ist es möglich geworden, den Zustand des Organisationsbaums zu jedem beliebigen Zeitpunkt zu berechnen. Der Mehraufwand ist dabei verschwindend gering und liefert durch die Verwendung einer relationalen Datenbank mit bedacht gewählten Indizes gute Performance. Die Implementierung verwendet für den Zugriff auf die Datenbank Hibernate, wodurch weitestgehend objektorientierte Datenbankzugriffe verwendet werden konnten und das darunter liegende Datenbanksystem ohne Weiteres ausgetauscht werden kann. Durch Hibernate lassen sich aus einer Datenbank zu ladende Objekte direkt initialisieren, d.h. das Resultat der Abfrage an die Datenbank muss nicht mehr durch den Programmierer in die objektorientierte Welt übersetzt werden, sondern findet im Hibernate Framework selbst statt. Lediglich für die Berechnung eines Zustands in der Vergangenheit oder Zukunft werden die Attributwerte aus den Änderungstabellen geladen und per Java Reflection als Objekte instanziert.

 

Viele kleine Helfer

FAU.ORG wird nicht nur als zentrale Instanz die Organisationsstruktur der Universität Erlangen-Nürnberg verwalten, sondern eine Reihe externer, heterogener Systeme mit den verwalteten Daten provisionieren. Da jede Nacht für den aktuellen Tag der oben beschriebene Keyframe berechnet werden muss, werden gleichzeitig alle Änderungsereignisse, die an diesem Tag gültig werden ausgelesen. Diese Änderungen müssen an die externen Systeme verschickt werden. Um das System später leichter um neue anzubindende Systeme zu erweitern, strebt man eine möglichst generische Architektur an. Daher wurde der neue Kern von FAU.ORG ausschließlich als EJB-Komponenten (Enterprise JavaBean) implementiert. Diese Technologie birgt unter anderem die folgende Vorteile in sich:

  • Implementierung gegen Schnittstellen als Grundlage der Umsetzung
  • losere Kopplung der Komponenten durch kleinere Module, die per Annotationen miteinander verbunden werden können
  • leichteres Neu-Deployen von Komponenten on-the-fly im laufenden Betrieb, wenn Aktualisierungen oder Bugfixes vorliegen
  • einfachere Transaktionsverwaltung out-of-the-box
  • Trennung der Methoden, die durch interne und externe Aufrufe verwendet werden dürfen/können (lokale und entfernte Schnittstelle)
  • andere Projekte aus P&P können diese Komponenten einfach nutzen
  • problemlose Anbindung an einen Enterprise Service Bus (ESB), über den die Exportprozesse für externe Systeme leichter und generischer umgesetzt werden können

Durch die Verwendung von EJBs und dem ESB können Änderungen einfach als Nachrichten über den Bus verschickt und von den verschiedenen Treibern, die externe Systeme anbinden, entgegengenommen und verarbeitet werden. Weiterhin macht diese Methodik die Konfiguration dieser Prozesse einfacher.

 

FAU.ORG setzt also auf Altbewährtes, Aufgebohrtes, Brandneues und lose Gekoppeltes und ist damit gerüstet für alle zukünftigen Aufgaben. 🙂

Inside FAU.ORG 2.0

FAU.ORG’s new core is characterized by its use of modern technologies, a slim design, advanced modularity and new interoperability. This article introduces the new core components from a technical point of view and gives some insight into the developing process with modern software concepts at P&P.

A dinosaur with new clothes.

FAU.ORG’s new core uses a proven system: relational databases. While you already had versioning and dynamic schemata with Java Content Repository System Jackrabbit as a persistance backend, versions could only be created in a chronological order. In other words, you could not simply ?work in the past?, changes in the past with an effect on the present were rather difficult.

So a new concept was created for the core, adapted from video coding. Not every picture (or frame) in the video is saved as a complete picture (or keyframe), instead keyframes are only created in certain intervals. All the frames in between store only changes from one picture tothe next. That way, the information to be displayed can be compressed without loss. FAU.ORG implements the same principle.

The current day always contains the complete information in a classic relational schema. It is assumed that most will access the organisational structure on the current day and not at some point in the past or future. When changes are made to the organisational units, only those changes are stored. The difference to a video codec is that both the new and the old value are saved, so that organisational units’ states can be recreated both forward and backwards in time. With this method, it is possible to create the state of the organisational tree at any point in time. The additional workload is negligible, and by using a relational database with cautiously chosen indices, performance is good. The implementation uses Hibernate for accessing the database, so that most database accesses are object oriented, making sure that the basic database system can easily be exchanged. Hibernate allows direct initialisation of objects loaded from the database, i.e. results from accessing the database do not have to be translated into the object-oriented world, but are used directly within the Hibernate Framework. Attribute values are only loaded from the change tables and instanced via Java Reflection as objects when calculating a state in the future or past.

Lots of little helpers

FAU.ORG is not only going to manage the Universiy Erlangen-Nuremberg’s organisational structure as central instance, it will also provision a number of external, heterogenous systems with the managed data. Since the keyframe mentioned above needs to be constructed every night, all change events relevant for the next day are read. These changes need to be sent to external systems. To ease expansion into new systems later, it was aimed to keep the architecture as generic as possible. FAU.ORG’s core, e.g., was implemented exclusively as EJB components. This technology comes with the following advantages:

  • Implementation against interfaces as basis for the realisation.
  • Loose coupling of components through use of smaller modules, which can be connected via annotations.
  • Easier new deploying of components on-the-fly in a running system, when updates or bugfixes are available.
  • Easier transaction management out-of-the-box.
  • Separation of methods that can be called internally and externally (local and remote interfaces).
  • Other P&P projects can use these components easily.
  • Easy connection to an Enterprise Service Bus (ESB), so that export processes for external systems can be implemented easier and more generically.

By using EJBs and an ESB, changes can be transferred as messages through the bus, and can be accepted by the various drivers that connect external systems. Furthermore, this method makes configuration of the processes easier.

To sum up, FAU.ORG combines things well tried, finely tuned, brand new and losely coupled, and is thus ready for all future tasks.

Friedrich-Alexander-Universität verwaltet ihre Organisationsstruktur jetzt online

English Version

Seit dem 19.01.2010 werden alle Einträge und Änderungen der Organisationsstruktur der Friedrich-Alexander-Universität über die zentrale Webanwendung FAU.ORG online abgewickelt.

Bayerische Hochschulen werden immer stärker in die Pflicht genommen, ihre Zahlungs- und Leistungströme transparent darzustellen. Dies soll durch die Einführung einer bayernweit verbindlichen universitären Kosten- und Leistungsrechnung (KLR) in diesem Jahr erreicht werden, für die wiederum Daten aus den unterschiedlichen Bereichen der Universität zusammengeführt werden. Die KLR setzt eine zentrale Datenbank, die Organisations- und Kostenstellennummern verwaltet voraus. Die technische Implementierung einer entsprechenden webbasierten Anwendung zur Verwaltung der Organisationsstruktur der Friedrich-Alexander-Universität steht im Fokus des Projekts FAU.ORG.

Über die Webanwendung hat derzeit ein noch kleiner Kreis Zugriff auf die Organisationsstruktur der Universität Erlangen-Nürnberg und die Berechtigung zur Datenänderung. Über die E-Mail-Adresse fau.org-support@zuv.uni-erlangen.de eingehende Anfragen und Änderungswünsche werden bearbeitet. Zukünftig werden die Daten automatisiert an die angeschlossenen Systeme übertragen.

Deshalb setzt sich das Projekt FAU.ORG auch in diesem Jahr noch fort. Ein Team aus Mitarbeitern der Zentralen Universitätsverwaltung (ZUV) und des RRZE arbeitet an der Anbindung der Finanz- und Sachmittelverwaltung HIS FSV. Und auch der Identity Management (IdM) Self Service sowie das Informationssystem UnivIS sollen integriert werden. Weitere Systeme folgen nach.

Aktuelle Informationen zur Entwicklung finden Sie hier.

Kontakt

Markus Leber, ORR
Leiter Kanzlerbüro
Markus.Leber@zuv.uni-erlangen.de

Hendrik Eggers
RRZE, Projekte & Prozesse
Hendrik.Eggers@rrze.uni-erlangen.de

Friedrich-Alexander-University introduces online management of organisational structure

Since 19.01.2010, all new entries and changes in the Friedrich-Alexander-University’s organisational structure are conducted online via web application FAU.ORG.

Bavarian universities are increasingly held to make their costs and services transparent. One step in this direction is the introduction of statewide cost and activity accounting (Kosten- und Leistungsrechnung, KLR) for universities. For this, data from various sectors of the university needs to be merged. Using a central database that allows maintenance of organisational numbers and cost units enables KLR to be implemented. FAU.ORG focusses on the creation and technical implementation of a web-based application for managing the Friedrich-Alexander-University’s organisational structure.

So far, a small group of people has access to and permission to change the University Erlangen-Nuremberg’s organisational units. Queries and requests for changes arriving via fau.org-support@zuv.uni-erlangen.de are processed, the resulting data is then transferred to all connected systems.

Project FAU.ORG will continue its work this year. A team consisting of members of the central university management (ZUV) and the RRZE are working on a connection to finance and assets management system HIS FSV. Next in line to be integrated are the Identity Management (IdM) Self Service and the information system UnivIS. Further systems will follow further down the line.

Current information about the development can be found here in the blog.

Contact

Markus Leber, ORR
Head of Chancellor’s office
Markus.Leber@zuv.uni-erlangen.de

Hendrik Eggers
RRZE, Projects & Processes
Hendrik.Eggers@rrze.uni-erlangen.de

Von einer Organisationsstruktur in Raum und Zeit

English Version

Als zentrale Komponente zur Verwaltung der Organisationsstruktur der Universität Erlangen-Nürnberg hat FAU.ORG nun das Release der zweiten Version erreicht. Seit der ersten Version hat sich hier einiges verändert. Die Benutzeroberfläche weist einige Neuerungen und verbesserte Features auf und die Kernkomponente wurde sogar komplett neu entwickelt. Dieser Blogartikel stellt das neue, bessere, schnellere und einfachere FAU.ORG vor.

Neue Datenhaltung

Die neu entwickelte Kernkomponente von FAU.ORG basiert nun auf einer relationalen Datenbank und bietet die folgenden Möglichkeiten:

  • Abbildung der benötigten Informationen in ein geeignetes Entity-Relationship-Schema
  • Persistierung der Daten und Änderungen auf diesen Daten (in separaten Relationen)
  • Unterstützung der temporalen Semantik für die Speicherungen von Änderungen in der Vergangenheit, Gegenwart und Zukunft
  • Volltextsuche in den Daten der Gegenwart

Zunächst wurde aus dem Datenmodell der ersten Version ein Entity-Relationship-Modell (ER-Modell) mit geringen Modifikationen erstellt. Da die meisten Attribute einer Organisationseinheit einwertige Daten enthalten, hätte man nur eine sehr geringe Anzahl an Relationen mit vielen Attributen entwerfen können. Dann wäre es jedoch nicht mehr so einfach gewesen, zusammen gehörende Daten zu gruppieren und später eine feingranulare Zugriffskontrolle auf bestimmte Attributgruppen zu implementieren. Über dies lässt sich mit mehreren Tabellen ein Mechanismus namens Lazy Loading nutzen. Hierbei werden aus der Datenhaltung nicht mehr alle verfügbaren Daten geladen, sondern nur noch das, was der Benutzer gerade benötigt. Das spart Hauptspeicher und ist in den meisten Fällen effizienter.

Neben den Relationen zur Speicherung der eigentlichen Daten, werden in FAU.ORG alle Änderungen von Beginn an auch als Änderungsereignisse in zwei eigenen Tabellen gespeichert. Ein Änderungsereignis bezieht sich auf das Erstellen, Modifizieren und Löschen von Daten einer Attributgruppe. Jedes Änderungsereignis enthält eine Reihe von Änderungseinträgen, die den alten und den neuen Wert des modifizierten Attributs, sowie das Datum der Änderung und das Datum, ab dem die Änderung gültig wird, enthalten. Dadurch ist es möglich in der Zeit zu reisen, da der Zustand jeder Organisationseinheit für jeden beliebigen Zeitpunkt aus dessen Änderungsereignissen berechnet werden kann.

Damit nicht bei jedem Zugriff der Zustand einer Organisationseinheit berechnet werden muss, enthält die Datenbank den Stand der Gegenwart in den eigentlichen Relationen zur Datenhaltung. Diese können schneller ausgelesen werden. Ändert der Benutzer etwas in der Zukunft werden für diese Änderungen lediglich Änderungsereignisse erstellt und gespeichert. Eine eigene Komponente liest jede Nacht die Änderungsereignisse aus, die für den aktuellen Tag gültig werden und setzt diese Änderungen im Stand der Gegenwart um. Damit wird der Zustand in den Tabellen immer up-to-date gehalten. Eine ähnliche Komponente wird in späteren Versionen externe Systeme mit diesen Änderungen provisionieren. Werden die Organisationsdaten in der Vergangenheit geändert, trägt die Datenhaltung diese Änderungen ebenfalls als Änderungsereignisse ein, prüft danach jedoch zusätzlich, ob sich diese Modifikationen auf die Gegenwart auswirken. Dies ist der Fall, wenn das Attribut der betroffenen Organisationseinheit zwischen dem Änderungszeitpunkt der Vergangenheit und dem Stand der Gegenwart nicht noch einmal modifiziert wurde. Die Änderung wird dann dementsprechend in den Relationen der Gegenwart umgesetzt.

Für die Suche wurde in der neuen Datenhaltung wieder eine Volltextindizierung integriert. Das heißt, dass Benutzer nach beliebigen Stichwörtern in allen Attributen suchen können. Die Volltextsuche kann in zukünftigen Versionen so erweitert werden, dass sie auch die Daten der Vergangenheit und Zukunft indiziert.

 

Neue und verbesserte Features in der Weboberfläche

Die Benutzeroberfläche von FAU.ORG hat ebenfalls einige Neuerungen zu bieten. So lassen sich beispielsweise Kontaktdaten, die Anschrift und die Statistikschlüssel rekursiv ändern. Das bedeutet, dass die Änderungen auch bei allen bzw. ausgewählten Kindern dieser Organisationseinheit umgesetzt werden. Das Verschieben von Einheiten ist nun auch problemlos möglich. Der Benutzer muss lediglich eine neue Organisationsnummer vergeben (dazu mehr weiter unten) und die Einheit wird mit allen Kindern im Baum an die entsprechende Stelle verschoben.

An der Benutzerfreundlichkeit der Weboberfläche wurde ebenfalls gearbeitet. Die Übersichtsseite einer Organisationseinheit enthält nun Sprungmarken, damit Benutzer schneller zur gewünschten Information gelangen. Des Weiteren unterstützt FAU.ORG nun die Anmeldung per SSO. Die wichtigsten Funktionen sind nun direkt aus dem Baum der Organisationseinheiten abrufbar. Des Weiteren zeigt der Baum nun die Langbezeichnung der Einheiten, was die Lesbarkeit verbessert.

Für die Integration der temporalen Semantik wurde in die Hauptseite eine Auswahlbox für das Systemdatum eingebaut. Hier wählt der Benutzer das Datum, in dem das System gerade betrieben wird. Damit entscheidet man also, ob man sich in der Vergangenheit, Gegenwart oder Zukunft arbeiten möchte. Die angezeigten Daten entsprechen dem zum ausgewählten Datum gültigen Stand der Organisationsstruktur. Das gewählte Systemdatum wird in allen Seiten in der kleinen Infobox auf der rechten Seite angezeigt.

Die verschiedenen Zustände (oder Versionen) der Organisationseinheiten lassen sich in der Historienansicht abrufen. Hier wird angezeigt, wer die Änderung erstellt hat, wann die Änderung erstellt wurde und zu welchem Zeitpunkt die Änderung gültig werden soll. Diese Ansicht lässt sich auf bestimmte Attributgruppen und Zeiträume filtern. Die Weboberfläche unterscheidet zudem seit der zweiten Version normale und kleine Änderungen. Eine kleine Änderung bezeichnet Modifikationen an den Daten, die lediglich Schreibfehler oder ähnliches betreffen und keine Wertänderung im eigentlichen Sinne darstellen. Kleine Änderungen lassen sich in der Historienansicht ausfiltern, was der Übersichtlichkeit beiträgt.

Das Erstellen von Brücken wird nun vollautomatisch von der Weboberfläche übernommen. Zur Erinnerung: jede Organisationseinheit besitzt eine Organisationsnummer aus fünf zweistelligen Zahlen. Der Organisationsbaum wird nach diesen Nummern aufgebaut und besitzt daher eine maximale Tiefe von fünf Ebenen. Ein Beispiel: der Hauptknoten des RRZE im Baum besitzt die Organisationsnummer 10 11 12 00 00. Dessen Vaterknoten hat dementsprechend die 10 11 00 00 00. Es kann nun vorkommen, dass ein Knoten einem Vaterknoten zugeordnet ist, der mehr als eine Ebene höher im Baum liegt. Mit anderen Worten überspringt ein Kind damit eine oder mehrere Ebenen. Der Datenmanagement-Lehrstuhl der Informatik besitzt beispielsweise die 15 13 00 16 00 und überspringt die dritte Ebene im Baum. Damit der Baum keine Lücken aufweist, existieren an diesen Stellen besondere Knoten, sogenannte Brücken (hier die 15 13 00 00 00), die als letzte definierte Stelle in der Organisationsnummer eine Doppelnull besitzen. Das Erstellen von Brücken wird in der zweiten Version nun vollkommen automatisch übernommen, sobald eine Brücke benötigt wird. Brücken werden ebenfalls automatisch gelöscht, falls sie keine Kinder mehr besitzt.

 

Zu den technischen Finessen werde ich im nächsten Blog-Artikel einen tieferen Einblick in die Umsetzung der Version 2 liefern.

RRZE ? Projects & Processes (P&P): An organisational structure in space and time

An organisational structure in space and time

The University Erlangen-Nuremberg’s central component for managing its organisational structure, FAU.ORG, has released its second version. There have been quite a few changes since the first version was originally released. Several improvements have been made to the user interface, improved features have been added and a new core component has been developed. This articles introduces the new, better, faster and easier-to-use FAU.ORG.

New Data management

FAU.ORG’s newly developed core component is now based on a relational database and offers the following:

  • Mapping the necessary information in a suitable entity relationship schema
  • Both persistance of data and changing the data (in separate relations)
  • Supporting temporal semantics for saving changes in the past, present and future.
  • full-text search in present data.

First, an entity relationship model (ER-model) was created from version 1’s data model with only a few changes. As most of the organisational units’ attributes only contain single values, a system with only few relations and a large number of attributes would have been possible. This would have impeded both the grouping of data belonging together, and a later implementation of access control for attribute groups. Use of several tables also allows use of a method called Lazy Loading. With this method, not all available data is loaded from data storage, but only the items the user needs at the moment. This saves memory and is more efficient in most cases.

In addition to saving the actual data, all changes in FAU.ORG are saved as change events in two tables. A change event is given when an attribute group is created, modified or deleted. Every change event contains a number of change entries with the old and new value of the modified attribute, date of the change and the date the change becomes active. This makes ?time travel? possible, as the state of every organisational unit at any point in time can be recreated from these change events.

To avoid having to create the state of an organisational unit with every access, the database contains the present state in the relations for data storage, as these can be read faster. If a user changes something in the future, change events are created and saved. A separate component reads these change events every night, selects those that become active the next day and includes them in the present state. That way, the tables are kept up to date. A similar component will later provision external systems with these changes. If organisational data is changed in the pats, data storage also enters these changes as change events, but then goes on to check if the modification affects the present state. That is the case if the attribute of the organisational unit in question is not modified again between the time of change in the past and the present state. Then, the change is included in the present relations.

For searching, the new data storage has been provided with a full-text index. That allows the user to search for keywords in all attributes. This can be expanded in future versions to allow indexing of past and future data.

New and improved features in the web interface

There are several improvements in FAU.ORG’s user interface as well. Recursive changing of contact data, mailing address and statistical keys is now possible, allowing changes for all or selected children of an organisational unit. Moving units is also much easier now. The user only needs to enter a new organisational number (more on this further down), and the unit and all its children are moved to a new place in the tree.

The website is now much more user-friendly. The starting page contains new jump labels, allowing users to get to the wanted information more easily. Furthermore, FAU.ORG now supports SSO login. The most important functions are available directly from organisational unit tree. The tree also uses the long description of units now, improving readability.

For better integration of the temporal semantic, the main page now features an entry box for the system date. Here, the user can chose the date at which the system runs. That way, you can chose whether to work in the past, present and future. The data displayed matches the organisational structure valid at the selected date. The system data chosen is always displayed in an info box on the right side of the screen.

The organisational units’ different states (or versions) can be selected in the history view. Here you can see who entered a change, and at what time that change will become active. Filters for attribute groups and time periods can be used in this view. The web interface also differenciates between normal and small changes. A small change indicates minor modifications to data like fixed spelling mistakes. They do not normally represent real changes to the values themselves. These small changes can be filtered out in the history view.

Bridges are now created automatically by the web interface. A reminder: Every organisational unit has its own organisational number, consisting of five two-digit numbers. The organisational tree is created from these numbers and accordingly has a maximum depth of five levels. E.g.: The RRZE’s main node in the tree is organisational number 10 11 12 00 00. Its father node is therefore 10 11 00 00 00. It is possible, however, for nodes to be attached to a father node that is more than one level higher up the tree. In other words, the child jumps one or more levels. Since the tree cannot have any ?gaps? special nodes, so called bridges, are entered in these places. Their last defined digit ist 00 (in our example 15 13 00 00 00). These bridges are now created automatically when they are needed. They are also deleted automatically if they do not have any children.

For the finer technical details, I will use the next blog article to give some insight into version 2’s implementation.

Icon Inspector / GTK Icon Inspector

English Version

Neues Verwaltungstool für Icon-Sammlung

Zusätzlich zu dem vom Regionalen Rechenzentrum Erlangen (RRZE) der Friedrich-Alexander-Universität entworfenen eigenen Icon-Satz, der zur freien Nutzung im Internet angeboten wird, gibt es nun auch einen sogenannten Icon Inspector, der die kleinen "Bildchen" verwaltet.

Unter der Haube des Icon Inspectors steckt weit mehr, als mit der ursprünglich geplanten einfachen Icon-Übersicht für das RRZE Icon Set Projekt geplant war. Neben einer ansprechenden, tabellarischen Aufbereitung der zur Verfügung gestellten Symbole, inklusive alphabetischem Index und Ankern zur direkten Verlinkung wartet der Icon Inspector mit zahlreichen nützlichen Funktionen auf. So behält er zum Beispiel den Inhalt und Aufbau der Ordnerstruktur im Auge, um die Icon-Designer bei ihrer Arbeit und der Einhaltung der Icon Set Richtlinien zu unterstützen. Darüber hinaus wird bei jedem Inspektionslauf überprüft, ob jedes Icon in allen benötigten Skalierungsgrößen vorhanden ist und welche skalierten Icons nicht als skalierbare Vektorgrafik (Scalable Vector Graphics, kurz SVG) vorliegen, was meist auf Tippfehler schließen lässt. Außerdem kontrolliert der Icon Inspector, ob die Metadaten der Inkscape-SVG-Dateien existieren und den Vorgaben entsprechen und ob alle Bilddateien korrekt in die Ordnerstruktur eingeordnet wurden.

Ermittelte Probleme werden in einer Logdatei protokolliert und lassen sich dann nacheinander beheben. Um fehlende Skalierungsgrößen automatisch aus den Scalable Vector Graphics zu generieren, kann sich der Icon Inspector auf Wunsch eines installierten Inkscapes bedienen. Damit wird Entwicklern das eintönige "Durchskalieren" jedes neu erstellten Icons erspart. Darüber hinaus ist der Icon Inspector bereits in der Lage, mit mehreren Detailstufen ein und desselben Icons umzugehen. Für den problemlosen Einsatz mit gängigen Versionsverwaltungstools werden Nicht-Bilddateien und hier insbesondere versteckte SVN- und CVS-Verzeichnisse vom Icon Inspector standardmäßig ignoriert.

Der komplett in PHP programmierte Icon Inspector kann mittels mitgelieferter Startskripte einfach von der Kommandozeile aufgerufen werden. Die Konfiguration erfolgt wahlweise über Kommandozeilenparameter, eine config.php-Konfigurationsdatei oder beim Einsatz der GIMP-Toolkits direkt in der grafischen Oberfläche.

Weitere Informationen

Kontakt

Florian Löffler
Stabsstelle Projekte & Prozesse
florian.loeffler@rrze.uni-erlangen.de

New Icon manager for Icon collection

In addition to the Icon set created by the Friedrich-Alexander-University’s Regional Computing Centre Erlangen, which is freely available for use, there is now the Icon Inspector to manage all the little "pictures".

The Icon Inspector manages a lot more than what was originally planned, i.e. a simple icon overview for the RRZE Icon Set Project. In addition to an attractive, tabular view of the available symbols with alphabetic indec and anchors for direct links, the Inspector has several other useful functions. It keeps an eye on your folders content and structure, to make it easier for icon designers to keep to the Icon Set guidelines. It also tests availability of the necessary scaling sizes with every inspection run, and notes which icons are not available as scalable vector graphics. It also checks if metadata for Inkscape SVG files is available and in keeping with the guideline, and whether the picture files are in their correct folder.

Any uncovered problems are saved in a log file and can then be dealt with. To generate missing sizes, the Icon Inspector is able to use an installed version of Inkscape if wanted. This saves developers from the boring work of "Scaling" every single new icon. Furthermore, the Inspector is able to deal with several levels of detail for every icon. To make use with subversion tools easier, non-picture files and especially hidden SVN and CVS folders are generally ignored.

Icon Inspector has been programmed in PHP completely and can be run from the commandline using the start scripts that come with it. Configuration can be done either via commandline parameter, a config.php configuration file or directly in the graphic interface when using the GIMP toolkit.

Further Information

Contact

Florian Löffler
Stabsstelle Projekte & Prozesse
florian.loeffler@rrze.uni-erlangen.de

14 Tage Single …

English Version

… Sign-On


Am Mittwoch, dem 14.10.2009, ging der Zentrale Anmeldedienst der Universität Erlangen-Nürnberg online. Dabei handelt es sich um ein sog. Single Sign-On (kurz: SSO) für Web-Anwendungen.

Für eine Was-bringt-mir-das-Übersicht wird auf die dazugehörige Pressemeldung verwiesen. Für alle die einen Blick hinter die Kulissen werfen wollen, soll eine kleine Serie von Blogbeiträgen die technischen Grundlagen und die gewonne Erfahrung vermitteln.

Identity Management

Grundlage für ein SSO-System ist ein funktionierendes Identity Management (kurz: IdM). Ein IdM-System provisioniert alle aktuell gültigen Benutzerkonten in die Datenhaltung des SSO-Systems. Durch eine event-basierte Aktualisierung wird sichergestellt, dass immer der IST-Zustand im SSO-System vorliegt. Benutzer welche die Universität verlassen, sind am nächsten Tag nicht mehr im SSO-System zu finden.

Im vorliegenden Fall provisioniert IdM einen OpenLDAP-Server. Dabei werden alle Benutzerkonten in einen Container unter
ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
geschrieben. Ein typischer Eintrag könnte wie folgt aussehen:

dn: uid=ddummy,ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: eduPerson
objectClass: dfnEduPerson
objectClass: fauSsoPerson
objectClass: schacPersonalCharacteristics
objectClass: schacLinkageIdentifiers
cn: Dolly Dummy
displayName: Dolly Dummy
eduPersonAffiliation: student
eduPersonAffiliation: employee
eduPersonOrgDN: dc=uni-erlangen,dc=de
eduPersonPrincipalName: ddummy@uni-erlangen.de
eduPersonScopedAffiliation: student@uni-erlangen.de
eduPersonScopedAffiliation: employee@uni-erlangen.de
givenName: Dolly
mail: Dolly.Dummy@rrze.uni-erlangen.de
o:: RnJpZWRyaWNoLUFsZXhhbmRlci1Vbml2ZXJzaXTDpHQgRXJsYW5nZW4tTsO8cm5iZXJn
schacGender: 2
schacPersonalUniqueCode: urn:mace:terena.org:schac:personalUniqueCode:de:uni-erlangen.de:Matrikelnummer:1234567
sn: Dummy
uid: ddummy
userPassword:: e1NTqEF9e3Ew3UdwY1crMFdPc3hwaGo3UVpNTtFIdnFJcoJ6ZGg=

Ein Eintrag enthält neben dem Benutzernamen (uid) und dem Passwort in SSHA-gehashter Form (userPassword) weitere Attribute zum Benutzerkonto.

Benutzername und Passwort dienen natürlich der Authentifizierung des Benutzers am SSO-Dienst. Die anderen Attribute können grob in zwei Kategorien unterteilt werden.

  1. Attribute zur Personalisierung von Anwendungen
  2. Attribute zur Autorisierung

Attribute der ersten Kategorie sollen es der Anwendung z.B. ermöglichen die korrekte Anrede (z.B. displayName oder schacGender) zu finden oder die Person hinter dem Benutzerkonto per E-Mail zu erreichen (mail).

Attribute der zweiten Kategorie dienen der Anwendung zum Setzen von unterschiedlichen Berechtigungen. Z.B. kann Anwendung A nur Studenten (eduPersonAffiliation: student) Zugriff auf einen bestimmten Bereich erlauben.

Im ersten Beitrag dieser Serie wurde die Anbindung des SSO-Systems an das vorliegende IdM beschrieben. Im nächsten Schritt wird der sog. Identity Provider, also die zentrale Komponente des SSO-Dienstes, betrachtet. Zur Überbrückung gibt es noch eine kleine Statistik:


Anmerkung:
Der Graph zeigt die Logins pro Stunde der einzelnen Service Providers übereinander angeordnet

14 Days Single…

… Sign-On


On wednesday 14.10.2009 the  Central Login Service of the Univesity of Erlangen-Nuremberg went online. This so called Single Sign-On (short: SSO) is used for web logins.

For a What-do-I-get-out-of-it-overview read the corresponding Press Report. For a peek behind the scenes a small series of blog entries should give the technical basic knowledge and the earned experience.

Identity Management

Basis for the SSO-System is a functioning Identity Management (short: IdM). An IdM-System comissions every recently valid user account in the data management of the SSO System. Through a event based update all the time the as-is state is secured. Users who leave the university are no longer to be found in the SSO System the next day.

In the following case IdM comissions an OpenLDAP-Server. Here every user account is written into one container under:
ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de

A typical entry could look like following:

dn: uid=ddummy,ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: eduPerson
objectClass: dfnEduPerson
objectClass: fauSsoPerson
objectClass: schacPersonalCharacteristics
objectClass: schacLinkageIdentifiers
cn: Dolly Dummy
displayName: Dolly Dummy
eduPersonAffiliation: student
eduPersonAffiliation: employee
eduPersonOrgDN: dc=uni-erlangen,dc=de
eduPersonPrincipalName: ddummy@uni-erlangen.de
eduPersonScopedAffiliation: student@uni-erlangen.de
eduPersonScopedAffiliation: employee@uni-erlangen.de
givenName: Dolly
mail: Dolly.Dummy@rrze.uni-erlangen.de
o:: RnJpZWRyaWNoLUFsZXhhbmRlci1Vbml2ZXJzaXTDpHQgRXJsYW5nZW4tTsO8cm5iZXJn
schacGender: 2
schacPersonalUniqueCode: urn:mace:terena.org:schac:personalUniqueCode:de:uni-erlangen.de:Matrikelnummer:1234567
sn: Dummy
uid: ddummy
userPassword:: e1NTqEF9e3Ew3UdwY1crMFdPc3hwaGo3UVpNTtFIdnFJcoJ6ZGg=

An entry is given an username (uid) and a password in SSHA-hashed form (userPassword) and further attributes of the user account.

Username and password ´are of course used to authentificate the user in the SSO Service. The other attributes can be differentiated into two categoies.

  1. Attribute for personalising of applications
  2. Attribute for authorisation

Attributes of the first categorie should make it for example possible for the application  to find the correct form of address  or to reach the person behind the user account via email (mail).

Attributes of the second categorie are used for the application to set different rights. For example the application A gives only students  (eduPersonAffiliation: student)the right to use a specific part of the application.

In the first article of this serial the connection with the SSO System is shown. In the next step the so called Identity Provider, the central component of the SSO service is described. To bridge these two, here is a small statistic:


Note:
The graph shows the logins per hour of each and every provider one upon the other.

Volker Buzek

Foto Volker Buzek

Projektmanager und IT-Architekt mit Schwerpunkt webbasierten Applikationen (-> XING), im echten Leben gerne 1..n Kombination aus Sport, Jazz, Motorrad, Film&Literatur, gutem Essen und Getränken.

Über den C128 und Elite in den IT-Bereich gelangt; später mit Hilfe von Stefan Münz den ersten Webentwicklungs-Job gelandet. Nach Lehr- und Wanderjahren durch Webtempel im In- und Ausland, 2004 am RRZE angekommen. Zuerst das Webteam verstärkend und Kurse haltend das Sügelände heimgesucht, anschließend 2007 in den Campus IT (CIT)-Fahrersitz gesetzt worden; in Kürze das CIT-Folgeprojekt übernehmend.

(Volker Buzek hat zum 30.09.2010 die FAU und P&P verlassen.)

Refactoring WAID

WAID is build-up of various, separately developed, components which are combined in a monolithic application. The application is structured and deployed as a single web application archive(war). The above mentioned components are of different granularity and perform tasks related to business logic, data fetching, presentation, transformation and so on. Refer to Fig.1 for a simplified diagram:

Architektur (Komponenten) von WAID

Splitting the application into small parts during the development cycle proved to be more than useful for code maintenance and rapid on-demand changes. Similar component-based approach is now proposed for the runtime structure of the application. The idea is to break up the application into smaller business-logic-based parts which can be easily exchanged during runtime without or with insignificant downtimes. Downtimes should occur only at redeployment of components which are directly related to user sessions. The exchange of all other underlying components should happen transparent to the users of the application. A simplified version of WAID’s current runtime architectural design can be seen on Fig.2. The application is started by deploying the web application archive into a JBoss AS. The JBoss server initializes a Spring (springframework) context, which is depicted by orange on Fig.2. The Spring framework is responsible for linking together the different runtime components. The most important component is idmone-core. This module is itself a Spring project which is developed separately and is responsible for the back-end functionality related to interacting with MetaDirectory. This project is only configured and used within the web application. Security is provided by the spring-security module, which is not shown on the Fig.2 but it closely couples with the Tapestry module, so these are represented by a single block. The Tapestry module is responsible for rendering the web page templates. Other required components are added within the Spring context to provide additional functionality. The pdf-generator module is shown on Fig.2 as an example of these type of components. The current implementation is focused on combining different projects into a single web application. The Spring framework provides the necessary flexibility and configuration options. The newly proposed component paradigm does the same but at runtime. Components are bound together when requested and not at initialization time. This allows for changing the underlying components implementation without re-deployment of the dependent applications. This would also allow for a better load distribution because different components can run on different machines. Generating pdf files, for example, can consume quite a lot of CPU cycles and memory. Distributing components to different machines can provide better performance but at the same time can make components reusable. Thus it would be possible to share a runtime component between applications – for example, pdf generation utilities can be used by several applications. An additional advantage is that in case of a bug fix only a single instance of a component is to be replaced. This would clearly prevent repackaging all applications that use it.

Struktur von WAID vor Refactoring

At the same time the proposed paradigm enables a major conceptual shift to Service Oriented Architecture(SOA). To put it short, the idea is instead of combining smaller projects into bigger applications, to start building up composite applications. These will consist of different runtime-bound services. The services will provide distributed business logic instead of packaged functionality. Once a certain degree of “service orientation” is achieved it would be possible to start using enterprise integration design patterns to accommodate better communication between the different systems involved. A proof of concept has been developed and a schematic view of the proposed solution is shown on Fig.3.

WAID Struktur nach Refactoring

At first glance there is not much of a difference. However, the yellow components are Enterprise Java Beans(EJBs) and run outside the web application. These can be looked up by the web application and used. EJBs have two type of interfaces local and remote. On the figure the local interface is depicted in pale blue and is the one connected with WAID. Technically this type of interface is used in the case when both modules run within the same application server, thus enabling data exchange with better performance. Although idmone-core exposes its functionality in the form of EJBs these are still initialized by a Spring context, depicted with green on Fig.3. Several developers share the opinion that Spring and JEE are excluding and competing standards but in our case these seem to form a symbiosis.

At the same time a proposal is evaluated to deploy the application as an exploded war file to accommodate on-the-fly changes. This proposal is done for the purpose of fixing typos, translation errors and similar. The same technique was tested, as a proof of concept, for implementing complex changes such as registering or unregistering existent Tapestry components on a page. So far , the concept seems useful but raises questions related to stability, reliability and can lead to inconsistencies if not thoroughly thought through. By inconsistencies are meant different versions of code on the productive system and the one tagged in the repository. In emergency cases there exists the possibility that updates are introduced in the productive system and these are later not propagated into the source code. In general managing a single web application archive seems to be a better way of handling tagging. Thus a system restore can be done by copying a single file instead of hundreds of small ones. This operation is also much more time efficient in the above mentioned case. At the time being, deploying WAID as an exploded archive is not considered harmful. However, unless the above mentioned issues are properly address and tested, changes of files under the exploded directory is granted only in exceptional situations.

Eine neue Struktur für WAID

WAID besteht aus verschiedenen, unabhängig entwickelten Komponenten, zusammengefügt zu einer monolithischen Anwendung. Diese Anwendung wird als einfaches web application archive (war) strukturiert und entwickelt. Die oben genannten Komponenten haben unterschiedliche Granularität und erfüllen Aufgaben im Zusammenhang mit Business Logic, Datensammlung, Präsentation, Transformation und so weiter. Abb.1 zeigt ein vereinfachtes Diagramm:

Architektur (Komponenten) von WAID

Die Aufteilung der Anwendung in kleinere Teile erwies sich als vorrteilhaft für Codepflege und schnell gewünschte Änderungen. Eine ähnliche komponentenbasierte Herangehensweise bietet sich nun für die Laufzeitstruktur der Anwendung an. Die Idee besteht darin, die Anwendung in kleinere, auf Business Logic basierende Einheiten aufzubrechen, die einen einfachen Austausch während der Laufzeit erlauben, entweder ganz ohne, oder zumindest mit vernachlässigbaren Ausfallzeiten. Ausfälle sollten nur bei einer Umstrukturierung von Komponenten stattfinden, die direkt mit den Nutzer-Arbeitssitzungen zu tun haben. Änderungen an allen anderen zugrundeliegenden Komponenten sollten so geschehen, dass sie für die Nutzer der Anwendung transparent sind. Eine vereinfachte Version der aktuellen WAID Laufzeitarchitektur ist in Abb.2 dargestellt. Die Anwendung wird gestarted, indem das Webanwendungsarchiv in eine JBoss AS übertragen wird. Der JBoss Server initialisiert einen Spring Kontext, der in Abb.2 orange dargestellt ist. Das Spring framework ist dafür verantwortlich, die verschiedenen Laufzeitkomponenten zu verbinden. Die wichtigste Komponente ist idmone-core. Das Modul ist selbst ein unabhängig entwickeltes Spring Projekt, verantwortlich für die Back-end Funktionalität im Zusammenhang mit der MetaDirectory-Interaktion. Das Projekt wird nur innerhalb der Webanwendung konfiguriert und genutzt. Sicherheit wird durch ein Spring Security Modul gewährleistet. Dieses Modul ist in Abb.2 nicht gezeigt, es ist jedoch eng an das Tapestry Modul gekoppelt, so dass beide durch einen einzelnen Block dargestellt werden. Das Tapestry Modul ist für das Rendern der Web page templates verantwortlich. Andere benötigte Module werden innerhalb des Spring Kontextes hinzugefügt, um zusätzliche Funktionalität bereitzustellen. Das pdf-Generator Modul in Abb.2 dient als Beispiel für diese Art Komponente. Der Fokus der momentanen Implementierung liegt darauf, die verschiedenen Projekte zu einer einzigen Webanwendung zusammenzubringen. Das Spring Framework bietet die dafür nötige Flexibilität und die entsprechenden Konfigurationsmöglichkeiten. Das kürzlich vorgeschlagene Komponentenmodell erfüllt die gleiche Aufgabe auf der Laufzeitebene. Komponenten werden erst auf Anfrage zusammengefasst, und nicht bereits bei der Initialisierung. Dies erlaubt es, die zugrundeliegenden Komponenten auszutauschen, ohne alle abhängigen Komponenten erneut übertragen zu müssen. Es macht zudem eine bessere Lastverteilung möglich, da die jeweiligen Komponenten auf unterschiedlichen Servern laufen können. PDF-Dateien zu generieren, beispielsweise, kann eine Menge CPU-Zeit und Arbeitsspeicher belegen. Durch die Verteilung der Komponenten auf verschiedene Rechner kann sowohl eine bessere Performance, als auch eine Wiederbenutzbarkeit der einzelnen Komponenten erreicht werden. Dadurch wäre es möglich, Laufzeitkomponenten mit verschiedenen Anwendungen zu nutzen – Dienstprogramme für die pdf-Generierung beispielsweise können von mehreren Anwendungen genutzt werden. Ein weiterer Vorteil liegt darin, das bei einem Bugfix nur eine einzige Instanz der Komponente ersetzt werden muss. Dadurch würde verhindert, alle Anwendungen neu packen zu müssen, die die Komponente nutzen.

Struktur von WAID vor Refactoring

Gleichzeitig ermöglicht das vorgeschlagene Modell eine wichtige Konzeptverschiebung hin zur dienstorientierten Architektur (Service Oriented Architecture, SOA). Kurz gesagt besteht die Idee darin, Kompositanwendungen zu bauen anstatt kleine Projekte zu großen Anwendungen zusammenzufassen. Diese Kompositanwendungen werden aus verschiedenen Laufzeitgebundenen Diensten bestehen. Die Dienste stellen eine dezentralisierte Business Logik zur Verfügung anstelle einer fertig gepackten Funktionalität. Sobald ein gewisser Grad der “Dienstorientierung” erreicht ist, würde es möglich werden, Unternehmensintegrations-Muster zu nutzen, um eine bessere Kommunikation zwischen den verschiedenen involvierten Systemen zu erreichen. Eine Machbarkeitsstudie ist bereits entwickelt worden und eine schematische Übersiccht der vorgeschlagenen Lösung ist in Abb.3 zu sehen.

WAID Struktur nach Refactoring

Auf den ersten Blick ist kein großer Unterschied zu sehen. Die gelben Komponenten sind jedoch Enterprise Java Beans (EJBs), die ausserhalb der Webanwendung laufen. Sie können von der Webanwendung aufgerufen und genutzt werden. EJBs haben zwei Arten von Schnittstellen, lokal oder remote. In der Darstellung ist die lokale Schnittstelle hellblau dargestellt, verbunden mit WAID. Technisch gesehen wird diese Art der Schnittstelle genutzt, wenn beide Module innerhalb der gleichen Anwendung laufen, um einen Datenaustausch mit besserer Performance zu erreichen. Obwohl idmone-core seine Funktionalität in Form der EJBs offenlegt, werden sie trotzdem durch einen Spring Kontext initialisiert, in Abb.3 dunkelgrün dargestellt. Mehrere Entwickler sind der Meinung, dass SPRING und JEE sich gegenseitig ausschließen und miteinander konkurrieren. In unserem Fall bilden sie jedoch anscheinend eine Symbiose.

Zur gleichen Zeit wird ein Vorschlag bewertet, die Anwendung als entpackte .war Datei einzusetzen, um “fliegende” Änderungen möglich zu machen. Ziel des Vorschlages ist ein vereinfachtes Verbessern von Schreibfehlern, Übersetzungsfehlern und Ähnlichem. Die Technik wurde als Machbarkeitsstudie bei der Umsetzung komplexer Änderungen erprobt, wie dem Registrieren und Entfernen existierender Tapestry Komponenten auf einer Seite. Bisher erscheint das Konzept brauchbar, es wirft jedoch Fragen in Bezug auf Stabilität und Zuverlässigkeit auf, und kann zu Inkonsistenzen führen, wenn es nicht gründlich genug durchdacht ist. Inkonsistenzen beziehen sich in diesem Zusammenhang auf verschiedene Code-Versionen im Produktivsystem und dem Repository. In Notfällen besteht die Möglichkeit, dass Updates im Produktivsystem eingefügt werden, dann aber nicht in den Code übernommen werden. Generell erscheint für die Handhabe des tagging eine einzelne Webanwendung besser geeignet, da eine Systemmwiederherstellung in diesem Fall durch das Kopieren einer einzelnen Datei einfacher ist als durch Hunderte kleiner Dateien. Die Operation verläuft ebenso deutlich effizienter im oben genannten Fall. Zum gegenwärtigen Zeitpunkt wird der Einsatz von WAID als entpacktes Archiv als nicht schädlich beurteilt. Solange jedoch die oben genannten Schwierigkeiten nicht ordentlich angegangen und getestet worden sind, sind Dateiänderungen im entpackten Verzeichnis nur in Ausnahmesituationen gestattet.

Neue Funktion im IdM Self-Service

English Version

Vergessenes Passwort kann ab sofort über E-Mail-Adresse zurückgesetzt werden

Eine neue Funktion erleichtert im IDM Self-Service (WAID) künftig das Vorgehen bei vergessenem Passwort. Zusätzlich zu den Sicherheitsfragen hat der Benutzer nun die Möglichkeit, eine beliebige E-Mail-Adresse zum Zurücksetzen des Passwortes zu hinterlegen. Zur Aktivierung dieser Funktion muss die hinterlegte E-Mail-Adresse einmalig bestätigt werden. Hierfür erhält der Benutzer an die eingetragene Adresse eine E-Mail mit einem Link, den er innerhalb von 24 Stunden anklicken muss.

Bei vergessenem Passwort kann der Nutzer dann eine E-Mail an die angegebene Adresse anfordern und das Passwort durch Anklicken des darin enthaltenen Links innerhalb von 24 Stunden neu setzen. Das Rücksetzen des Passwortes über die Sicherheitsfragen ist trotz der neuen Funktion nach wie vor möglich.

Leider erfolgt die Kommunikation zwischen E-Mail-Servern prinzipiell unverschlüsselt. Die neue Funktion ist daher vor diversen Attacken (sogenannte “man-in-the-middle-Attacken”) nicht geschützt und birgt die (allerdings geringe) Gefahr, von Dritten missbraucht zu werden.

Das am häufigsten zu erwartende Problem wird leider nicht zu umgehen sein: Eine nicht existente oder nicht zustellbare externe Mailbox.

New Function in IdM Self-Service

Forgotten password can now be put back via e-mail address.

A new function makes the process of a forgotten password easier in the IdM Self-Service (WAID). Additionally to the safety questions the user is able to deposit any e-mail address to put back the password. For the activation of this function the deposited e-mail address needs to be confirmed once. Therefore the user will receive an e-mail with a link to the deposited address which needs to be clicked within 24 hours.

In case of a forgotten password the user can request an e-mail to the deposited address and can, within 24 hours, set a new password by clicking the link in the e-mail. The password can still be reseted with the safety questions.

Unfortunately the communication between the e-mail servers happens uncoded. Therefore the new function is not protected from different attacks (so called “man-in-the-middle-attack”) and has also the risk to be abused by thirds.

The most likely problem that can not be avioded: a non existing or not reachable extern mail box.

Aktuelles zum neuen Dienstleistungsportfolio

Bezugnehmend auf ITIL wurde eine Struktur erstellt, in die alle Dienstleistungen eingetragen werden können. Das Medium, das gewählt wurde ist das Wiki – zum Einen, weil es einfach zu bedienen ist und zum Anderen, weil es ein schon etabliertes Tool am RRZE ist, mit dem der größte Teil der Mitarbeiter bereits vertraut ist. Eingesetzt wird eine mediawiki-Installation.

So wird nun jede Dienstleistung in einer eigenen Beschreibung (sogenannte DL-Beschreibung) dargestellt. Dies erhöht Vergleichbarkeit und Übersichtlichkeit und macht es u.a. für den Support einfacher Informationen, die benötigt werden zu finden.

In Zusammenarbeit mit der Redaktion des RRZE wurde am Beispiel der DL-Beschreibung "Rechnertechnik" ein ausformulierter Text entworfen, der als Beispiel dient und an dessen Form sich alle anderen Texte orientieren sollen. Außerdem wurden Leitfragen formuliert, die die Autoren der DL-Beschreibungen bei der Abfassung "Ihrer" Beschreibungen unterstützen.

Die Struktur des gesamten Portfolios ist noch im Entstehen und wird sowohl den Bedürfnissen und Wünschen der Mitarbeiter als auch den strukturellen Gegebenheiten am Regionalen Rechenzentrum angepasst. Somit wird auch die Vorlage für die DL-Beschreibung iterativ weiter entwickelt.

Der Transfer aus der Mind Map in diese neue Struktur gestaltet sich sehr aufwändig. So wurde als notwendig erkannt, über die bereits in der Mind Map erfassten Informationen hinaus, weitere Details der DL-Beschreibung hinzuzufügen, um den benötigten Informationsumfang "zusammen zu bringen". Diese werden aus den RRZE-Webseiten, Schriftstücken oder mündlichen Informationen von mir zusammen getragen und in das Wiki eingepflegt. Je nach Bereich ist der Aufwand hierfür sehr unterschiedlich. Von einigen Abteilungen wurden bereits in den Workshops die erbrachten Dienstleistungen fast vollständig in der Mind Map erfasst, bei anderen dagegen weisen sie große Lücken auf. Auch ist die durch die Form der Mind Map entstandene Baum-Struktur her nicht – oder nicht mehr – passend. Einige Dienstleistungen haben sich seit den Workshops vollständig geändert.
Hier zeigt sich, dass die Wahl des Mediums "Wiki" sehr sinnvoll ist, denn so können die zuständigen Mitarbeiter und Abteilungsleiter "ihre" Dienstleistungsinformationen an zentraler Stelle einfach und intuitiv selbst pflegen und aktuell halten.

Besonders positiv fällt in dieser Phase auf, dass trotzt der vergangenen Zeit und der in die Workshops investierte Zeit der Großteil der RRZE-Mitarbeiter an dieser Stelle sehr engagiert ist. Nach Information über das neue Schema und die Hintegründe tragen sie mit schriftlichen Informationen und in Gesprächen viel dazu bei, dass Dienstleistungsportfolio zu entwickeln und damit eine gemeinsame Informationsbasis für Alle zu schaffen, die insbesondere dem Support die Arbeit erleichtern wird.

Zudem haben wir festgestellt, dass es von besonderer Bedeutung ist, Begriffe genau zu bestimmen, so dass ein einheitliches Verständnis davon entsteht worüber "man" redet. Zu diesem Zweck wurde ein Glossar angelegt, auf das aus den Texten verlinkt wird, wenn ein Fachbegriff gebraucht wird. So kann jeder nachlesen, was mit genau diesem Begriff gemeint ist. An dieser Stelle wurden wir tatkräftig durch Bastian Melsheimer unterstützt, der u.a. auch dafür gesorgt hat, dass auch eine englische Übersetzung des Glossars verfügbar ist.

News from the service portfolio

Referring to ITIL, we created a structure into which all services can be entered. We decided to use a Wiki interface – because it is both easy to use, and already widely used by most of the RRZE’s staff. We decided to use a mediawiki installation.

Every service is displayed with its own description, the so-called DL-description. This increases both comparability and clearness, and makes it easier for support to find needed information.

Together with the RRZE’s editorial department we used the DL description for the entry “Rechnertechnik” to draft a text that should be used as guideline for all further texts. We also formulated central questions to help the DL descriptions’ authors with their writing.

The portfolio’s structure is still developing, and will be adapted for both requirements and the staff’s wishes, as well as for structural circumstances at the regional computing centre. That means that the DL descriptions’ template will also be developed iteratively.

Transferring data from the mind map to this new structure proved to be rather complex. It was deemed necessary to add further details to the information gained from the mind map, in order to gather the amount of information needed for the DL description. These details were taken from the RRZE website, publications and oral information, and were entered into the Wiki. The effort for this varies significantly, and depends largely on the area. Some departments have already collected most of the necessary service data during their workshops, while others are still missing large parts of the information. In addition, the tree structure used due to the mind maps form is not – or no longer – adequate. Some services have changed completely since the workshops.

Using the medium “Wiki” proved to be a good choice, since it allows the responsible staff and heads of departments to maintain their service information centrally and keep it up to date.

What stands out positively at this stage is the RRZE staff’s commitment, despite the time that has passed and the time that was invested into the workshops. After being informed about the new schema and background, they contributed to both the service portfolio’s development and the creation of a common information base with written information and conversations. This will make work easier later, especially for Support.

We also noticed the importance of a clear definition of terms, so that everyone understands what is said. For this reason, a Glossary was created, to which the texts can link when a technical term needs to be explained. That way, everyone can look up what is meant by the term. Here we were avtively supported by Bastian Melsheimer who also provided an English translation of the glossary.