Difference between revisions of "stoney core: OpenLDAP provisioning"
From stoney cloud
| [unchecked revision] | [unchecked revision] |
(→Overview) |
m (Michael moved page Provisioning to stoney core: OpenLDAP provisioning) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
| − | In most cases, the stoney cloud separates the user input (web interface via REST API, external applications via | + | 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 [[:Category:OpenLDAP_directory|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 == | == Provisioning == | ||
For the provisioning to work, wen need the three attributes '''sstProvisioningMode''', '''sstProvisioningState''' and '''sstProvisioningExecutionDate'''. Workflow: | For the provisioning to work, wen need the three attributes '''sstProvisioningMode''', '''sstProvisioningState''' and '''sstProvisioningExecutionDate'''. Workflow: | ||
| − | # '''sstProvisioningMode''': The ''' | + | # '''sstProvisioningMode''': The '''REST API''' updates the attribute '''sstProvisioningMode''' with the value '''add''', '''modify''' or '''delete'''. |
## '''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. | ## '''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. | ||
## '''sstProvisioningMode: modify''': Der Service soll modifiziert werden. | ## '''sstProvisioningMode: modify''': Der Service soll modifiziert werden. | ||
| Line 15: | Line 15: | ||
## 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 ([http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]). | ## 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 ([http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]). | ||
| − | The ''' | + | 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]''' ([http://en.wikipedia.org/wiki/ISO_8601 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. |
| − | [[Category:Provisioning]] | + | [[Category:Provisioning Modules]] |
Latest revision as of 09:08, 24 December 2013
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:
- sstProvisioningMode: The REST API updates the attribute sstProvisioningMode with the value add, modify or delete.
- 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.
- sstProvisioningMode: modify: Der Service soll modifiziert werden.
- sstProvisioningMode: delete: Der Service soll gelöscht werden.
- sstProvisioningExecutionDate: Die Applikation Selfcare beschreibt das Attribut sstProvisioningExecutionDate mit dem gewünschten Ausführungszeitpunkt. Zwei Fälle:
- 0: Dies bedeutet "sofort" und wird durch den Provisionierungs-Daemon provisioning.pl ausgewertet.
- [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).
- sstProvisioningState: Die Applikation Selfcare oder der Provisionierungs-Daemon provisioning.pl beschreiben das Attribut sstProvisioningState:
- 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.
- 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.
