A service package is implemented by the Class-of-Service mechanism in the LDAP directory. This mechanism lets you set values for predefined attributes that are installed in the directory when you configure Delegated Administrator. A service package adds the characteristics of the service to user or group entries.
Delegated Administrator provides sample Class-of-Service templates.
You can also create your own service packages.
In the Delegated Administrator console, you can assign the sample packages and your own packages to users or groups.
A service package includes the following components:
Access Manager service
Service bundle (mail service and/or calendar service)
LDAP object (users or groups)
Delegated Administrator automatically provides Access Manager service with every service definition. When you assign a service package to a user or group, Delegated Administrator takes the Access Manager object classes and attributes from the service definition and adds them to the LDAP entry.
Do not change or delete the Access Manager portion of any service package.
When you create a service package, you can configure its service bundle and LDAP object.
Delegated Administrator provides two types of service: mail service and calendar service.
A service package bundles one or more services, together with a set of attributes associated with that service. Thus, an individual service package can contain the following combinations of services:
Mail service only
Calendar service only
Mail and calendar service
Only the mail service package templates have LDAP attributes associated with the mail Class-of-Service definition. The Calendar service package templates do not include attributes associated with the Calendar service definition.
A service package is defined either for users or for groups. You cannot assign the same service package to a user and a group.
Delegated Administrator provides service packages with the following service bundles and LDAP objects:
User mail service
User calendar service
User mail and calendar service
Group mail service
Group calendar service
Group mail and calendar service
In Delegated Administrator, a group is an entry in the LDAP directory that comprises a list of users. Characteristics of the group are not passed on to the users who are members of the group. For example, when you assign a service package to a group, the service package attributes are not inherited by the members of the group. The user entries in the directory are not subordinate to (do not “belong” to) the group entry.
When a mail service package is assigned to a group, the group becomes a mailing list, which is used by Messaging Server.
When calendar service is assigned to a group, the members of the group share group invitations and other calendar information managed by Calendar Server.
A mail group does not have its own mailbox; a message sent to the group address is delivered to the mailboxes of the individual members of the group.
However, a calendar group does have its own calendar; an invitation sent to the group is displayed on the group calendar and on the calendars of the individual members of the group.
When you configure Delegated Administrator, you can choose to install a set of predefined, sample Class-of-Service templates. The Delegated Administrator console displays these templates.
(When you run the configuration program, select Load sample service packages in the Service Package and Organization Samples panel.) The configuration program adds the cos.sample.ldif file to the LDAP directory.
You can use the sample templates to provide services and mail attributes to users and groups. For a list of the templates with their attribute values, see Sample Class-of-Service Templates.
Figure 1–7 shows the user service package templates.
Figure 1–8 shows the group service package templates.
In the Delegated Administrator console, you perform the following service-package tasks:
Allocate service packages to organizations. By allocating some (or all) packages to an organization, you make those packages available to users or groups in the organization.
For each package, you allocate a specified number of packages.
For example, for the ABC organization, you might allocate 5,000 gold service packages, 10,000 venus service packages, and 500 atlantic service packages.
Assign service packages to users.
Assign service packages to groups.
The service packages allocated to an organization make up the pool from which service packages can be assigned to users or groups in the organization.
You can assign multiple service packages to a user or group.
When you assign a service package to a user or group, all the attributes and values in the service package are automatically assigned to the user or group.
To assign only calendar service to a user, use the standardUserCalendar service package. Calendar service does not have any associated attributes.
Assigning the standardUserCalendar service package is equivalent to using the -s cal option in the commadmin user create or commadmin user modify command.
For instructions on how to allocate and assign service packages, see the Delegated Administrator console online help.
The Class-of-Service templates described in this chapter are meant to be examples. Most likely you will want to create your own service packages with attribute values appropriate for the users and groups in your installation.
To create your own service packages, you can use a Class-of-Service template stored in the da.cos.skeleton.ldif file. This file was created specifically for use as a template for writing service packages. It is not installed in the LDAP directory when Delegated Administrator is configured.
You can copy and edit the da.cos.skeleton.ldif file and use an LDAP directory tool such as ldapmodify to install your customized Class-of-Service templates in the directory.
The Delegated Administrator console displays your customized templates along with the sample templates. In the console, the Class-of-Service template is called a service package. When you can assign a service package either to a user or to a group, Delegated Administrator populates the user or group LDAP entry with a complete service package, including Access Manager service.
For instructions on using the da.cos.skeleton.ldif file to configure your own service packages, see Create Service Packages in Chapter 3, Configuring Delegated Administrator.
You can extend the Delegated Administrator service package definition by adding any attribute to the definition entry.
However, in this release of Delegated Administrator, the console allows you to view only the predefined attributes provided when Delegated Administrator is configured. The Delegated Administrator console does not display any attributes you add to a service package definition.
In this release, you also should not remove the predefined attribute definitions from the Class-of-Service definitions provided by Delegated Administrator.
When you use Delegated Administrator to assign a service package to a user or group, a single attribute (inetCOS) is added to the user or group entry in the LDAP directory. The value of the inetCOS attribute assigns the entire service package to the user or group, including the service and any attributes associated with that service. (inetCOS is a multi-valued attribute.)
For example, suppose you assign the platinum package to a user. The following attribute is added to the user entry:
inetCOS: platinum
The platinum package provides mail service to the user. The package also contains the following values for mail attributes. Thus, assigning the platinum package has the effect of adding these attributes to the user entry:
mailMsgMaxBlocks: 800 mailQuota: 10000000 mailMsgQuota: 6000 mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL |
The Access Manager service definition provides the object classes and attributes required for the mail and/or calendar service. When you assign the service package, Delegated Administrator adds these object classes and attributes to the user or group entry.
This section lists the sample Class-of-Service templates and mail attribute values provided by the templates.
These templates are contained in the cos.sample.ldif file.
Mail service includes LDAP attributes defined for mail users. Table 1–2 defines these attributes.
Table 1–2 Mail service attributes that can be used in a service package
Attribute |
Definition |
---|---|
Size in units of MTA blocks of the largest message that can be sent to the user or group. |
|
Filter specifying the available client access to specified services. For example: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALL |
|
Maximum number of messages permitted for a user (including all user folders). |
|
Disk space (in bytes) allowed for the user’s mailbox. |
For more information about these attributes, see “Chapter 3: Messaging Server and Calendar Server Attributes” in the Sun Java System Communications Suite Schema Reference.
Platinum
mailMsgMaxBlocks: 800 mailquota: 10000000 mailmsgquota: 6000 mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL daServiceType: mail user |
Gold
mailMsgMaxBlocks: 700 mailquota: 8000000 mailmsgquota: 3000 mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL daServiceType: mail user |
Silver
mailMsgMaxBlocks: 300 mailquota: 6291456 mailmsgquota: 2000 mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL daServiceType: mail user |
Bronze
mailMsgMaxBlocks: 700 mailquota: 5242288 mailmsgquota: 3000 mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL daServiceType: mail user |
Ruby
mailMsgMaxBlocks: 600 mailquota: 1048576 mailmsgquota: 2000 mailAllowedServiceAccess: +pops:ALL$+smtps:ALL$+http:ALL daServiceType: mail user |
Emerald
mailMsgMaxBlocks: 600 mailquota: 2097152 mailmsgquota: 2000 mailAllowedServiceAccess: +pop:ALL$+smtp:ALL$+http:ALL daServiceType: mail user |
Diamond
mailMsgMaxBlocks: 5000 mailquota: 3145728 mailmsgquota: 3000 mailAllowedServiceAccess: +imaps:ALL$+smtps:ALL$+http:ALL daServiceType: mail user |
Topaz
mailMsgMaxBlocks: 3000 mailquota: 4194304 mailmsgquota: 2000 mailAllowedServiceAccess: +imap:ALL$+smtp:ALL$+http:ALL daServiceType: mail user |
None (standardUserCalendar)
There is no predefined Class-of-Service template that provides calendar service and contains attribute values. Calendar service is provided without associated attributes.
Because no sample template exists, Delegated Administrator generates a default service package, without a template, directly from the User Calendar Class-of-Service definition. Its name is the same as that of the Class-of-Service definition: standardUserCalendar.
This service package provides calendar service only.
The following sample templates apply both mail and calendar service.
Mercury
mailMsgMaxBlocks: 800 mailquota: 10000000 mailmsgquota: 6000 mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL daServiceType: mail user daServiceType: calendar user |
Venus
mailMsgMaxBlocks: 700 mailquota: 8000000 mailmsgquota: 3000 mailAllowedServiceAccess: +imaps:ALL$+pops:ALL$+smtps:ALL$+http:ALL daServiceType: mail user daServiceType: calendar user |
Earth
mailMsgMaxBlocks: 300 mailquota: 6291456 mailmsgquota: 2000 mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL daServiceType: mail user daServiceType: calendar user |
Mars
mailMsgMaxBlocks: 700 mailquota: 5242288 mailmsgquota: 3000 mailAllowedServiceAccess: +pop:ALL$+imap:ALL$+smtp:ALL$+http:ALL daServiceType: mail user daServiceType: calendar user |
Atlantic
mailMsgMaxBlocks: 800 daServiceType: mail group |
Pacific
mailMsgMaxBlocks: 900 daServiceType: mail group |
Indian
mailMsgMaxBlocks: 1000 daServiceType: mail group |
Arctic
mailMsgMaxBlocks: 1200 daServiceType: mail group |
None (standardGroupCalendar)
There is no predefined Class-of-Service template that provides calendar service to groups and contains attribute values. Calendar service is provided without associated attributes.
Because no sample template exists, Delegated Administrator generates a default service package, without a template, directly from the Group Calendar Class-of-Service definition. Its name is the same as that of the Class-of-Service definition: standardGroupCalendar.
This service package provides calendar service (to groups) only.
The following sample templates apply both mail and calendar service to groups.
Nile
mailMsgMaxBlocks: 1600 daServiceType: mail group daServiceType: calendar group |
Amazon
mailMsgMaxBlocks: 1800 daServiceType: mail group daServiceType: calendar group |
Thames
mailMsgMaxBlocks: 2000 daServiceType: mail group daServiceType: calendar group |
Danube
mailMsgMaxBlocks: 2200 daServiceType: mail group daServiceType: calendar group |
This release of Delegated Administrator provides a Class-of-Service definition for each type of service package:
User mail service
User calendar service
User mail and calendar service
Group mail service
Group calendar service
Group mail and calendar service
When you configure Delegated Administrator, the Class-of-Service definitions are installed in the directory.
In each definition, the daServiceType attribute determines the type of service package with the following syntax:
daServiceType: <service type> <target>
where service type is mail service, calendar service, or both, and target is either user or group.
The user mail service is defined in a Class-of-Service definition called standardUserMail:
# # Definition for user mail service bundle # dn: cn=standardUserMail,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=mailuser,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: mailAllowedServiceAccess cosAttribute: mailMsgMaxBlocks cosAttribute: mailquota cosAttribute: mailmsgquota daServiceType: mail user NOTE: When the Delegated Administrator configuration program installs the standardUserMail definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The daServiceType attribute defines this as a mail service for users.
The user calendar service is defined in a Class-of-Service definition called standardUserCalendar:
# # Definition for user calendar service bundle # dn: cn=standardUserCalendar,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=calendaruser,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: icsPreferredHost cosAttribute: icsDWPHost cosAttribute: icsFirstDay daServiceType: calendar user NOTE: When the Delegated Administrator configuration program installs the standardUserCalendar definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The daServiceType attribute defines this as a calendar service for users.
The calendar service definition also includes calendar attributes such as icsPreferredHost.
However, Delegated Administrator does not provide service-package templates that specify values for these attributes. The Delegated Administrator console provides one service package with calendar service only: the standardUserCalendar service package. This package does not include calendar attributes.
The user mail and calendar service is defined in a Class-of-Service definition called standardUserMailCalendar:
# # Definition for user mail and user calendar service bundle # dn: cn=standardUserMailCalendar,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=mailcalendaruser,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: icsPreferredHost cosAttribute: icsDWPHost cosAttribute: icsFirstDay cosAttribute: icsQuota cosAttribute: mailAllowedServiceAccess cosAttribute: mailMsgMaxBlocks cosAttribute: mailquota cosAttribute: mailmsgquota daServiceType: calendar user daServiceType: mail user NOTE: When the Delegated Administrator configuration program installs the standardUserMailCalendar definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The two daServiceType attribute entries define this as a calendar service and mail service for users.
The group mail service is defined in a Class-of-Service definition called standardGroupMail:
# # Definition for group mail service bundle # dn: cn=standardGroupMail,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=mailgroup,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: mailMsgMaxBlocks daServiceType: mail group NOTE: When the Delegated Administrator configuration program installs the standardGroupMail definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The daServiceType attribute defines this as a mail service for groups.
The group calendar service is defined in a Class-of-Service definition called standardGroupCalendar:
# # Definition for group calendar service bundle # dn: cn=standardGroupCalendar,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=calendargroup,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: icsdoublebooking cosAttribute: icsautoaccept daServiceType: calendar group NOTE: When the Delegated Administrator configuration program installs the standardGroupCalendar definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The daServiceType attribute defines this as a calendar service for groups.
The calendar service definition also includes calendar attributes such as icsdoublebooking.
However, Delegated Administrator does not provide service-package templates that specify values for these attributes. The Delegated Administrator console provides one service package for groups with calendar service only: the standardGroupCalendar service package. This package does not include calendar attributes.
The user mail and calendar service is defined in a Class-of-Service definition called standardGroupMailCalendar:
# # Definition for group mail and group calendar service bundle # dn: cn=standardGroupMailCalendar,<ugldapbasedn> changetype: add objectclass: top objectclass: LDAPsubentry objectclass: extensibleObject objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: o=mailcalendargroup,o=cosTemplates,<ugldapbasedn> cosSpecifier: inetCos cosAttribute: mgrpMsgMaxSize cosAttribute: mailMsgMaxBlocks daServiceType: calendar group daServiceType: mail group NOTE: When the Delegated Administrator configuration program installs the standardGroupMailCalendar definition in the directory, the variable <ugldapbasedn>, shown above, is replaced by your root suffix (such as o=usergroup).
The two daServiceType attribute entries define this as a calendar service and mail service for groups.
In the LDAP Directory Information Tree (DIT), the Class-of-Service definitions are located in a node directly under the root suffix. Because they are stored at the top of the DIT, the service packages can be assigned to all user entries in the directory.
Figure 1–9 shows the location of the service definitions and packages in the DIT.
Each type of Class-of-Service template is located under its own node. Thus, a template providing mail service to users is located under the Mail User node. This structure enables Delegated Administrator to use the correct Class-of-Service definition (such as standardUserMail) when it assigns a service package to a user or group.
Delegated Administrator uses the classic Class-of-Service definition.
For more information about the Class-of-Service mechanism, see the Sun Java System Directory Server Administration Guide. Specifically, see “Defining Class-of-Service (CoS)” in “Chapter 5: Managing Identity and Roles.”
The Sun Java System Directory Server Administration Guide also describes related topics such as determining which service attribute value takes precedence if an attribute defined in a service package assigned to a user already exists in that individual user entry.