stoney core: OpenLDAP provisioning - Revision history

Michael: Michael moved page Provisioning to stoney core: OpenLDAP provisioning

2013-12-24T08:08:29Z

Michael moved page Provisioning to stoney core: OpenLDAP provisioning

← Older revision

Revision as of 10:08, 24 December 2013

Michael at 08:03, 24 December 2013

2013-12-24T08:03:29Z

← Older revision		Revision as of 10:03, 24 December 2013
Line 17:		Line 17:
	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.		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]]

Michael at 11:46, 17 October 2013

2013-10-17T11:46:36Z

← Older revision		Revision as of 13:46, 17 October 2013
Line 1:		Line 1:
	== Overview ==		== 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 [[: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.		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 '''~~rest api~~''' updates the attribute '''sstProvisioningMode''' with the value '''add''', '''modify''' or '''delete'''.		# '''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 '''~~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.		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]]

Michael: /* Overview */

2013-10-17T11:45:04Z

Overview

← Older revision		Revision as of 13:45, 17 October 2013
Line 1:		Line 1:
	== Overview ==		== 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 [[: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.		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 ==

Michael: Created page with "== 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 servic..."

2013-10-15T13:44:28Z

Created page with "== 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 servic..."

New page

== 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 [[: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 ==
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 ([http://en.wikipedia.org/wiki/ISO_8601 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 ([http://en.wikipedia.org/wiki/ISO_8601 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 ([http://en.wikipedia.org/wiki/ISO_8601 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]''' ([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]]