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 |
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 |
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.
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.
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.
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).
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.
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 |