RRZE - Projekte & Prozesse (P&P)

Suche


Inhalte überspringen: zur Funktionsnavigation zur Inhaltenavigation mit Inhaltsübersicht und Verzeichnis A-Z

Über...

Aktuelles aus der Stabsstelle "Projekte & Prozesse" (P&P) des Regionalen RechenRentrums Erlangen (RRZE) der Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)

News and Infos from the IT advisory board "Projects & Processes" (P&P) at the Regional Computing Center Erlangen (RRZE) of the Friedrich-Alexander-University Erlangen-Nuremberg (FAU)

Status

Online seit einem Jahr und 165 Tagen
Letzter Eintrag: 2010.02.08, 16:17

Kalender

Februar 2010
Mo Di Mi Do Fr Sa So
 1   2   3   4   5   6   7 
 8   9  10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
Januar    

Letzte Beiträge

Leiste ausblenden

Montag, 8. Februar 2010

Inkscape und Datenschutz

Dank David Wessel (infeurope S.A.) wurden wir darauf hingewiesen, dass die svg-Dateien durchaus private Informationen enthalten.

Mir ist aufgefallen, dass in den jeweiligen SVG-Versionen der Dateien noch einige Pfadangaben enthalten sind, welche teilweise Rückschlüsse auf den Inhalt ihrer Dateiablage geben können.

Das sieht dann z.B. so aus:

inkscape:export-filename="C:\Users\dieDesignerin\RRZE\berlios_rrze_icons\tango\720x720\actions\add-participant.png"

Nicht schlimm, aber auch nicht schön.

Etwas Suchen via Google brachte mich auf einen Fehlerreport bei Ubuntu Privacy concern with export-filename and sodipodi:absref. Aha - das Problem ist also nicht nur bekannt, sondern es haben noch mehr! Wirklich spannend wird es dann, denn Sebastian Pipping schreibt in Kommentar 7, dass er das Programm "svgstrip" erstellt, um diese Informationen zu entfernen. Also runtergeladen und angewendet. Das Tool hatte noch ein Problem mit UTF-8 Zeichen in den Metadaten, aber Sebastian hat den Fehler binnen 3 Tagen - und wie bei Open Source Software so oft - unentgeldlich behoben. Vielen Dank dafür. Und nun klappt es auch mit den UTF-8 Zeichen.

Also Datenschutz wieder hergestellt. Version der Grafiken committed.

Dumm nur, dass man dies nach jeden erneuten Speichern mit Inkscape wiederholen muss. Es müsste eine Option geben, Inkscape diese Unart abzukonfigurieren. Aber daran arbeite ich noch. Genau wie an einer Anleitung, wie man die Metadaten unter Windows entfernt. Vielleicht?! ;-)

Hier kommt erstmal die Schritt-für-Schritt-Anleitung unter Linux.
Voraussetzung ist, dass git, svn und python installiert sind, aber wer sich auf die Befehlszeile traut, bekommt das auch hin. O:-)

  1. Die aktuellste Version von svgstrip via git holen.
    git clone git://git.goodpoint.de/svgstrip.git git/svgstrip
    (übrigens: ein git pull in dem neuen Verzeichnis hält die Version aktuell.)
  2. In das Verzeichnis mit den Icons wechseln - in meinem Fall das RRZE Icon Set.
    cd svn/rrze-icon-set/trunk
  3. Dann möchte ich alle svg-Dateien suchen und durch svgstrip bearbeiten lassen.
    for i in $(find -name *.svg); do echo $i; ../../svgstrip/svgstrip --in-place $i; done;
  4. und dann das Ganze zurück ins subversion.
    svn ci

Fertig!

Danke an David Wessel und Sebastian Pipping!

  

Inkscape and privacy

David Wessel (infeurope S.A.) was kind enough to inform us that svg files can, in fact, contain private information.

I noticed that svg versions of files still contain parts of the files' paths, which allows inference of the original file system.

It looks like this:

inkscape:export-filename="C:\Users\dieDesignerin\RRZE\berlios_rrze_icons\tango\720x720\actions\add-participant.png"

Not too bad, but not very nice, either.

Some searching with Google led me to an error report for Ubuntu: Privacy concern with export-filename and sodipodi:absref. So not only is the problem already known, others are having it as well. Now it's getting interesting, as Sebastian Pipping writes in commentary 7 that he wrote the program "svgstrip" to get rid of this information. I downloaded the program and ran it. The tool still had a problem with UTF-8 characters in the Metadata, but Sebastian fixed that bug within 3 days. And, like most of the time with Open Source Software, for free.And now, UTF-8 characters are no longer a problem.

Data security is once again intact. New versions of the graphics were committed.

On the down side, this needs to be repeated every time you save a file with Inkscape. There ought to be an option to configure what is saved in svg files. But I'm still working on that. I'm also working on instructions how to remove the metadata under Windows. Maybe?

For now, I give you a step by step instruction for Linux.
You need svn and python installed, but if you are confident to use the command line, you will manage that, too. O:-)

  1. Get an up to date version of svgstrip with git.
    git clone git://git.goodpoint.de/svgstrip.git git/svgstrip
    (by the way: git pull in the new directory keeps the version up to date.)
  2. Change into your icon directory ? in my case that is the RRZE Icon Set.
    cd svn/rrze-icon-set/trunk
  3. Now I would like to search for all svg files and edit them with svgstrip.
    for i in $(find -name *.svg); do echo $i; ../../svgstrip/svgstrip --in-place $i; done;
  4. and finally, send it all back into the subversion
    svn ci

Finished!

Thanks to David Wessel and Sebastian Pipping!

  • Kommentieren (keine Kommentare)

Freitag, 22. Januar 2010

Rekonstruktion von Dateisystemrechten in Linux

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.

  • Kommentieren (keine Kommentare)

Donnerstag, 21. Januar 2010

Inside FAU.ORG 2.0

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.

  • Kommentieren (keine Kommentare)

Nach oben