RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Promovierendenverwaltung – was ist das?

Bis Mai 2010 wurden Promovierende der FAU Erlangen-Nürnberg hauptsächlich mittels Papier und Excel-Listen verwaltet. Die Verwaltung von über 1.000 Promovenden stieß mit diesem Verfahren an ihre Grenzen. Deshalb starteten im November 2009 die Entwicklungen zur Promovierendenverwaltung (PV). Die Software-Entwicklung wurde von der Graduiertenschule der FAU, vertreten durch deren Leiterin Frau Dr. Monica Mayer, in Auftrag gegeben.

Die PV ist eine moderne Webanwendung, mit der die Promotionsregistrierungen und anfallende Daten elektronisch verwaltet werden. Damit wird ein universitätsweiter zentraler Überblick über laufende wie abgeschlossene Promotionen erreicht.

Genaugenommen besteht die PV aus drei Webanwendungen:

  • Die Registrierung, zugänglich für Promovenden, zur Eingabe ihrer Daten und Herunterladen ihrer Betreuungsbestätigung als PDF. Mit Hilfe der Betreuungsbestätigung kann der Betreuer des Promovenden schnell sicherstellen und durch Unterschrift bestätigen, dass die Daten zum Promotionsvorhaben richtig sind.

 

  • Die Administrationsoberfläche zur Einsicht und Änderung der Daten und zum endgültigen Freischalten von Promovenden. Freischalten meint den Promovenden auf Seite der PV zu aktivieren und Personen- und Kontaktdaten an IdM zu liefern. Freigeschaltet wird ein Promovend, wenn er seine vom Betreuer unterschriebene Betreuungsbestätigung bei der Graduiertenschule einreicht.

 

  • Die Client-Anwendung, zugänglich für Promovenden, zur Einsicht in ihre Daten.

Die PV ist an weitere Systeme der FAU angeschlossen:

 

  • Organisationsstrukturmanagement FAU.ORG: Aus FAU.ORG werden Organisationsdaten für Professuren, Lehrstühle, Institute, Departments und Fakultäten bezogen. Diese werden bei der Auswahl der Betreuer in der Registrierung benötigt.

 

  • Identity Management (IdM): Nachdem ein Promovend freigeschaltet wurde, gelangen seine Personen- und Kontaktdaten nach IdM. Wenn der Promovend noch keinen Eintrag im IdM hat, wird dieser angelegt und ein Aktivierungsbrief zugestellt. Nach seiner Aktivierung gelangen seine Zugangsinformationen zurück zur PV. Danach kann sich der Promovend in der Client-Anwendung anmelden.

 

  • Funktionenmanagement (FM): FM liefert an die PV die Personen, die berechtigt sind, Promotionen zu betreuen. Diese können dann in der Registrierung und Administrationsoberfläche unter ihrem Lehrstuhl ausgewählt werden.

Die Administrationsoberfläche bietet konfigurierten Administratoren die Möglichkeit, BIRT (Business Intelligence and Reporting Tools) Berichte hochzuladen und anzusehen. Mit Hilfe dieser Berichte läßt sich ein schneller Überblick über Sachverhalte wie z. B. “Wieviele Promovenden gibt es im Durchschnitt je Betreuer in jeder Fakultät?” gewinnen.

Es gibt ein Rechtemanagement, das vorgibt, welcher Administrator Promovenden suchen, freischalten, Berichte ansehen und Berichte hochladen darf. Ferner gilt, das Administratoren bei der Suche und Berichten nur diejenigen Daten sehen, für die sie konfiguriert sind. Dies ermöglicht es, die Administrierung der Promovenden auch durch Mitarbeiter der dezentralen Promotionsbüros erledigen zu lassen.

Die PV speicherte zum 01.03.2011 die Daten von 1.191 aktiven Promovenden. Sie hat sich zur Verwaltung von Promovendendaten bewährt und soll in Zukunft noch weiter ausgebaut werden.

Wenn Sie sich selbst ein Bild von der PV machen wollen, finden Sie den Direkteinstieg unter https://www.docdaten.uni-erlangen.de/.

Promotion-Management – What is it?

