Gruppen und Listen am Fachbereich MI
Beschreibt die künftige Struktur und Verwaltungsweise von Accountgruppen und
Emaillisten.
Begriffe: Gruppe, Liste, Verteiler
- Gruppe: Eine Menge von lokalen Benutzeraccounts des Fachbereichsnetzes.
- Liste: Eine Menge von beliebigen Emailadressen (lokal oder nichtlokal).
- Emailverteiler: Eine Menge von Emailadressen, die durch eine Gruppe oder eine Liste realisiert sein kann.
Wofür brauchen wir Gruppen?
Derzeit haben Gruppen die folgenden Anwendungszwecke:
- Rechtegruppen: Dienen zur bequemen Zuweisung von Zugriffsrechten im Dateiystem.
- Login-Gruppen: Dienen zur Zuteilung von Anmelderechten auf Rechnern.
- Email-Gruppen: Dienen als Emailverteiler für die meisten Zwecke.
Künftig kommen zwei weitere Zwecke hinzu:
- Verwaltungsgruppen: Bilden Personengruppen aus Sicht der Universitätsverwaltung ab (z.B. alle Angestellten, alle Beamten, alle HiWis, etc.). Diese Gruppen müssen wir aus rechtlichen Gründen künftig abbilden.
- Außensicht-Gruppen: Bilden Personengruppen für die Außendarstellung des FB ab (Webauftritt).
Wegen des Hinzutretens insbesondere der Außensicht-Gruppen ergibt sich eine
Notwendigkeit und Chance, unser bisheriges Gruppensystem (das ziemlich
verwirrend und undurchsichtig ist) zu überarbeiten. Insbesondere im Bereich
der Emailverteiler ergibt sich dadurch eine große Verbesserung, weil bislang
z.B. sehr individuelle Definitionen vorkamen und zugleich der Unterschied
zwischen Email-Gruppen und Email-Listen überhaupt nicht erkennbar war und
deshalb alle möglichen Überraschungen auftraten.
Die neue Struktur ist im Folgenden beschrieben.
Ziele
Die Reform des Gruppenwesens soll die folgenden Ziele erreichen:
- Selbstverwaltet: Viele der Gruppen werden künftig direkt von denjenigen verwaltet, die die Gruppe hauptsächlich nutzen (sprich: von einem ihrer Insassen). Das verbessert die Reaktionsgeschwindigkeit für Änderungen und erhöht bei den Mitgliedern die Klarheit darüber, wer eigentlich Mitglied in einer Gruppe ist.
- Verständlich: Die Benennung der Gruppen wird nach einem regelmäßigen Schema vereinheitlicht, so dass Gruppennamen leichter zu finden und zu verstehen sind. Insbesondere gibt es keine Synonyme mehr.
- Hierarchisch: Die meisten Accounts sollen künftig nur in einer Gruppe Mitglied sein, um die Pflege zu erleichtern. Dies wird durch hierarchische Verschachtelung der Gruppen erreicht. Ein paar wichtige Ausnahmen von dieser Regel bleiben jedoch, um zu vermeiden, dass das Gruppensystem zu kompliziert wird.
Und so sieht das Vorgehen dazu aus:
Benennung der Gruppen: Gruppenarten
Eine Gruppe mit dem eigentlichen Namen X heißt als
- Rechtegruppe: X
- Login-Gruppe: log_X
- Email-Gruppe: X
- Verwaltungsgruppe: mgm_X
- Außensicht-Gruppe: org_X
Jede Rechtegruppe ist künftig auch eine Email-Gruppe und umgekehrt.
Dadurch wird das Ganze schon mal erheblich leichter verständlich.
Ansonsten muss es nicht zu jedem X alle diese Gruppen geben. Im Gegenteil:
Das wird nur selten der Fall sein. Tendenziell sind X und org_X eng
miteinander verwandt (sie sind nur in Ausnahmefällen verschieden; solche
Ausnahmen sind aber häufig genug, um die Trennung zu rechtfertigen), log_X
existieren nur in gelegentlichen Fällen und die mgm_Y-Gruppen bilden eine
überwiegend eigene Welt.
Benennung der Gruppen: Organisationsstruktur
Die folgenden Aussagen gelten für Rechtegruppen, Email-Gruppen und
Außensicht-Gruppen jeweils analog (jedoch nicht für Verwaltungsgruppen).
Die entsprechenden Gruppenstrukturen
laufen also weitgehend parallel, können aber immer bei Bedarf voneinander
abweichen.
Im Folgenden bezeichnet "ag1, ag2, ..." immer eine passende Liste von
Arbeitsgruppen (natürlich mehr als 2). In Wirklichkeit heißen die
Arbeitsgruppen beispielsweise agse für AG Software Engineering etc.
Zerlegung des Fachbereichs
Hier zunächst die Zerlegung des Fachbereichs in seine Teile:
- Fachbereich: mi = m_inst, i_inst, mi_tec, mi_fbv, mi_bib, mi_druck
- (Wie lautet die richtige Zuordnung der Hausmeister? Derzeit zu den Instituten)
- Mathematik: m_inst = mi_tec, ag1, ag2, …
- Informatik: i_inst = mi_tec, ag1, ag2, …
- Rechnerbetriebsgruppe: mi_tec = (Liste von Personen)
- Fachberreichsverwaltung: mi_fbv = (Liste von Personen)
- Bibliothek: mi_bib = (Liste von Personen)
- Druckerei: mi_druck = (Liste von Personen)
Gruppen auf Institutsebene
Hier eine Liste von Gruppen, die von den Geschäftsführenden Direktoren der
Institute gepflegt werden:
- Hauptamtliche Professoren (i_prof oder m_prof)
- Sekretärinnen (i_sekr oder m_sekr)
- Institut gesamt (i_inst oder m_inst)
Diese Pflege ist sehr einfach, weil sich an dieser Struktur nur selten etwas
ändert.
Gruppen auf Zuständigkeitsebene
Hier eine Liste von Gruppen, die vom Vorsitz des Fachbereichsrat gepflegt werden. Y meint die entsprechende Gruppe, wie z.B. FBR was zu org_mi_gremium_fbr wird.
- Fachbereichsgremien (mi_grem_Y, i_grem_Y, m_grem_Y), siehe...
- vom HG vorgeschriebene Gremien (Wahlvorstand, ..?), siehe...
- Ausschüsse (mi_auss_Y, i_auss_Y, m_auss_Y), siehe...
- Beauftragte (mi_beauf_Y, i_beauf_Y, m_beauf_Y), siehe...
- Kommissionen (mi_kommi_Y, i_kommi_Y, m_kommi_Y), siehe...
Gruppen auf Arbeitsgruppenebene
Hier eine Liste von Gruppen, die von der betreffenden Arbeitsgruppe (hier
genannt ag1) gepflegt werden:
- ag1_sekr: Das Sekretariat
- ag1_hl: Liste der Hochschullehrer (Professoren, apl. Professoren, Privatdozenten)
- ag1_lehrb: Liste der zusätzlichen Lehrbeauftragten, deren Veranstaltungen inhaltlich dem Gebiet der AG zuzuordnen sind.
- ag1_gast: Gastwissenschaftler, die für den jeweiligen Zweck der Gruppe (Rechte oder Außendarstellung) als Mitglieder betrachtet werden sollen
- ag1_stud: Studierende, die für den jeweiligen Zweck der Gruppe (Rechte oder Außendarstellung) als Mitglieder betrachtet werden sollen. Meist Forschungs-HiWis oder Abschlussarbeiter, evtl. auch Tutoren.
- ag1_ehem: Ehemalige Mitglieder, die für den jeweiligen Zweck der Gruppe (Rechte oder Außendarstellung) noch als Mitglieder betrachtet werden sollen
- Wimis und Somis sind Verwaltungssicht, müssen wegen datenschutz anders benannt sein
- ag1_wimi: Liste der Wissenschaftlichen Mitglieder, die keine Hochschullehrer sind (Doktoranden, Postdoktoranden, Habilitanden mit längerfristiger Verbindung zur Arbeitsgruppe)
- ag1_somi: Nichtwissenschaftliche Mitglieder der Arbeitsgruppe
Die Gruppe, die die Arbeitsgruppe im Ganzen beschreibt ist dann die
Vereinigung der oben erwähnten Teilgruppen:
- ag1 = ag1_hl, ag1_lehrb, (ag1_wimi, ag1_somi,) ag1_gast, ag1_stud, ag1_ehem
Die Unterteilung der Gruppen in Rechtegruppen/Emailgruppen einerseits und
Außensicht-Gruppen andererseits erlaubt, die Abweichungen in den
Personenkreisen zwischen diesen verschiedenen Zwecken rein innerhalb der
Teilgruppen abzubilden und die Zusammensetzung der Gesamtgruppe in obiger
Weise ganz konstant zu halten.
Gruppen nach Mitgliedschaftsstatus
Dadurch lassen sich nun ohne manuellen Mehraufwand Gesamtgruppen für andere
Personenkreise aufstellen:
- i_hl = ag1_hl, ag2_hl, …
- i_wimi = ag1_wimi, ag2_wimi, …
- …
(und analog in der Mathematik)
- i_stud = NICHT! über Gruppen wie ag1_stud, sondern direkt (s.u.)
Globale Gruppen
Ferner gibt es natürlich weiterhin die ganz globalen Gruppen, die alle
Studierenden mitumfassen:
- i_all = i_inst, i_stud
- i_stud = (wird von der Accountverwaltung gepflegt)
(und analog in der Mathematik)
Benennung der Gruppen: Gruppen für spezielle Zwecke
Die oben erwähnten Teilgruppen für die Arbeitsgruppen sind nur deshalb verbindlich
vorgeschrieben, damit man die Gruppen nach Mitgliedschaftsstatus ohne
manuelle Pflege erhalten kann.
Eine Einschränkung bei der Struktur
möglicher Gruppen ist damit nicht beabsichtigt.
Es steht allen Arbeitsgruppen und anderen Personengruppen frei, für
entsprechende Zwecke zusätzliche Gruppen nach Bedarf einzurichten (wenn möglich mit dem entsprechenden Namenspräfix, andernfalls ohne).
Der Pflegevorgang
Für die dezentrale Pflege von Gruppen wie oben beschrieben bekommen die
entsprechend dafür ermächtigten Gruppenverwalter (eine oder zwei Personen pro
Arbeitsgruppe) entsprechende Rechte in der Datenbank, in der die Gruppen
definiert sind.
Email-Listen
Für manche Zwecke im Bereich von Email-Verteilern reichen Gruppen nicht aus,
da oft auch Personen Mitglied eines Verteilers werden sollen, die keinen
Account am Fachbereich besitzen.
Bislang gab es für diesen Fall Email-Aliases, die aber aus Benutzersicht
nicht von Gruppen zu unterscheiden waren und in deren Definition man auch
kaum Einsicht nehmen konnte, was immer wieder zu Verwirrung und sogar
Verärgerung geführt hat.
Deshalb gibt es künftig eine scharfe Trennung zwischen Email-Gruppen (nur
interne Accounts, dezentral verwaltet, viele davon vordefiniert) einerseits
und Email-Listen (auch externe Email-Adressen, ebenfalls dezentral verwaltet,
syntaktisch unterschiedlich anzusprechen im Vergleich zu Email-Gruppen)
andererseits. Listen brauchen nur verwendet zu werden, wo Gruppen nicht
ausreichen.
Zeitlicher Ablauf
Die dezentrale Pflege der org_X-Gruppen beginnt im Prinzip sofort, damit die
entsprechenden Mitgliederlisten im neuen Webauftritt automatisiert angezeigt
werden können.
Die dezentrale Pflege der Rechte-/Emailgruppen beginnt, sobald in der
Rechnerbetriebsgruppe die dafür noch nötigen technischen Voraussetzungen
geschaffen wurden. Wegen der technischen Heterogenität (Unix/Windows) am
Fachbereich sind dafür nämlich die normalen Werkzeuge zur Gruppenverwaltung
nicht ausreichend, sondern es müssen selbstgeschaffene Werkzeuge (die im Kern
bereits vorhanden sind) noch mit geeigneten web-basierten
Bedienschnittstellen versehen werden.
Termin???
Die neue Lösung für Email-Listen wird ebenfalls noch etwas auf sich warten
lassen und zwar ungefähr bis ???
Kommentare
wie werden institutsgremien abgebildet?
-- Main.ertelPCPOOL.MI.FU-BERLIN.DE - 2006-10-24 10:56
UTC