MoUSe

Ein neues Werkzeug zur Verwaltung von URZ-Geschäftsvorgängen


Motivation

Unter http://www.tu-chemnitz.de/urz/alle-dienste.html findet man einen Überblick über alle URZ-Dienste. Jeder Dienst bindet in irgendeiner Form Ressourcen. Bei einigen Diensten (z.B. WWW-Server, FTP-Archiv, Admindienste) ist der Ressourceneinsatz unabhängig von den Personen, die den Dienst nutzen. Bei anderen Diensten (z.B. Kurspraktika) besteht nur ein Zusammenhang zur Nutzeranzahl. Bei vielen Diensten erfolgt die Ressourcenbereitstellung aber unmittelbar personenbezogen (siehe Tabellen 1 und 2). Das trifft u.a. auf Accounts, Homeverzeichnisse, Mailadressen, Drucken und den Zugriff auf lizenzierte Software zu.

Einrichtung Nutzeranzahl
Technische Universität Chemnitz 8963
Hochschule für Technik und Wirtschaft Mittweida 146
Technische Universität Dresden 70
Seniorenkolleg 43
Universität Leipzig 40
Westsächsische Hochschule Zwickau 32
Technische Universität Bergakademie Freiberg 29
Berufsakademie Sachsen (Glauchau) 28
Hochschule für Technik, Wirtschaft und Kunst Dresden 25
Studentenwerk 11
Institut für Konstruktion und Verbundbauweisen e.V 11
Institut für Mechatronik 11
Friedrich-Schiller-Universität Jena 11
Tabelle 1: Accounts je Einrichtung - Stand: 31.12.2000

Diese Dienste erfordern eine spezielle Verwaltung.
Natürlich bleibt der Nutzerkreis an einer Uni nicht unverändert. So lief im letzten Jahr für knapp 2000 Personen die Nutzungsberechtigung aus - über 2500 neue Benutzer wurden erfasst.

Diese Zahlen zeigen deutlich, dass im Umfeld von Ressourcen-, Dienste- und Benutzerverwaltung erhebliche Routinearbeiten anfallen. Der dafür täglich notwendige Aufwand muss auf ein Minimum reduziert werden.

Struktureinheit Nutzeranzahl
Philosophische Fakultät 2818
Fakultät für Wirtschaftswissenschaften 1931
Fakultät für Maschinenbau und Verfahrenstechnik 1106
Fakultät für Informatik 907
Fakultät für Elektrotechnik und Informationstechnik 744
Fakultät für Naturwissenschaften (Physik) 357
VDE-Kurse 315
Fakultät für Mathematik 291
Fakultät für Naturwissenschaften (Chemie) 234
Uni-Bibliothek 79
Zentrale Verwaltung - Dezernate 74
Uni-Rechenzentrum 41
sonstige zentrale Einrichtungen 37
Uni-Leitung, Gremien, Kommisionen, ... 29

Tabelle 2: Accounts je Struktureinheit - Stand: 31.12.2000

Bis zum Sommer 2000 setzten wir eine Datenbanklösung ein, die als Eigenentwicklung in den Jahren 1992/93 entstanden war. Damals hatte das URZ etwa 2000 Benutzer - Internet-Zugang, E-Mail und WWW gehörten noch nicht zum Dienstangebot. Trotzdem wurde bereits ein Tool zur systemübergreifenden Benutzerverwaltung benötigt. Die Eigenlösung basierte auf einer Datenbank db++, hatte ein ASCII-Interface, bestand aus Shell- und Perl-Scripts sowie einigen C-Programmen.
Erweiterungen des URZ-Dienstangebotes und viele technologischen Weiterentwicklungen hatten unmittelbar Auswirkung auf dieses Werkzeug, mehrfach mussten Ergänzungen und Änderungen erfolgen. Spätestens 1998 war zu erkennen, dass die Lösung nicht mehr den gewachsenen Anforderungen entsprach. Die seit 1993 erfolgten Modifikationen beeinträchtigten die Übersichtlichkeit einiger Programme enorm, die Performance war schlecht, wünschenswerte Features - wie eine offene SQL-Schnittstelle - fehlten. Benutzerinterface und einige grundlegenden Protokolle waren nicht mehr zeitgemäß - eine völlig neue Lösung war gefragt.