Up to May 2010 PhD-students at the FAU Erlangen-Nuremberg were managed mostly via pen and paper and Excel lists. The management with this method for over 1.000 PhD-students finally reached its limits. Therefore the development of the PhD-student management started in November 2009. The software development was ordered by  FAU’s grad school, represented from the leader Ms Dr. Monica Mayer.

The promotion-management is a modern web application with which the PhD registrations and according data can be managed electronically. With this method an university-wide central overview of running as well as completed promotions can be reached.

In a closer look the promotion management consists of three web applications:

  • The registration, available for PhD-students to enter their data and to download their adviser-confirmation-form as PDF. With the help of the adviser-confirmation-form the adviser of the PhD-student assure and confirm quickly with a signature that the data for the promotion proposition are correct.

 

  • The administration surface to see and change the data and for the final activation of the PhD-student. Activation means that the PhD-student, on the side of the PV, is activated and personal and contact data are delivered. A PhD-student is activated if he/she hands in the from the adviser signed adviser-confirmation at the grad school.

 

  • The client application, available for PhD-students to view their data.

The PV is connected to further FAU systems:

  • Organizational-structure management FAU.ORG: from FAU.ORG organizational data for professors, chairs, institutes, departments and faculties are transferred. These are needed for the selection of advisers during the registration.

 

  • Identity Management (IdM): After a PhD-student has been activated, his/her personal- and contact-data are transmitted to IdM. If the PhD-student doesn’t already have an entry in IdM, one is added for him/her and an activation letter will be sent. After the activation the login data are transmitted back to PV. After that the PhD-student can log into the client application.

 

  • Function Management (FM): FM delivers the persons, who are allowed to advise the PhD-student, to the PV. Those can then be chosen in the registration and administration surface within in one chair.

The administration surface gives the possibility for configured admins to upload and read BIRT (Business Intelligence and Reporting Tools) reports. With the help of those reports, a quick overview of issues, e.g. “How many PhD-students are at every faculty according to each adviser?” can be gained.

There is a right management which dictates which admin is allowed to search for or to activate PhD-students, to view and to upload reports. Furthermore it is considered that admins can only see the data within a search for which they are configured for.  This allows the administration of the PhD-students to be done by the employees of the decentralized promotion office.

The PV already saved data from 1.191 active PhD-students until 01.03.2011. It proved itself for managing the data of PhD-students and is supposed to be further enlarged in the future.

If you want to have an own view of the PV, you can find a direct entry at https://www.docdaten.uni-erlangen.de/.

Release 1.2 der Promovierendenverwaltung (PV) online

English Version
Seit 23.03.2011, 17:00 ist das Release 1.2 der PV online. Es gab folgende nach außen hin sichtbare Veränderungen:

  • Verbesserungen an Usability und Geschwindigkeit

    U. a. wurde in allen drei Web-Anwendungen (Registrierung, Admin-Oberfläche, Client-Anwendung)
    der eigene Menüpunkt Betreuer hinzugefügt und der Workflow, sowie die Performance verbessert.

  • Anpassung an das Universitätsdesign

    Es erfolgte eine Angleichung an das Corporate Design der Universität, so dass docdaten wie andere
    Webanwendungen der Universität aussieht.

  • Vereinheitlichte Betreuer (geliefert vom Funktionenmanagement (FM))

    Die Betreuer eines Promovenden wurden zuvor als Freitext eingegeben. Nun werden die auswählbaren
    Betreuer vom Funktionenmanagement geliefert, so dass nur wirklich an der FAU vorhandene Betreuer
    ausgewählt und abgespeichert werden können. Die als Freitext eingegebenen Betreuer mussten auf FM-Betreuer gematched und migriert werden. Damit verbunden wurde die Obergrenze von drei Betreuern auf beliebig viele erweitert.

  • Promotionsbüro-Mitarbeiter-Login via SSO

    Die Promotionsbüro-Mitarbeiter könne sich via SSO anmelden und sehen nur die Promovenden-Daten,
    für die sie zuständig sind. Sie können Datenänderungen durchführen, sowie Reports betrachten.
    Die Reports werden bisher nur von der Graduiertenschule hochgeladen.

  • Rechtemanagement (sowohl Datenauswahl, als auch Funktionsauswahl)

    Den Admins wurden unterschiedliche, teilweise mehrere Rollen zugeordnet, welche festlegen, ob Reports hochgeladen werden dürfen, betrachtet werden dürfen und ob Promovenden freigeschaltet werden dürfen. Des weiteren wurden die Daten, die ein Admin betrachten und bearbeiten darf auf seine Rolle eingegrenzt.

  • Konsolidierte Fächerliste für das Hauptfach des Promotionsvorhabens

    Es erfolgten Umbenennungen, Löschungen und Neuaufnahmen der auswählbaren Hauptfächer. Auch hierbei mussten Promovenden-Datensätze angepasst werden.

  • Lehrstuhl-Kurzname

    Für jeden Lehrstuhl ist ein Kurzname hinterlegbar, der z. B. in Reports angesprochen werden kann.

  • Betreueraufstellung mit Datenübersicht über jeden Promovenden

    Für jeden Betreuer wurde eine Übersicht über seine freigeschalteten Promovenden erzeugt und für jeden freigeschalteten Promovenden ein Datenblatt. Diese PDFs wurden ausgedruckt und an die Betreuer verschickt.

