stoney backup: OpenLDAP directory data organisation

Abstract

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

Introduction

All Service-, User- and Billing-Data is stored in the OpenLDAP directory. The directory runs in Multi-Master Mirror-Mode for high availability.

Data Organisation

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

Backup

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

dn: ou=backup,ou=services,dc=stone-cloud,dc=org
objectclass: organizationalUnit
objectclass: top
ou: backup

Backup Account

Original

dn: uid=3723707,ou=people,ou=backup,ou=service,o=stepping-stone,c=ch
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: customerAdministration
uid: 3723707
cn: michael.eichenberger@stepping-stone.ch
uidNumber: 3723707
shadowLastChange: 11108
shadowMax: 99999
shadowWarning: 7
shadowFlag: 134539460
loginShell: /bin/sh
adminUID: 3723707
memberOfCustomerUID: 3723707
homeDirectory: /var/backup/7/707/723/3723707/chroot/./home/3723707
gidNumber: 3723707
structuralObjectClass: account
entryUUID: b660274c-224a-102c-8ffa-e3d4581c4963
creatorsName: cn=Manager,o=stepping-stone,c=ch
createTimestamp: 20071108133153Z
userPassword:: e2NyeXB0fWFzYXh1by9WcnVURk0=
gecos: Michael Eichenberger
entryCSN: 20130602130116Z#000000#00#000000
modifiersName: cn=Manager,o=stepping-stone,c=ch
modifyTimestamp: 20130602130116Z

dn: cn=3723707,ou=group,ou=backup,ou=service,o=stepping-stone,c=ch
objectClass: posixGroup
objectClass: top
cn: 3723707
gidNumber: 3723707
structuralObjectClass: posixGroup
entryUUID: b66452a4-224a-102c-8ffb-e3d4581c4963
creatorsName: cn=Manager,o=stepping-stone,c=ch
createTimestamp: 20071108133153Z
entryCSN: 20071108133153Z#000001#00#000000
modifiersName: cn=Manager,o=stepping-stone,c=ch
modifyTimestamp: 20071108133153Z

Planned

Only one entry per account.

dn: uid=3723707,ou=backup,ou=services,dc=stoney-cloud,dc=org
objectclass: top
objectclass: account
objectclass: posixAccount
objectclass: shadowAccount
objectclass: sstProvisioning
objectclass: sstRelationship
objectclass: customerAdministration
adminuid: 3723707
cn: michael.eichenberger@stepping-stone.ch
gecos: Michael Eichenberger
gidnumber: 3723707
homedirectory: /var/backup/7/707/723/3723707/chroot/./home/3723707
loginshell: /bin/sh
memberofcustomeruid: 3723707
shadowflag: 134539460
shadowlastchange: 11108
shadowmax: 99999
shadowwarning: 7
uid: 3723707
uidnumber: 3723707
userpassword: {crypt}asaxuo/VruTFM

sstBackupIntervalHourly: 
sstBackupIntervalDaily: 
sstBackupIntervalWeekly: 
sstBackupIntervalMonthly: 
sstBackupIntervalYearly: 
sstBackupLastSuccessfulBackup: 
sstBackupWarningMissedDays:
sstBackupWarningMissedNumbers:
sstBackupWarningOn:
sstNotificationWarningMedium:
sstQuota:
mobile:
sstBackupWarningMail:

sstProvisioningMode: add
sstProvisioningExecutionDate: 0
sstProvisioningState: 0
sstBelongsToResellerUID: 4000000
sstBelongsToCustomerUID: 4000001
sstBelongsToPersonUID: 4000002

• Untergrenze Quota?
• Obergrenze Quota?
• Schrittweite?
• Bei der Homeverzeichnis-Erstellung schauen, ob wir diese noch anpassen müssen, da wir nahe beim Sprung von 3 auf 4 Millionen sind.
• Welche Werte werden aus dem People Eintrag verwendet?
  • Mail
  • Vorname
  • ...
• Welche Werte werden automatisch generiert?
  • Passwort
• Welche Werte werden konkret für den Service abgefragt?
  • Quota
• People Eintrag mit einem weiteren Flag ergänzen, welche mit dem sstIsActive kombiniert werden kann, damit er aktiv sein kann, aber nicht einloggen darf)?
• Wenn Reseller oder Customer sstIsActive auf FALSE gesetzt ist, dürfen die dazugehörigen Benutzer auch nicht einloggen.
• WarningLevel in Prozent fehlt noch!

• Wir nehmen nur die Sprachen, welche das Web Interface kann: de-CH und en-GB (oder müsste es mit Unterstrich sein?) -> CWI/MEI
• Sprachen-Fallback ist English.

Backup Notification

Work in progress ... TBD

objectclass ( sstObjectClass:39
    NAME 'sstBackup'
    SUP top AUXILIARY
    MUST ( sstBackupIntervalHourly $ sstBackupIntervalDaily $ sstBackupIntervalWeekly $
           sstBackupIntervalMonthly $ sstBackupIntervalYearly $
           sstBackupLastSuccessfulBackup $ sstBackupWarningMissedDays $ sstBackupWarningMissedNumbers $
           sstBackupWarningOn $ sstNotificationWarningMedium $ sstQuota )
    MAY ( mobile $ sstBackupWarningMail ) )

• sstBackup - Objektklasse
  • sstBackupWarningOn - Ist die Warnung bei nicht erfolgtem Backup aktiv? (TRUE oder FALSE)
  • sstBackupWarningMissedNumbers - Bei nicht erfolgtem Backup wird nach X Mal eine Warnung ausgelöst.
  • sstBackupWarningMissedDays - Falls nach X Tagen kein Backup erfolgt ist, wird eine Warnung ausgelöst.
  • sstBackupWarningEmail - E-Mail Adresse(n) an welche die Warnung geht (multivalued). Obligatorisch.
  • sstBackupWarningMobileTelephoneNumber Händy Nummer falls sstQuotaNotificationWarningMedium aus SMS gesetzt ist.
  • sstBackupWarningLanguage - Notifikationssprache gemäss RFC 1766 (ISO 3166-1-alpha-2 code-ISO 639-1 Code, Beispiel de-CH) Optional, nur nötig wenn anders als die Sprache bei der Person.
  • sstNotificationWarningMedium - Art der Notifikation, z.B. E-Mail, SMS) (wird zu 99% der Fälle E-Mail sein).
  • sstBackupLastSuccessfulBackup - Timestamp des letzen erfolgreichen Backups (Syntax: Generalized Time, siehe RFC 2252, Punkt 6.14. Beispiel: 199412161032Z)

The following table describes the different attributes:

Attribute	Existence	Mandatory	Description
attribure	MUST	x	TBD.

Legend:

• x: Mandatory in all cases.