Arbeitsvorhaben für den T-Bereich
am FB 3 der Universität Bremen

Cornelia Zahlten
Oliver Laumann
Jan Peleska

Diese Aufstellung enthält einige kurz- bis mittelfristige Arbeitsvorhaben zur Verbesserung und Weiterentwicklung des FB3-Rechnernetzes der Universität Bremen. Die Hauptziele der Arbeitspunkte sind

Der aktuelle Status der im folgenden aufgeführten Arbeitsvorhaben ist aus einem separaten Dokument ersichtlich, das vom T-Bereich kontinuierlich aktualisiert wird.

1. Dokumentation und Transparenz

1.1 Definition von Policies für die Nutzer und Betreiber des FB3-Netzes

Benötigt wird eine Policy, die die Zuteilung und Benutzung der Rechnerressourcen des Fachbereichs regelt und die Rechte und Pflichten der Benutzer und der Betreiber des FB3-Netzes definiert. Zur Zeit ist beispielsweise unklar, wann der T-Bereich in Benutzerdaten eingreifen (z.B. WWW-Seiten sperren) darf. Darüberhinaus müssen spezifische Policies und Verfahrensweisen für die einzelnen Bereiche des FB3-Netzes definiert werden, z.B. Richtlinien für die Installation von Software, eine Vorgehensweise bei Systemeinbrüchen, eine Security-Policy und ein Backup-Verfahren.

1.2 Erstellung von Benutzerdokumentation

Dringend benötigt wird ausführliche und aktuelle Dokumentation (als Hypertext-Dokumente im WWW) für die Benutzer des Fachbereichsnetzes. Dokumentiert werden müssen unter anderem die verfügbare Software und deren Benutzung, die eingesetzte Hardware und ihre Benutzung (insbesondere auch die Bedienung sensibler Geräte wie Scanner und CD-Brenner), die Service-Angebote des T-Bereichs, die gängigen Verfahren und Richtlinien im Zusammenhang mit Kommunikationsdiensten wie WWW und Netnews (Erstellen eigener Homepages, ``Netikette'', etc.) und die verwendeten Konzepte, Regelungen und Verfahren innerhalb des T-Bereichs.

1.3 Bekanntmachung von Neuigkeiten

Der T-Bereich muß sicherstellen, daß seine ``Kunden'' über Neuerungen und wichtige Änderungen im Fachbereichsnetz und im technischen Bereich rechtzeitig informiert werden, insbesondere über neu installierte Softwarepakete, neu beschaffte Geräte, geplante Downtimes, Hardwareupgrades und Ausfälle von Komponenten der Arbeitsumgebung. Dies sollte durch das Veröffentlichen entsprechender Nachrichten in den lokalen fb3-Newsgroups geschehen, gegebenenfalls mit Verweisen auf WWW-Seiten mit weiterführenden Informationen. Gleichzeitig müssen die Benutzer dazu motiviert werden, die lokalen Newsgroups regelmäßig zu lesen.

1.4 Ein Konzept für die Bearbeitung von Benutzerbeschwerden

Der T-Bereich muß sicherstellen, daß über das Service-Request-System (``mail service'') eingereichte Benutzerbeschwerden und -anfragen schnell und in für die Benutzer zufriedenstellender Weise abgearbeitet und beantwortet werden. Gleichzeitig muß das Verwerfen unbearbeiteter Service-Requests ausgeschlossen werden. Dieser Arbeitspunkt betrifft ebenfalls Beschwerden und Anfragen, die von Benutzern in den fb3-Newsgroups des T-Bereichs veröffentlicht werden. Voraussetzung hierfür ist, daß die Mitarbeitenden des T-Bereichs regelmäßig die Fachbereichs-Newsgroups lesen.

1.5 Einrichtung und Pflege eines Softwareinventars

Sowohl die Benutzer am Fachbereich als auch die Mitglieder des T-Bereichs benötigen häufig Informationen darüber, welche Version eines Softwarepakets auf welchen Plattformen installiert ist, wer es installiert hat, wer dafür verantwortlich ist, wer die Software wartet, etc. Zur Zeit lassen sich solche Fragen nicht zuverlässig beantworten. Daher sollte über jedes im Workstationnetz installierte Softwarepaket in einer Inventar-Datenbank Buch geführt werden (ähnlich der bereits eingeführten Rechner-Inventarisierung über die Hostdatenbank).

