Difference between revisions of "stoney backup: Notification Overview"
[unchecked revision] | [unchecked revision] |
(→Overview) |
(→Graphical) |
||
(32 intermediate revisions by one other user not shown) | |||
Line 3: | Line 3: | ||
Main tasks: | Main tasks: | ||
− | * Warns the user when the backup is running out of space (quota). | + | * Warns the user when the backup is running out of space ([[#Quota |quota]]). |
− | * Warns the user if the backup wasn't executed at the planned time (schedule). | + | * Warns the user if the backup wasn't executed at the planned time ([[#Schedule |schedule]]). |
− | * Informs the user if the backup was executed, but finished with errors (unsuccessful). | + | * Informs the user if the backup was executed, but finished with errors ([[#Unsuccessful |unsuccessful]]). |
* If the Backup Client is too old, inform the user (upgrade) (not implemented yet). | * If the Backup Client is too old, inform the user (upgrade) (not implemented yet). | ||
* Tell the user, that they have a backup account, but it was never used (no backup) (not implemented yet). | * Tell the user, that they have a backup account, but it was never used (no backup) (not implemented yet). | ||
+ | = Tasks = | ||
+ | == Quota == | ||
+ | If the used quota in percentage is bigger than the threshold, the appropriate error message is sent (see [[#Who_will_receive_notification_mails | who will be informed]]). The threshold is variable value which is read from the accounts backend (LDAP directory) entry. (The reseller and/or the customer can change the threshold for the given account using the [[stoney_backup:_Self-Service#Modify_backup_account | selfcare web-interface]] (not implemented yet).) | ||
+ | |||
+ | The script [[stoney_backup:_Service_Software#writeAccountSize.pl | writeAccountSize.pl]] (see [[#Source Code]]) is responsible for this task. | ||
+ | |||
+ | == Schedule == | ||
+ | Each (more or less up-to-date) backup client (developed by [http://www.stepping-stone.ch stepping stone GmbH]) uploads scheduling information to the server when backing up a computer. According to the scheduling information, the server can check if a backup was executed at the correct time or not. If not an appropriate error message is sent (see [[#Who_will_receive_notification_mails | who will be informed]]). (The reseller and/or customer can define after how many not executed backups he or she wants to be informed using the [[stoney_backup:_Self-Service#Modify_backup_account | selfcare web-interface]] (not implemented yet).) | ||
+ | |||
+ | The script [[stoney_backup:_Service_Software#scheduleWarning.pl | scheduleWarning.pl]] (see [[#Source Code]]) is responsible for this task. | ||
+ | == Unsuccessful == | ||
+ | Each (more or less up-to-date) backup client (developed by [http://www.stepping-stone.ch stepping stone GmbH]) uploads the status of the backup to the server after backing up a computer. According to this status information, the server can check if the last backup was successful. If not an appropriate error message is sent (see [[#Who_will_receive_notification_mails | who will be informed]]). (The reseller and/or customer can define after how many not successful backups he or she wants to be informed using the [[stoney_backup:_Self-Service#Modify_backup_account | selfcare web-interface]] (not implemented yet).) | ||
+ | |||
+ | The script [[stoney_backup:_Service_Software#scheduleWarning.pl | scheduleWarning.pl]] (see [[#Source Code]]) is responsible for this task. | ||
+ | |||
+ | = Who will receive notification mails = | ||
+ | If one (or more) of the [[#Tasks | tasks]] result in sending an error message, the notification scripts collects the mail addresses to whom it must send the message(s) from the LDAP directory backend in the following way: | ||
+ | == Customer / User == | ||
+ | # Check if the customer / user must be informed | ||
+ | #* If <code>sstBackupWarningOn</code> of the accounts backend (LDAP directory) entry is set to <code>TRUE</code> the customer / user has to be informed | ||
+ | #* If <code>sstBackupWarningOn</code> of the accounts backend (LDAP directory) entry is set to <code>FALSE</code> the customer / user does not have to be informed | ||
+ | # Check if the account itself has some E-Mail addresses attached | ||
+ | #* Check if the LDAP attribute <code>mail</code> exists for the accounts backend (LDAP directory) entry AND <code>sstNotificationWarningMedium</code> is set to <code>mail</code>. | ||
+ | #** If yes, send the mail to all (the attribute <code>mail</code> is multivalued, see [[stoney_backup:_OpenLDAP_directory_data_organisation#Backup_Account_Example | OpenLDAP directory data organisation]]) addresses specified in the attribute <code>mail</code> | ||
+ | #** If not, check to whom the accounts belongs | ||
+ | # Check to which person the backup accounts belongs | ||
+ | #* Read the attribute <code>sstBelongsToPersonUID</code> and search the given person UID in the backend (LDAP directory). | ||
+ | #* Read the attibute <code>mail</code> from the persons bachend (LDAP directory) entry retrieved form the previous serach | ||
+ | #* Send the mail to all (the attribute <code>mail</code> is multivalued, see [[stoney_backup:_OpenLDAP_directory_data_organisation#Backup_Account_Example | OpenLDAP directory data organisation]]) addresses specified in the attribute <code>mail</code> | ||
+ | (The reseller and/or customer can define the values of <code>sstBackupWarningOn</code>, <code>sstNotificationWarningMedium</code> and <code>mail</code> using the [[stoney_backup:_Self-Service#Modify_backup_account | selfcare web-interface]] (not implemented yet).) | ||
+ | |||
+ | == Reseller == | ||
+ | # Check if the reseller wants to be informed | ||
+ | #* If the given problem (see [[#Tasks]]) is part of the attribute <code>sstNotificationWarning</code> in the resellers notification-settings backend (LDAP directory) entry, the reseller has to be informed. | ||
+ | #* If the given problem (see [[#Tasks]]) is not part of the attribute <code>sstNotificationWarning</code> in the resellers notification-settings backend (LDAP directory) entry, the reseller does not have to be informed. | ||
+ | # Send the notification mail (reseller version) to all (the attribute <code>sstMailTo</code> is multivalued, see [[stoney_backup:_OpenLDAP_directory_data_organisation#Backup_Reseller_Backup_Notification_Settings | OpenLDAP directory data organisation]]) addresses specified in the attribute <code>sstMailTo</code> | ||
+ | |||
+ | == Graphical == | ||
+ | [[File:Notification-receiver-workflow.png|650px|thumbnail|none|Figure 1: Who will receive notification mails]] | ||
+ | |||
+ | = Template distribution = | ||
+ | As the templates should be editable for resellers, they are stored on the server which is running the selfcare web interface. On a default stoney cloud setup this will be the [[Primary-Master-Node | primary master node]]. However as described on the [[stoney_cloud:_Notification_Architecture#File_System | notification architecture page]], the templates need to be present on server where the notification process takes place. As we do not have shared storage resources for the primary master node and VMs, the solution is to regularly (once a day) copy the templates from the primary master node to where they should go (for example the backup server): | ||
+ | /etc/cron.d/distribute-templates | ||
+ | <pre> | ||
+ | # Distribute selfcare templates | ||
+ | 00 04 * * * /root/distributeTemplates.sh | logger -t distributeTemplates | ||
+ | </pre> | ||
+ | /root/distributeTemplates.sh | ||
+ | <source lang="bash"> | ||
+ | #!/bin/bash | ||
+ | |||
+ | readonly backup_server="<Server>" | ||
+ | readonly username="<user>" | ||
+ | readonly identity_file=/root/.ssh/id_rsa_demo | ||
+ | readonly themes_source_directory=/var/www/selfcare/htdocs/themes/ | ||
+ | readonly themes_destination_directory=/var/www/selfcare/htdocs/themes/ | ||
+ | readonly files_from="/root/distribute_backup_templates.txt"; | ||
+ | |||
+ | rsync -vrlt --delete -e "ssh -i ${identity_file}" --files-from ${files_from} ${themes_source_directory} ${username}@${backup_server}:${themes_destination_directory} | ||
+ | </source> | ||
+ | /root/distribute_backup_templates.txt | ||
+ | <pre> | ||
+ | <reseller1-themes-direcory>/templates/services/<servce>/ | ||
+ | <reseller2-themes-direcory>/templates/services/<servce>/ | ||
+ | </pre> | ||
+ | For example: | ||
+ | <pre> | ||
+ | selfcare.reseller.org/templates/services/backup/ | ||
+ | selfcare.another-reseller.org/templates/services/backup/ | ||
+ | </pre> | ||
= Source Code = | = Source Code = | ||
The source code is located in our GitHub Repository: | The source code is located in our GitHub Repository: |
Latest revision as of 15:12, 27 June 2014
Contents
Overview
The pages gives you an overview of the stoney backup relevant notifications scripts.
Main tasks:
- Warns the user when the backup is running out of space (quota).
- Warns the user if the backup wasn't executed at the planned time (schedule).
- Informs the user if the backup was executed, but finished with errors (unsuccessful).
- If the Backup Client is too old, inform the user (upgrade) (not implemented yet).
- Tell the user, that they have a backup account, but it was never used (no backup) (not implemented yet).
Tasks
Quota
If the used quota in percentage is bigger than the threshold, the appropriate error message is sent (see who will be informed). The threshold is variable value which is read from the accounts backend (LDAP directory) entry. (The reseller and/or the customer can change the threshold for the given account using the selfcare web-interface (not implemented yet).)
The script writeAccountSize.pl (see #Source Code) is responsible for this task.
Schedule
Each (more or less up-to-date) backup client (developed by stepping stone GmbH) uploads scheduling information to the server when backing up a computer. According to the scheduling information, the server can check if a backup was executed at the correct time or not. If not an appropriate error message is sent (see who will be informed). (The reseller and/or customer can define after how many not executed backups he or she wants to be informed using the selfcare web-interface (not implemented yet).)
The script scheduleWarning.pl (see #Source Code) is responsible for this task.
Unsuccessful
Each (more or less up-to-date) backup client (developed by stepping stone GmbH) uploads the status of the backup to the server after backing up a computer. According to this status information, the server can check if the last backup was successful. If not an appropriate error message is sent (see who will be informed). (The reseller and/or customer can define after how many not successful backups he or she wants to be informed using the selfcare web-interface (not implemented yet).)
The script scheduleWarning.pl (see #Source Code) is responsible for this task.
Who will receive notification mails
If one (or more) of the tasks result in sending an error message, the notification scripts collects the mail addresses to whom it must send the message(s) from the LDAP directory backend in the following way:
Customer / User
- Check if the customer / user must be informed
- If
sstBackupWarningOn
of the accounts backend (LDAP directory) entry is set toTRUE
the customer / user has to be informed - If
sstBackupWarningOn
of the accounts backend (LDAP directory) entry is set toFALSE
the customer / user does not have to be informed
- If
- Check if the account itself has some E-Mail addresses attached
- Check if the LDAP attribute
mail
exists for the accounts backend (LDAP directory) entry ANDsstNotificationWarningMedium
is set tomail
.- If yes, send the mail to all (the attribute
mail
is multivalued, see OpenLDAP directory data organisation) addresses specified in the attributemail
- If not, check to whom the accounts belongs
- If yes, send the mail to all (the attribute
- Check if the LDAP attribute
- Check to which person the backup accounts belongs
- Read the attribute
sstBelongsToPersonUID
and search the given person UID in the backend (LDAP directory). - Read the attibute
mail
from the persons bachend (LDAP directory) entry retrieved form the previous serach - Send the mail to all (the attribute
mail
is multivalued, see OpenLDAP directory data organisation) addresses specified in the attributemail
- Read the attribute
(The reseller and/or customer can define the values of sstBackupWarningOn
, sstNotificationWarningMedium
and mail
using the selfcare web-interface (not implemented yet).)
Reseller
- Check if the reseller wants to be informed
- If the given problem (see #Tasks) is part of the attribute
sstNotificationWarning
in the resellers notification-settings backend (LDAP directory) entry, the reseller has to be informed. - If the given problem (see #Tasks) is not part of the attribute
sstNotificationWarning
in the resellers notification-settings backend (LDAP directory) entry, the reseller does not have to be informed.
- If the given problem (see #Tasks) is part of the attribute
- Send the notification mail (reseller version) to all (the attribute
sstMailTo
is multivalued, see OpenLDAP directory data organisation) addresses specified in the attributesstMailTo
Graphical
Template distribution
As the templates should be editable for resellers, they are stored on the server which is running the selfcare web interface. On a default stoney cloud setup this will be the primary master node. However as described on the notification architecture page, the templates need to be present on server where the notification process takes place. As we do not have shared storage resources for the primary master node and VMs, the solution is to regularly (once a day) copy the templates from the primary master node to where they should go (for example the backup server):
/etc/cron.d/distribute-templates
# Distribute selfcare templates 00 04 * * * /root/distributeTemplates.sh | logger -t distributeTemplates
/root/distributeTemplates.sh
#!/bin/bash readonly backup_server="<Server>" readonly username="<user>" readonly identity_file=/root/.ssh/id_rsa_demo readonly themes_source_directory=/var/www/selfcare/htdocs/themes/ readonly themes_destination_directory=/var/www/selfcare/htdocs/themes/ readonly files_from="/root/distribute_backup_templates.txt"; rsync -vrlt --delete -e "ssh -i ${identity_file}" --files-from ${files_from} ${themes_source_directory} ${username}@${backup_server}:${themes_destination_directory}
/root/distribute_backup_templates.txt
<reseller1-themes-direcory>/templates/services/<servce>/ <reseller2-themes-direcory>/templates/services/<servce>/
For example:
selfcare.reseller.org/templates/services/backup/ selfcare.another-reseller.org/templates/services/backup/
Source Code
The source code is located in our GitHub Repository: