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:

1. 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.
2. 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.
3. 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