1.6 Hostdatenbank: Erhöhung der Akzeptanz und Weiterentwicklung

Damit die Hostdatenbank das aktuelle Rechnerinventar jederzeit korrekt und vollständig wiedergibt, muß die Akzeptanz in einigen Arbeitsgruppen (insbesondere auch im zentralen T-Bereich) erhöht werden. Ferner muß diskutiert werden, wie die Hostdatenbank erweitert werden kann, um sie besser den Bedürfnissen der Benutzer und des T-Bereichs anzupassen (z.B. Definition neuer Capabilities).

1.7 Mail-Aliases überarbeiten bzw. einrichten

E-Mail an root, postmaster und mailer-daemon wird zur Zeit in der Mailbox eines einzelnen Mitarbeiters gesammelt. Um eine zügige Bearbeitung zu gewährleisten (insbesondere von externen Beschwerden), sollten die Aliases auf ein Team von ca. zwei bis vier Mitarbeitenden verweisen (``Reponse-Team''). Weiterhin müssen auch die anderen Standard-Mail-Adressen (z.B. abuse) eingerichtet werden (die Adressen sind beschrieben im Internet-Draft ``draft-vixie-ops-stdaddr-01''). Ferner muß sichergestellt werden, daß E-Mail an administrative Logins (z.B. grpadm) gelesen und bearbeitet wird.

2. Zentrale Dienste

2.1 Überarbeitung des Server-Konzepts für zentrale Dienste

Die Auslastung, Zuverlässigkeit und Funktionalität zentraler Server und Dienste (Mail, News, Compute-Server, etc.) müssen überprüft und gegebenenfalls verbessert werden. Dies schließt die Modernisierung und den Ausbau der verwendeten Plattformen ein (z.B. Erhöhung der Plattenkapazität, Aktualisierung der Software-Versionen).

2.2 Erstellung und Realisierung eines Konzepts für den WWW-Server am FB3

Dieser Arbeitspunkt umfaßt sowohl die Überprüfung der Auslastung und gegenbenenfalls den Ausbau der eingesetzten Hardwareplattform und WWW-Server-Infrastruktur, als auch die Anhebung des Sicherheitsniveaus und der Zuverlässigkeit des Servers. Verschiedene Fragen im Zusammenhang mit der Administration unseres zentralen WWW-Servers müssen geklärt werden (Zulassen von CGI-Skripten der Benutzer, Konfiguration des Servers, Rotieren der Logfiles, Vermeidung von Ausfällen, etc.). Darüberhinaus sind der Aufbau eines WWW-Proxys und die Teilnahme am deutschlandweiten WWW-Cache-Verbund des DFN geplant.

2.3 Überarbeitung der fachbereichszentralen WWW-Seiten

Um die Außendarstellung des Fachbereichs im World Wide Web zu verbessern, müssen die zentralen WWW-Seiten überarbeitet und aktualisiert werden. Der T-Bereich sollte den Nutzern (insbesondere der FB-Verwaltung) ermöglichen, eigene Informationen und Dienste selbständig in den fachbereichszentralen WWW-Seiten anzubieten, damit auch in Zukunft eine hohe Aktualität des Angebots sichergestellt ist. Hierbei könnte eine Unterstützung der Anbieter durch Schulungen und geeignete Werkzeuge nützlich sein.

2.4 Einrichten eines FTP-Servers für den Fachbereich und das TZI

Die Einrichtung eines eigenen FTP-Servers für den Fachbereich und das Technologie-Zentrum Informatik ist sinnvoll, um vom Uni-zentralen Server unabhängig zu werden. Dies hätte unter anderem die Vorteile, nicht unter den Ausfällen des zentralen Servers leiden zu müssen, Files unter freier Bestimmung der Pfadnamen anbieten zu können, und in eigener Regie Files von externen Servern spiegeln zu können.

2.5 Zentrale ``Sammelbeschaffungen'', Kosteneinsparung und Kostenumlage

Der zentrale T-Bereich bietet zur Zeit einige kostenpflichtige Services fachbereichs- und zum Teil universitätsweit an (ISDN-Zugang, Sun-Service-Vertrag, etc.). Der erzielten Kosteneinsparung durch solche ``Sammelbeschaffungen'' steht ein recht hoher Verwaltungsaufwand gegenüber. Hier fehlen einerseits Werkzeuge zur effizienten und pünktlichen Bearbeitung der Kostenumlage, andererseits ist zu prüfen und festzulegen, welche Dienste auf diese Weise angeboten werden sollen.

