After completing this module, you should be able to:

• ExplaintheSausalitosoftwarearchitecturedesigngoals
• Create and extend object schemas
• Use the Sausalito cceclient utility to activate systems changes from the command line
• Analyze Cobalt Configuration Engine (CCE) server log files
• Explain the contents of the /usr/sausalito directory tree
• Extend the Server Desktop with menu items, options, and pages
• Create languages for the Server Desktop using the 118n component
• Create and implement a new Server Desktop style

Additional resources ‐ The following reference provides additional details on the topics discussed in this module:

• The Sun Cobalt Qube 3 Developer’s Guide, which is available at http://developer.cobalt.com/sausalito/index.php
• For more information on PHP the widely-used, general-purpose scripting language that is especially suited for Web development and can be embedded into HTML see: http://www.php.net/PHP
• For more information on gettext' utilities which are a set of tools that provides a framework to help produce multi-lingual messages http://www.gnu.org/software/getteXt/gettext.html

This module describes the Sausalito architecture and how to use it to extend the server appliance’s out‐of-the-box service features. The major topics in this module are:

• Sausalito Architecture Overview
• Sausalito Software Architecture
• SET Transaction Overview and Components 1 SET Transaction Configuration
• Registering an Event Handler
• CSCP Communication
• GET Transactions
• Server Desktop Screen Generation
• Navigation Sub‐system Overview
• Internationalization (i18n)
• User Interface Foundation Classes (UIFC)

As you read this module, look for answers to the following questions. See Appendix A for answers.

1. What is the Sausalito software architecture designed to provide?
2. What are the Sausalito processes?
3. What are the main components of CCE?
4. What are SET transactions and how are they triggered?
5. What is the purpose of the Cobalt System Configuration Protocol?
6. How is an Event Handler registered?
7. What are GET transactions?
8. What is the purpose of the Navigation sub-system?
9. What is the function of Internationalization (i18n)?

Sausalito is the name of the Sun Cobalt Qube 3 Plus server appliance’s software architecture, which is designed to provide an extensible development platform that enables third parties to customize and modularize the platform and quickly implement services, applications, and languages.

Having a clear understanding of Sausalito is helpful for maintaining the server appliance. This module describes the Sausalito architecture and the process for extending the server appliance’s out-of-the-box service features.

Figure 17-1 shows that the Sausalito software layer lies between the Server Desktop, applications, and the Linux operating system.

: Add a diagram here Sausalito on the server appliance platform layers

Sausalito handles operating system modifications, such as creating, deleting, and modifying users and groups. Sausalito also handles requests for changing system functionality, such asenabling SMTP, CGI scripts, and Microsoft FrontPage server extensions. Having Sausalito handle these requests helps hide the complexities of the operating system from the end user.

Sausalito’s fully open Application Programming Interface (API) allows programmers to seamlessly integrate additional applications, giving them the look and feel of the server appliance.

Sausalito is based on object-oriented programming; everything in the system is an object that can be added, removed, changed, and extended. Object-oriented programming helps Sausalito live up to its goal of extensibility.

Figure 17‐2 shows a block diagram of the Sausalito software architecture. This diagram expands later in this module to Show more details about Sausalito’s components and process flow.

: Add a diagram here Sausalito software architecture block diagram

Sausalito can be broken down into two main processes: SET transactions and GET requests. These t w o processes let you manipulate the system software through the Server Desktop, while keeping the system software and Server Desktop logically separate. Figure 17-3 shows the major Sausalito components and the process flow for the two main processes.

: Add a diagram here Sausalito components and process flow

The main component of Sausalito is the Cobalt Configuration Engine (CCE), which is responsible for both SET transactions and GET requests. CCE is designed to act as a buffer between the system and the Server Desktop to keep the two logically separate.

CCE has several components:

• The Cobalt Object‐oriented Database (codb)
• The Cobalt System Configuration Protocol (CSCP)
• Event handlers

CCE maintains the configuration state of Sausalito by:

• Initiating event handlers to change the state of the system
• Changing codb information
• Delivering information from codb to the Server Desktop

This section provides an overview of the SET transaction process and components and their functions within Sausalito,