Daneben erfolgten noch weitere, sorgfältig konzipierte Verbesserungen an der Oberfläche und dem Backend der PV.

Release 1.2 of PhD Management (PV) is online

Since 23.03.2011, 5 PM the release 1.2 of PV is online. There are following changes which are visible to the outside:

  • Improvements on usability and speed

    Among others in all of the three web applications (registration, admin interface, client application) an own menu point advisor added and the workflow aswell as the performance has been improved.

  • Matching to University Design

    There has been a matching to the university’s corporate design to make docdaten look like the other university’s web applications.

  • Unified Advisors (delivered from Function Managment (FM))

    A PhD student’s advisor has former been entered as free text. Now there are chosable advisors delivered from the function management so that only advirors can be chosen and saved who are actually working at the FAU. The advisors entered as free text had to be matched and migrated to FM advisors. Accordingly the maximum of three advisors has been raised to indefinetely.

  • Promotion Office Employees’ Login via SSO

    The promaotion office employees can now login via SSO and only see the PhD students’ data for whom they are responsible for. They can change data aswell as look at reports. The reports have been so far uploaded by the grad school

  • Right Management (aswell as Choice of Data and Choice of Function)

    The admins have been assigned to different, sometimes multiple roles, which determine if reports can be uploaded, read and if PhD students can be activated. Furthermore data which the admin can read and modify have been constricted to his/her role.

  • Consolidated Subject List for Main Subject of PhD Plan

    There have been name changes, deletes and additions of chosable main subjects. Here also the Phd student data had to be adjusted.

  • Department Nickname

    For every department a nickname is now attributed which e.g. can be addressed in reports.

  • Advisor List with Data Overview or every PhD Student

    For every advisor an overview of his/her activated PhD students has been generated and a data sheet for every activated PhD student. These PDF forms have been printed out and sent to the advisor.

There have also been further, thoroughly concipated improvement on the surface and in PV’s backend.

Abkündigung CIT2

English Version
Mit der Ankündigung des Ausscheidens von Herrn Buzek ist es ruhig um CIT2 geworden. Seine Entscheidung wurde unter anderem zum Anlass genommen, das Thema Campus Management kritisch zu überdenken. Inzwischen ist klar, dass die Universitätsleitung zeitnah eine strategische Neuausrichtung beschließen wird.
Der Entscheidung der UL möchte ich nicht vorgreifen, so viel ist aber bereits jetzt klar: CIT2 ist mit der bisherigen Ausrichtung nicht mehr mit der zukünftigen Campus Management Strategie vereinbar.

Daher wurde am 23.02.2011 beschlossen, das das organisatorische Projekt CIT2 aufzulösen und das bestehende Personal sowie die Projekte in die Stabsstelle “Projekte & Prozesse” am RRZE zu integrieren.
Der Betrieb der “mein campus” Plattform liegt bei der Gruppe “Campus IT (CIT)”, geleitet von Frau Andrea Grimm.
Die Stabsstelle wird von Herrn Dr. Peter Reiß als meinem Stellvertreter und mir geleitet.
Die Stabsstelle fungiert zukünftig als Software-Entwicklungsabteilung und wird die Gruppe CIT nach Kräften unterstützen.

Für die im Rahmen von CIT2 geplanten Module sind die Gespräche über Fortführung oder alternative Realisierung bereits angelaufen.
Für die gute und fruchtbare Zusammenarbeit bedanke ich mich bei Ihnen allen!
Ich bin mir sicher, dass wir im Zuge der einzelnen Entwicklungsprojekte wieder das Vergnügen haben werden, zusammen arbeiten zu können, worauf ich mich sehr freue.

Meine letzte Bitte geht in die Richtung der Studierenden: Ich würde mich freuen, wenn wir den Dialog aufrecht erhalten könnten. Über Vorschläge wie dies zu gestalten ist, bin ich sehr dankbar.

Announcement CIT2

 

With the announcement of Mr. Buzek leaving it has become quiet around CIT2. His decision became an occasion among others to critically rethink the topic of campus management. Meanwhile it is clear that the university administration soon will decide a stragetic redirection.
I don’t want to anticipate the decision of the university administration, but this is already clear: CIT2 is with the previous focusing not compatible with the upcoming Campus Management Strategy.

Therefore, on 23.02.2011 it has been decided that the organisational project CIT2 will be dissolved and the pesonnel aswell as the projects will be integrated to the staff unit “Projects & Processes” at the RRZE.
The maintenance of the “mein campus” platform is within the group  Gruppe “Campus IT (CIT)”, managed by Ms. Andrea Grimm. The staff unit is now managed by Mr. Dr. Peter Reiß as my substitute and me.

The staff unit will further function as a software development department and will support the group CIT by all means.

Discussions about continuances or alternative realisations for the in the frame of CIT2 planned modules are already in process.
Thank you all for a good and productive teamwork!

I am sure that due to the individual development projects we will have the pleasure to work together again, to which I am looking forward to.

My last request is tend towards the students: it would be a pleasure to keep up the dialogue. I’m very thankful about suggestions how to create this.

 

Logging von Grails-Applikationen in JBoss

Kurzanleitung:

  • Aus Classloader-Gründen darf die Applikation nicht eine eigene log4j-xxx.jar beinhalten. Diese kann aus dem war-file entfernt werden durch folgenden Eintrag in BuildConfig.groovy:
    [groovy]
    grails.war.resources = { stagingDir ->
    delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
    delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
    }
    [/groovy]
    (Der Eintrag mit tomcat ist für das Thema hier nicht relevant, entfernt aber unnötige Klassen aus dem war-file.)
  • Die Grails-Log4j-Konfiguration aus Config.groovy wird im JBoss nicht ausgewertet. Daher sind die Einträge in der JBoss-Log4j-Konfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml nachzuziehen.
    Beispiel für Controller:
    [xml]
    <category name=”grails.app.controller.MyController”>
    <priority value=”INFO”/>
    </category>
    [/xml]
    Man beachte auch das “grails.app.controller“-Präfix!
  • Eine weitere Seltsamkeit ist, dass nach einem Undeploy oder Redeploy eines Grails-war-files das Logging des JBoss komplett beendet wird, d.h. absolut nichts mehr in die Logdatei geschrieben wird. Den Grund und eine saubere Lösung dafür habe ich noch nicht gefunden, aber als Workaround ist es möglich, ein touch auf ${JBOSS}/server/default/conf/jboss-log4j.xml auszuführen. Da diese Konfiguration regelmäßig eingelesen wird, erscheinen die Logmeldungen wieder.

Logging of Grails application in JBoss

