SurgeLDAP comes with the following schema files:

Common Object Request Broker Architecture (corba)
Core schema (core) [from RFC2251-RFC2256]
Cosine and Internet X.500 schema (cosine) [from RFC1274]
InetOrgPerson (inetorgperson) [from RFC2798]
Java Object Schema (java)
Kerberos V KDC schema (krb5-kdc)
North American Directory Forum (nadf)
Network Information Service (nis) [from RFC2307]
OpenLDAP Project's directory schema (openldap)

All these schema's are located in the SurgeLDAP schema directory

unix - /usr/local/surgeldap/schema/open/
windows - c:\surgeldap\schema\open\

The default installation only sets up 3 of these schema's, these are:

Core schema (core) [from RFC2251-RFC2256]
Cosine and Internet X.500 schema (cosine) [from RFC1274]
InetOrgPerson (inetorgperson) [from RFC2798]

To add or extend the schema you can edit the file:

unix - /usr/local/surgeldap/schema/schema.dat
windows - c:\surgeldap\schema\schema.dat

To create a new schema layout you can either place your schema definition inside an already create schema file or create a a brand new schema file and update the '/usr/local/surgeldap/scahema/schema.dat' to include your schema file.

In SurgeLDAP there are two main types: Fields and ObjectClass

Fields:
	A field is definition of data. The field can be defined as any of the base 8 data types, 'binary', 'string', 'bit_string', 'oid_string', 'integer', 'bool', 'time' or any already defined field. Fields should be defined before they are used in ObjectClass. This is not necessary and can be defined within a ObjectClass. But defining then seperately makes them easier to locate if any changes are needed. The layout to define a field is: name = data_type [,SINGLE-VALUE] [,MATCH-CASE] [,HIDDENxx]              [,ADMIN_MOD] [,SYSTEM_MOD] [,MATCH(...)] The 'data_type' can be: Binary Binary(max_size) This will store the data as binary without any base type. Only equal checks are allowed on this data type. String String(max_size) Data type cast as strings, only 7bit values are allowed in this datatype. Bit_string Bit_string(max_size) This stores binary values as a easy to read string. An example of this is:             '01010101'B no other charcter is allowed. Oid_string Oid_string(max_size) This stores the 'oid' as a string value. SurgeLDAP does support IOD's but does need them to function. An example of this is:             123.123.123.123.123.123 Interger This stores an interger value as a string. An example of this is:             1234 Bool This stores a TRUE/FALSE value only. Time This stores a time in the layout: yyyymmddHHMMZ This is mainly used for 'timestamps' Another Field You can also define a field based on another already defined field. See below for an example. name = string(100) commonName = name sn = name surname = name Only the first 4 data types you can specify the max length of the data. After the data type their are 4 options that you can setup, Not all options have an effect with every data type. See below for their description. SINGLE-VALUE This states that this field is only allow to have 1 value when a record is being created. If this is not define you can have a record which has multiple values for the field. MATCH-CASE This only effects the 'string' data type, any compares done on this field will fail if the case is different. If this is not define the comparisons are case insensitive. HIDDENxx This is used to define the level of secuity that you wish to place on this field. The 'xx' is replace with a number from '1' to '20'. Only uses that have the neccessary security level will be allowed to view and change the data in this field. An example of this is the 'userPassword' which is defines as having 'HIDDEN10'. Users with 10 or higher level security are allowed to view and change this field. ADMIN_MOD Only users that are ADMIN's are allowed to modify this field. Anyone can view this field, but only administractors are allowed to setup or change their value. SYSTEM_MOD Only SurgeLDAP is allowed to modify this field. The following are fields that SurgeLDAP changes: createTimestamp, modifyTimestamp, creatorsName and modifiersName MATCH(...) This forces SurgeLDAP to verify the data it gets matches the string field within the brackets. The best example of this is an email field could be defined as: MATCH(?*@?*.?*) Which will force it to have at least 1 character for each part and have an '@' and '.' in the correct order. Each field defination must be on seperate line inside the schema file. Below are a few example of some default fields defined. createTimestamp = time,SYSTEM-MOD,SINGLE-VALUE,HIDDEN12 creatorsName = dn,SYSTEM-MOD,SINGLE-VALUE,HIDDEN12 name = string(100) distinguishedName = dn objectClass = string,MATCH-CASE aliasedObjectName = dn,SINGLE-VALUE cn = name commonName = name sn = name surname = name
ObjectClass:
	This is a collection of various fields to build a ObjectClass. Every record MUST be defined from a ObjectClass. A ObjectClass can be derived from another ObjectClass with more fields or just from fields. ObjectClass can also include a defination of a new field. It is best to define an field before using it within a ObjectClass as this makes them easier to locate if any changes are needed. The layout to define a ObjectClass is: name = [STRUCTURE struct_list]              [SYSTEM list]              [REQUIRES list]              [ALLOWS list] A ObjectClass must have at least 1 of the above 4 lists, but can also have 2, 3 or all of them. See below on what each one means. STRUCTURE This is a comma seperated list of ObjectClass that this ObjectClass will be derived from. All fields within the list of ObjectClass will exist in the same group. (system,requires or allows) SYSTEM This is the list of fields that only SurgeLDAP is allowed to change. The main values placed here are: createTimestamp, modifyTimestamp, creatorsName and modifiersName REQUIRES This is the list of fields that MUST be define before the record will be created. If you are missing any fields SurgeLDAP will resond with a 'Constraint Violation' error, and the record will NOT be created. ALLOWS These are list of fields that are allowed to be present. When an object is created/modified and it is provided a field that does not exists within this list SurgeLDAP will resond with a 'Constraint Violation' error, and the record will NOT be created. Below are a few example of some default ObjectClass defined. top = REQUIRES objectClass system_stamp = SYSTEM createTimestamp, modifyTimestamp, creatorsName, modifiersName person = STRUCTURE top, system_stamp REQUIRES sn, cn, ALLOWS userPassword, name, telephoneNumber, seeAlso, description, mail, userdata, addrbook

Once you have created your schema and updated the schema.dat to include your schema file you should tell SurgeLDAP to check the schemas. To do this you need to run SurgeLDAP from a command prompt like this:

./surgeldap -schema

***************************
Databank and Schema are OK
***************************

If you are unable to remove all the schema errors you should then revert back to the orginal schema files.

SurgeLDAP does allow you to change the default schema defination, the same procedure as when you are creating a new schema should be followed.

The main issue you need to be aware of SurgeLDAP will NOT allow any schema changes that will make any current record invalid. If for example you wish to add another 'REQUIRES' field in an ObjectClass any current record which uses the ObjectClass will need to have that field already. The best way to do this is first add it as a 'ALLOWS' first then adding it to every object that needs and then moving it to the 'REQUIRES' list.

If SurgeLDAP is shutdown (power cut for example) before you finish ensuring that no schema violations are left, if their are any SurgeLDAP will NOT start on boot up. Any you need fix any violations and manually start SurgeLDAP.