3. Fachbereichsnetz-Infrastruktur

3.1 Replizieren von Filesystemen auf Arbeitsgruppen-lokalen Servern

Wichtige zentrale Filesysteme (insbesondere /usr/local) sollten auf lokalen Servern der Arbeitsgruppen gespiegelt werden, um größeren Schutz vor Ausfällen und eine Verringerung der Netzlast zu erreichen. Benötigt werden ein einfaches Konzept für das Einrichten, Aktualisieren und automatische Auffinden gespiegelter Filesysteme; ein Konfigurationsfile und einige Scripts müssen entworfen und erstellt werden.

3.2 Einführung von Zeitsynchronisation mit NTP

Die Gangungenauigkeiten der Rechneruhren verbunden mit dem Fehlen einer Zeitsynchronisation der Rechner im Fachbereichsnetz führt unter anderem zu Problemen bei der Benutzung von ``Makefiles'' (die Abweichung von der korrekten Zeit beträgt auf den meisten Rechnern mehrere Minuten). Benötigt wird eine Installation von xntp und ein Konzept zur Konfiguration. xntp basiert auf dem Network Time Protocol (RFC 1305) und dient dazu, Rechneruhren millisekundengenau mit UT zu synchronisieren; als Referenz dient eine externe Zeitquelle (Funkuhr) oder ein externer Peer-Rechner.

3.3 Überarbeitung der UNIX-Drucker-Infrastruktur im Fachbereichsnetz

Die öffentlichen und arbeitsgruppenlokalen unter UNIX zugänglichen Drucker im Fachbereich werden zur Zeit (unter anderem) mit einer älteren Version von PLP, mit der Solaris/System-V-Druckersoftware, mit CAP/AppleTalk, sowie mit einem an der TU-Berlin entwickelten Programm zur Verwaltung von Seiten-Quotas betrieben. Wegen der zum Teil schwierigen Wartung einiger dieser Komponenten und der Zuverlässigkeitsprobleme im Zusammenhang mit dem Seiten-Accounting bietet sich das einheitliche Aufrüsten aller Drucker auf LPRng an. LPRng (LPR: Next Generation), der Nachfolger von PLP, ist ein modernes und portables Drucker-Spooler-System mit umfangreicher Funktionalität, das die klassischen UNIX-lpr-Kommandos emuliert und unter anderem das für eine universitäre Umgebung sinnvolle zuverlässige Seiten-Accounting bietet. Ferner muß /etc/printcap vereinheitlicht werden, um das Ansprechen beliebiger Drucker am Fachbereich unabhängig von der gerade benutzten Workstation zu ermöglichen (siehe auch Arbeitspunkt 4.5).

3.4 Filesystem und Policy zum autonomen Installieren von Software

Ein allgemein zugängliches und für ,,world'' schreibbares UNIX-Filesystem hinreichender Größe ermöglicht den Benutzern das eigenverantwortliche und netzweite Installieren von Software und gegebenenfalls anderen Daten (Video, Audio, Images). Zur Unterstützung werden einige einfache Installationsrichtlinien sowie Prozeduren zum periodischen ,,Ausmisten'' des Filesystems benötigt. Ein solches Filesystem erlaubt den Benutzern das Ausprobieren neuer oder experimenteller Programm-Versionen, ohne auf eine zentrale Installation warten zu müssen, und es verringert den Plattenplatzbedarf durch das Vermeiden von Mehrfachinstallationen in den Homedirectories der Benutzer.

4. Systemadministration

4.1 Erstellung eines Konzepts für die Installation von Software im FB3-Netz

Verschiedene Softwarepakete im FB3-Netz wurden seit langem nicht mehr aktualisiert, und neue Software wird zur Zeit nur selten oder nur für einen Teil unserer Plattformen installiert. Neuinstallationen und Upgrades müssen nicht nur regelmäßiger durchgeführt werden, sondern auch in der Newsgroup fb3.t.announce angekündigt werden; alte Versionen müssen für eine Übergangszeit aufbewahrt werden, etc. (Hier geht es weniger um kommerzielle, vom Fachbereich beschaffte Software, sondern um frei verfügbare Systeme wie Emacs, gcc, ghostscript, perl, X11, etc.)