SET transactions are system changes performed by event handlers registered to objects or object properties being created, deleted, or modified. SET transactions are triggered by user input, such as:

• Adding a new object such as a user or group, or
• Modifying an existing object’s properties, such asenabling or disabling a service or modifying user information

Then the event handlers registered to the object or the object properties are executed.

The CCE daemon (coed) listens on the cced.socket , which is a standard UNIX socket, and handles incoming connections and signals from the CSCP. The CCE daemon is the administrator of Sausalito: It initiates event handlers based on change requests and commits changes to codb, when applicable. When you check the system processes on the server appliance, you should see the cced process running. Figure 17‐4 shows the cced responsibilities:

: Add a diagram here The cced responsibilities

In object-oriented programming, everything is an object. Objects have properties that contain values. For example, users and groups have names and disk quotas have sizes. In codb, the System object has properties for the server appliance’s services. For example, the FTP service has a maximum-number-of-connections property, a maximum-number-of‐ megabytes-per-transfer property, and other properties.

Figure 17‐5 shows a c o d b object expanded. Objects in codb are identified by numbers. Each object has a CLASS property that designates the type of the object (user, group, system, or network route, among others) and several other properties that contain configurable information. c o d b objects can be extended with additional properties.

: Add a diagram here The codb with an expanded object

codb is a holding tank for objects and their property values. The information stored in codb is what is retrieved by CCE and viewed through the Server Desktop. For example, a user is an object and that user object has property values that include user name,full name, maximum disk space, email aliases, and other properties. These object property values display in the Server Desktop when you View a specific user’s details.

CSCP is a simple protocol used for communicating between clients and CCE, and between CCE and the event handlers. CSCP is the only mechanism by which CCE knows what actions to take. CSCP communicates requests from the client to CCE, and it communicates requests from CCE to the event handlers when system and service configuration files need to be added, removed, or modified. After the event handlers complete their work, either successfully or unsuccessfully, CSCP reports back to CCE with the status. Figure 17-6 shows the function of CSCP in Sausalito for handling the communication between requesting clients and CCE and between CCE and the event handlers.

: Add a diagram here CSCP functions in Sausalito

Event handlers are executable scripts that are triggered by CSCP. They have specific functions for changing system state, and registering services and applications. Services and applications register themselves in CCE by requesting notifications when specific codb objects and object property values are added, removed, or modified.

When these notifications take place, the event handlers make the changes to the system and report back, using CSCP, to CCE with the success or failure status.

Event handlers make it possible for software developers to apply changes to the system without affecting existing functionality, as long as guidelines are followed for adhering to the modularity of Sausalito. Figure 17-7 shows how the event handlers in Sausalito handle changes to the system and configuration files.

: Add a diagram here Event Handler functions in Sausalito

Table 17‐1 on page 17‐13 shows an overview of the process flow for SET transactions:

: Add a diagram here

Before SET transactions can take place in Sausalito, the system must be configured to recognize requested changes and system changes that must be made. This means:

• Objects and object properties need to be defined
• Event handlers need to be created and registered to the objects and object properties

Objects and object properties need to be defined for program packages, such as Apache, Proftpd, Active Monitor, Sendmail, and others. Then the objects and object properties need to be registered with the event handlers.

Note ‐ When an object is added, deleted, or modified, the event handlers registered to that object or that object’s properties are notified to make the necessary system changes.

The structure of objects within codb is defined by schema definition files. These definition files provide schema, class, property, and typedef information.

At system startup, the definition files are read; they define what objects can be created, the properties the objects can have, and the data type the object properties can contain. The schema definition files are located in the /usr/sausalito/schemas/base/service‐type directories.

When cced is started, all files with a .schema file extension under the /usr/sausalito/schemas directory tree are used to build the object schemas.

The /usr/sausalito/schemas/base/service‐name directories are strictly for organization. If you have installed third-party applications, you might also find /usr/sausalito/schema/vendor‐name directories that contain schema definition files.

Table 17-2 contains the schema file elements and attributes discussed in this course. For a complete listing and description of the schema file elements and attributes, see the Sun Cobalt QubeTM 3 Developer’s Guide, which is referenced in “Additional Resources” on page 17‐2.