4.3. The LDAP scheme

The following scheme defines the classes and attributes used in our example database. We added some comments to better explain the choices we made and the meaning of the various sections.

#
# infra.scheme
#

# base OIDs
objectIdentifier infraOID 1.1
objectIdentifier infraLDAP infraOID:2
objectIdentifier infraAttributeType infraLDAP:1
objectIdentifier infraObjectClass  infraLDAP:2
    

these are macros defining the OIDs for the classes and attributes we will describe. OID 1.1 is used for tests. One should register his/her own OID to avoid overlapping with other schemes defined by somebody else.

# short forms for very common data types
objectIdentifier String   1.3.6.1.4.1.1466.115.121.1.26
objectIdentifier Boolean  1.3.6.1.4.1.1466.115.121.1.7
objectIdentifier Date     1.3.6.1.4.1.1466.115.121.1.26
objectIdentifier Counter  1.3.6.1.4.1.1466.115.121.1.27



### Attributes

attributetype ( infraAttributeType:7 NAME 'status'
        DESC 'Status of an object'
        EQUALITY caseIgnoreIA5Match
        SYNTAX String SINGLE-VALUE )
    

the status attribute has been introduced to allow objects to exist in different states (e.g. to specify in what phases of creation the object is, or to enforce a password change before users can access their newly created services, or to disable an account without deleting it). All of the filters we use for virtual services include a part verifying that the status of the object is set to active

attributetype ( infraAttributeType:1 NAME 'documentRoot'
        DESC 'The absolute path to the document root directory'
        EQUALITY caseExactIA5Match
        SYNTAX String SINGLE-VALUE )

attributetype ( infraAttributeType:2 NAME 'serverAlias'
        DESC 'Apache server alias'
        EQUALITY caseExactIA5Match
        SYNTAX String )

attributetype ( infraAttributeType:3 NAME 'options'
        DESC 'Comma separated string of options'
        EQUALITY  caseExactIA5Match
        SYNTAX String SINGLE-VALUE )    

attributetype ( infraAttributeType:5 NAME 'alias'
        DESC 'apache alias'
        EQUALITY caseExactIA5Match
        SYNTAX String SINGLE-VALUE )

attributetype ( infraAttributeType:6 NAME 'parentSite'
        DESC 'website an apache alias is referring to'
        EQUALITY caseExactIA5Match
        SYNTAX String SINGLE-VALUE )
    

these attributes have been created particularly to store values for virtual hosts and subsites configuration of Apache server.

attributetype ( infraAttributeType:8 NAME 'ftpEnabled'
        DESC 'Machine enabled to use the network '
        EQUALITY caseIgnoreIA5Match
        SYNTAX String  SINGLE-VALUE )

attributetype ( infraAttributeType:12 NAME 'creationDate'
        DESC 'Accont creation date'
        EQUALITY caseIgnoreIA5Match
        SYNTAX Date SINGLE-VALUE )

attributetype ( infraAttributeType:20 NAME 'dbuser'
        DESC 'username of datbase'
        EQUALITY caseIgnoreIA5Match
        SYNTAX String SINGLE-VALUE )

attributetype ( infraAttributeType:21 NAME 'dbname'
        DESC 'database name'
        EQUALITY caseIgnoreIA5Match
        SYNTAX String SINGLE-VALUE )

attributetype ( infraAttributeType:22 NAME 'clearPassword'
        DESC 'cleartext password'
        EQUALITY caseExactIA5Match
        SYNTAX String SINGLE-VALUE )
    

these last three attribute concern the MySQL database objects. Mysql is not able to authenticate users on an LDAP database but it's useful nonetheless to keep track of this informations from an administrative point of view.

### Classes

objectclass ( infraObjectClass:1 NAME 'infraObject'
        SUP top ABSTRACT
        DESC 'Basic administrable object'
        MAY ( creationDate $ host $ status )
        )
    

These is the base class from which all of the objects of virtual services are derived. In this way it's possible to have a common set of attributes relative to all virtual services objects (as attribute relatively to the management of the user or the box on which the services is hosted through the host attribute).

objectclass ( infraObjectClass:2 NAME 'virtualHost'  
        SUP infraObject STRUCTURAL
        DESC 'Apache virtual host'
        MUST ( documentRoot $ cn $ status )
        MAY ( serverAlias $ emailAddress $ options )
        )

objectclass ( infraObjectClass:3 NAME 'virtualMailUser'
        SUP infraObject STRUCTURAL
        DESC 'Virtual mail user' 
        MUST ( mail )
        MAY ( mailMessageStore $ userPassword $
              mailAlternateAddress $ mailForwardingAddress $ 
              gidNumber $ uidNumber )
        )

objectclass ( infraObjectClass:4 NAME 'subSite'
        SUP infraObject STRUCTURAL
        DESC 'Apache sub-directory of our main sites'
        MUST ( alias $ parentSite $ documentRoot )
        )

objectclass ( infraObjectClass:8 NAME 'dataBase'
        SUP infraObject STRUCTURAL
        DESC 'MySQL database info'
        MUST ( dbname )
        MAY  ( dbuser $ clearPassword )
        )

objectclass ( infraObjectClass:10 NAME 'ftpAccount'
        SUP infraObject AUXILIARY
        DESC 'an FTP account'
        MUST ( ftpEnabled )
        )

    

These are the classes corresponding to the different virtual services. The only exception is the ftpAccount object, defined as a addon class to shadowAccount, so that the FTP server can authenticate using PAM. In the end there discrepancies are not important since the management software hides them.