4.2 Entwerfen und Realisieren einer Logging-Policy

Das zentrale Sammeln der Logdaten der einzelnen Rechner ist eine Voraussetzung, um Fehler und vermutete Systemeinbrüche wirksam analysieren zu können. Hierzu muß ein ``Loghost'' mit einem passenden Filesystem ausgewählt und die syslog-Konfigurationsfiles vereinheitlicht und überarbeitet werden. Des weiteren müssen die einzelnen Logfiles periodisch rotiert und alte Files eventuell archiviert werden. Das Löschen aktueller oder jüngerer Logfiles muß ausgeschlossen werden.

4.3 Anhebung des Security-Niveaus im FB3-Netz

Um die bestehenden Sicherheitsdefizite im FB3-Netz möglichst umgehend und systematisch zu beheben, wird in folgenden Schritte vorgegangen:

  1. Erfassen und Bewerten von Sicherheitslücken auf Grundlage der CERT-Advisories und der Ergebnisse aus dem Projekt STRAIT und dem T-Bereich;
  2. Beseitigen der Lücken durch Einspielen von sicherheitsrelevanten Vendor-Patches und zusätzlichen Sicherheitsmechanismen;
  3. Verbessern des Security-Monitoring zur Aufdeckung von Systemeinbrüchen und Sicherheitslücken.

4.4 Automatisches Abgleichen von lokalen Filesystemen

Mit der wachsenden Anzahl von Rechnern jeder Plattform wird es zunehmend schwieriger, Probleme zu analysieren und Upgrades durchzuführen, wenn die (lokalen) Filesysteme der einzelnen Rechner nicht auf einem gemeinsamen Stand sind. Dieses Problem kann durch autmatisches, periodisches Abgleichen der Filesysteme mit einer ``Master-Kopie'' gelöst werden (z.B. einmal pro Nacht). Änderungen werden nur noch in der Master-Kopie für die jeweilige Plattform vorgenommen; das Durchführen lokaler Änderungen auf einzelnen Rechnern (wie bisher üblich) muß dann unterbleiben.

4.5 Zentrales Generieren lokaler Konfigurationsfiles

Files wie /etc/passwd, /etc/printcap und /etc/inetd.conf unterscheiden sich oft (wenn auch geringfügig) auf den einzelnen Rechnern. Um Wildwuchs vorzubeugen und um das Durchführen von Änderungen (z.B. des root-Passwords) und System-Upgrades zu erleichtern, sollten auch diese Files aus zentralen ``Master-Kopien'' generiert werden. Hierbei muß über die hostspezifischen Abweichungen (z.B. zusätzliche lokale Einträge in /etc/passwd) Buch geführt werden, und die ``lokalisierten'' Versionen der Files müssen erzeugt und auf den Zielrechnern installiert werden können.

5. Koordination

5.1 Integration Informatik-Netz/Mathematik-Netz

Die Integration der Informatik-Subnetze und Mathematik-Subnetze muß fortgeführt und abgeschlossen werden, um allen Benutzern im Fachbereich eine einheitliche Arbeitsumgebung zu bieten und um die Systemadministration zu erleichtern. Dies schließt die Aufnahme aller Rechner in die Hostdatenbank des Fachbereichs ein, um auch die DNS-Zonendaten der Domäne mathematik.uni-bremen.de sowie die NIS-Files automatisch generieren zu können. In diesem Zusammenhang muß geklärt werden, ob für die Mathematik-Domänen weiterhin NIS+ eingesetzt werden soll, und falls dies gewünscht wird, wie eine geeignete Integration von NIS und NIS+ realisiert werden kann.

5.2 Festlegung der Aufgabenteilung innerhalb des T-Bereichs

Zur Zeit ist oft unklar, welche Mitglieder des T-Bereichs für welche Aufgabenbereiche (z.B. Rechnerplattformen, Software) im technischen Bereich jeweils die Ansprechpartner sind. In diesem Zusammenhang muß eine größere Transparenz gegenüber den ``Kunden'' des T-Bereichs geschaffen werden. Ferner wird ein Notfall- und Vertretungskonzept benötigt.

Oliver Laumann · net@informatik.uni-bremen.de
Cornelia Zahlten · cmz@informatik.uni-bremen.de
Jan Peleska · jp@informatik.uni-bremen.de