stoney core: OpenLDAP provisioning

From stoney cloud
Revision as of 12:45, 17 October 2013 by Michael (Talk | contribs)


Jump to: navigation, search

Overview

In most cases, the stoney cloud separates the user input (web interface via REST API, external applications via rest api) from the actual provisioning of services. The user input get written in the OpenLDAP directory. The backend systems, that are to be provisioned have a specialised provisioning daemon running, which tracks OpenLDAP directory for changes. If a change concerns them, the execute the provisioning step and update the OpenLDAP directory about the successful (or unsuccessful) provisioning step.

Provisioning

For the provisioning to work, wen need the three attributes sstProvisioningMode, sstProvisioningState and sstProvisioningExecutionDate. Workflow:

  1. sstProvisioningMode: The rest api updates the attribute sstProvisioningMode with the value add, modify or delete.
    1. sstProvisioningMode: add: Der Service soll hinzugefügt werden. Dieser Fall muss mehrmals nacheinander aufgerufen werden können. Beispiel: Bei Online Backup wurde die chroot-Umgebung bereits erstellt, dann müsste ein add nur noch kontrollieren, ob die chroot-Umgebung aktuell ist, falls nicht, müssten die entsprechenden Punkte aktualisiert werden.
    2. sstProvisioningMode: modify: Der Service soll modifiziert werden.
    3. sstProvisioningMode: delete: Der Service soll gelöscht werden.
  2. sstProvisioningExecutionDate: Die Applikation Selfcare beschreibt das Attribut sstProvisioningExecutionDate mit dem gewünschten Ausführungszeitpunkt. Zwei Fälle:
    1. 0: Dies bedeutet "sofort" und wird durch den Provisionierungs-Daemon provisioning.pl ausgewertet.
    2. [YYYY][MM][DD]: Das gewünschte Ausführungsdatum (ISO 8601). Muss mindestens ein Tag später als das aktuelle Datum sein, da diese Attribut durch ein alle 24 Stunden aufgerufenes Aufräum-Script gelesen wird. Der genaue Ausführungszeitpunkt kann somit nicht bestimmt werden (da abhängig vom Ausführungszeitpuntk der Aufräum-Scripts und der Anzahl anstehenden Aufgaben).
  3. sstProvisioningState: Die Applikation Selfcare oder der Provisionierungs-Daemon provisioning.pl beschreiben das Attribut sstProvisioningState:
    1. Keine Provisionierung nötig: Falls eine Änderung keine Provisionierung im Backend verlangt (zum Beispiel bei einer Passwört-Änderung), wird das Attribut sstProvisioningState direkt durch die Applikation Selfcare it dem aktuellen Datum und der aktuellen Zeit in Form von [YYYY][MM][DD]T[hh][mm][ss] ausfüllen (ISO 8601) beschrieben. In diesem Falle ignoriert der Provisionierungs-Daemon provisioning.pl die Modifikation.
    2. Provisionierung nötig: Falls eine Änderung eine Provisionierung im Backend verlangt (zum Beispiel bei einer Quota-Änderung), muss die Applikation Selfcare dieses Attribut auf den Wert 0 setzen. Nach der erfolgreichen Provisionierung muss Provisionierungs-Daemon provisioning.pl das Attribut sstProvisioningState mit dem aktuellen Datum und der aktuellen Zeit in Form von [YYYY][MM][DD]T[hh][mm][ss] ausfüllen (ISO 8601).

The rest api darf erst dann wieder eine Modifikation durch einen Benutzer zulassen, wenn das Attribut sstProvisioningState einen gültigen Zeitstempel in der Form von [YYYY][MM][DD]T[hh][mm][ss] (ISO 8601) hat. Technisch gesehen muss der Provisionierungs-Daemon provisioning.pl im RefreshAndPersist Modus nur noch auf die LDAP-Mechanismen add und modify hören. Der LDAP-Mechanismus delete muss ignoriert werden.