Ein generisches CIM-Schema für Mailserver

Mit dem Entwurf eines Objektmodells für Mailserver-Systeme in Form eines CIM-Schemas beginnt der praktische Teile dieser Arbeit, nachdem zuvor bereits die zu berücksichtigenden Produkte ausgewählt wurden (Kapitel 6). Hauptaugenmerk im Rahmen des praktischen Teils galt dabei dem Schema:

• Das Schema sollte so allgemein sein, dass es alle Mailserver-Systeme abdeckt, nicht nur die beiden implementierten.
• Ein gutes Schema erleichtert die spätere Implementierung, während ein weniger gelungener Entwurf die spätere Umsetzung eher behindert.
• Eine Veröffentlichung des Schemas und Einreichung bei der DMTF würde über den Gedanken eines Piloten hinweg einen weitreichenderen Nutzen dieser Arbeit bringen.

Der Entwurf des Schemas gliederte sich in fünf Schritte:

1. genaue Definition des Umfangs des Modells in Hinsicht auf die Aspekte eines Mailservers, die innerhalb des Modells definiert werden sollen.
2. Identifikation allgemeiner Objektklassen, die innerhalb des im ersten Schritt definierten Bereichs liegen.
3. Formulierung des CIM-Objektmodells in UML (siehe Kapitel 5.2.1) mit allen Attributen, Methoden und Assoziationen.
4. Ableitung dieser Klassen von solchen des CIM Common Schema (siehe Kapitel 5.2.3). Damit lag des Schema für Mailserver-Systeme als CIM Extension Schema (siehe Kapitel 5.2.4) vor.
5. Umsetzung des CIM-Schemas von UML in eine MOF-Datei (siehe Kapitel 5.2.1.2) zur weiteren Verwendung innerhalb eines CIMOM (siehe Kapitel 5.4.1), der für die spätere Implementierung (siehe Kapitel 8) verwendet wird.

Auf den ersten Punkt wird in Kapitel 7.1 eingegangen, der zweite Punkt wird dann in Kapitel 7.2 behandelt. Die Punkte drei und vier kommen schließlich in Kapitel 7.3 zum Zuge. Das Ergebnis von Punkt fünf, der lediglich eine Transformation des Ergebnisses von Punkt vier darstellt, ist in Anhang A.3 aufgeführt.

Definition des Modellumfangs

Im Rahmen des praktischen Teils dieser Arbeit sollte ein CIM-Schema für das Management eines Mailserver-Systems entstehen. Da es sich bei einem Mailserver-System um ein ein sehr komplexes Gebilde handelt, wurde schnell deutlich, dass die Modellierung der wichtigsten Teilbereiche zunächst ausreichend sein dürfte.

Besonderer Aspekt dieser Arbeit war es -- wie schon aus der Fragestellung der Arbeit hervorgeht (nämlich, ob CIM für die Konfiguration verteilter Anwendungen geeignet ist) -- das Konfigurationsmanagement eines solchen Systems zu modellieren. Das bedeutet, dass die Aspekte des Fehler-, Performance-, Accounting- und Security-Management für den Entwurf von geringerem Interesse waren und daher hier kein Wert auf Vollständigkeit gelegt wurde.

Ein weiterer Aspekt war die Frage, in welchen Bereichen der Konfigurationsverwaltung ein CIM-basiertes Management einen Nutzen bringt. Generell können zwei verschiedene Tätigkeiten im Rahmen der Konfiguration eines Mailservers identifiziert werden:

• initiale Konfiguration des Mailservers, z.B. Definition von Pfaden für Datenbanken, Definition der zu startenden Subsysteme

• tägliche Administrationsaufgaben, hierunter fällt insbesondere die Verwaltung von allem, was einen Bezug zu Benutzeraccounts besitzt, wie beispielsweise von Accounts selbst, Ordnern, Quotas und Access Control Listen. Eine weitere Tätigkeit wäre die Kontrolle des Servicedienstes.

Zweifellos kann hier durch eine Abdeckung des zweiten Punkts ein höherer Nutzen erzielt werden, da hier eine Umsetzung weitaus häufiger eingesetzt werden würde.