Brief administration:

  • Because of  Classloader reasons the application can not have an own  log4j-xxx.jar. It can be deleted from the war-file with the following entry in  BuildConfig.groovy:
    [groovy]
    grails.war.resources = { stagingDir ->
    delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
    delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
    }
    [/groovy]
    (The entry with tomcat is not relevant for this topic, but deletes unnecessary classes from the war-file.)
  • The Grails-Log4j-configuration from Config.groovy is not evaluated in JBoss. Therefore the entries need to be moved in the JBoss-Log4j-onfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml.
    Example for Controller:
    [xml]
    <category name=”grails.app.controller.MyController”>
    <priority value=”INFO”/>
    </category>
    [/xml]
    Keep the “grails.app.controller“-Prefix in mind!
  • Another oddity is that after an undeploy or redeploy of a Grails-war-file the logging of the JBoss will be completely closed,  which means that absolutely nothing is written in the log file. We haven’t found yet the reason and a clean solution for this problem, but as a Workaround it is possible to make a touch to ${JBOSS}/server/default/conf/jboss-log4j.xml. Because this configuration will be importet regularly the logging messages will reoccur.

IP mit Hostnamen ergänzen

English Version

Beschreibung

Es ist schwierig IP-Adressen richtig zuordnen zu können. Erst durch eine Auflösung mit den Hostnamen werden sie verständlich. Aus diesem Grund sollen diese mit den entsprechenden Hostnamen ergänzt werden. Die am RRZE verwendeten Firewallregeln basieren auf IP-Adressen. Um diese leichter zu verstehen und somit bearbeiten zu können müssen sie in Hostnamen aufgelöst werden.
Händisch wäre diese Ergänzung sehr aufwendig. Daher sollte hierfür ein Skript geschrieben werden. Ich habe mich entschieden Perl zu verwenden, da diese Skriptsprache die gewünschte Funktionalität und Flexibilität bietet.

Benutzung

[bash] $ ./ipHostname.pl -i INPUTFILE -o OUTPUTFILE[/bash]

Beispiel

[bash]

$ ./ipHostname.pl -i ipinput.txt -o ipoutput.txt

dali.rrze.uni-erlangen.de/131.188.84.???
web.de/213.165.64.???
mordor.rrze.uni-erlangen.de/131.188.12.???

Hosts saved to file: ipoutput.txt

[/bash]

Das letzte Oktett der IPs wurden aus Sicherheitsgründen zensiert.

Quellcode

[perl]
#!/usr/bin/perl
#
# Inputs IP address from log file and outputs
# host name to screen and file.
#
# Typical usage: ./ipHostname.pl -i inputfile -o outputfile [-s]
#

use Getopt::Long;
use strict;
use warnings;

my $outputfile = 0;
my $inputfile = 0;
my $silent = 0;
my $counter = 0;

#Sind die Optionen, welche Ausgewählt werden könen/müssen
GetOptions (
“o=s” => \$outputfile,
“output=s” => \$outputfile,
“i=s” => \$inputfile,
“input=s” => \$inputfile,
“s|silent” => \&silent,
“h|help|?” => \&syntax);

#Wenn Inputfile oder Outputfile nicht angegeben sind soll die Syntax ausgegeben werden, da beide Parameter Pflichtfelder sind
if ((!$inputfile ) || (!$outputfile )) {
&syntax;
}

#Die Variable $silent wird hier so gesetzt, dass es keine Ausgabe auf der Konsole gibt
sub silent {
$silent = 1;
}

#Hier werden In- und Outputfile geöffnet
open(IP, $inputfile) || warn “Can’t open input $inputfile: $!\n”;
open(HOST, “>$outputfile”) || warn “Can’t open output $outputfile: $!\n”;

print “\n” if !$silent;

#Datei wird zum gesplittet um sie richtig verarbeiten zu können
while() {
my @foo = split(/ /,$_);
my @ip = grep(/\d+\.\d+\.\d+\.\d+/,@foo);
my $ip = $ip[0];
#IPs werden gesplittet und mit gethostbyaddr gecheckt. Anschliessend folgt nur die Ausgabe.
if ($ip) {
my @numbers = split(/\./, $ip);
my $ip_number = pack(“C4”, @numbers);
my ($name) = (gethostbyaddr($ip_number, 2))[0];
if ($name) {
print “$name/$ip\n” if !$silent;
print HOST “$name/@foo”;
} else {
print “This IP has no name: $ip\n” if !$silent;
print HOST “(no host name)/@foo”;
}
}else {
print HOST “@foo”;
}
}
if ($outputfile && !$silent) {
print “\nHosts saved to file: $outputfile\n\n”;
}
close IP;
close HOST;

#Hilfe
sub syntax {

if ($counter == 0) {
print “\nipHostname.pl \n
Usage: ./ipHostname.pl -i inputfile -o outputfile [options]
-i Path to Inputfile
-o Path to Outputfile
-h –help Print this Help
-s Silence
-silent Silence
\n”;
++$counter;
}
}
exit;
[/perl]

IP Supplement with Hostname

Description

It is difficult to assign IP-adresses correctly. Only by breaking up through the hostname they become understandable. Because of this reason the hostname should be added to these. The firewall rules, used at the RRZE, are based on IP-adresses. To make this process easier to understand and therefore easier to work with the hostnames need to be broken up.
These supplements are very time consuming if you do this per hand. Therefore a skript is needed. I decided to use Perl, because this script language offers the needed functionality and flexability.

Usage

[bash] $ ./ipHostname.pl -i INPUTFILE -o OUTPUTFILE[/bash]

Example

[bash]

$ ./ipHostname.pl -i ipinput.txt -o ipoutput.txt

dali.rrze.uni-erlangen.de/131.188.84.???
web.de/213.165.64.???
mordor.rrze.uni-erlangen.de/131.188.12.???

Hosts saved to file: ipoutput.txt

[/bash]

The last octet of the IPs has been cencored because of safety issues.

Source Code

[perl]
#!/usr/bin/perl
#
# Inputs IP address from log file and outputs
# host name to screen and file.
#
# Typical usage: ./ipHostname.pl -i inputfile -o outputfile [-s]
#

use Getopt::Long;
use strict;
use warnings;

my $outputfile = 0;
my $inputfile = 0;
my $silent = 0;
my $counter = 0;

#Sind die Optionen, welche Ausgewählt werden könen/müssen
GetOptions (
“o=s” => \$outputfile,
“output=s” => \$outputfile,
“i=s” => \$inputfile,
“input=s” => \$inputfile,
“s|silent” => \&silent,
“h|help|?” => \&syntax);

#Wenn Inputfile oder Outputfile nicht angegeben sind soll die Syntax ausgegeben werden, da beide Parameter Pflichtfelder sind
if ((!$inputfile ) || (!$outputfile )) {
&syntax;
}

#Die Variable $silent wird hier so gesetzt, dass es keine Ausgabe auf der Konsole gibt
sub silent {
$silent = 1;
}

#Hier werden In- und Outputfile geöffnet
open(IP, $inputfile) || warn “Can’t open input $inputfile: $!\n”;
open(HOST, “>$outputfile”) || warn “Can’t open output $outputfile: $!\n”;

print “\n” if !$silent;

#Datei wird zum gesplittet um sie richtig verarbeiten zu können
while() {
my @foo = split(/ /,$_);
my @ip = grep(/\d+\.\d+\.\d+\.\d+/,@foo);
my $ip = $ip[0];
#IPs werden gesplittet und mit gethostbyaddr gecheckt. Anschliessend folgt nur die Ausgabe.
if ($ip) {
my @numbers = split(/\./, $ip);
my $ip_number = pack(“C4”, @numbers);
my ($name) = (gethostbyaddr($ip_number, 2))[0];
if ($name) {
print “$name/$ip\n” if !$silent;
print HOST “$name/@foo”;
} else {
print “This IP has no name: $ip\n” if !$silent;
print HOST “(no host name)/@foo”;
}
}else {
print HOST “@foo”;
}
}
if ($outputfile && !$silent) {
print “\nHosts saved to file: $outputfile\n\n”;
}
close IP;
close HOST;

#Hilfe
sub syntax {

if ($counter == 0) {
print “\nipHostname.pl \n
Usage: ./ipHostname.pl -i inputfile -o outputfile [options]
-i Path to Inputfile
-o Path to Outputfile
-h –help Print this Help
-s Silence
-silent Silence
\n”;
++$counter;
}
}
exit;
[/perl]