This pages contains all necessary information one needs to know about the prov-backup-rsnapshot daemon. This daemon provisions the stoney backup account according to what was requested in the selfcare web interface. Changes performed on the web interface (for example creating a new stoney backup account) will be written to the LDAP directory. The changes in the LDAP directory are spotted by the prov-backup-rsnapshot daemon which then can set up the appropriate action (for example creating directories and setting quota values for the new stoney backup account) and change the LDAP again. This change in the LDAP will then be visible in the web interface. Like that the user can see, that the new stoney backup account it requested is now ready to use.

(Note: Comments starting with /* are not in the configuration file, they are only in the wiki to add some additional information)

# Copyright (C) 2013 stepping stone GmbH
#                    Switzerland
#                    http://www.stepping-stone.ch
#                    support@stepping-stone.ch
#
# Authors:
#  Pat Kläy <pat.klaey@stepping-stone.ch>
#  
# Licensed under the EUPL, Version 1.1.
#
# You may not use this work except in compliance with the
# Licence.
# You may obtain a copy of the Licence at:
#
# http://www.osor.eu/eupl
#
# Unless required by applicable law or agreed to in
# writing, software distributed under the Licence is
# distributed on an "AS IS" basis,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
# express or implied.
# See the Licence for the specific language governing
# permissions and limitations under the Licence.
#

/* If you want, you can override the log information from the global configuration file this might be useful for debugging */
[Global]
# If true the script logs every information to the log-file.
LOG_DEBUG = 1

# If true the script logs additional information to the log-file.
LOG_INFO = 1

#If true the script logs warnings to the log-file.
LOG_WARNING = 1

#If true the script logs errors to the log-file.
LOG_ERR = 1

/* Specify the hosts fully qualified domain name. This name will be used to perform some checks and also appear in the information and error mails */
ENVIRONMENT = <FQDN>
 
[Database]
BACKEND = LDAP
SERVER = ldaps://ldapm.tombstone.org
PORT = 636
ADMIN_USER = cn=Manager,dc=stoney-cloud,dc=org
ADMIN_PASSWORD = <PASSWORD>
SERVICE_SUBTREE = ou=accounts,ou=backup,ou=services,dc=stoney-cloud,dc=org
COOKIE_FILE = /etc/Provisioning/Backup/rsnapshot.cookie
DEFAULT_COOKIE = rid=001,csn=
SEARCH_FILTER = (&(entryCSN>=%entryCSN%)(sstProvisioningState=0))

/* Specifies the service itself. As it is the prov-backup-rsnapshot module, the SERVICE is "Backup" and the TYPE is "Rsnapshot".
 * The MODUS is as usual selfcare and the TRANSPORTAPI is LocalCLI. This is because the daemon is running on the same host as the
 * backup accounts are provisioned and the commands can be executed on this host using the cli.
 * For more information about MODUS and TRANSPORTAPI see https://int.stepping-stone.ch/wiki/provisioning.pl#Service_Konfiguration
 */
[Service]
MODUS = selfcare
TRANSPORTAPI = LocalCLI
SERVICE = Backup
TYPE = Rsnapshot

SYSLOG = prov-backup-rsnapshot

/* For the TRANSPORTAPI LocalCLI there is no gateway required because there is no connection to establish. So set HOST, USER and
 * DSA_FILE to whatever you want. Don't leave it blank, otherwise the provisioning daemon would log some error messages saying
 * these attributes are empty 
 */
[Gateway]
HOST = localhost
USER = provisioning
DSA_FILE = none

/* Information about the backup itself (how to setup everything). Note that the %uid% int the RSNAPSHOT_CONFIG_FILE parameter will
 * be replaced by the accounts UID. The script CREATE_CHROOT_CMD was installed with the prov-backup-rsnapshot module, so do not
 * change this parameter. The quota parameters (SET_QUOTA_CMD, MOUNTPOINT, QUOTA_FILE, PROJECTS_FILE and PROJID_FILE) represent 
 * the quota setup as described on http://wiki.stoney-cloud.org/index.php/stoney_backup:_Server_set-up#Quota. If you followed this
 * manual, you can copy-paste them into your configuration file, otherwise adapt them according to your quota setup.
 */
[Backup]
RSNAPSHOT_CONFIG_FILE = /etc/rsnapshot/rsnapshot.conf.%uid%
SET_QUOTA_CMD = /usr/sbin/xfs_quota
CREATE_CHROOT_CMD = /usr/libexec/createBackupDirectory.sh
MOUNTPOINT = /var
QUOTA_FILE = /etc/backupSize
PROJECTS_FILE = /etc/projects
PROJID_FILE = /etc/projid

The daemon "communicates" with the LDAP to let other processes know its current state. The important attributes therefore are sstProvisioningMode and sstProvisioningState in the given Backup-Account entry. The sequence is defined for adding, modifying or deleting an entry. The preconditions for all three modi are:

• sstProvisioningMode is set to add, modify or delete
• sstProvisioningState is set to 0
• sstProvisioningDate is set to 0 or the current date (format: YYYYMMDD)

Add

Precondition

...
sstProvisioningMode: add
sstProvisioningState: 0
sstProvisioningDate: 0
...

Step 1

...
sstProvisioningMode: adding
sstProvisioningState: 0
sstProvisioningDate: 0
...

Now the prov-backup-rsnapshot daemon works on the given entry.

Step 2

As soon as the prov-backup-rsnapshot daemon finished working on the given entry:

...
sstProvisioningMode: added
sstProvisioningState: YYYYMMDDThhmmssZ
sstProvisioningDate: 0
...

Modify

Precondition

...
sstProvisioningMode: modify
sstProvisioningState: 0
sstProvisioningDate: 0
...

Step 1

...
sstProvisioningMode: modifying
sstProvisioningState: 0
sstProvisioningDate: 0
...

Now the prov-backup-rsnapshot daemon works on the given entry.

Step 2

As soon as the prov-backup-rsnapshot daemon has finished working on the given entry:

...
sstProvisioningMode: modified
sstProvisioningState: YYYYMMDDThhmmssZ
sstProvisioningDate: 0
...

Delete

Precondition

...
sstIsActive: FALSE
sstProvisioningMode: delete
sstProvisioningState: 0
sstProvisioningDate: 0
...

Step 1

...
sstProvisioningMode: deleting
sstProvisioningState: 0
sstProvisioningDate: 0
...

Now the prov-backup-rsnapshot daemon works on the given entry.

Step 2

As soon as the prov-backup-rsnapshot daemon finished working on the given entry:

...
sstProvisioningMode: deleted
sstProvisioningState: YYYYMMDDThhmmssZ
sstProvisioningDate: 0
...

Requirements

A working test server set up following the stoney backup: Server set-up guide.

Test the daemon

• The daemon is running on the Backup-Server VM
  • Open a terminal and login to the Backup-Server VM

  • tail -f /var/log/syslog/provisioning.log

• Open a second terminal and login to the Backup-Server VM
  • Make sure the directory /root/data exists, if not create it
  • Create an online backup account by executing the test script:

  • /usr/libexec/createBackupDirectory.sh --uid 3724300

  • The test script currently supports the following options:
    • --uid <UID>: Mandatory option, the backup accounts uid
    • --reseller <UID>: Optional, sets sstBelongsToResellerUID (default 4000000)
    • --customer <UID>: Optional, sets sstBelongsToCustomerUID (default 4000001)
    • --people <UID>: Optional, sets sstBelongsToPersonUID (default 4000002)
    • --givenname <Name>: Optional, sets the givenname attribute (default "Givenname")
    • --surname <Name>: Optional, sets the sn attribute (defualt "Surname")
  • Load the generated LDIF (you find them under /root/data) step by step into the LDAP and observe what the deamon is doing in the first terminal:

    • /root/loadOpenLDAPsingleLDIF.sh /root/data/01_add_3724300.ldif

      • After this step, the account with the given uid should be created and you should be able to login via ssh using the uid and the password "gugus":

        • ssh <UID>@<Server>

    • /root/loadOpenLDAPsingleLDIF.sh /root/data/02_modify_3724300.ldif

      • After this step, the quota should be reduced by 50% (from 1GB to 500MB)
        • To verify use the report_xfs quota command as mentioned in server setup

    • /root/loadOpenLDAPsingleLDIF.sh /root/data/03_delete_3724300.ldif

      • After this step, the account should be removed, the login via ssh should no longer be possible. The LDAP entry however is still present.

        • ssh <UID>@<Server>

    • /root/loadOpenLDAPsingleLDIF.sh /root/data/04_remove_3724300.ldif

      • After this step, the LDAP entry should be removed

@PAT: What are the expected results of this test, how can one verify if it is working correctly? --Chrigu (talk) 10:09, 19 June 2014 (CEST)