Tags:
create new tag
, view all tags

Storage-Service

Beteiligte Personen

  • Willi Engeli (ID Systemdienste) auf Seite Storage / NAS-DFS
  • Swen Vermeul (WAI - ID Basisdienste) auf Seite nethz
  • Matteo Corti (Gruppenleiter WAI - ID Basisdienste)
  • Peter Bircher (ID Basisdienste)
  • Tilo Steiger (Gruppenleiter Storage - ID Systemdienste)
  • Jürgen Winkelmann (ID Systemdienste)

Ausgangslage und Mängel des jetzigen Systems

Das frühere AFS-Dateisystem und der dazugehörige nethz-Service wurden im August 2007 abgelöst. Das neue NAS-System, welches im Herbst 2007 eingeführt wurde, sollte ursprünglich ebenfalls mit einem entsprechendem nethz-Service ausgestatt werden. Aufgrund anderer Projekte und Prioritäten wurde dieser Service nie implementiert (respektive nur als Dummy-Service). Die Folge ist, dass Home-Directories von abgelaufenen Kontos nie gelöscht wurden und (nicht ganz billigen) Speicher auf dem NAS belegen.

Der Unix-Zugang zum DFS erfolgt zur Zeit via Sharity. Marcus Möller erarbeitet eine neue Lösung für den Zugang. Auch hier werden Managementmöglichkeiten benötigt. Insbesondere das UID Mapping UNIX/WINDOS Benutzer muss noch standardisiert eingeführt werden.

Mängel am jetzigen System

  • durch die fehlende automatisierte Löschung werden manuelle Eingriffe und Korrekturen im automatisierten Betrieb notwendig
  • die Anzahl entsprechender Tickets im Jahr 2010 ist heftig gestiegen
  • es muss jetzt individuell der Besitzer der veralteten Benutzerdirectories abgeklärt werden und führt so zu bei falscher Neuberechtigung zu einer potentiellen Persönlichkeitsverletzung.
  • die Zuweisung oder Löschung eines DFS-Services zu einem User hat absolut keine Wirkung
  • die Zuständigkeiten für den Betrieb des DFS sind zur Zeit nicht klar geregelt
  • die Primäre Gruppe (primary group) eines Users kann heute weder für AD- noch für LDAPS-Kontos geändert werden

Ablauf der Generierung eines DFS-Kontos (nach bisherigem Wissensstand):

  • ein Webservice von Peter Bircher (http://webservice.ethz.ch/cgi-bin/adpasswd )
    • sucht periodisch das gesamte AD nach Usernamen ab
    • generiert einen Output im Stile eines passwd-Files
  • ein Skript von Jürgen Winkelmann (...)
    • übernimmt den Output dieses Webservices
    • generiert damit NAS/DFS Directories für CIFS/SMB Clients
    • generiert die passwd entries auf den entsprechenden NAS-Server
    • setzt die Berechtigungen (ACLs) für die CIFS/SMB Clients

Das NAS ist zur Zeit noch nicht in LDAPS integriert. Das heisst, dass die Benutzersynchronisation zwischen CIFS/SMB und NFS mittels Scripts auf verschiedenen Maschinen ausgeführt werden müssen.

involviert sind dabei:

Service Hostname
DFS nas-dfs-1.d.ethz.ch
NAS

nsx1-cs.ethz.ch

nsx2-cs.ethz.ch

Unix -server nas-proxy

technische Randbedingungen

Auf das Filesystem muss sowohl Windows- als auch UNIX-mässig zugegriffen werden können. Die Authentisierung wie auch die Authorisierung läuft über das Active Directory (AD).

Ein FTP Service stellt den Benutzern auch einen Zugriff von Extern auf Ihre Homepage zur Verfügung. Dieser Service benötigt einen gültigen NAS/DFS Phad auf die Studenten-Filesysteme.
In diesem Bereich gibt es oefters Probleme, wenn ein Benutzer in ein Departement verschoben wird und dabei ein Departement-eigenes Homeverzeichnis erhält. Damit wird die Homepage via FTP nicht mehr verfügbar.
es ist vorstellbar, dass hier mehrere Verzeichnisse geführt werden müssen.

Die sog. primary group eines AD Users heisst «Domain Users». Diese Gruppe trägt die GroupID 513 (als Teil der objectSID) respektive gidNumber 1029 und wird jedem neuen AD-User automatisch zugewiesen. Wenn ein User in eine Departements-OU verschoben wird, kann der dortige OU-Admin diese primary group ändern. Dabei wird jedoch bloss die primaryGroupID eines Users angepasst, nicht aber die gidNumber, welche zur POSIX-Schemaerweiterung gehört. Damit das POSIX-Attribut gidNumber stets mit der AD-Realität übereinstimmt, läuft periodisch (alle 20 min) ein cronjob ad.pl:

Ziele des Projektes und des neuen Services

  • direkte Kontrolle von nethz bei der Generierung und Löschung von Accounts und der dazugehörigen UUID
  • Ändern der primären Gruppe eines Users im Admin-Tool
  • Synchronisieren der Primären Gruppe (AD und LDAPS)
  • Aufräumaktion: gezieltes Löschen der verfallenen Benutzerdaten
    • Löschen von Accounts, die nicht mehr existieren
    • Bereinigen von Inkonsistenzen zwischen Username und UUID.
    • ein bereits bestehendes Skript von Peter Bircher kann diese Inkonsistenzen auflisten
  • Detailiertere Informationen für den Benutzer über seinen Diskplatz
  • Windows Berechtigungen neu setzen für Kunden, die im AD erneut erstellt wurden.

  • die primary group eines AD-Users hat kein entsprechendes Pendant im LDAPS
  • die GID-Nummer der AD-Gruppe «Domain Users» ist nicht diesselbe wie wie die GID-Number dieses Users im LDAPS

Bisher ausgeführte Arbeiten

noch auszuführende Arbeiten

  • DFS-Service für alle ETH-Angehörigen (welche Personenkategorien dies sind, muss noch definiert werden)
  • Schnittstelle (z.B. Web-Service) auf Seite von DFS, mit folgenden Möglichkeiten:
    • erstellen von DFS-Links und zugehörigen Verzeichnissen (resp. shares)
    • löschen von DFS-Links und zugehörigen Verzeichnissen
    • Abruf von Service-Informationen für ein Konto
    • Berechtigungsentzug für DFS-Links und zugehörigen Verzeichnissen
    • ev. erweitern der erlaubten Verzeichnis-Grösse (Quota)
  • Aufräumaktion (siehe oben)

Beschreibung des neuen DFS-Services

  • nethz verwaltet den DFS-Service
  • der Service sollte besser «Speicher-Service» heissen, da DFS, AFS, NAS, SAN, SMB, AFP, FTP etc. nicht Begriffe sind, die jedermann geläufig sind
  • jeder User kann mehrere Shares haben
  • nethz weiss, welche File-Shares für einen bestimmten User eingerichet sind
  • Aufträge werden an das Storage-System aufgegeben
  • Storage-System führt periodisch diese Aufträge aus und schreibt danach den neuen Status in den DFS-Service
  • Storage-System kümmert sich um die Filesystem-Details
  • vorgefertigte Templates, welche für jede Personenkategorie bestimmte Default-Werte für Quota, DFS-Pfade, ISG etc. festlegen
  • im Admin-Tool soll jederzeit der aktuelle Status «aller» Shares eines Users ersichtlich sein
  • die zuständige Admingruppe resp. ISG sollte ebenfalls ersichtlich sein
  • Admins sollen Quota ändern können
  • ev. soll zusätzlicher Platz eingekauft werden können (unterschiedliche Preise je nach Qualität, z.B. Wuala, SATA-Storage etc.)
  • wenn Template-Werte geändert werden (neue Quota, neue ISG), sollen diese manuell auf bestehende Userobjekte angewendet werden
  • Änderungen an den Service-Parametern (DFS-/NAS-Pfade, Quota, verantwortliche ISG) sollen dem User mitgeteilt werden

Voraussetzungen

  • Harmonisierung der primären Gruppe eines Users im AD und LDAPS
    • identische GID-Number
    • identische Bezeichnung
  • Möglichkeit der Änderung der primären Gruppe für einen User
    • im AD ist jeder User Mitglied der Gruppe «Domain Users»
    • Anpassung der der primären Gruppe im AD ist implementiert, aber noch nicht im GUI
  • zentrale Gruppenregelung für einen User
    • nicht separat im Mailbox- resp. nethz-Service

weitere technische Randbedingungen

  • Erstellen, Löschen und Ändern von DFS-Links benötigen Zeit
  • MOVED TO... alle Aktionen mit dem Storage-System müssen asynchron getätigt werden
  • Wenn User ihre Hard-Quota überschreiten, können sie dies tun - nach einer bestimmten Zeit aber führt dieses Überschreiten dazu, dass der User gar keine Aktionen mehr durchführen kann
  • Historisierung der DFS-Service - Tabelle

Implementierungsvorschläge

  • Storage-System holt sich die Aufträge via einem Web-Service periodisch ab
  • Storage-System schreibt über denselben Web-Service, welche Aufträge es durchgeführt hat
  • Web-Service schreibt in eine Service-Tabelle in nethz, welche folgende Felder beinhaltet
Feldname Beschreibung
USERNAME identisch mit nethz-Username
DFS_PATH  
NAS_PATH  
FTP_PATH optional
QUOTA_PERMANENT dauerhafte Quota für diesen User
QUOTA_TEMPORARY temporäres Erhöhen einer Quota für einen bestimmten User, damit er bei Überschreitung der Hard-Quota Files wieder löschen kann
RESPONSIBLE_ISG die für diesen Storage-Teil verantwortliche Informatik-Supportgruppe (ISG). Neben dem User selbst soll immer eine dedizierte ISG für Maintenance-Zwecke auf den Speicher zugreifen können

Die aktuelle Status-Tabelle muss für jeden Parameter einen IST und einen SOLL Zustand beinhalten. Somit weiss das Storage-System immer, was noch zu erledigen ist und der Benutzer weiss jederzeit, in welchem Zustand sein jetziges System ist.

Aufwandschätzung

Für eine Schätzung des Gesamt-Aufwandes müssen folgende Teilarbeiten berücksichtigt werden:
  • Formulierung des Mechanismus im Detail
  • Design und Erstellung der notwendigen Tabellen
  • Integration in jetziges und ev. zukünftigen Identity-Management-Systems (nethz)
  • Module für den Zugriff auf diese Tabellen
  • Service-Module erstellen
  • GUI für Endbenutzer / für Admin
  • Berechtigungen für Admins
  • Web-Service für Storage-System
    • Spezifikation der Schnittstelle
    • Implementation
  • Information / Schulung der ISG, Admingruppen und Helpdesk

-- SwenVermeul - 2010-11-04

Topic revision: r12 - 2011-12-06 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback