stoney monitoring: OpenLDAP directory data organisation

From stoney-cloud.org
Revision as of 20:45, 18 January 2024 by Michael (talk | contribs)
Jump to navigation Jump to search

Abstract

This document describes the OpenLDAP directory data organisation for the stoney monitoring service.

Data Organisation

The following chapters explain the data organisation of the stoney cloud OpenLDAP directory, in this case we looking at the stoney monitoring service.

Maintenance

The following LDIF shows the monitoring entry of the whole OpenLDAP directory tree for the stoney cloud: 

dn: ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: monitoring
description: The sub tree for the monitoring (configuration management) service.

Maintenance - Configuration

The sub tree for the configuration of the monitoring service: 

dn: ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: configuration
description: The sub tree for the configuration of the monitoring service.

Maintenance - Configuration - Reseller

The sub tree for the reseller specific monitoring service settings: 

dn: ou=reseller,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: reseller
description: The sub tree for the reseller specific monitoring service settings.

Maintenance - Configuration - Customers

The sub tree for the customers specific monitoring service settings: 

dn: ou=customers,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: customer
description: The sub tree for the customer specific monitoring service settings.

Maintenance - Configuration - OpenStack projects

The sub tree for the OpenStack projects specific monitoring service settings: 

dn: ou=projects,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: projects
description: The sub tree for the OpenStack projects specific monitoring service settings.

The sub tree for the specific monitoring service settings for the OpenStack project Customer Ltd. - Public Systems with the uid 4100001. 

dn: uid=4100001,ou=projects,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstOpenStackProject
objectclass: sstRelationship
uid: 4100001
sstOpenStackId: 9ecb5bfdd4564f6ca52bba1e869eeea4
sstOpenStackName: Customer Ltd. - Public Systems
description: The sub tree for the specific monitoring service settings for the OpenStack project 'Customer Ltd. - Public Systems' with the uid 4100001.
sstIsActive: TRUE
sstBelongsToDomainID: b01822477be64c09950022486300c59c
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

The following table describes the different attributes: The following table describes the different attributes:

Attribute Objectclass
Existence
Mandatory
 Description
uid sstOpenStackProject
MUST
x
 A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of uid corresponds with the value of sstBelongsToResellerUID.

For example: uid: 4000000 corresponds with sstBelongsToResellerUID: 4000000.

sstOpenStackId sstOpenStackProject
MAY
x
 The OpenStack project id as returned from the OpenStack API.

For example: "id" : "5a3a4fd5d6e94a87815131be42d8e6d9". This gives us the LDAP entry: sstOpenStackId: 5a3a4fd5d6e94a87815131be42d8e6d9.

sstOpenStackName sstOpenStackProject
MAY
x
 The OpenStack project name as returned from the OpenStack API.

For example: "name" : "Customer Ltd. - Public Systems". This gives us the LDAP entry: sstOpenStackName: Customer Ltd. - Public Systems.

description sstOpenStackProject
MAY
x
 The description of the leaf.

For example: The sub tree for the specific monitoring service settings for the OpenStack project 'Customer Ltd. - Public Systems' with the uid 4100001.

sstIsActive sstOpenStackProject
MUST
x
 Is the entry active? Either TRUE (yes) or FALSE (no).

The default value is TRUE.

sstBelongsToDomainID sstOpenStackProject
MUST
x
 The OpenStack domain id the project belongs to.

For example: sstBelongsToDomainID: b01822477be64c09950022486300c59c.

sstBelongsToResellerUID sstRelationship
MAY
x
 Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of sstBelongsToResellerUID corresponds with the value of uid.

For example: sstBelongsToResellerUID: 4000000 corresponds with uid: 4000000.

sstBelongsToCustomerUID sstRelationship
MAY
x
 Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute sstBelongsToCustomerUID should always be set to the customer UID, that reflects the reseller for the OpenStack Domains.

For example: sstBelongsToCustomerUID: 4000001.

Legend:

  • x: Mandatory in all cases.

Maintenance - Configuration - OpenStack projects - Defaults

This sub tree stores the default settings for the stoney monitoring service for the OpenStack project 'Customer Ltd. - Internal Systems' with OpenStack id '5a3a4fd5d6e94a87815131be42d8e6d9' and with the OpenStack project uid '4000001'.

The configuration below tells us the following:

  • We have a monitoring window range (as sstCronMinuteEnd and sstCronHourEnd are set).
  • The monitoring window is executed every 2nd Tuesday of every month.
  • The monitoring windows can start a 09:30 and must end at 13:45 and takes 1 hour (60 minutes).
  • A reminder will be sent to 'Support stepping stone AG <support@stepping-stone.ch>'.

The lookup of the default settings for the stoney monitoring service is as follows:

  1. Service roles: ou=defaults,ou=stoney_office,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  2. OpenStack project: ou=defaults,uid=4100000,ou=projects,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  3. Customer: ou=defaults,uid=4000001,ou=projects,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  4. Reseller: ou=defaults,uid=4000000,ou=reseller,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.

For example: If no monitoring values or only a subset of monitoring values are set by the provisioning api (or provisioning script), an missing values are first looked up in the service roles sub tree. If there are still missing values, the next lookup occurs in the OpenStack project subtree. Once again, if there are still missing values, the next lookup occurs in the customer sub tree. If there are still missing values, the final lookup occurs in the reseller sub tree. If there are still missing values, the provisioning api (or provisioning script) must inform the calling instance (this would normally be a human). 

dn: ou=defaults,uid=4000001,ou=projects,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
objectclass: sstMaintenanceDefaultsObjectClass
objectclass: sstNotificationObjectClass
objectclass: sstRelationship
ou: defaults
description: This sub tree stores the default settings for the stoney monitoring service for the OpenStack project 'Customer Ltd. - Internal Systems' with OpenStack id '5a3a4fd5d6e94a87815131be42d8e6d9' and with the OpenStack project uid '4000001'.
sstIsActive: TRUE                       # MAY: The default is always TRUE, otherwise why bother? 
sstServicePriority: 3                   # MAY: We always set this, in case sstServiceAutomated is set to FALSE (as a fall-back position)
sstServiceAutomated: TRUE               # MAY: Depending on the reseller, we either have TRUE or FALSE. If sstServiceAutomated is not set, we presume FALSE
sstCronRepeatType: monthly              # MAY: repeat type is monthly
sstCronInterval: 1                      # MAY: repeat every month
sstCronOccurrenceInMonth: 2             # MAY: second occurence
sstCronDayOfWeek: 2                     # MAY: Tuesday
sstCronMinute: 30                       # MAY: 30 Minutes past the hour
sstCronMinuteEnd: 45                    # MAY: 45 Minutes past the hour (new attribute, for if we have a range: 09:30 - 13:45)
sstCronHour: 9                          # MAY: 9 am
sstCronHourEnd: 13                      # MAY: 1 pm (new attribute, for if we have a range: 09:30 - 13:45)  
sstCronDuration: 60                     # MAY: 60 minutes (one hour)
sstNotificationWarning: reminder        # MAY: We alway set this (Multi-valued attribute).
sstInformPersonUID: 1000482             # MAY: Support stepping stone AG (support@stepping-stone.ch)
sstResponsiblePersonUID: 1000482        # MAY: Support stepping stone AG (support@stepping-stone.ch)
sstResponsibleDeputyPersonUID: 1000482  # MAY: Support stepping stone AG (support@stepping-stone.ch)
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

The following table describes the different attributes:

Attribute Objectclass
Existence
Mandatory
 Description
description sstMaintenanceDefaultsObjectClass
MAY
x
 The description of the leaf.
sstIsActive sstMaintenanceDefaultsObjectClass
MAY
x
 Is the entry active? Either TRUE (yes) or FALSE (no).
sstServicePriority sstMaintenanceDefaultsObjectClass
MAY
x
 The monitoring service level. The possible monitoring service levels (1, 2 or 3):
  • 3: Maintenance P3 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the working hours (Monday to Friday from 09:00 - 12:00 and 13:00 - 17:00).
  • 2: Maintenance P2 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the extended working hours (Monday to Friday from 07:00 - 12:00 and 13:00 - 19:00).
  • 1: Maintenance P1 [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).

For more information on these monitoring service levels, visit stepping stone GmbH web page.

If the attribute sstServiceAutomated is set to TRUE, the sstServicePriority will be ignored. And we will have automated monitoring windows in the form of:

  • Maintenance Automated (vcs_gitlab) [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).
sstServiceAutomated sstMaintenanceDefaultsObjectClass
MAY
A monitoring window is either executed automatically:
  • sstServiceAutomated: TRUE

or manually:

  • sstServiceAutomated: FALSE