Somit stand fest, dass durch das Modell primär der Bereich eines Mailserver-Systems bearbeitet werden sollte, der für die User-Anbindung eingesetzt wird, während der MTA-Teil, der für die Kommunikation mit anderen Mailserver-Systemen eingesetzt wird, nicht berücksichtigt wird. Für diesen Teil, der für sich alleine eine hohe Komplexität aufweist, wäre jedoch eine spätere Erweiterung des Schemas möglich.

Identifikation von Objektklassen

Die wichtigsten Objektklassen für das Management eines Mailserver-Systems innerhalb des vorherigen Kapitels 7.1 festgelegt wurden, sollen an dieser Stelle vorgestellt werden. Die Vorgehensweise für die Identifikation entsprach dabei den üblichen Leitlinien für die objektorientierte Softwareentwicklung, wie sie beispielsweise in [23] beschrieben werden.

Als die wesentlichen Elemente wurden identifiziert:

• Ein Mailservice ist das installierte Mailserver-Produkt, das auf einem Rechnersystem als Serverdienst bzw. unter UNIX als daemon gestartet wird. Dabei handelt es sich beispielsweise um eines der in Kapitel 6 vorstellten Produkte. Alle weiteren identifizierten Elemente gehören zu genau einem solchen Mailserver-System. Auf einem Rechnersystem können auch mehrere Mailservices parallel lauffähig sein.
• Ein Mailservice startet einen oder mehrere Prozesse, die seine Funktionalität implementieren, wie beispielsweise einen IMAP-Server-Prozess.
• Ein Mailservice empfängt für eine oder mehrere Domains e-Mail. Im Internet-Bereich bezieht sich eine Domain auf den Teil einer Mail-Adresse nach dem Klammeraffen (@). Die meisten Mailserver-Systeme können mehrere Domains parallel bedienten, dies geschieht beispielsweise in einer Cyrus-Architektur durch virtuelle Domains über den eingesetzten MTA, in Contact ist eine interne Verwaltung über so genannte Mailnodes möglich.
• Die Bedeutung eines Benutzers dürfte offensichtlich sein: Dabei handelt es sich um eine Person, die innerhalb des Mailserver-Systems durch einen Account abgebildet wird, der Zugang zu einem solchen Account wird über ein Passwort geschützt. Innerhalb verschiedener Domains auf einem Mailservice kann es verschiedene Benutzer gleichen Namens geben, ein Benutzer-Account kann nur für eine Domain gelten. Daher ist die Existenz eines Benutzers an eine Domain gekoppelt.
• Oft ist es wünschenswert, dass ein Benutzer unter mehreren e-Mail-Adressen erreichbar ist oder dass über eine dedizierte Adresse mehrere Personen erreicht werden können (Mailverteiler). Dies kann durch einen so genannten Alias erreicht werden. Der Cyrus IMAPd bedient sich für die Alias-Verwaltung des MTAs, Contact pflegt Aliase innerhalb eines Benutzereintrages.
• Ein Folder ist ein Ordner, in dem eine beliebige Menge an Nachrichten gespeichert werden kann.
• Eine Mailbox ist die Ansammlung von Foldern, die einem Benutzer persönlich gehören. Spezielle Folder einer Mailbox sind die Inbox, in die der Posteingang einsortiert wird, der Trash-Folder, in dem gelöschte Nachrichten vorgehalten werden und der Sent-Folder, in dem verschickte Nachrichten standardmäßig abgelegt werden.
• Eine Gruppe ist selbsterklärend: In ihr wird eine Menge von Benutzern zusammengefasst, was eine spätere gemeinsame Verwaltung ermöglicht.
• Quotas definieren eine Relation zwischen einem Benutzer oder einer Benutzergruppe und einem Folder. Sie legt fest, wie viel Speicherplatz belegt werden darf.
• ACLs definieren ebenfalls eine Relation zwischen einem Benutzer oder einer Benutzergruppe und einem Folder. Dabei wird festgelegt, welche Zugriffsrechte (wie z.B. Lesen, Löschen oder Anlegen von Unterordnern) gelten.

Formulierung des Extension Schemas

Die vollständige Umsetzung des Modells für Mailserver-Systeme im Rahmen des in Kapitel 7.1 festgelegten Umfangs in ein CIM-UML-Diagramm ist in den folgenden Abbildungen wiedergeben -- eine Verteilung auf mehrere Seiten war dabei unumgänglich:

• Abbildung 7.1 zeigt einen Teil der Klassen und Assoziationen, insbesondere diejenigen, die sich auf den Mailservice, die Domain und den Benutzer beziehen.
• Abbildung 7.2 zeigt alle weiteren Klassen (mit einigen Überschneidungen zu Abbildung 7.1), diese Klassen beziehen sich auf die Verwaltung von Foldern und Mailboxen.
• Abbildung 7.3 enthält zusätzlich die Vererbungshierarchie der Assoziationen.

Alle Klassen, deren Name mit Mail_ beginnt, sind dabei die eigenen Klassen des Extension Schemas, während den Klassen der CIM Core und Common Modelle, der Namensraum CIM_ vorangestellt ist.

Abbildung 7.1: CIM-Schema für Mailserver-Systeme, Teil 1

 

Abbildung 7.2: CIM-Schema für Mailserver-Systeme, Teil 2

 

Abbildung 7.3: CIM-Schema für Mailserver-Systeme, Teil 3

 

Die Transformation des Schemas in eine MOF-Datei befindet sich im Anhang A.3. Dort wurden sämtliche Klassen und Assoziationen in englischer Sprache kommentiert. Die CIM-Klassen des Common Schema, die für den eigenen Entwurf die Grundlage bildeten, finden sich in gleicher Weise in Anhang A.2.

Die wichtigsten entworfenen CIM-Klassen sollen an dieser Stelle erläutert werden -- eine vollständige Vorstellung aller Klassen würde den Umfang der Arbeit an dieser Stelle sprengen.

• Mail_MailService
  Diese Klasse repräsentiert einen Mailserver, wie beispielsweise den Cyrus IMAPd oder Contact. Sie wurde von der allgemeinen CIM-Klasse CIM_Service abgeleitet.

  Attribute:

  • string SystemCreationClassName (Schlüssel, von CIM_Service)
    siehe dazu auch Kapitel 5.2.2, CCN des Systems, welches den Dienst beherbergt.
  • string SystemName (Schlüssel, von CIM_Service)
    Name des Systems, welches den Dienst beherbergt.
  • string CreationClassName (Schlüssel, von CIM_Service)
    in diesem Fall Mail_MailService
  • string Name (Schlüssel, von CIM_Service)
    Name des Dienstes, z.B. cyrus-imapd oder openmail.
  • string StartMode (von CIM_Service)
    gibt an, ob der Dienst automatisch beim Systemstart gestartet werden soll.
  • boolean Started (von CIM_Service)
    gibt an, ob der Dienst gestartet ist.
  • uint32 NumUsers
    zeigt die Anzahl der aktuell angemeldeten Benutzer.

  Methoden:

  • uint32 StartService() (von CIM_Service)
    startet den Dienst
  • uint32 StopService() (von CIM_Service)
    stoppt den Dienst
  • uint32 ReloadService()
    bewirkt ein Neuladen der aktuellen Konfigurationseinstellungen.

• Mail_HostedMailService (Assoziation)
  Diese Assoziation, die von CIM_HostedService abgeleitet wurde, beschreibt die Beziehung zwischen einem Mailserver-Dienst und dem Rechnersystem, auf dem er läuft.

  Attribute:

  • Referenz auf CIM_System Antecedent
    Kardinalität: 1
  • Referenz auf Mail_MailService Dependent
    Kardinalität: beliebig; schwach

• Mail_MailDomain
  Diese Klasse repräsentiert eine oder mehrere Domains, innerhalb derer ein Account gültig ist. Sie entspricht beispielsweise einer virtuellen Domain im Cyrus IMAPd oder einem Mailnode in Contact. Sie ist von der CIM-Core-Klasse CIM_LogicalElement abgeleitet.

  Attribute:

  • string SystemCreationClassName (Schlüssel)
    CCN des Systems, welches die Domain beherbergt.
  • string SystemName (Schlüssel)
    Name des Systems, welches die Domain beherbergt.
  • string ServiceCreationClassName (Schlüssel)
    in diesem Fall Mail_MailService
  • string ServiceName (Schlüssel)
    z.B. cyrus-imapd oder openmail
  • string CreationClassName (Schlüssel)
    in diesem Fall Mail_MailDomain
  • string Name (Schlüssel, von CIM_LogicalElement)
    Name der Domain
  • string DomainNames[]
    Array weiterer Domains, die auf diese Domain gemappt werden
  • boolean IsDefault
    gibt an, ob es sich bei dieser Domain um die primäre Domain eines MailService handelt.

• Mail_MailServiceForDomain (Assoziation)
  Diese Assoziation, die direkt von CIM_Dependency abgeleitet wurde, beschreibt die Beziehung zwischen einem Mailserver-Dienst und einer darauf gehosteten Domain.

  Attribute:

  • Referenz auf Mail_MailService Antecedent
    Kardinalität: 1
  • Referenz auf Mail_MailDomain Dependent
    Kardinalität: beliebig; schwach

• Mail_MailAccount
  Diese Klasse repräsentiert einen Benutzeraccount auf einem Mailserver. Sie wurde mit Erweiterungen von der CIM-Klasse CIM_Account abgeleitet.

  Attribute:

  • string SystemCreationClassName (Schlüssel, von CIM_Account)
    CCN des Systems, welches den Account beherbergt.
  • string SystemName (Schlüssel, von CIM_Account)
    Name des Systems, welches den Account beherbergt.
  • string CreationClassName (Schlüssel, von CIM_Account)
    in diesem Fall Mail_MailAccount
  • string Name (Schlüssel, von CIM_Account)
    Name des Accounts, entspricht der User-ID
  • string UserPassword
    Gehashtes Passwort des Benutzers. Es ist schreibbar, daher muss es auf jeden Fall über eine ACL-Regel geschützt werden.

  Darüber hinaus verfügt die Klasse CIM_Account über einige weitere Attribute zur Abbildung der LDAP-Klasse account, wie beispielsweise LocalityName, OrganizationName oder OU, die für die Implementierung nicht genutzt wurden.

• Mail_MailAccountOnSystem (Assoziation)
  Diese Assoziation, die von CIM_AccountOnSystem abgeleitet wurde, beschreibt die Beziehung zwischen einem System und darauf gehosteten Accounts.

  Attribute:

  • Referenz auf CIM_System GroupComponent
    Kardinalität: 1
  • Referenz auf Mail_MailDomain PartComponent
    Kardinalität: beliebig; schwach

• Mail_UsersMailDomain (Assoziation)
  Diese Assoziation beschreibt die Beziehung zwischen einem Useraccount auf einem Mailserver und der Domain, in der sich der User befindet.

  Attribute:

  • Referenz auf Mail_MailDomain MailDomain
    Kardinalität: 1
  • Referenz auf Mail_MailAccount MailDomain
    Kardinalität: beliebig

• Mail_MailContainer (abstrakt)
  Diese Klasse ist abstrakt und dient als Generalisierung der Klassen Mail_Folder und Mail_Mailbox, bei denen es sich jeweils um Elemente handelt, die einzelne Nachrichten und Ordner enthalten können. Oberklasse ist CIM_LogicalElement.

  Attribute:

  • string Tag
    enthält eine Kurzbezeichnung des Containers
  • uint32 NumItems
    beziffert die Anzahl enthaltener Nachrichten und Ordner
  • uint32 NumMsgs
    beziffert die Anzahl enthaltener Nachrichten
  • uint32 NumFolders
    beziffert die Anzahl enthaltener Ordner
  • uint32 FileSize
    beziffert die Größe des Containers in Byte, ohne Unterordner
  • uint32 FileSub
    beziffert die Größe des Containers in Byte, mit Unterordnern
  • datetime CreationDate
    bezeichnet den Zeitpunkt, an dem der Container erstellt wurde
  • datetime LastModified
    bezeichnet den Zeitpunkt, an dem der Container zuletzt verändert wurde
  • datetime LastAccessed
    bezeichnet den Zeitpunkt, an dem zuletzt auf den Container zugegriffen wurde

  Methoden:

  • uint32 Export()
    bewirkt einen Export des Containers
  • uint32 Check()
    bewirkt eine Konsistenzprüfung des Containers

