Sun Desktop Manager 1.0 Administration Guide

Chapter 1 Concepts and Architecture

The Sun Desktop Manager provides a framework to store configuration settings for applications on a network in a central location for users, organizations, and host machines that run the application.

This chapter describes the general architecture and the key concepts of the Desktop Manager.

Scope of the Desktop Manager

The Desktop Manager directly supports the following configuration settings:

Gconf (Gnome configuration framework)
StarOffice^TM Registry
Mozilla^TM Preferences
Java^TM Preferences
Desktop launchers
Menu entries
Startup applications

Note –

The Desktop Manager only supports applications that use these settings.

By default, only the settings that are relevant to a system administrator can be configured with the Desktop Manager. However, you can use templates that are included with the installation to extend the functionality of the Desktop Manager to include the configuration settings that you want to control. Furthermore, desktop applications that do not use the supported configuration systems can access central configuration data through the legacy data framework.

Architecture

Figure 1–1 High-level architecture

The Desktop Manager contains the following components:

Configuration Repositories: Configuration repositories store the configuration profiles and organizational structures.
Management Tools: Management tools refers to both the Desktop Manager web-based administration GUI and the command line interface (CLI). With these tools, you can create, modify, delete, and assign configuration profiles.

The management tools access the data in a configuration repository and use templates to display the data in a browser window.
Configuration Agent and adapters: The agent retrieves and caches the configuration settings on the configuration repositories for the user applications. The adapters apply the settings. The agent and the adapters must be installed on every client.
Templates: Templates render the configuration data in a web browser window.

Configuration Repositories

The Desktop Manager stores configuration data in a configuration repository. A configuration repository stores the following three types of configuration data:

Organization structure: describes the structure of an organization. A single object of an organization structure is called an element. The configuration data for an organization structure provides the following information:
- A tree that represents the Organization/Sub-Organization's structure. This includes a list of users that are part of the organization, as well as the location of the users in the organization structure.
- A tree that represents the host Domain/Sub-Domain structure.
Configuration profiles: define sets of configuration data, called configuration profiles, for applications or modules. Profiles can be assigned to organizations, domains, hosts, and users. A profile provides a default value for a configuration setting or enforces a value for a configuration key. A profile can also contain profiles that cover multiple applications.

You can use configuration profiles to define default configuration settings for an organization, such as the default unit of measure for rulers in StarOffice Writer. However, a user can set preferences manually in an application to override such defaults.

Note –
You can change the value of a configuration setting to enforce a default setting in a profile, so that a user cannot change the setting manually.

Configuration profiles are stored at an element node in an organization or domain structure.

The assignment of profiles associates the configuration data that is contained in a profile to an element. You can only assign a profile to the element that stores the profile, or to elements that occur below the storage element in the hierarchy.

The Desktop Manager also stores a priority with configuration profiles. Priorities determine the order that the profiles are assigned when you create the Profile Configuration Data (see Construction of the Profile Configuration Data). You cannot store more than one configuration profile with the same priority in an element.

You can also use the Desktop Manager to store local, user-specific configuration profiles directly on desktop machines.
Assignments: Assignments define the relationship between one or many elements of an organization and a profile. Assignments define the elements of the organization or domain that the configuration data can be applied to.

Child elements inherit the assignments of the parent element in the organization hierarchy.

Available Configuration Repositories

There are three types of configuration repositories that can be implemented:

LDAP: stores the configuration data on an LDAP directory server as additional entries. Desktop Manager supports the following LDAP directory servers:
- Sun^TM Java Systems Directory Server
- OpenLDAP
- Microsoft Active Directory
The access protocol to query this type of repository is LDAP. However, any other LDAPv3 compliant directory can be used as a repository.
File: stores the configuration data in a filesystem. The Desktop Manager accesses this type of repository directly from the filesystem or through HTTP/HTTPS. For HTTP/HTTPS access, you need to configure a web server so that the Agent can access the configuration repository; the management tools require read/write access to the file system that stores the profiles and assignments.
Hybrid: a hybrid repository reads the organizational structure of the company from an LDAP server, and then read/writes the configuration settings into a file system.

Note –

The LDAP Configuration Repository provides the best overall performance. The hybrid repository is best for when you do not have write access to the LDAP directory. The file-based repository is only useful for evaluation purposes.

Management Tools

The management tools provide a web-based graphical user interface and a command-line interface where you can manage the configuration data. The tools only operate on the configuration repository and do not require the agents to run.