If the attribute sstServiceAutomated does not exist, presume FALSE.

sstCronRepeatType sstMaintenanceDefaultsObjectClass
MAY
How often is a cron job to be repeated. Valid values are: daily, weekly, monthly, yearly.
sstCronInterval sstMaintenanceDefaultsObjectClass
MAY
The interval of a cron job. This attribute is dependant on the attribute sstCronRepeatType. Valid values are: 1 - 12. For example: 2 could be every two days, weeks, months or years (depending on the value of the attribute sstCronRepeatType.
sstCronOccurrenceInMonth sstMaintenanceDefaultsObjectClass
MAY
The occurence of the day in a month a cron job is to be executed. Valid values are: 1 - 4. For example: 3 would be the third occurence. If you use a value higher than 4, the calculation will fail in months, which only have 4 same days (for example February will never have 5 Mondays ...).
sstCronDayOfWeek sstMaintenanceDefaultsObjectClass
MAY
Day of week (0 - 6), where Sunday is 0. For example: 1, which means Monday.
sstCronMinute sstMaintenanceDefaultsObjectClass
MAY
The number of minutes past the hour that the monitoring window must start.

Valid values are: 0 - 59. For example: 30, which means 30 minutes past the hour.

If the attribute sstCronMinuteEnd is set, then sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronMinuteEnd sstMaintenanceDefaultsObjectClass
MAY
The number of minutes past the hour that the monitoring window must end (minus the duration defined with attribute sstCronDuration>/code>). Valid values are: 0 - 59.

For example: 45, which means 45 minutes past the hour.

If this attribute is set, it is interpreted as the end of a monitoring window minute range, while sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronHour sstMaintenanceDefaultsObjectClass
MAY
The hour the monitoring window must start.

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If the attribute sstCronHourEnd is set, then sstCronMinute is interpreted as the start of a monitoring window hour range.

sstCronHourEnd sstMaintenanceDefaultsObjectClass
MAY
The hour the monitoring window must end.

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If this attribute is set, it is interpreted as the end of a monitoring window hour range, while sstCronHour is interpreted as the start of a monitoring window hour range. Therefore, the latest monitoring window can start at <coode>sstCronHourEnd minus the duration defined with attribute sstCronDuration.

sstCronDuration sstMaintenanceDefaultsObjectClass
MAY
The duration of the monitoring window in minutes. Valid values are: 15 - 1440 (15 minutes to 24 hours). For example: 60, which means 60 minutes (one hour).
sstNotificationWarning sstNotificationObjectClass
MAY
This multi-valued attribute will be used to turn single notifications on or off. Currently, the only allowed value is reminder. The value (name) corresponds with the template dn.
sstInformPersonUID sstRelationship
MAY
Stores the UID of the person to be informed if necessary. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.

As this attribute is multi-valued, the lookups will continue, even if this attribute is set.

sstResponsiblePersonUID sstRelationship
MAY
Stores the UID of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstResponsibleDeputyPersonUID sstRelationship
MAY
Stores the UID of the deputy of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstBelongsToResellerUID sstRelationship
MAY
x
 Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of sstBelongsToResellerUID corresponds with the value of uid.

For example: sstBelongsToResellerUID: 4000000 corresponds with uid: 4000000.

sstBelongsToCustomerUID sstRelationship
MAY
x
 Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute sstBelongsToCustomerUID should always be set to the customer UID, that reflects the reseller for the OpenStack Domains.

For example: sstBelongsToCustomerUID: 4000001.

Legend:

  • x: Mandatory in all cases.

Maintenance - Configuration - Service (Puppet) roles

The sub tree for the service (Puppet) roles specific monitoring service settings: 

dn: ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: roles
description: The sub tree for the service (Puppet) roles specific monitoring service settings.

The sub tree of the specific monitoring service settings for the stoney office service (Puppet) role called 'stoney_office' (Puppet roles don't contain spaces). 

dn: ou=stoney_office,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
objectclass: sstServiceConfigurationObjectClass
ou: stoney_office
description: The sub tree of the specific monitoring service settings for the stoney office service (Puppet) role called 'stoney_office'.
sstIsActive: TRUE
sstIsDefault: TRUE


The following table describes the different attributes:

Attribute Objectclass
Existence
Mandatory
 Description
ou organizationalUnit
MUST
x
 The name of the service (Puppet) role.

For example: ou: stoney_office (Puppet roles don't contain spaces).

description organizationalUnit
MAY
x
 The description of the leaf.

For example: The sub tree of the specific monitoring service settings for the stoney office service (Puppet) role called 'stoney_office'.

sstIsActive sstServiceConfigurationObjectClass
MUST
x
 Is the entry active? Either TRUE (yes) or FALSE (no).

The default value is TRUE.

sstIsDefault sstServiceConfigurationObjectClass
MAY
Contains the leaf a default entry? Either TRUE (yes) or FALSE (no).

If sstIsDefault is set to TRUE, the information of this subtree must alway be used (to make sure, that all automated monitoring windows are executed in the same time frame).

Legend:

  • x: Mandatory in all cases.

Maintenance - Configuration - service (Puppet) roles - Defaults

This sub tree stores the default settings for the stoney monitoring service settings for the stoney office service (Puppet) role called 'stoney_office'.

The configuration below tells us the following:

  • We have a monitoring window range (as sstCronMinuteEnd and sstCronHourEnd are set).
  • The monitoring window is executed every 2nd Wednesday of every month.
  • The monitoring windows can start a 03:00 and must end at 05:00 and takes half an hour (30 minutes).
  • A reminder will be sent to 'Support stepping stone AG <support@stepping-stone.ch>'.

The lookup of the default settings for the stoney monitoring service is as follows:

  1. Service roles: ou=defaults,ou=stoney_office,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  2. OpenStack project: ou=defaults,uid=4100000,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  3. Customer: ou=defaults,uid=4000001,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.
  4. Reseller: ou=defaults,uid=4000000,ou=reseller,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org.

For example: If no monitoring values or only a subset of monitoring values are set by the provisioning api (or provisioning script), an missing values are first looked up in the service roles sub tree. If there are still missing values, the next lookup occurs in the OpenStack project subtree. Once again, if there are still missing values, the next lookup occurs in the customer sub tree. If there are still missing values, the final lookup occurs in the reseller sub tree. If there are still missing values, the provisioning api (or provisioning script) must inform the calling instance (this would normally be a human). 

dn: ou=defaults,ou=stoney_office,ou=roles,ou=configuration,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
objectclass: sstMaintenanceDefaultsObjectClass
objectclass: sstNotificationObjectClass
objectclass: sstRelationship
ou: defaults
description: This sub tree stores the default settings for the stoney monitoring service settings for the stoney office service (Puppet) role called 'stoney_office'. Please be aware, that this is the production definition. The integration (test) definition is the same, except that the sstCronOccurrenceInMonth attribute is 1 instead of 2 (a week before).
sstIsActive: TRUE                       # MAY: The default is always TRUE, otherwise why bother? 
sstServicePriority: 3                   # MAY: We always set this, in case sstServiceAutomated is set to FALSE (as a fall-back position)
sstServiceAutomated: TRUE               # MAY: Depending on the reseller, we either have TRUE or FALSE. If sstServiceAutomated is not set, we presume FALSE
sstCronRepeatType: monthly              # MAY: repeat type is monthly
sstCronInterval: 1                      # MAY: repeat every month
sstCronOccurrenceInMonth: 2             # MAY: second occurence
sstCronDayOfWeek: 3                     # MAY: Wednesday
sstCronMinute: 0                        # MAY: 0 Minutes past the hour
sstCronMinuteEnd: 0                     # MAY: 0 Minutes past the hour (new attribute, for if we have a range: 03:00 - 05:00)
sstCronHour: 3                          # MAY: 3 am
sstCronHourEnd: 5                       # MAY: 5 am (new attribute, for if we have a range: 03:00 - 05:00)  
sstCronDuration: 30                     # MAY: 30 minutes (half an hour)
sstNotificationWarning: reminder        # MAY: We alway set this (Multi-valued attribute).
sstInformPersonUID: 1000482             # MAY: Support stepping stone AG (support@stepping-stone.ch)
sstResponsiblePersonUID: 1000482        # MAY: Support stepping stone AG (support@stepping-stone.ch)
sstResponsibleDeputyPersonUID: 1000482  # MAY: Support stepping stone AG (support@stepping-stone.ch)

The following table describes the different attributes:

Attribute Objectclass
Existence
Mandatory
 Description
description sstMaintenanceDefaultsObjectClass
MAY
x
 The description of the leaf.
sstIsActive sstMaintenanceDefaultsObjectClass
MAY
x
 Is the entry active? Either TRUE (yes) or FALSE (no).
sstServicePriority sstMaintenanceDefaultsObjectClass
MAY
x
 The monitoring service level. The possible monitoring service levels (1, 2 or 3):
  • 3: Maintenance P3 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the working hours (Monday to Friday from 09:00 - 12:00 and 13:00 - 17:00).
  • 2: Maintenance P2 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the extended working hours (Monday to Friday from 07:00 - 12:00 and 13:00 - 19:00).
  • 1: Maintenance P1 [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).

For more information on these monitoring service levels, visit stepping stone GmbH web page.

If the attribute sstServiceAutomated is set to TRUE, the sstServicePriority will be ignored. And we will have automated monitoring windows in the form of:

  • Maintenance Automated (vcs_gitlab) [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).
sstServiceAutomated sstMaintenanceDefaultsObjectClass
MAY
A monitoring window is either executed automatically:
  • sstServiceAutomated: TRUE

or manually:

  • sstServiceAutomated: FALSE

If the attribute sstServiceAutomated does not exist, presume FALSE.

sstCronRepeatType sstMaintenanceDefaultsObjectClass
MAY
How often is a cron job to be repeated. Valid values are: daily, weekly, monthly, yearly.
sstCronInterval sstMaintenanceDefaultsObjectClass
MAY
The interval of a cron job. This attribute is dependant on the attribute sstCronRepeatType. Valid values are: 1 - 12. For example: 2 could be every two days, weeks, months or years (depending on the value of the attribute sstCronRepeatType.
sstCronOccurrenceInMonth sstMaintenanceDefaultsObjectClass
MAY
The occurence of the day in a month a cron job is to be executed. Valid values are: 1 - 4. For example: 3 would be the third occurence. If you use a value higher than 4, the calculation will fail in months, which only have 4 same days (for example February will never have 5 Mondays ...).
sstCronDayOfWeek sstMaintenanceDefaultsObjectClass
MAY
Day of week (0 - 6), where Sunday is 0. For example: 1, which means Monday.
sstCronMinute sstMaintenanceDefaultsObjectClass
MAY
The number of minutes past the hour that the monitoring window must start.

Valid values are: 0 - 59. For example: 30, which means 30 minutes past the hour.

If the attribute sstCronMinuteEnd is set, then sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronMinuteEnd sstMaintenanceDefaultsObjectClass
MAY
The number of minutes past the hour that the monitoring window must end (minus the duration defined with attribute sstCronDuration>/code>). Valid values are: 0 - 59.

For example: 45, which means 45 minutes past the hour.

If this attribute is set, it is interpreted as the end of a monitoring window minute range, while sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronHour sstMaintenanceDefaultsObjectClass
MAY
The hour the monitoring window must start.

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If the attribute sstCronHourEnd is set, then sstCronMinute is interpreted as the start of a monitoring window hour range.

sstCronHourEnd sstMaintenanceDefaultsObjectClass
MAY
The hour the monitoring window must end (minus the duration defined with attribute sstCronDuration>/code>).

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If this attribute is set, it is interpreted as the end of a monitoring window hour range, while sstCronHour is interpreted as the start of a monitoring window hour range.

sstCronDuration sstMaintenanceDefaultsObjectClass
MAY
The duration of the monitoring window in minutes. Valid values are: 15 - 1440 (15 minutes to 24 hours). For example: 60, which means 60 minutes (one hour).
sstNotificationWarning sstNotificationObjectClass
MAY
This multi-valued attribute will be used to turn single notifications on or off. Currently, the only allowed value is reminder. The value (name) corresponds with the template dn.
sstInformPersonUID sstRelationship
MAY
Stores the UID of the person to be informed if necessary. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.

As this attribute is multi-valued, the lookups will continue, even if this attribute is set.

sstResponsiblePersonUID sstRelationship
MAY
x
 Stores the UID of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstResponsibleDeputyPersonUID sstRelationship
MAY
x
 Stores the UID of the deputy of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstBelongsToResellerUID sstRelationship
MAY
Stores the reseller UID the leaf belongs to. A unique integer value with 7 digits or more. In the case of OpenStack Domains (resellers), the value of sstBelongsToResellerUID corresponds with the value of uid.

For example: sstBelongsToResellerUID: 4000000 corresponds with uid: 4000000.

For the service (Puppet) roles this attribute must not be set, as the content of this value must be taken from either the OpenStack project, the customer or the reseller.

sstBelongsToCustomerUID sstRelationship
MAY
x
 Stores the customer UID the leaf belongs to. A unique value with 7 digits or more, must correspond with the uid entry. Each reseller is also a customer in the LDAP directory. Therefore, the value of the attribute sstBelongsToCustomerUID should always be set to the customer UID, that reflects the reseller for the OpenStack Domains.

For example: sstBelongsToCustomerUID: 4000001.

For the service (Puppet) roles this attribute must not be set, as the content of this value must be taken from either the OpenStack project, the customer or the reseller.

Legend:

  • x: Mandatory in all cases.

Maintenance - Units

The sub tree for the units of the monitoring service: 

dn: ou=units,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: organizationalUnit
ou: units
description: The sub tree for the units of the monitoring service.

Maintenance - Units example

Each monitoring unit has its own leaf. A monthly monitoring window is the norm.

Maintenance window every month on the second Tuesday of the month between 09:30 and 10:30, starting on Tuesday, the 14th of April 2015.

The sstBelongsToServiceUID lookup is as follows:

  1. OpenStack unit (server): ou=units,ou=openstack,ou=services,dc=stoney-cloud,dc=org.
  2. Virtual Machine: ou=virtual machines,ou=virtualization,ou=services,dc=stoney-cloud,dc=org.
  3. vServer: ou=vservers,ou=services,dc=stoney-cloud,dc=org.
  4. Dedicated Server: ou=dedicated servers,ou=services,dc=stoney-cloud,dc=org (not implemented yet).
  5. External Server: ou=external servers,ou=services,dc=stoney-cloud,dc=org (not implemented yet).

The idea is, that we presume, that most of the monitoring units belong to OpenStack units (servers) running on our OpenStack based stoney cloud installation.

In the example below, the service UID sstBelongsToServiceUID: 1234567 points to virtual machine with the b543f88f-dffe-426f-86d3-c7ff85c16d2a and the uid: 1234567. 

dn: uid=4000003,ou=units,ou=monitoring,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: sstMaintenanceObjectClass
objectclass: sstRelationship
uid: 4000003
description: The monitoring leaf for the virtual machine with the uid 1234567.
sstIsActive: TRUE
sstBillable: TRUE
sstServicePriority: 3
sstServiceAutomated: TRUE
sstCronRepeatType: monthly     # repeat type is monthly
sstCronInterval: 1             # repeat every month
sstCronStartDate: 20150414     # starting on Tuesday, the 14th of April 2015
sstCronOccurrenceInMonth: 2    # second occurence
sstCronDayOfWeek: 2            # Tuesday
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)
sstInformPersonUID: 4000002
sstResponsiblePersonUID: 4000002
sstResponsibleDeputyPersonUID: 4000002
sstNotificationWarning: reminder
sstIsMultiTenant: FALSE
sstBelongsToServiceUID: 1234567
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001

Other possible monitoring windows range from daily monitoring windows to bi yearly monitoring windows. The following examples just show the relevant attributes.

Maintenance window every day between 09:30 and 10:30, starting on Monday, the 5th of January 2015. 

sstCronRepeatType: daily       # repeat type is daily
sstCronInterval: 1             # repeated every day
sstCronStartDate: 20150105     # starting on the fifth of January 2015
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every second day between 09:30 and 10:30, starting on Monday, the 5th of January 2015. 

sstCronRepeatType: daily       # repeat type is daily
sstCronInterval: 2             # repeat every second day
sstCronStartDate: 20150105     # starting on the fifth of January 2015
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every two weeks on Monday between 09:30 and 10:30, starting on Monday, the 13th of April 2015. 

sstCronRepeatType: weekly      # repeat type is weekly
sstCronInterval: 2             # repeat every second week
sstCronStartDate: 20150413     # starting on Monday, the 13th of April 2015
sstCronDayOfWeek: 1            # on Monday
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every six months on the 15. of the month between 09:30 and 10:30, starting on Wednesday, the 15th of April 2015. 

sstCronRepeatType: monthly     # repeat type is monthly
sstCronInterval: 6             # repeat every six months
sstCronStartDate: 20150415     # starting on Wednesday, the 15th of April 2015
sstCronDayOfMonth: 15          # on the 15th day of the month
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every six months on the third Monday of the month between 09:30 and 10:30, starting on Monday, the 20th of April 2015. 

sstCronRepeatType: monthly     # repeat type is monthly
sstCronInterval: 6             # repeat every six months
sstCronStartDate: 20150420     # starting on Monday, the 20th of April 2015
sstCronOccurrenceInMonth: 3    # third occurence
sstCronDayOfWeek: 1            # Monday
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every year on the 15th of March between 09:30 and 10:30, starting on Wednesday, the 11th of March 2015. 

sstCronRepeatType: yearly      # repeat type is yearly
sstCronInterval: 1             # repeat every year
sstCronStartDate: 20150311     # starting on Wednesday, the 11th of March 2015
sstCronDayOfMonth: 11          # on the 11th day of the month
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every year on the third Monday of March between 09:30 and 10:30, starting on Monday, the 16th of March 2015. 

sstCronRepeatType: yearly      # repeat type is yearly
sstCronInterval: 1             # repeat every year
sstCronStartDate: 20150316     # starting on Monday, the 16th of March 2015
sstCronMonthOfyear: 3          # third month of the year
sstCronOccurrenceInMonth: 3    # third occurence
sstCronDayOfWeek: 1            # Monday
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

Maintenance window every two years on the third Monday of March between 09:30 and 10:30, starting on Monday, the 16th of March 2015. 

sstCronRepeatType: yearly      # repeat type is yearly
sstCronInterval: 2             # repeat every two years
sstCronStartDate: 20150316     # starting on Monday, the 16th of March 2015
sstCronMonthOfyear: 3          # third month of the year
sstCronOccurrenceInMonth: 3    # third occurence
sstCronDayOfMonth: 1           # Monday
sstCronMinute: 30              # 30 Minutes past the hour
sstCronHour: 9                 # 9 am
sstCronDuration: 60            # 60 minutes (one hour)

The following table describes the different attributes:

Attribute Objectclass
Existence
Mandatory
 Description
uid sstMaintenanceObjectClass
MUST
x
 A unique integer value with 7 digits or more. For example: 4000003.
description sstMaintenanceObjectClass
MAY
x
 The description of the leaf.
sstIsActive sstMaintenanceObjectClass
MUST
x
 Is the entry active? Either TRUE (yes) or FALSE (no).
sstBillable sstRelationship
MAY
x
 It the entry billable? Either TRUE (yes) or FALSE (no). All hierarchical levels must have sstBillable: TRUE to actually have an invoice generated and sent. If the attribute sstBillable doesn't exist, the default is TRUE. This way, we are forced to set a reseller, customer or product manually to sstBillable: FALSE if we want to avoid sending them an invoice.
sstCancellationDate sstRelationship
MAY
The cancellation date of a reseller, customer or service in the form of [YYYY][MM][DD] (ISO 8601). For example: 20201231.

The attribute sstCancellationDate is used in a logical AND combination with sstIsActive. With other words: Once the cancellation date has passed, it overrides the sstIsActive value.

sstServicePriority sstMaintenanceObjectClass
MAY
x
 The monitoring service level. The possible monitoring service levels (1, 2 or 3):
  • 3: Maintenance P3 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the working hours (Monday to Friday from 09:00 - 12:00 and 13:00 - 17:00).
  • 2: Maintenance P2 [per Unit]: The Security Advisories will be installed once a month at the desired moment during the extended working hours (Monday to Friday from 07:00 - 12:00 and 13:00 - 19:00).
  • 1: Maintenance P1 [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).

For more information on these monitoring service levels, visit stepping stone GmbH web page.

If the attribute sstServiceAutomated is set to TRUE, the sstServicePriority will be ignored. And we will have automated monitoring windows in the form of:

  • Maintenance Automated (vcs_gitlab) [per Unit]: The Security Advisories will be installed once a month at the desired moment around the clock (Monday to Sunday from 00:00 - 24:00).
sstServiceAutomated sstMaintenanceObjectClass
MAY
A monitoring window is either executed automatically:
  • sstServiceAutomated: TRUE

or manually:

  • sstServiceAutomated: FALSE

If the attribute sstServiceAutomated does not exist, presume FALSE.

sstCronRepeatType sstMaintenanceObjectClass
MAY
x
 How often is a cron job to be repeated. Valid values are: daily, weekly, monthly, yearly.
sstCronInterval sstMaintenanceObjectClass
MAY
x
 The interval of a cron job. This attribute is dependant on the attribute sstCronRepeatType. Valid values are: 1 - 12. For example: 2 could be every two days, weeks, months or years (depending on the value of the attribute sstCronRepeatType.
sstCronStartDate sstMaintenanceObjectClass
MAY
x
 The first time a cron job is executed. This date is stored in the form of [YYYY][MM][DD] (ISO 8601). For example: 2010314 (the 14th of March 2015).
sstCronDuration sstMaintenanceObjectClass
MAY
x
 The duration of the monitoring window in minutes. Valid values are: 15 - 1440 (15 minutes to 24 hours). For example: 60, which means 60 minutes (one hour).
sstCronMinute sstMaintenanceObjectClass
MAY
The number of minutes past the hour that the monitoring window must start.

Valid values are: 0 - 59. For example: 30, which means 30 minutes past the hour.

If the attribute sstCronMinuteEnd is set, then sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronMinuteEnd sstMaintenanceObjectClass
MAY
The number of minutes past the hour that the monitoring window must end (minus the duration defined with attribute sstCronDuration>/code>). Valid values are: 0 - 59.

For example: 45, which means 45 minutes past the hour.

If this attribute is set, it is interpreted as the end of a monitoring window minute range, while sstCronMinute is interpreted as the start of a monitoring window minute range.

sstCronHour sstMaintenanceObjectClass
MAY
The hour the monitoring window must start.

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If the attribute sstCronHourEnd is set, then sstCronMinute is interpreted as the start of a monitoring window hour range.

sstCronHourEnd sstMaintenanceObjectClass
MAY
The hour the monitoring window must end (minus the duration defined with attribute sstCronDuration>/code>).

Valid values are: 0 - 23. For example: 9, which means 9 am, while 17 means 5 pm.

If this attribute is set, it is interpreted as the end of a monitoring window hour range, while sstCronHour is interpreted as the start of a monitoring window hour range.

sstCronDayOfWeek sstMaintenanceObjectClass
MAY
Day of week (0 - 6), where Sunday is 0. For example: 1, which means Monday.
sstCronDayOfMonth sstMaintenanceObjectClass
MAY
The day of the month a cron job is to be executed. Valid values are: 1 - 31. For example: 3 is the third of the month.
sstCronMonthOfyear sstMaintenanceObjectClass
MAY
The month of the year a cron job is to be executed. Valid values are: 1 - 12. For example: 3 would be March.
sstCronOccurrenceInMonth sstMaintenanceObjectClass
MAY
The occurence of the day in a month a cron job is to be executed. Valid values are: 1 - 4. For example: 3 would be the third occurence. If you use a value higher than 4, the calculation will fail in months, which only have 4 same days (for example February will never have 5 Mondays ...).
sstInformPersonUID sstRelationship
MAY
x
 Stores the UID of the person to be informed if necessary. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstResponsiblePersonUID sstRelationship
MAY
x
 Stores the UID of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstResponsibleDeputyPersonUID sstRelationship
MAY
Stores the UID of the deputy of the person who is responsible for the system or service. This UID can be used to look up the persons mail address, preferred language, name, surname or other information.
sstNotificationWarning sstMaintenanceObjectClass
MUST
x
 This multi-valued attribute will be used to turn single notifications on or off. Currently, the only allowed value is reminder. The value (name) corresponds with the template dn.
sstIsMultiTenant sstMaintenanceObjectClass
MAY
If this singe-valued attribute is set to TRUE, we know that this is a multi tenant capable system or service. For example stoney backup, stoney storage or stoney wiki). The monitoring notification system will therefore know, that it must inform the tenants differently.
sstBelongsToServiceUID sstMaintenanceObjectClass
MAY
x
 Stores the UID of the service the leaf belongs to. This UID can be used to look up other information. A unique value with 7 digits or more. 4000123.
sstBelongsToResellerUID sstRelationship
MUST
x
 Stores the reseller UID the leaf belongs to. A unique value with 7 digits or more. For example: 4000000.
sstBelongsToCustomerUID sstRelationship
MUST
x
 Stores the customer UID the leaf belongs to. A unique value with 7 digits or more. For example: 4000001.

Legend:

  • x: Mandatory in all cases.
Retrieved from "https://wiki.stoney-cloud.org/w/index.php?title=stoney_monitoring:_OpenLDAP_directory_data_organisation&oldid=5422"