Campusmanagement

Campusmanagement an der FAU

Inhalt

mein campus jetzt auch unter www.campus.fau.de zu erreichen

Auf Anregung eines Studenten, dass es schön wäre, wenn sich auch mein campus unter der neuen fau.de Domain finden würde, haben wir diesen Wunsch heute umgesetzt. mein campus ist ab sofort nicht mehr nur unter der „alten“ URL https://www.campus.uni-erlangen.de zu erreichen, sondern auch unter der neuen URL https://www.campus.fau.de.

Zudem wurden die Aliase campus.uni-erlangen.de bzw. campus.fau.de eingerichtet, die einem das Tippen des lästigen www sparen. Weitergeleitet wird dann auf die jeweilige Domain.

Inhaltlich und funktional ändert sich natürlich nichts an mein campus; egal unter welchem Namen man die Seite aufruft.

Wartungsarbeiten am 23.09.2010

Am Donnerstag, den 23. September 2010 wird die Online-Serviceplattform mein campus zwischen 18.00 und 18:30 Uhr aufgrund von Wartungsarbeiten am Netz der Zentralen Universitätsverwaltung nicht zur Verfügung stehen.
Die Wartungsarbeiten werden auch auf der Loginseite von mein campus angekündigt. Nach Beendigung der Wartungsarbeiten wird der Hinweis wieder entfernt.

Fehlermeldung „Fehler in Modul {unknown}“ nach dem Release von mein campus 5.0

Nach dem Release der Version 5.0 von mein campus traten bei zahlreichen Benutzern des Internet Explorers „Fehler im Module {unknown}“ auf. Dieser Blogeintrag wird die Ursachen dieses Fehlers beleuchten.
Die Online-Serviceplattform mein campus integriert unter einer einheitlichen Oberfläche mehrere, eigenständige Anwendungen. Damit diese unterschiedlichen Anwendungen miteinander funktionieren, müssen im Hintergrund verschieden Daten ausgetauscht werden. So müssen beispielsweise alle Anwendungen prüfen können, ob der Benutzer angemeldet ist und die jeweiligen Session-Timeouts müssen synchronisiert werden. Geschieht letzteres nicht, würde ein Benutzer, der die Veranstaltungsverwaltung nutzt, automatisch aus der Prüfungsverwaltung ausgeloggt, da aus Sicht dieser Anwendung zu lange keine Interaktion erfolgte.

Bis zur Version 4.4 von mein campus wurden die Informationen über authentifizierte Benutzer über eine kleines, gemeinsam genutzes Datenbankbackend ausgetauscht. Für die Synchronisation der Sessions wurden im Hintergrund immer auch Aufrufe aller anderen Anwendungen durchgeführt. Dies war für den Benutzer zwar transparent, machte für jede neue Anwendung die integriert werden sollte, aber Anpassungen an allen bisherigen Anwendungen notwendig (und beinhaltet damit auch das Risiko Fehler in den Code einzubauen).

Mit Version 5.0 wurde die notwendige Funktionalität in den Applikationsserver selbst verlagert. Dieser platziert nun ein gesondertes Session-Cookie, das alle Anwendungen lesen können. Damit wird sichergestellt, dass der User authentifiziert ist. Zudem lassen sich über die ID dieser Session alle Anwendungssessions identifizieren und deren Session-Timeouts aktualisieren. Damit entfällt die fehleranfällige Modifikation der bestehenden Anwendungen und neue Anwendungen müssen lediglich noch in die Konfiguration des Applikationsservers eingetragen werden.

Damit das globale Session-Cookie von allen Anwendungen gelesen werden kann, wird dieses mit dem Root-Verzeichnis von mein campus gesetzt. Der Internet Explorer erlaubt das Setzen eines solchen Session-Cookies in der Standardkonfiguration aus Sicherheitsgründen allerdings nicht. Für diesen Fall werden die benötigten Informationen über die aufgerufene URL übergeben. Diese werden, beginnend mit einem Semikolon, an die URL gehängt und können so vom Applikationsserver verwendet werden. Dieses Verhalten funktioniert in den meisten Browsern und mit einer Außnahme auch im Internet Explorer. Wird eine so codierte URL im Meta-Refresh-Tag einer Seite verwendet, betrachtet der Internet Explorer das Semikolon nicht als Bestandteil der URL, sondern als Parametertrenner ( siehe MSDN Library). Daher wurde in solchen Fällen nur eine verstümmelte URL für den Seitenaufruf übergeben, so dass in diesen Fällen kein korrekter Aufruf mehr vorlag. Dies führte zu der oben genannten Fehlermeldung.

Zur Lösung dieses Problems wurden sowohl die Methode zur Encodierung solcher Refresh-URLs, als auch die Methode zu deren Weiterverabeitung so erweitert, dass diese nun auch das globale Cookie unterstützen.

Sollte trotzdem noch jemand auf diesen Fehler stoßen, liegt das mit großer Wahrscheinlichkeit am Aufruf einer falschen Methode zur Codierung solcher URLs. Diese bitte dann einfach an meincampus-support@uni-erlangen.de melden… oder einfach nicht mehr den IE verwenden Wink.

Wartungsarbeiten beendet

Die angekündigten Wartungsarbeiten an mein campus konnten bereits 10 Minuten nach Beginn, gegen 18:10 Uhr, dank tatkräfitger Mithilfe der Kollegen im Südgelände beendet werden. Die verspätete Meldung zum Ende der Wartungsarbeiten bitte ich zu entschuldigen.

Ausfall Single Sign-On Anmeldung

Nach der Stromabschaltung am Samstag, 28.11.09, funktioniert die Anmeldung über Single Sign-On derzeit nicht. Bis der Fehler behoben wurde, können sich alle Studiereden über die Lokale Anmeldung anmelden. Auf die restliche Funktionalität von mein campus hat dieser Ausfall keine Auswirkungen.

mc 4.0: Neue Hardware und eine andere Virtualisierungslösung

Mit dem kürzlich erfolgten Release hat sich die mein campus-Version von 3 auf 4 erhöht. Den Hauptgrund für diesen Versionssprung sieht man jedoch nicht in den Versionsinformationen oder dem Frontend, sondern hauptsächlich „unter der Haube“. Wie in einem früheren Blogbeitrag beschrieben, wurde die Geschäftslogik auf den aktuellen Stand gebracht. Zudem hat sich mit mein campus 4.0 die grundlegende Architektur geändert auf der mein campus läuft. Erhalten bleibt alleine die Virtualisierung, die sich von VMware Server zu VMware ESX ändert.
Von Beginn an und bis einschließlich Version 3.5 liefen die virtuellen Maschinen (mindestens 3 Stück) in denen die Komponenten von mein campus laufen auf einem Linux-HA/DRBD-Cluster. Dazu wurde für jede der virtuellen Maschinen ein eigenes DRBD (Distributed Replicated Block Device) angelegt. Jedes DRBD verhält sich dabei wie ein RAID-1 über das Netzwerk. Auf Blocklevelebene werden sämtliche Schreibzugriffe auf das aktive Gerät zu dem passiven repliziert. Auf diese Art wurde sichergestellt, dass die physikalischen Knoten über den gleichen Datenstand verfügen.

Linux-HA ist eine Hochverfügbarkeitslösung für Linux. Diese übernimmt das Starten und Stoppen, sowie die Kontrolle der hochverfügbaren Dienste und migriert diese im Fehlerfall auf einen anderen Clusterknoten. Im Fall von mein campus waren dies folgende Dienste pro virtueller Maschine:
– Setup des DRBD
– Mounten des Filesystems
– Starten der virtuellen Maschinen.

Mit Version 4.0 wurden die virtuellen Maschinen jetzt auf ein Cluster unter VMware ESX migriert. Das Cluster besteht aus einem HP Bladecenter mit 5 Blades und einer HP EVA als Shared-Storage. Der Hauptgrund für diesen Architekturwechsel ist die einfachere Bedienbarkeit von VMware ESX.

Obwohl die Eigenkonstruktion auf Linux-HA/DRBD Basis gut funktionierte, waren Erweiterung und Wartung häufig mit hohem Aufwand verbunden. So war es beispielsweise notwendig alle virtuellen Maschinen herunterzufahren, um neue DRBDs und damit neue virtuelle Maschinen auf dem Cluster anlegen zu können. Würde man mehrere virtuelle Maschinen in 1 DRBD legen müssten diese immer auf dem selben Knoten laufen. Ein weiterer Grund für die Migration auf VMware ESX ist die einfachere und vollständige Bedienung der Software über ein GUI. Zwar bringt Linux-HA ein eigenes GUI mit, dieses deckt jedoch nicht alle Konfigurationsmöglichkeiten ab. Master/Slave-Resourcen wie DRBDs sind über das GUI beispielsweise nicht zu konfigurieren.

Neues SSL-Zertifikat für mein campus