If you use an LDAP configuration repository, you can deploy the management tools in a separate system from the one that holds the LDAP service. If you use the file-based repository, the management tools require direct access as well as read/write permissions to the repository for the noaccess user, or the user under which the Java Web Console is executed. That is, the tools must be in the same system as the repository, or the repository must be an NFS mount with read/write access for the tools. The noaccess user runs the Desktop Manager GUI, and must be created when you install the tools.

You can use the management tools to create, delete, modify, assign, and unassign profiles. You cannot use the tools to add, delete, and modify elements in the hierarchy, for example, to add users.

Templates

Desktop Manager uses templates to view, define, and enforce configuration settings in the configuration repository and to render the GUI for displaying these configuration settings. The templates are deployed by the web-based Management tools.

For more information on templates, see the Sun Desktop Manager 1.0 Developer Guide.

Configuration Agent

To access the configuration data from the Desktop Manager, a desktop client requires the Desktop Manager Configuration Agent. The Configuration Agent communicates with the remote configuration data repository and the adapters, as well as integrates data into specific configuration systems. The configuration systems that are currently supported are GConf, Java Preferences, Mozilla Preferences, and StarOffice Registry.

Configuration Adapters

Configuration adapters query the configuration agent for configuration data and provide the data to the applications. The adapters must be installed on every client that you want to manage centrally.

From Configuration Profiles to Application Settings

This section describes how the configuration data is processed to end up with user settings for a specific application running in a specific host.

Configuration Data Sources

Each user application receives configuration data from the following sources:

Default configuration data source: stores the default settings for an application. This configuration data source is deployed with the application and remains mostly unchanged throughout its lifetime. The query mechanisms and the format for this data source are defined by each application. Some applications use a "proprietary" method to store configuration data, while other applications use a shared subsystem for the configuration data, for example, GConf.
User configuration data source: stores user settings for an application. The query/update mechanisms and format for this data source are defined by each application.
Profile Configuration data source: this data source is provided by the Sun Desktop Manager 1.0. The configuration data is stored in the configuration repositories. The mechanisms to access that data are provided by the Configuration Agent and the Configuration Adapters.

The application settings for a user on a host are calculated in two steps. The profile configuration tree is constructed, and then the configuration data sources are combined.

Construction of the Profile Configuration Data

The profile configuration data holds the configuration profile for a user application that runs on a specific host.

The organizational units of an organization, along with the users, are stored in the configuration repository hierarchically. The same applies to the domain components.

Configuration profiles are assigned to elements in the hierarchies. Configuration profiles that are assigned to an element are inherited by the children of that element.

The configuration data of an application depends on the user who runs the application and the host where the application runs.

The configuration settings that affect a user depend on the configuration profiles that are assigned to the elements in the path from the user element to the root of the tree. These profiles must be merged together to build the set of configuration settings for the user.

Since it is possible to define profiles based on the host where the application of the user is running, the profiles assigned to the host, or to any of the elements that are in the path from the host to the root of the tree should also be merged together with the configuration profiles that affects the user.

Figure 1–2 Configuration Process

The following rules are used to construct the profile configuration:

Order of processing: The order in which profiles are merged is important. The Host Local set of configuration profiles are processed first, followed by the Host Global set, the User Local set, and then the User Global set.

If there is more than one configuration profile in a set, the priority number that is associated with a profile determines the precessing order for the profile, that is, the lowest number is processed first.
Properties and Values: A property is an element in the configuration that can be defined, for example, "background color". A value is the value that you assign to a property, for example, the value for the property "background color" is "white".

If a new property is introduced by one profile, the property and its value are added to the merged configuration tree.

If a property has a value that is marked as enforced, the new value is stored in the merged tree. New values for the property that occur in other profiles are ignored.

If a property already has a value when a new value is defined in a profile that is being processed, the new value is assigned to the property.

Configuration Data Source Combination

The configuration data provided by the three different configuration data sources must be combined to produce a single set of settings for the user application to use at runtime.

The configuration data provided by the default configuration provider is read and a configuration tree is constructed.
A profile configuration data is constructed based on the user and host of the client application.
The user settings are read and a configuration tree is constructed.
The three trees are combined into one to get the configuration settings that the application will use. The rules followed in this process are the same that where used to construct the profile configuration data.

The resulting tree will be used by the application adapters to provide the configuration settings.