Da auf dem Markt kein Produkt angeboten wird, welches den sehr speziellen Anforderungen entspricht, war erneut eine Eigenentwicklung notwendig.

Vorgehensweise

Vor den eigentlichen Entwicklungsarbeiten wurden alle Verfahrensansätze unabhängig von der technischen Realisierung kritisch hinterfragt.

Von Bewährtem wurde unter Beachtung der aktuellen Anforderungen der Algorithmus niedergeschrieben. Das betraf z.B. die Übernahme der vom Studentensekretariat maschinenlesbar bereitgestellten Daten zu allen immatrikulierten Studenten. Im URZ ist keine manuelle Datenerfassung notwendig, Missverständnisse durch Tippfehler können nicht auftreten.
Jeder Studierende spürt die Vorteile dieser Regelung ganz unmittelbar. Nutzerkennzeichen, Mailadresse usw. sind bereits erstellt, bevor der Student erstmals im URZ-Nutzerservice erscheint. Beantragung und Ausgabe des Accounts sind ein Vorgang. Die Wartezeit beschränkt sich auf die Dauer des Druckvorgangs, durch den alle persönlichen Daten bereitgestellt werden. Später reicht die fristgemäße Rückmeldung im Studentensekretariat für die Verlängerung der URZ-Nutzungsberechtigung aus.

Mehrfach erforderte die angestrebte Lösung aber auch tiefgreifende konzeptionelle Überarbeitungen.

Beispielsweise passten An-Institute, Honorarprofessuren, Seniorenkolleg, Studiengänge des VDE sowie studierende Mitarbeiter nicht in das 1992 entworfene Zuordnungsmodell zwischen Personen und Uni-Struktureinheiten.
Die Verwaltung von E-Mailadressen und Mailboxen bis hin zur Wartung jener Tabellen, die der zentrale Mailserver bei der Mailzustellung auswertet, war komplett in die neue Lösung zu integrieren.
Im Umfeld des Magnetkarten-Türzugangssystems bestanden neue Anforderungen. Der Geltungsbereich der vorhandenen Karten war auf die gesamte Uni auszuweiten und die TU-Card sollte gleichberechtigt verwendbar sein. Technische Voraussetzungen waren zu schaffen, neue Verfahrensweisen mussten konzipiert und mit den beteiligten Struktureinheiten sowie der Uni-Verwaltung abgestimmt werden.

Parallel zur verbalen Problembeschreibung erfolgte im Rahmen einer Diplomarbeit der Vergleich von möglichen Lösungsvarianten. Die geeignete Systemplattform (Linux), Benutzerschnittstelle (Web-Browser), Datenbank (MySQL) und Programmiersprache (PHP) wurden auf diesem Weg diskutiert und festgelegt.
Außerdem wurde der geplante Datenbankaufbau aus theoretischer Sicht untersucht und mehrere zweckmäßige Veränderungen vorgeschlagen.

Da die im Stellenplan des URZ verankerten Aufgaben kaum Freiräume für komplexe Softwareentwicklungen belassen, erforderte die Umsetzung des Vorhabens außergewöhnliche Anstrengungen. Die zu erwartenden Effekte rechtfertigten die Anstrengungen und gleichen den einmalig investierten Aufwand mehr als aus.
Das "Entwicklungsteam" bestand aus zwei Personen - einem URZ-Mitarbeiter, der sich etwa ab März 2000 vorrangig dieser Aufgabe widmen konnte und einer studentischen Hilfskraft. Mit der Auswahl des Informatik-Studenten Ronald Schmidt hatten wir eine ausgesprochen glückliche Hand. Er erwies sich als hoch begabt und engagiert - besitzt im Umfeld moderner Programmierverfahren einen hervorragenden Überblick und erstaunliche Fertigkeiten. Er realisierte Programmieraufgaben, die ganz erheblich über die übliche Hilfsassistenten-Tätigkeit hinaus gehen.

In einer Wochenend-Aktion im September - gerade noch rechtzeitig vor Semesterbeginn - konnte die neue Lösung in Betrieb genommen werden.
Die in der db++-Datenbank gespeicherten Daten wurden im ASCII-Format ausgelesen. Tabellenstrukturen wurden modifiziert, Informationen, die zuvor in ASCII-Dateien (Protokolle, Logfiles, ...) geführt wurden, waren zu integrieren und in die MySQL-Datenbank einzulesen.

Bereits in den ersten Tagen des Einsatzes erfolgte ein Härtetest des neuen Systems, da zum Semesterbeginn fast alle "Erstsemestler" ihren Account sofort abholen und sehr viele Kurse durchgeführt werden.

Wichtige Merkmale der neuen Lösung

Das neue Werkzeug, das inzwischen den Namen MoUSe (Management of User and Services) trägt, wurde als typische Klient-/Serveranwendung implementiert.

Das Benutzerinterface ist ein gewöhnlicher Web-Browser, der im Normalfall auf jedem PC und jeder Workstation vorhanden ist. Somit kann an jedem Arbeitsplatz unabhängig vom installierten Betriebssystem sofort mit MoUSe gearbeitet werden. Damit unterscheidet sich MoUSe deutlich von vielen kommerziellen Softwaresystemen aus dem Verwaltungsumfeld. Probleme wie

sind von vornherein ausgeschlossen.

NS1
Bild 1: Dispatcher-Arbeitsplatz beim Einsehen der Benutzungsberechtigung eines Studenten

Die Funktionalität von MoUSe realisieren Programme, die ein Web-Server interpretiert. Sie sind in PHP3 geschrieben und behandeln alle Details der URZ-Geschäftsabläufe:

Die Kommunikation zwischen Web-Server und Web-Klient erfolgt über eine gesicherte Netzverbindung (https). Das gilt auch für die Verbindung zum Print-Server (Web-Klient), der die Abbuchung der Druckkosten vom Nutzerkonto veranlasst.

Der Sicherheitsaspekt erfordert, dass verschiedene Anwendergruppen mit unterschiedlichen Befugnissen auf das System zugreifen. Beispielsweise besitzen URZ-Mitarbeiter mit speziellen Aufgaben (Postmaster, Sachbearbeiter Finanzen) andere Rechte als die Dispatcher im URZ-Nutzerservice und nur die Mitarbeiter in den Fakultäten, welche die Zugangsbefugnisse zu Räumen festlegen, können MoUSe dazu benutzen.
Die Vergabe der Zugriffsprivilegien erforderte keine spezielle Programmlösung, sondern es wird das vom Apache-Server vorgesehene Verfahren benutzt (.htaccess).

NS2
Bild 2: Dispatcher-Arbeitsplatz beim Bearbeiten von Anwesenheitslisten

Die Anwendung von MoUSe ist denkbar einfach. Da es in der gewohnten Umgebung des Web-Browsers läuft, ist die Kenntnis der Wirkungsweise aller Bedienelemente gegeben.

Zur Datenspeicherung dient MySQL - ein kleines Datenbanksystem, das eigentlich alles kann. Es zeichnet sich durch Zuverlässigkeit, schnellen Zugriff, überschaubare Tools, guten Support, die Unterstützung vieler Programmiersprachen und einfache Administration aus. Insbesondere die Einbindung in PHP ist unglaublich einfach.
Für MoUSe verwaltet der MySQL-Server z.Z. etwa 40 Relationen. Diese Tabellen sind so strukturiert, dass Suchvorgänge, Updates usw. effektiv und flexibel möglich sind. MySQL-Klient sind die oben erwähnten PHP-Programme. MySQL-Server und -Klienten laufen zwar auf dem gleichen Rechner, trotzdem ist auch hier das Klient- Serverprinzip konsequent eingehalten.

Als dedizierte Servermaschine dient ein normaler PC mit AMD Athlon Prozessor 600 MHz, 512 MB RAM und einer 20 GB IDE-Festplatte. Betriebssystem ist Red Hat Linux Version 6.2. Es läuft ein MySQL-Server (z.Z. Version 3.23) und ein http-Server Apache (z.Z. Version 1.3.).

Dem sachkundigen und aufmerksamen Leser wird auffallen, dass MoUSe ausschließlich auf kostenfreier Open-Source-Software aufbaut!

MoUSe ersetzt nicht die Instrumentarien, welche die Systemanbieter zur Benutzerverwaltung einer AFS-Zelle, einer Windows-, NIS- oder Maildomain bereitstellen. Das System erzeugt vielmehr die Daten für deren Stapelinterfaces und garantiert, dass alle Einträge in den verschiedenen Systemwelten inhaltlich zusammenpassen. Beim Löschen von Accounts bleiben wichtige Informationen in der MySQL-Datenbank gespeichert.
Damit ermöglicht MoUSe einige neue Qualitäten:

Jedem Nutzer wird eine Verbindung zur MySQL-Datenbank bereitgestellt. Hier kann der Nutzer alle Daten, die ihn betreffen, einsehen und verschiedene Aktionen veranlassen. Dieses Interface wird z.Z. noch weiter ausgebaut.

Eine SQL-Schnittstelle für URZ-Mitarbeiter erlaubt vielfältige Abfragen und statistische Auswertungen.

MoUSe gehört zu den Systemen, die vom "Endnutzer" kaum wahrgenommen werden, solange alles funktioniert. Pannen haben aber sehr unangenehme Auswirkungen. Deshalb laufen jede Nacht mehrere Programme, welche die in der Datenbank gespeicherten Informationen auf Integrität und Plausibilität kontrollieren und Gegenüberstellungen mit der NIS-Map, der AFS-VLDB und anderen Datenbasen durchführen. Das bietet die Gewähr, dass Probleme frühzeitig erkannt und gelöst werden können.

Was bleibt noch zu tun ?

Erwähnt wurde bereits, dass das Interface, welches jedem URZ-Nutzer angeboten wird, noch nicht die vollständige Funktionalität besitzt. Es gibt verschiedene Ideen, welche weiteren Informationen wir unseren Nutzern auf diesem Weg bereitstellen wollen. Außerdem soll der Nutzer eine Reihe von Aktionen bei Bedarf selbst anstoßen können (z.B. die An- und Abmeldung zu einem Kurs, die Möglichkeit der Umbuchung von Finanzen). Vorschläge aus dem Kreis der Nutzer nehmen wir gern entgegen.

Eine umfangreiche noch ausstehende Aufgabe ist die Reorganisation der Verwaltung von Ausleihen aller Art. Diese Funktionalität wird gegenwärtig noch mit der "alten" Datenbank erledigt.

Ein Problem ist die Verwaltung der Zugehörigkeit von Benutzern zu jenem Personenkreis, der Leistungen des URZ in Anspruch nehmen darf. Bei Studenten ist das (siehe oben) bereits optimal geregelt - bei Mitarbeitern der TU dagegen noch nicht. Ein Dokument mit dem sich TU-Mitarbeiter zweifelsfrei als solche ausweisen können (TU-Card), wäre beim Erfassen neuer Mitarbeiter hilfreich. Der bisherige Verfahrensweg auf dem das URZ über die Beendigung von Arbeitsverhältnissen informiert wird, ist langwierig, fehleranfällig und aufwendig. Sinnvolle Regelungen sind angedacht und werden technisch umgesetzt.

In Zukunft wird es mit Sicherheit Veränderungen am Dienstangebot des URZ geben und nicht selten werden diese ihre Auswirkung auf die erforderlichen Verwaltungsprozesse haben. Die Schnittstellen des neuen Systems sind so gestaltet, dass Modifikationen und Erweiterungen relativ einfach möglich sind.

Im Rahmen von Überlegungen, wohin sich Verwaltungswerkzeuge entwickeln müssen, kommt unwillkürlich auch folgender Gedanke.
URZ und Uni-Bibliothek haben jeweils eine Datenbank mit Angaben über ihre Benutzer. Der Benutzerkreis und die pro Benutzer gespeicherten Attribute stimmen weitgehend überein. Die zu verwaltenden Dienste sind ähnlich. Besonders effektiv ist die "doppelte Datenhaltung" nicht, über Varianten zur Integration muss nachgedacht werden.

Dietmar Grunewald, Januar 2001