Nachdem das alte Sicherheitszertifikat für mein campus ausgelaufen ist und eine Verlängerung des Zertifikats nicht möglich war, wurde heute auf mein campus ein neues Zertifikat installiert. Dieses wurde von der CA (Certificate Authority) der Universität signiert. Das universitätseigene Zertifikat ist allen neueren Browsern bekannt, so dass für die meisten Nutzer keinerlei Probleme auftreten sollten.
Benutzer von Firefox vor Version 3.5 könnten allerdings Warnungen wegen eines unbekannten Zertifikatsherausgebers erhalten. Wir empfehlen in diesem Fall auf eine aktuellere Version von Firefox zu wechseln. Ein Schritt der auch aus Sicherheitsgründen sinnvoll ist, da aktuelle Software meist schneller gefixt wird. Wer dennoch bei seiner Firefox-Version bleiben möchte kann eine Ausnahme für das Zertifikat einrichten. Dabei sollte bei der Überprüfung des Zertifikats darauf geachtet werden, dass die „Fingerabdrücke“ des Zertifikats mit folgenden Werten übereinstimmen:
SHA1-Fingerabdruck: 7E:0A:24:29:42:9C:06:EA:C2:DF:18:B1:BB:54:83:88:A5:AF:06:86
MD5-Fingerabdruck: F1:33:B5:A9:46:C5:A6:E9:B7:8F:3C:5B:DC:97:8B:36

Anmeldung bei mein campus mittels Single Sign-On

Mit der nächsten mein campus Version können sich Studierende per Single Sign-On (SSO) am System anmelden. Unter SSO versteht man die einmalige Anmeldung an einem zentralen System. Nach dieser Anmeldung kann man alle Dienste nutzen, die am System registiert sind. Für alle anderen Nutzergruppen steht SSO leider noch nicht zur Verfügung, da diese Nutzerkennungen noch lokal verwaltet werden. Um die Anmeldung mittels SSO zu unterstützen, waren einige Änderungen an der Webseite von mein campus nötig.
Dafür wurde die bisherige Login Maske von der mein campus Seite entfernt und durch 2 Links ersetzt.


(mein campus Loginseite)
Der erste Link führt zur SSO Anmeldung. Nach dem der Student diesem Link gefolgt ist, gibt es zwei Möglichkeiten. Falls der Student bisher noch nicht am System angemeldet ist, erscheint die zentrale Loginseite und er muss sich authentifizieren, danach wird er auf die mein campus Startseite weitergeleitet.

Falls er sich am System schon angemeldet hat, kommt er direkt auf die mein campus Startseite. Um die lokale Anmeldung zu nutzen, klicken alle anderen Nutzer auf den zweiten Link. Dann erscheint die bisherige Anmeldemaske.
Die zweite Änderung betrifft die Informationsbox, wo sich neben dem Benutzernamen auch der Abmelde-Link befindet. Falls es sich um eine Anmeldung via SSO handelt, ändert sich dieser Link zu „Abmelden (SLO)“, wobei SLO für Single Log-Out steht. Mittels diesem Link meldet sich der Student nicht nur bei mein campus, sondern auch bei allen anderen angeschlossenen Diensten ab.

Anzeige von Studiengang und Abschluss vorübergehend deaktiviert

Aufgrund der in einem Blogeintrag beschriebenen Problematik mussten in den Prüferfunktionen „Teilnehmerliste“ und „Noten- und Leistungsverbuchung“ in mein campus nun auch in den Export-Möglichkeiten nach Excel und als kommaseparierte Datei (*.csv) sowie den PDF-Versionen die Abschlüsse und Studiengänge der Prüfungsteilnehmer ausgeblendet werden.
Abgesehen von dieser Einschränkung ist der Excel-Export und der Import nach erfolgter Bearbeitung jedoch weiterhin möglich.

Probleme mit mehreren Tabs oder Fenstern in mein campus

Diese Woche trat ein Problem bei der Verwendung mehrerer Fenster oder Tabs als Prüfer in mein campus auf. Betroffen von diesem Problem sind alle Links, die Dateien zum Download anbieten.
Werden mehrere Links in neuen Fenstern oder Tabs geöffnet, so können in allen Fenstern oder Tabs nur die Dateien des zuletzt geöffneten Links heruntergeladen werden.
Die Ursache des Problems ist die Art und Weise, auf die mein campus die Links für die Exporte erzeugt. Diese werden aus Informationen konstruiert, die in der Session des Benutzers gespeichert werden. Diese werden mit jedem Klick aktualisiert, so dass nur die Informationen zum zuletzt geklickten Link vorliegen.
Für das Release 4.1 von mein campus ist deshalb geplant, die Informationen beim Laden der Seite aus der Session zu extrahieren und die Variablen in der Seite abzulegen.
[UPDATE]:
Das beschriebene Problem betrifft nicht nur Exporte, sondern auch Prüfungsan- bzw. -abmeldung, sowie Noten- und Leistungsverbuchung. Es ist daher nicht möglich Unterstüzung für mehrere Tabs oder Fenster in mein campus nachzurüsten. Dies würde ein Neuschreiben großer Teile der Middleware erfordern, wofür weder Zeit noch Personal zur Verfügung steht.