• Mail_Mailbox
  Diese Klasse ist eine Ausprägung von Mail_Container zur Repräsentation einer Mailbox, also einer Sammlung aller Nachrichten einer Person. Mailboxen können aber auch shared sein, das heißt sie stehen zwar auf gleicher Ebene wie eine User-Mailbox, werden aber von einer Gruppe von Benutzern für einen speziellen Zweck verwendet. Eine Mailbox besitzt alle Attribute und Methoden eines Mailbcontainers, sowie zusätzlich:

  Attribute:

  • string SystemCreationClassName (Schlüssel)
    CCN des Systems, welches die Mailbox beherbergt.
  • string SystemName (Schlüssel)
    System, das die Mailbox beherbergt.
  • string ServiceCreationClassName (Schlüssel)
    CCN des Mailservice, welcher die Mailbox beherbergt.
  • string ServiceName (Schlüssel)
    Mailserver, in dem sich die Mailbox befindet.
  • string DomainCreationClassName (Schlüssel)
    CCN der Domain, welche die Mailbox beherbergt.
  • string DomainName (Schlüssel)
    Domain, in der sich die Mailbox befindet
  • string CreationClassName (Schlüssel)
    in diesem Fall Mail_Mailbox
  • string Name (Schlüssel)
    Name der Mailbox, welcher innerhalb der Maildomain eindeutig ist

• Mail_MailboxServer (Assoziation)
  Diese Assoziation, die von CIM_Dependency abgeleitet wurde, beschreibt die Beziehung zwischen einer Domain und darin enthaltenen Mailboxen.

  Attribute:

  • Referenz auf Mail_MailDomain Antecedent
    Kardinalität: 1
  • Referenz auf Mail_Mailbox Dependent
    Kardinalität: beliebig; schwach

• Mail_PersonalMailbox (Assoziation)
  Diese Assoziation, die von CIM_Dependency abgeleitet wurde, beschreibt die Beziehung zwischen einem Useraccount auf einem Mailserver und der persönlichen Mailbox dieses Users.

  Attribute:

  • Referenz auf Mail_Mailbox Antecedent
    Kardinalität: 1
  • Referenz auf Mail_MailAccount Dependent
    Kardinalität: maximal 1

• Mail_Folder
  Diese Klasse ist eine Ausprägung von Mail_Container zur Repräsentation eines Mailorders. Ein Ordner unterscheidet sich von einer Mailbox prinzipiell durch andere Schlüsselattribute, da ein Ordner in einer Mailbox enthalten ist.

  zusätzliche Attribute:

  • string SystemCreationClassName (Schlüssel)
    CCN des Systems, der den Ordner beherbergt.
  • string SystemName (Schlüssel)
    System, das den Ordner beherbergt.
  • string ServiceCreationClassName (Schlüssel)
    CCN des Mailservice, welcher den Ordner beherbergt.
  • string ServiceName (Schlüssel)
    Mailserver, in dem sich der Ordner befindet.
  • string DomainCreationClassName (Schlüssel)
    CCN der Domain, welche den Ordner beherbergt.
  • string DomainName (Schlüssel)
    Domain, in der sich der Ordner befindet
  • string MailboxCreationClassName (Schlüssel)
    CCN der Mailbox, in der sich der Ordner befindet
  • string MailboxName (Schlüssel)
    Name der Mailbox, in der sich der Ordner befindet
  • string CreationClassName (Schlüssel)
    in diesem Fall Mail_Folder
  • string Name (Schlüssel)
    Name des Ordner, der innerhalb der Mailbox eindeutig sein muss

• Mail_FolderLocation (Assoziation)
  Diese Assoziation, die von CIM_Component abgeleitet wurde, beschreibt den Aufenthaltsort eines Mailordners innerhalb einer Mailbox.

  Attribute:

  • Referenz auf Mail_Mailbox GroupComponent
    Kardinalität: 1
  • Referenz auf Mail_Folder PartComponent
    Kardinalität: beliebig; schwach

Fußnoten

... Schema

die zugrunde liegende Version war die zum Erstellungszeitpunkt aktuelle 2.6

... aufweist

Der MTA Postfix besitzt ca. 310 Konfigurationsoptionen, während es in sendmail für diesen Zweck eine eigene Programmiersprache gibt.