After you have installed (with commpkg install) and configured Oracle Communications Delegated Administrator (with config-commda), you can customize your configuration to meet your particular needs.
This chapter describes how to add customized attributes to the Delegated Administrator console. Next, it shows how to customize additional Delegated Administrator features. Finally, it lists the locations of the configuration files and explains how to redeploy a customized file to the proper location.
You should back up any existing Delegated Administrator configuration file before you begin customizing it.
Also, customized configuration data can be lost when you upgrade Delegated Administrator. Therefore, you should preserve your customized configuration before you upgrade Delegated Administrator or rerun the Delegated Administrator configuration program. For more information, see Delegated Administrator Installation and Configuration Guide.
This section describes how to add custom attributes that can be provisioned in the Delegated Administrator console in Access Manager mode only. In Direct LDAP mode, all LDAP attributes are retrieved by default.
You can customize the Delegated Administrator console to manage user attributes that are not already provided by the service packages and the Service sections (such as Mail Service or Calendar Service) of the User Properties page.
After you add the custom attributes, the Delegated Administrator console operates as follows:
The console displays a UI field representing each custom LDAP attribute.
When you create a user, the custom attributes appear in a page, called Custom Data Section, in the Create New User wizard. This page appears just before the Summary page.
In addition, you can edit the values of these attributes for existing users. The custom attributes appear in a Custom Data Section in the User Properties page.
You can enter a value in the UI field or check the box.
When you click Save in the console, Delegated Administrator stores the updated values in the corresponding LDAP attributes in the directory.
If you write business logic and validation in the Java class that implements the custom attribute, that logic is performed before the values are saved in the directory.
You can customize attributes for users only.
To add custom attributes to the console, you need to perform the following tasks:
Update your LDAP schema and add the object classes and attributes to the LDAP directory. Directory Server must recognize these attributes before Delegated Administrator can successfully write attribute values to the directory.
You also may add attributes that already belong to your schema and are recognized by Directory Server (attributes provided by the Directory Preparation Tool, comm_dssetup). For example, you may want to add a mail attribute that is not automatically provisioned by Delegated Administrator. In this case, you do not need to update your schema.
Create an XML customization file that identifies the LDAP attributes and defines the UI fields to be displayed in the Delegated Administrator console.
See "Creating a Customization File" for detailed instructions.
Edit the properties file that activates the customization and identifies the Java class.
See "Editing the daconfig.properties file" for detailed instructions.
(Optional) Create a Java class that enables Delegated Administrator to respond to user input for the attributes. The customization subsystem calls the business logic and validation you write for the attributes before values are written to the LDAP directory.
See "Creating a Java Class for the Custom Attributes" for detailed instructions.
You do not need to perform these tasks in any particular sequence.
However, after you complete these tasks, you must deploy your updated configuration files to the Web container used by the Delegated Administrator console. See "Creating a Java Class for the Custom Attributes" for a description of the deploy step.
(In Access Manager mode) Edit the Delegated Administrator server resource.properties file to add the custom attribute in the section userreturnattr-xx and follow the steps mentioned in the section "Deploying a Customized Configuration File" to deploy the changes.
See "Customization File Details" for information about the customization file, including guidelines for creating the file, descriptions of the XML elements, and an example.
Open the sample XML customization file, sampleCustom.xml, in a text editor.
The sampleCustom.xml file is located by default in the following directory:
DelegatedAdmin_home/data/da/jsp/users
Remove the comment markers from the XML entries.
The sampleCustom.xml file shows the DTD definition and a skeleton sample:
<?xml version="1.0" encoding="UTF--8"?> <!----DTD DEFINITION: PLEASE DO NOT EDIT THE FOLLOWING LINES----> <!DOCTYPE ;property--list [ <!ELEMENT property--list (property)+> <!ELEMENT> <!ATTLIST property label CDATA #REQUIRED CDATA #REQUIRED uifield (text | textarea | checkbox) #IMPLIED syntax (string \| number) #IMPLIED> ]> <!---- END DEFINITION ----> <!---- Pls uncomment and edit below for customization <property--list> <property label="Customized label1" attr="custattr1" > <property label="rsrc.key.label2" attr="custattr2" uifield="text"& > </property--list> ---->
See "Sample Customization File" for an example of a customization file containing three attributes.
Edit the section of the file that starts with the property-list element.
Add the XML elements to define the custom attributes. Add one entry, beginning with the property element, to define each attribute.
See "Guidelines for Creating a Customization File" for instructions on how to define the attributes and their corresponding UI fields in the console.
See "XML Elements Used in a Customization File" for definitions of the XML elements.
(Optional) Rename the customization file to a name suitable for your installation.
Save the customization file in the following directory:
DelegatedAdmin_home/data/da/jsp/users
The customization file must be in this location.
This task explains how to activate the customization and identify the Java class.
Open the daconfig.properties file in a text editor.
The daconfig.properties file is located by default in the following directory:
DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/comm/da/resources
Find the following properties in the file:
users.custom.plugin.exist=false users.custom.plugin.class=com.sun.comm.da.common.ReferenceCustomUIPluginImpl users.custom.plugin.separator=, \n\r
Change the value of the users.custom.plugin.exist property from false to true.
By default, this value is false.
For example:
users.custom.plugin.exist=true
Setting this value to true activates the task of customization in Delegated Administrator (which includes enabling the customization plug-in).
Even if you do not write a Java class for customized business logic (as described in "Creating a Java Class for the Custom Attributes"), you must set the users.custom.plugin.exist property to true to enable the customization to work.
(Optional) Modify the Java class name for the customization plug-in.
By default, the fully qualified Java class name is:
com.sun.comm.da.common.ReferenceCustomUIPluginImpl
To modify the Java class name, edit the name in the following property:
users.custom.plugin.class= com.sun.comm.da.common.ReferenceCustomUIPluginImpl
If you want to use the default name, you do not have to modify this property.
(Optional) Specify additional separators for multi-valued attributes.
If you add a multi-valued LDAP attribute, line separators are needed to distinguish multiple entries for attribute. By default, four common separators are configured in the following property:
users.custom.plugin.separator=, \n\r
To add to or modify the separators, edit the values in this property.
This task explains how to write a Java class that implements the Java interface for adding business logic to handle the custom attributes.
This task is optional. If you do not change the default Java class name and do not need to add business logic and validation for the custom attributes, you do not need to perform this task.
Create the Java class file.
The class implements the following two methods:
public String getCustomFilename();
You should return the name of the XML customization file that you created in "Creating a Customization File" for the getCustomFilename method.
public String performBusinessLogic(DAObjectContext ctx);
In the performBusinessLogic method, you can implement any business logic and validation you want to perform.
The customization subsystem calls the performBusinessLogic method before it saves the custom attribute values in the LDAP directory. It passes the DAObjectContext object as a parameter. Developers can get information from this object through the following methods:
public String getOrganizationDN(); public DAUser getUserObject();
The DAUser class is part of the Java Delegated Administrator API (JDAPI) library bundled with Delegated Administrator.
To see a simple example of how to implement this plug-in class, examine the default Java class file, named ReferenceCustomUIPluginImpl and located in the following path:
DelegatedAdmin_home/WEB-INF/classes/
This sample file is a fully working class for the default settings in the sample customization file, sampleCustom.xml. If you do not need to implement your own business logic and validation, you can use the sample Java class without modifying it. (Of course, if you change the name of the customization file, you also must change it in the getCustomFilename method in the Java class.)
Copy the Java class file to the following directory:
DelegatedAdmin_home/WEB-INF/classes/Java class
where Java class is the fully qualified Java class name.
The Java class file must be in this location.
Redeploy the edited files to the Web container used by the Delegated Administrator console.
All the files you have created or updated in this task and in the preceding task, "Creating a Customization File", are located in the Delegated Administrator configuration path. These files include:
The XML customization file
The daconfig.properties file
Java class file
Before the changes you have made can take effect, you must run the script that deploys the customized files to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to perform this task.
The customization file provides the Delegated Administrator console with the information it needs to do the following:
Display a field in the Delegated Administrator console that represents the LDAP attribute in the directory
Accept user input in a text box, text area, or check box in the console
Save the modified input as the value of the LDAP attribute in the directory
The customization file is defined in XML format.
When you create a customization file, follow these rules and guidelines:
You can define multiple attributes in a customization file.
Each attribute is defined on a separate line.
One element, property, identifies each attribute defined in the file.
The property element appears at the beginning of each attribute definition (each line in the file). If you define multiple attributes, the property element appears repeatedly in the file.
For each attribute, you must define a label to be displayed in the Delegated Administrator console, that describes the attribute.
For each attribute, you must provide the name of the LDAP attribute whose value the console field represents.
Table 8-1 describes the XML elements in the customization file.
Table 8-1 Elements used to define a Delegated Administrator console field derived from an LDAP attribute
| Element | Definition |
|---|---|
|
property |
Represents one UI field. Must be placed at the beginning of each line that defines an attribute. If multiple attributes are defined, this element appears multiple times in the customization file. |
|
label |
Specifies the display text that appears as the label in the Delegated Administrator console. This element is required. It must be used with each instance of the XML element property. |
|
attr |
Specifies the name of the LDAP attribute that will be represented by the display field. This element is required. By default, the LDAP attribute is assumed to be single-valued. To define a multi-valued LDAP attribute, add the prefix multi to the definition of the attr element. For example, to define a multi-valued attribute named custldapttr, enter the following: element:attr="multi:custldapattr" |
|
uifield |
Determines the type of field to be displayed. This field accepts user-supplied values for the LDAP attribute defined with attr. You can specify one of these types of fields:
|
|
syntax |
Specifies the type of value permitted for user input. You can choose one of these syntax values: string or number. If the user enters an invalid value in the display field (for example, an alphanumeric character in a field defined as a number), Delegated Administrator does not save the value in the directory and displays an error message in the console. |
The following sample customization file defines three attributes:
<property--list> <property label="Custom label 1" attr="custldapattr1" uifield="text" syntax="string"/> <property label="Custom label 2" attr="custldapattr2" uifield="textarea" syntax="number"/> <property label="Custom label 3" attr="custldapattr3" uifield="checkbox"/> </property--list>
In this example, the first line defines an LDAP attribute, custldapattr1, with the following label in the console: Custom label 1. Next to the label, the console will display a text box that accepts an alphanumeric string as input.
For the second attribute defined in this example, the console displays a label and a text area that accepts a number as input.
For the third attribute, the console displays a label and a check box. Delegated Administrator returns a value of true (if the check box is checked) or false (if it is unchecked) to be stored with the LDAP attribute in the directory.
If you want the Preferred Mail Host and Preferred Mail Store to be set using the server-wide default, you can perform the tasks described in this section.
If you need to remove the Preferred Mail Host field from the console (specifically, from the New Organization Wizard and Organization Properties screens), you must perform the following steps:
Edit the Security.properties file. This step is described in this section.
Enable the MailHostStorePlugin. This step is described in the "Adding Plug-ins for Delegated Administrator" section.
The Security.properties file lets you customize the Delegated Administrator console for all or for individual roles.
To remove the Preferred Mail Host from the console:
Add the lines shown below to the Security.properties file.
# Remove Preferred Mail Host from UI *.NewOrganizationPage6.PreferredMailHostProperty=INVISIBLE *.NewOrganizationSummaryPage.PreferredMailHostSummaryProperty=INVISIBLE *.OrgProperties.MailHostName=INVISIBLE *.OrgProperties.MailHostNameText=INVISIBLE *.OrgProperties.MailHostValue=INVISIBLE
Caution:
Do not use the line:*.NewOrganizationPage6.PreferredMailHostProperty=INVISIBLE
unless you turn on the server-side plug-in.
The Security.properties file is located in the following directory:
DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/comm/da/resources
Caution:
You may add lines to this file for your own customization, but do not edit the lines already present. Editing existing lines could result in exceptions being thrown on the console.Redeploy the edited Security.properties file to the Web container used by the Delegated Administrator console.
Before the change can take effect, you must run the script that deploys the customized Security.properties file to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to deploy a customized properties file to a particular Web container.
Properties in the Security.properties file are of the form:
Security_Element=status
where:
Security_Element is of the form Role.Container.Console_Element and specifies the console element (for example: MailHostNameText) and role for which a status is being assigned.
Valid roles for Delegated Administrator are:
ProviderAdminRole (SPA) See "Service Provider Administrator and Service Provider Organizations" for information about this role.
OrganizationAdminRole (OA)
Top-levelAdminRole (TLA)
You can use an asterisk to represent multiple roles. For example, the security element *.OrgProperties.MailHostNameText applies to all three roles and is equivalent to:
ProviderAdminRole.OrgProperties.MailHostNameText
OrganizationAdminRole.OrgProperties.MailHostNameText
Top-levelAdminRole.OrgProperties.MailHostNameText
You can assign a security element separate statuses of VISIBLE/INVISIBLE and EDITABLE/NONEDITABLE:
VISIBLE: indicates that the security element is visible and read-only.
INVISIBLE: indicates that the security element is invisible.
EDITABLE: indicates that the security element is editable.
NONEDITABLE: indicates that the security element is read-only.
In assigning statuses to security elements, a later assignment overrides an earlier assignment. For example, given the sequence:
OrganizationAdminRole.OrgProperties.MailHostNameText=EDITABLE *.OrgProperties.MailHostNameText=NONEDITABLE
MailHostNameText is non-editable for all roles.
However, given the following sequence, MailHostNameText is non-editable for the SPA and TLA roles, but editable for the OA role:
*.OrgProperties.MailHostNameText=NONEDITABLE OrganizationAdminRole.OrgProperties.MailHostNameText=EDITABLE
You can customize Delegated Administrator to support the following plug-ins:
MailHostStorePlugin
By default, this plug-in is disabled. If no preferredmailhost is supplied when a business organization is created, an exception will be raised. If the plug-in is enabled, values from the flat file (described later in this section) will be used only if the corresponding attribute is absent.
MailDomainReportAddressPlugin
Uses the domain value to return the desired DSN address. The default implementation is to return the string MAILER-DAEMON@domain.
UidPlugin
Generates a unique id string. The default implementation generates a GUID to return to the caller.
To enable these plug-ins, edit the commcli servlet serverconfig.properties file, located in the following directory:
DelegatedAdmin_home/data/WEB-INF/classes/sun/comm/cli/server/servlet/
serverconfig.properties
(By default, DelegatedAdmin_home for Oracle Solaris and Linux is /opt/sun/comms.)
The plug-ins are located in the serverconfig.properties file in a section headed as follows:
######################## # Plugin Configuration # ########################
Each has "plugin" as the suffix. The current list looks like:
jdapi-mailhoststoreplugin=disabled jdapi-mailhoststorepluginclass=sun.comm.cli.server.util.MailHostStorePlugin jdapi-mailhoststorepluginfile=/tmp/mailhostmailstore jdapi-maildomainreportaddressplugin=enabled jdapi-maildomainreportaddresspluginclass=sun.comm.cli.server.util.MailDomainReportAddressPlugin jdapi-uidautogenerationplugin=disabled jdapi-uidautogenerationpluginclass=sun.comm.cli.server.util.UidPlugin
Each plug-in has at least two lines, which take the following form:
jdapi-namepluginclass= "enablted" | "disablted" jdapi-namepluginclass=sun.comm.cli.server.util/ \ java class name
To enable a plug-in, change "disabled" to "enabled".
Plug-in classes are supplied for all the plug-ins listed in this section. The classes are located in the following directory:
DelegatedAdmin_home/data/WEB-INF/classes/sun/comm/cli/server/util
You do not need to do anything with these classes.
After you edit the serverconfig.properties file, redeploy it to the Web container used by the Delegated Administrator server.
Before the changes can take effect, you must run the script that deploys the customized serverconfig.properties file to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to deploy a customized properties file to a particular Web container.
The MailHostStorePlugin requires a flat file, which is included in a third line for the plug-in. The plug-in reads the value in the flat file and uses it to set attribute values. If the plug-in is enabled, the file must be present, or an error will occur.
jdapi-mailhoststoreplugin o jdapi-mailhoststoreplugininf=full file name o file has one line o value is that for : o preferredmailhost attribute o preferredmailmessagestore attribute o form o mailhost:mailpartition
You can enable Delegated Administrator to add a custom object class to the LDAP entry of a user, group, resource, or organization. To accomplish this task, you customize the appropriate object-creation template installed in the directory by Access Manager.
For example, the BasicUser creation template determines which object classes and attributes are added to a user entry when you create a user. You can update the BasicUser creation template with your custom object class. Thereafter, the custom object class will be added to each user entry with the standard object classes.
The following procedure describes how to customize the BasicUser template. You can follow the same procedure to customize the BasicGroup, BasicResource, and BasicOrganization creation templates.
To add a custom object class to the user-creation process
Make sure your custom object class is defined in the directory schema. See Directory Schema for more information.
Locate the following directory entry:
ou=basicuser,ou=creationtemplates,ou=templates,ou=default, ou=globalconfig,ou=1.0,ou=dai,ou=services, o=$Root_Suffix
where $Root_Suffix is the root suffix of your directory.
Add the following attribute:value to the entry:
sunkeyValue:required=objectClass=$Your_Custom_Objectclass.
where $Your_Custom_Objectclass is your custom object class.
When you run the Delegated Administrator configure program (config-commda), the value you use to log in to Delegated Administrator is set to be a uid.
For example, if you intend to log in as the TLA, and the TLA's uid is john.doe, you would use john.doe to log in to Delegated Administrator.
You can customize Delegated Administrator to enable you to use additional values for the user log-in. For example, you could add the mail address (mail).
The config-commda program sets this value to uid with the loginAuth-idAttr property in the resource.properties file, as shown in the following example:
loginAuth-searchBase=$rootSuffix servicepackage-cosdefbasedn = $rootSuffix loginAuth-idAttr-1=uid
where $rootSuffix is the root suffix in your directory.
You can set additional values for the user log-in by editing the resource.properties file.
The resource.properties file is located in
DelegatedAdmin_home/data/WEB-INF/classes/sun/comm/cli/server/servlet/
resource.properties
For example, to enable you to use a mail address (such as john.doe@sesta.com) to log in, you could add the following line to the resource.properties file:
loginAuth-searchBase=$rootSuffix servicepackage-cosdefbasedn = $rootSuffix loginAuth-idAttr-1=uid loginAuth-idAttr-2=mail
where $rootSuffix is the root suffix in your directory.
You must add an increment to the loginAuth-idAttr property for each value. In this example, a second value is added, so you add -2 to loginAuth-idAttr.
You can add multiple instances of the loginAuth-idAttr property:
loginAuth-idAttr-1=uid
loginAuth-idAttr-2=mail
|
loginAuth-idAttr-n=login-in value
After you edit the resource.properties file, redeploy it to the Web container used by the Delegated Administrator server.
Before the changes can take effect, you must run the script that deploys the customized resource.properties file to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to deploy a customized properties file to a particular Web container.
By default, Delegated Administrator lets you create a user without assigning a service package to the user. You can change the default setting so that all users must have at least one service package assigned to them.
To require users to have a service package assigned to them:
Open the daconfig.properties file in a text editor.
The daconfig.properties file is located by default in the following directory:
DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/comm/da/resources
Change the value of the user.atleastOneServicePackage property from false to true.
By default, this value is false.
For example:
user.atleastOneServicePackage=true
Run the script that deploys the customized daconfig.properties file to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to deploy a customized properties file to a particular Web container.
You can customize Delegated Administrator by adding a Calendar Server time zone. Delegated Administrator can then provision organizations, users, groups, and resources with the time zone.
To add a time zone, perform the following tasks. To administer the time zone with the Delegated Administrator utility, you must perform only the first task. To administer the time zone through Delegated Administrator console, you must perform both tasks.
Once the time zone has been added, you can set it as the default time zone for users created by performing the following task:
You must perform this task before you provision users with the time zone. This task updates Access Manager with the time zone value.
To add a time zone in Delegated Administrator:
Add the time zone in Calendar Server.
To accomplish this step, you must edit the timezones.ics file and other Calendar Server files. For Calendar 7, see Calendar Server System Administrators Guide.
Back up the UserCalendarService.xml and DomainCalendarService.xml files.
The xml files are located by default in the following directory:
DelegatedAdmin_home/lib/services
Edit the UserCalendarService.xml and DomainCalendarService.xml files to add the time zone in Delegated Administrator.
In both the UserCalendarService.xml and DomainCalendarService.xml files, find the following entry heading:
<AttributeSchema name="icstimezone" type="single choice" syntax="string" any="optional|adminDisplay"> <ChoiceValues>
Add the time zone value to the list of <ChoiceValues>.
Run the Access Manager amadmin command to delete the current service and add the updated service. For both the UserCalendarService.xml and DomainCalendarService.xml files, run the following amadmin commands:
amadmin -u admin -w password -rCalendarService ./amadmin -u admin -w password -sda_base/lib/services/CalendarService.xml
where CalendarService is either UserCalendarService or DomainCalendarService.
Note:
If you also intend to make the time zone your default, you can run these amadmin commands after you have performed both tasks. See "Changing the Default Time Zone in Delegated Administrator" for details.Restart your Web container to enable the changes to take effect.
See "Displaying and Administering the Time Zone in the Delegated Administrator Console" to enable the Delegated Administrator console to show the time zone.
This task adds the time zone to the list of time zones displayed in the console. Next, the task enables the time zone value to be saved in the directory.
Edit the Resources.properties file, located under your Delegated Administrator data directory.
The Resources.properties file is located by default in the following directory:
DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/
comm/da/resources
To edit Resources.properties, search for the rsrc.Timezone property and add the time zone to the appropriate list. You can localize this display value of the time zone.
Locate the list of time zone values in the daconfig.properties file, located under your Delegated Administrator data directory.
The daconfig.properties file is located by default in the following directory:
DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/
comm/da/resources
To find the list of time zone values, search for the following line:
#Timezone values - only English
These are the values stored in the LDAP directory. The time zone must be in English; this is the required format for the values stored in the directory.
Add the time zone to the list.
For example, to add America/Miami to the list, assuming Timezone1 currently has 24 values, you would add
rsrc.Timezone1-25=America/Miami
This value would be the 25th time zone displayed in the Americas drop-down list in the console. The time zone may be displayed in another language, depending on what you specified in the Resources.properties file in the preceding task.
Locate the reverse-time zone mappings list in the daconfig.properties file.
This list keys the localized time zone value (displayed in the console) to the actual value, which you specified in Step 2, above.
To find the list of reverse mappings, search for the following line:
#reverse timezone mappings - used by DA in getting localized tz value
Add the value to the reverse-mapping list.
For example, to add America/Miami to the list, you would add
rsrcKey-America-Miami=rsrc.Timezone1-25
Redeploy the edited daconfig.properties and Resources.properties files to the Web container used by the Delegated Administrator console.
Before the change can take effect, you must run the script that deploys the customized daconfig.properties file to your Web container.
See "Deploying a Customized Configuration File" for instructions on how to deploy a customized properties file to a particular Web container.
After you edit and redeploy the daconfig.properties and Resources.properties files, the time zone will appear in the appropriate list boxes in the Delegated Administrator console. It will be saved in the directory whenever you select the time zone in the Delegated Administrator console and click Save.
To change the default time zone in Delegated Administrator:
In the UserCalendarService.xml and DomainCalendarService.xml files, edit the following value:
<DefaultValues>
<Value>America/Denver</Value>
</DefaultValues>
You can find <DefaultValues> under the following entry in the xml files:
AttributeSchema name="icstimezone"
Run the Access Manager amadmin command to delete the current service and add the updated service.
For both the UserCalendarService.xml and DomainCalendarService.xml files, run the following amadmin commands:
./amadmin -u admin -w password -r DomainCalendarService ./amadmin -u admin -w password -sda_base/lib/services/DomainCalendarService.xml
Restart your Web container to enable the changes to take effect.
The directory /opt/sun/comms/da/lib/services contains reference information about the services for both modes. XML files are meant for Access Manager mode while LDIF files are meant for Direct LDAP mode.
However, these LDIF files are not quite exactly what has been employed in LDAP server.
This information is within the file /var/opt/sun/comms/da/config/daAllServices.ldif. Adding the time zone is performed by editing this file and then implementing its content into the LDAP service. This example describes the addition of the Europe/Belgrade time zone.
Save the backup copy of this file and open it in editor.
There are three places in which you will perform the same type of editing. They relate to the services DomainCalendar, GroupCalendar and UserCalendar and the specific attribute within each of them is called icstimezone. At each of these places, at the desired place within the list of available time zones, add the following:
ChoiceValueEurope/Belgrade/ChoiceValue
If you want to declare this time zone as default, then perform the following. Again, within the same three places, inside the attribute icstimezone, substitute the default time zone America/Denver with this one. The end result looks like this:
<DefaultValues><Value>Europe/Belgrade</Value></DefaultValues>
Finally perform the changes:
ldapmodify -D 'cn=Directory Manager' -w -f daAllServices.ldif
However, this method may fail due of the improper formatting of the XML text (the one that is going to become the value of the LDAP attribute sunserviceschema). In that case, you will need to remove all End-of-line characters from that XML description. One way to do this is extracting necessary parts into three separate files (one for each of the Calendar services), reformat the text and apply the files into the LDAP service.
Another way is to run three LDAP searches and have the different files. Through LDAP searches you'll get the text without End-of-Line characters, but encoded in Base64. Beware that simple command to decode and re-encode in Base64 does not exist in Solaris 10. Follow the steps:
Get the current values of the Calendar services from the LDAP directory:
ldapsearch -D 'cn=Directory Manager' -w -1 -T -b ou=1.0,ou=DomainCalendarService,o=daservices,o=comms-config "(|(objectClass=*) (objectClass=ldapsubentry))" sunserviceschema > /tmp/DomainCalendar.ldap ldapsearch -D 'cn=Directory Manager' -w -1 -T -b ou=1.0,ou=GroupCalendarService,o=daservices,o=comms-config "(|(objectClass=*) (objectClass=ldapsubentry))" sunserviceschema > /tmp/GroupCalendar.ldap ldapsearch -D 'cn=Directory Manager' -w -1 -T -b ou=1.0,ou=UserCalendarService,o=daservices,o=comms-config "(|(objectClass=*) (objectClass=ldapsubentry))" sunserviceschema > /tmp/UserCalendar.ldap
Extract the value of the sunserviceschema attribute:
grep ^sunserviceschema /tmp/DomainCalendar.ldap | cut -d" " -f 2 > /tmp/DomainCalendar.base64 grep ^sunserviceschema /tmp/GroupCalendar.ldap | cut -d" " -f 2 > /tmp/GroupCalendar.base64 grep ^sunserviceschema /tmp/UserCalendar.ldap | cut -d" " -f 2 > /tmp/UserCalendar.base64
Decode the Base64 files. This example uses the command base64 available in package GNU coreutils. It also adds End-Of-Line characters so that you can easily edit the textual contents:
base64 -d /tmp/DomainCalendar.base64 | sed -e 's/> />\n /g' -e 's/" /"\n /g' > /tmp/DomainCalendar.xml base64 -d /tmp/GroupCalendar.base64 | sed -e 's/> />\n /g' -e 's/" /"\n /g' > /tmp/GroupCalendar.xml base64 -d /tmp/UserCalendar.base64 | sed -e 's/> />\n /g' -e 's/" /"\n /g' > /tmp/UserCalendar.xml
Add the time zone in the just created XML files, as described. Then remove the End-Of-Line characters and create the final LDIF files ready for deployment into LDAP service:
( echo -e -n "dn: ou=1.0,ou=DomainCalendarService,o=daservices,o=comms-config\nchangetype: modify\nreplace: sunserviceschema\nsunserviceschema: " ; cat /tmp/DomainCalendar.xml | tr -d '\n' ) > /tmp/DomainCalendar.ldif ( echo -e -n "dn: ou=1.0,ou=GroupCalendarService,o=daservices,o=comms-config\nchangetype: modify\nreplace: sunserviceschema\nsunserviceschema: " ; cat /tmp/GroupCalendar.xml | tr -d '\n' ) > /tmp/GroupCalendar.ldif ( echo -e -n "dn: ou=1.0,ou=UserCalendarService,o=daservices,o=comms-config\nchangetype: modify\nreplace: sunserviceschema\nsunserviceschema: " ; cat /tmp/UserCalendar.xml | tr -d '\n' ) > /tmp/UserCalendar.ldif
Finally, perform the changes:
ldapmodify -D 'cn=Directory Manager' -w -f /tmp/DomainCalendar.ldif ldapmodify -D 'cn=Directory Manager' -w -f /tmp/GroupCalendar.ldif ldapmodify -D 'cn=Directory Manager' -w -f /tmp/UserCalendar.ldif
Once you have finished modifying LDAP, you need to add the time zone into Delegated Administrator's configuration files. This is done in the same way that it was done for the Access Manager mode.
At this point one feature is highlighted that, if you already went through the effort of adding the time zone, may be preferable to all others. This explains how to position in on the top of the list of time zones displayed in the Delegated Administrator GUI, which saves you from scrolling every time through the list of time zones. The list is short for this example (Europe and Africa) but is relatively extensive compared to the other two world areas available in the GUI.
Change to the directory containing configuration files:
cd /var/opt/sun/comms/da/da/WEB-INF/classes/com/sun/comm/da/resources
For each of the Resource*.properties files, both English and localized ones, perform the following
For each line that begins with rsrc.Timezone2- increment the latter number by one. For example, in file Resources.properties, change the line:
rsrc.Timezone2-16=(GMT+04:00) Europe/Samara
to become like this:
rsrc.Timezone2-17=(GMT+04:00) Europe/Samara
This way, the leading place (numbered "0") is being freed to receive your time zone. Use the following table to enter time zone description within each of the files:
Resources.properties: rsrc.Timezone2-0=(GMT+01:00) Europe/Belgrade Resources_de.properties: rsrc.Timezone2-0=(GMT+01:00) Europa/BelgradR esources_es.properties: rsrc.Timezone2-0=(GMT+01:00) Europa/Belgrado Resources_fr.properties: rsrc.Timezone2-0=(GMT+01:00) Europe/Belgrade Resources_ja.properties: rsrc.Timezone2-0=(GMT+01:00) \u30e8\u30fc\u30ed\u30c3\u30d1\u30d9\u30aa\u30b0\u30e9\u30fc\u30c9 Resources_ko.properties: rsrc.Timezone2-0=(GMT+01:00) \uc720\ub7fd\ubca8\uadf8\ub77c\ub4dc Resources_zh.properties: rsrc.Timezone2-0=(GMT+01:00) \u6b50\u6d32\u8d1d\u5c14\u683c\u83b1\u5fb7 Resources_zh_CN.properties: rsrc.Timezone2-0=(GMT+01:00) \u6b50\u6d32\u8d1d\u5c14\u683c\u83b1\u5fb7 Resources_zh_TW.properties: rsrc.Timezone2-0=(GMT+01:00) \u6b50\u6d32\u8c9d\u723e\u683c\u840a\u5fb7 Resources_zh_cn.properties: rsrc.Timezone2-0=(GMT+01:00) \u6b50\u6d32\u8d1d\u5c14\u683c\u83b1\u5fb7 Resources_zh_tw.properties: rsrc.Timezone2-0=(GMT+01:00) \u6b50\u6d32\u8c9d\u723e\u683c\u840a\u5fb7
Edit file daconfig.properties
Increment secondary number in each of the lines starting with rsrc.Timezone2-, just the same as you did with previous files
In the freed space, enter the line:
rsrc.Timezone2-0=Europe/Belgrade
Increment secondary number in each of the lines starting with rsrckey and ending with rsrc.Timezone2-, just the same as you did with previous files. For example, change the line:
rsrcKey-Europe-Samara=rsrc.Timezone2-16
to become like this:
rsrcKey-Europe-Samara=rsrc.Timezone2-17
In the freed space, enter the line:
rsrckey-Europe-Belgrade=rsrc.Timezone2-0
Restart your Web container to enable the changes to take effect.
This example shows how to add support for local language in Delegated Administrator. It is not the translation of the Web interface, but rather it's about making it able to have custom values for the preferredDomain LDAP attribute. In this example, Serbian language is going to be added. Similarly to Chinese, it has two different transcription: Serbian Latin and Serbian Cyrillic, which will be herein referenced as sr and cp, respectively.
Add the language into the list of available resources.
Change into the directory containing description of the resources:
cd /var/opt/sun/comms/da/da/WEB-INF/classes/com/sun/comm/da/resources
Change the following line near the top of the file daconfig.properties:
locale.supported=sr,cp,en,de,es,fr,ja,ko,zh_CN,zh_TW
Add these lines to the file Resources.properties:
locale.sr=Serbian Latin locale.cp=Serbian Cyrillic
Add these lines to the file Resources_de.properties:
locale.sr=Serbisch latinisch locale.cp=Serbisch kyrillisch
Add these lines to the file Resources_es.properties:
locale.sr=Lat\u00ednico serbio locale.cp=Cir\u00edlico serbio
Add these lines to the file Resources_fr.properties:
locale.sr=Serbe cyrillique locale.cp=Serbe latin
Add these lines to the file Resources_ja.properties:
locale.sr=\u30bb\u30eb\u30d3\u30a2\u8a9e\u30e9\u30c6\u30f3\u8a9e locale.cp=\u30bb\u30eb\u30d3\u30a2\u8a9e\u30ad\u30ea\u30eb\u6587\u5b57
Add these lines to the file Resources_ko.properties:
locale.sr=\ub77c\ud2f4 \uc138\ub974\ube44\uc544\uc5b4 locale.cp=\ud0a4\ub9b4 \uc138\ub974\ube44\uc544\uc5b4
Add these lines to the file Resources_zh_CN.properties:
locale.sr=\u585e\u5c14\u7ef4\u4e9a\u62c9\u4e01\u8a9e locale.cp=\u585e\u5c14\u7ef4\u4e9a\u897f\u91cc\u5c14\u6587
Add these lines to the file Resources_zh_TW.properties:
locale.sr=\u585e\u723e\u7dad\u4e9e\u62c9\u4e01\u8a9e locale.cp=\u585e\u723e\u7dad\u4e9e\u897f\u91cc\u723e\u6587
Make sure not to miss other Chinese localization files:
cp Resources_zh_CN.properties Resources_zh_cn.properties cp Resources_zh_TW.properties Resources_zh_tw.properties cp Resources_zh_CN.properties Resources_zh.properties
Add the language to the tasks related to the Organizations (to add new and view current) Change into the directory containing actions over Organizations:
cd /var/opt/sun/comms/da/da/jsp/organizations
Add these lines to the file newOrganization.xml:
<option label="locale.sr" value="sr" /> <option label="locale.cp" value="cp" />
Add these lines to the file newOrganization_nowrap.xml:
<option label="locale.sr" value="sr" /> <option label="locale.cp" value="cp" />
Within the file OrgPropsPropertySheet.xml remove the closing of the cc tag and add the following lines, so that it looks:
<cc name="PreferredLanguageValue" tagclass="com.sun.web.ui.taglib.html.CCDropDownMenuTag" > <option label="locale.sr" value="sr" /> <option label="locale.cp" value="cp" /> <option label="locale.en" value="en" /> <option label="locale.fr" value="fr" /> <option label="locale.de" value="de" /> <option label="locale.es" value="es" /> <option label="locale.ja" value="ja" /> <option label="locale.ko" value="ko" /> <option label="locale.zh_CN" value="zh_CN" /> <option label="locale.zh_TW" value="zh_TW" /> </cc>
Add the language to the tasks related to the Users (to add new and view current) Change into the directory containing actions over Users:
cd /var/opt/sun/comms/da/da/jsp/users
Within the file newUser.xml remove the following lines:
<!-- <option label="newuser.wizard.preferredlanguage.en" value="newuser.wizard.preferredlanguage.en" />
<option label="newuser.wizard.preferredlanguage.de" value="newuser.wizard.preferredlanguage.de" />
<option label="newuser.wizard.preferredlanguage.pl" value="newuser.wizard.preferredlanguage.pl" />
--> </cc>
and add the following lines in place of the ones you just removed:
<option label="Serbian Latin" value="sr" /> <option label="Serbian Cyrillic" value="cp" /> <option label="English" value="en" /> <option label="German" value="de" /> <option label="Spanish" value="es" /> <option label="French" value="fr" /> <option label="Japanese" value="ja" /> <option label="Korean" value="ko" /> <option label="Simplified Chinese" value="zh_CN" /> <option label="Traditional Chinese" value="zh_TW" /> </cc>
Within the file userProperties.xml remove the closing of the cc tag and add the following lines, so that it appears as follows:
<cc name="PreferredLanguageValue" tagclass="com.sun.web.ui.taglib.html.CCDropDownMenuTag"> <option label="Serbian Latin" value="sr" /> <option label="Serbian Cyrillic" value="cp" /> <option label="English" value="en" /> <option label="German" value="de" /> <option label="Spanish" value="es" /> <option label="French" value="fr" /> <option label="Japanese" value="ja" /> <option label="Korean" value="ko" /> <option label="Simplified Chinese" value="zh_CN" /> <option label="Traditional Chinese" value="zh_TW" /> </cc>
Restart your Web container to enable the changes to take effect.
When you configure Delegated Administrator with the config-commda program, config-commda places the configuration files in the installation directory. Next, the program deploys the configuration files to the application repository of the Web container, where you deployed Delegated Administrator. Thus the deployed location of the configuration files varies, depending on which Web container is used.
At run time, Delegated Administrator uses the property values of the configuration files in their deployed locations, that is, in the Web container repository to which Delegated Administrator has been deployed.
To customize a configuration file:
Edit the original configuration file located in the Delegated Administrator installation directory.
Use a script provided by Delegated Administrator to redeploy the configuration file to the Web container.
When you customize a configuration file, the values do not take effect until the file has been redeployed to the Web container.
To deploy a customized configuration file:
Log in as (or become) root and go to the following directory:
DelegatedAdmin_home/sbin
Run the appropriate deploy script to redeploy your customized configuration file to the Web container used by Delegated Administrator.
You must redeploy the configuration file to the Web container where you deployed Delegated Administrator the last time you ran the Delegated Administrator configuration program (config-commda).
Use the deploy script that applies both to your customized configuration file and to the correct Web container.
For example, to redeploy the resource.properties file to Web Server 6, run this command:
# ./config-wbsvr-commcli
See "Configuration File Deploy Scripts" for a list of the deploy scripts.
The remainder of this section describes the following topics:
When Delegated Administrator is configured (after you run the config-commda program), the configuration files are located in the following directories:
Delegated Administrator console:
logger.properties
Resources.properties
Security.properties
logger.properties
Location: DelegatedAdmin_home/data/da/WEB-INF/classes/com/sun/comm/da/resources/
Delegated Administrator server:
resource.properties
serverconfig.properties (only Delegated Administrator 7)
Location: DelegatedAdmin_home/data/WEB-INF/classes/sun/comm/cli/server/servlet/
After you run the config-commda program, the configuration files are deployed to the following locations, depending on which Web container you have chosen to deploy Delegated Administrator.
The resource.properties file is deployed to one of the following default locations:
Web Server 6.x
/opt/SUNWwbsvr/https-hostname/webapps/https-hostname/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/
Web Server 7.x
/var/opt/SUNWwbsvr7/https-hostname/webapps/hostname/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/
Application Server 7.x
/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee--modules/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/
Application Server 8.x
/var/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/
The following files are deployed to the same default location:
daconfig.properties
logger.properties
Resources.properties
Security.properties
These properties files are deployed to one of the following default locations, depending on the Web container you have chosen to deploy Delegated Administrator:
Web Server 6.x
/opt/SUNWwbsvr/https-hostname/webapps/https-hostname/da/WEB-INF/classes/com/sun/comm/da/resources
Web Server 7.x
/var/opt/SUNWwbsvr7/https-hostname/webapps/hostname/da/WEB--INF/classes/com/sun/comm/da/resources
Application Server 7.x
/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee-modules/Delegated_Administrator/WEB-INF/classes/com/sun/comm/da/resources
Application Server 8.x
/var/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/Delegated_Administrator/WEB-INF/classes/com/sun/comm/da/resources
There are two deploy scripts for each Web container. One script deploys the Delegated Administrator server files. The other deploys Delegated Administrator console files:
Delegated Administrator server configuration files: resource.properties and serverconfig.properties.
Delegated Administrator console configuration files: daconfig.properties, Security.properties, Resources.properties, and logger.properties.
Table 8-2 describes the deploy scripts.
| Web Container | Deploy Scripts |
|---|---|
|
Web Server 6 |
|
|
Web Server 7.x |
|
|
Application Server 7.x |
You must use the argument deploy with these commands. |
|
Application Server 8.x |
You must use the argument deploy with these commands. |