Humboldt-Universität Berlin - Rechenzentrum

Einführung von DCE
im Netz der Humboldt-Universität
Winfried Naumann
Humboldt-Universität zu Berlin/Rechenzentrum
5. DCE-Workshop, Augsburg 11./12.11.99

Die folgenden Ausführungen gelten nur für
den Hochschulbereich
- die Charité (Medizinische Fakultät) betreibt
ein relativ eigenständiges Netz.

Der Zeitplan
vor 2 Jahren:
Entscheidung für die Einführung von
DCE/DFS
vor 1 Jahr:
Beginn der Einführung in die Produktion
(Einrichtung der DCE-Zelle,
Übernahme der NIS-Passwörter, ...)

in der Zwischenzeit:
– Test aller (Betriebs-) Systeme innerhalb von
Testzellen auf Lauffähigkeit, Stabilität
– Testen aller bisher angebotenen Dienste,
ob Sie in DCE/DFS integrierbar sind
(Mail-, Web-, Radius-, FTP- , Computeu.a.
Server, Einwahlmöglichkeiten,
Abrechnungssystem)

– Testen der Integrationsmöglichkeiten für
PC-Clients/Server
– Test, ob alles mit unserem Namenskonzept
funktioniert
(Accounts der Form dept/user, z.B rz/awn,
siehe später)

1.4.99
Wunsch-Termin für die Umstellung auf
DCE/DFS,
nicht gescheitert an DFS,
sondern am Programmierungsaufwand
für das Abrechnungssystem
4./5.12.99 = Tag X (in 3 Wochen)
endgültiger Umstellungstermin :-)

siehe auch:
Frank Sittel,
Einführung von DCE am Rechenzentrum
http://www.hu-berlin.de/rz/rzmit/rzm16/6.html
(Artikel in den RZ-Mitteilungen Nr. 16,
Juni 1998)

Das HU-Netz
– ca. 25.200 Benutzer im NIS (vor einem Jahr
noch 16.000),
pro Semester ca. 4000 Accounts
– ca. 600 Workstations (Solaris, AIX, Digital
UNIX, Irix, HP-UX, Linux)
– 12 dezentrale Fileserver (Solaris, AIX)

– UniTree auf CONVEX C3820 ES mit
Metrum VHS-Robotersystem RSS-600
(HSM),
SM-arch (Software Moguls)
Ablösung wegen Jahr 2000-Problem
– ca. 3500 PCs
– PC-Netz unter Banyan VINES:
90 Server, ca. 5000 Benutzer

Konzept der DCE-Zelle
Entwurf, Projektleiter:
Frank Sittel
sittel@rz.hu-berlin.de

1.Einplanung der Möglichkeit einer
dezentralen Verwaltung innerhalb der Zelle.
(nach einem Konzept von Dr. Dieter Mack,
Uni Hohenheim, siehe
http://www.uni-hohenheim/rz/mack/mack.html)

Möglichkeiten:
– für die einzelnen Struktureinheiten hierarchische
Zellen ausgründen;
– innerhalb einer Zelle eine Struktur erzeugen, die
gegeneinander abgeschirmte, administrative
Bereiche im CDS-, DFS- und Security-Bereich
enthält;
Wir haben uns für die zweite Variante entschieden.

– Einschieben einer zusätzlichen Directory-Ebene
für die einzelnen Struktureinheiten (/dept), an
der die entsprechenden Rechte für lokale
Administratoren befestigt werden;
– Nutzung der Eigenschaft, auch im Security-
Bereich Directories anlegen zu können;
– ähnl. Verfahren im CDS-Raum für die host-
Einträge und im DFS-Raum für die
Dateiverzeichnisse;

– Nachteil:
es entstehen Accounts, die das Directory (für
die Strukturebene) im Namen enthalten,
was zu Schwierigkeiten mit diverser Software
führt (dazu später);
Beispiele:
alt
neu
Accounts: h0043xyz rz/pwn
Gruppen: p0043 rz/sys

– zusätzlich wird zum Directory
der Struktureinheit (z.B. bio) ein User-Objekt
(bio) erzeugt,
damit z.B. Dinge wie cd ~bio/xbn
funktionieren;
Pfade im DFS:
/.../dce.hu-berlin.de/fs/home/org/group/ident
Bsp.
/.../dce.hu-berlin.de/fs/home/med/stud/awn

2.Jeder Benutzer erhält ein eigenes Fileset
(sonst funktionieren Quotas nicht).
3.“Einsammeln” der NIS-Passwörter und
Eintragung in die DCE-Registry seit dem
Start der DCE-Zelle mit entspr.
angepaßtem Perl-Skript ANLpasswd
(überwacht bei uns die Eingabe besserer
Passwörter).
ftp://info.mcs.anl.gov/pub/systems/anlpasswd.tar.Z

Jeder Passwort-Wechsel wird seitdem in
beiden Systemen vollzogen (NIS, DCE),
ohne daß sich für die Benutzer etwas ändert.
4.Der alte Account (Form h0zzzaaa) wird in
der DCE-Registry als Alias zum neuen
Account (Form dept/aaaa) weiter
mitgeführt.
– die Registry hat z.Z. ca. 50.400 Einträge;

– in der Phase bis zur endgültigen Abschaltung
von NIS (Tag X) können die Clients bereits auf
DCE umgestellt werden;
Nutzer, denen bereits ein DCE-Login gelingt,
werden im NFS Home Directory abgesetzt.
– auch am Tage X+y gelingt Benutzern, die die
Umstellung verschlafen haben weiterhin das
Login mit altem Account,
besser:
wir brauchen den Benutzern erst nach dem
Abklingen der Umstellungsprobleme zu
erklären, daß ihr Account anders lautet.

aktuelle Konfiguration
– DCE 1.2.2 auf allen Maschinen
(außer Solaris: Fileservice und Clients
1.2.2, Security Service und CDS 1.1)
– z.Z. Security-Server und CDS auf einer
extra Maschine (SPARC Ultra1, 256 MB,
Fast Ethernet), später auf DFS-Server

– 2 DFS-Server (später Einbeziehung der
vorhandenen dezentralen Fileserver):
SPARC Ultra2, 2x300 MHz, 512 MB bzw.
1GB RAM, Fast Ethernet, Solaris 2.6,
jeweils mit Storage Array IBM T40 (z.Z.
nur 72 GB für Aggregate)
Ausfallsicherheit:
jede Maschine nutzt nur eine Hälfte ihres
T40 und spiegelt jeweils auf die zweite
Hälfte des anderen T40 (noch Test).

– Mail-Server (sendmail):
läuft auf den DFS-Servern (Ausfallsicherheit
durch Redundanz),
schreibt in die Inboxen per epimount
(zur Performance-Steigerung, müßte sonst
die eigene Maschine erst über CDS
kontaktieren)
deshalb Solaris (epimount z.Z. nur dort
implementiert);
Nachfragen an:
Burckhard Schmidt (bschmidt@rz.hu-berlin.de)

– POP3- und IMAP-Server:
IBM RS6000/43P-260 (2 CPU, 512 MB
RAM, Fast Ethernet), AIX 4.3.2
zweite Maschine zur Zeit nur für den
Havariefall,
Verteilung auf weitere Maschinen wegen zu
erwartender hoher Last ist geplant;
IMAP-Server der U Washington
ftp://ftp.cac.washington.edu/mail/imap-4.5.tar.Z

DCE-Patch von Paul B. Henson
http://www.intranet.csupomona.edu/~henson/www/
projects/dce_patches/imap
getestet auch unter Solaris
Nachfragen an:
Burckhard Schmidt (bschmidt@rz.hu-berlin.de)

– Web-Server:
– Solaris 2.6
– z.Z. noch Apache 2.3.3 mit Modul
mod_auth_dce von Paul B. Henson
(verfügbar auch für 2.3.9)
– ! Problem mit Namenskonzept (siehe dort)
http://www.intranet.csupomona.edu/~henson/
www/projects/mod_auth_dce/dist/
http://www.csupomona.edu/~intranet/implementation/http.html
Nachfragen:
Winfried Naumann (w.naumann@rz.hu-berlin.de)

– Radius-Server:
(Authentifizierung bei Zugang über Wählverbindungen,
Türöffnung bei einigen PC-Pools)
– Server von MERIT,
Version 3.5.6 bzw. 3.6.0.b
– DCE-Unterstützung als Option beim
Kompilieren
– bei uns unter Digital Unix (3 Maschinen)
Nachfragen:
Jens-Uwe Winks (winks@rz.hu-berlin.de)

– Compute-Service:
CODINE (Resource-Managment-System)
GENIAS Software GmbH
http://www.genias.de/products/codine/
http://www.hu-berlin.de/rz/compsv/codine.html
DCE-Unterstützung ab Version 5.0,
von Genias in DCE-Zelle der HU unter
Digital Unix entwickelt;
Nachfragen:
Daniela-Maria Pusinelli (pusinelli@rz.hu-berlin.de)

– Backup:
– ADSM (z.Z. Version 3, Release1, Level 2.40)
–auf IBM H70,
Library: IBM 3590 (Magstar)
– Ablösung für CONVEX/UniTree/SM-arch
– entspr. Clients mit DFS-Unterstützung
Nachfragen:
Christoph Weickmann (weickmann@rz.hu-berlin.de)

– Windows-Clients:
– kommerzielle Software (Gradient) getestet
– Anschaffungskosten zu hoch
– Ausweichen auf Lösungen mit Samba:
z.Z. Samba 2.0.4b unter Solaris 2.6
mit DCE-Patch von Paul B. Henson
http://www.intranet.csupomona.edu/~henson/www/
projects/dce_patches/samba/
(auch für Samba 2.0.5a verfügbar)
http://www.csupomona.edu/~intranet/implementation/
smb.html

– noch ohne sec_auth von Paul B. Henson
(verschlüsselte Paßwort-Übertragung,
nicht getestet,
erfordert Kerberos5-Bibliotheken,
erwarten noch Domestic Version von Transarc)
– damit auch Ablösung des Banyan VINES-
Zugangs für Studenten:
erstmals Bereitstellung von persönlichem
Plattenplatz in PC-Pools möglich (Zugriff mit
Samba auf Home-Directories im DFS),
unter VINES für Studenten nur begrenzt
ermöglicht (keine Quotas);

– Authentifizierung in PC-Pools (Windows NT):
lokale Anmeldung als Dummy-User mit
Autologon und minimalem Angebot an
Programmen (keine Kommunikation),
Browser, Mailtools erst nach DCE-Login
verfügbar (z.Z. über Samba);
– ! Problem mit dem Namenskonzept (siehe dort)
Nachfragen:
Winfried Naumann (w.naumann@rz.hu-berlin.de)

– Abrechnungssystem:
– Datenbank unter Sybase 11.x
– programmiert in SQL und das GUI in Java
(PowerJ)

Probleme mit dem
Namenskonzept
– Web-Server:
URLs der Form http://server/~user
Lösung durch Links:
ln -s rz/awn/public_html rz/public_html/awn
standardmäßig für alle Benutzer

– fts lsquota
funktioniert nicht unter Solaris, AIX
Lösung:
Ausführung über sudo (als root)
– elm, ssh1 u.a. (freie) Programme (deren
Quelltext verfügbar ist),
wollen temporäre Dateien anlegen, die den
Benutzernamen enthalten:
Änderung im Quelltext: ‘/’ im Namen wird
durch ‘_’ (Unterstrich) ersetzt.

– Kommerzielle Programme (z.B. Sun
mailtool) funktionieren nicht mehr.
– Windows-Clients (Anmeldung über
“Netzlaufwerk verbinden” u.ä):
der Schrägstrich im Benutzernamen ist ein
verbotenes Zeichen.
Lösung:
Samba gepatcht (Umwandlung ‘_’ in ‘/’),

Benutzer melden sich mit Unterstrich im
Namen an (rz_awn statt rz/awn) oder
benutzen von die von uns programmierte
Eingabemaske.
Möglichkeiten mit GINA verworfen:
• keine Windows-Programmierer;
• GINAs anderer Unis (U NotreDame
u.a.) nicht bekommen;
• nur für Windows NT

unsere Fragen:
– was machen Sie mit alten,verfallenen
Tickets, die sich ansammeln ?
– Stand von Linux und DCE ?

Ihre Fragen ?

Kontakt:
Frank Sittel (Projektleiter)
sittel@rz.hu-berlin.de
Winfried Naumann
w.naumann@rz.hu-berlin.de