The manager retrieves software information from the source. This can be used by a command line or graphical user interface to present software selections to the user. Then, both the GUI and command line interface send the resolved software selections to the targets.
The target is implemented using a daemon/agent pair of processes. The daemon is always running on each target host, and spawns an agent session for each target. The agent session can be a separate process, or part of the daemon process. The agent session performs the software operation, including retrieving information and files from the source.
The source is implemented as the same daemon/agent pair. The daemon is always running on each source host and spawns an agent session for each source request. The source agent serves information and files from the source software collection for the target agent and manager.
In this way, in relation to the POSIX 1387.2 standard software hierarchy where a host object contains a set of distribution and installed software collections, the daemon essentially manages the host object and each agent manages one software collection.
As described above, an agent session is defined for each target. After initiating an agent for the target, the rest of the task addresses each agent.
The software selections are communicated between the various roles as strings using the standard software selection syntax defined by the POSIX 1387.2 standard. Using the standard software identifier syntax is important for interoperability as it insulates the implementations from any implementation specific software object identifiers.
The task type is the primary parameter in the RPC interface. Further, there is a separate interface for analysis and execution. This point is important for interactive interfaces, where results of analysis can be viewed, and analysis can be repeated, before committing to execution. It also is necessary to support consistent multiple target success where all targets need to pass analysis before execution is committed to for any target. If the execution phase suspends, then it too can be retried.
The options are communicated using the standard syntax defined by the POSIX 1387.2 standard. This syntax is important for both interoperability and extensibility. This same parameter is used to pass any additional options that can be described as name=value strings, and is used for features beyond the POSIX 1387.2 standard definition, including additional control options and security information.
The key roles for the source agent is to provide files and data to the manager and target agent.
The software files to be transferred are identified by the software specification and the file path. An important aspect of this interface is that the target only requests the files that it requires, allowing for target optimizations for files that are already up to date.
For listing software objects and attributes, applying software selections by the manager or agent, and retrieving control scripts to be executed by the manager or agent, the same file transfer interface is used.
While natural for control scripts, this is also important to interoperability for software object and attribute information. Using this interface, all information is transferred in the POSIX 1387.2 standard external format (software packaging layout) via INDEX and INFO files. This saves implementations from having to support an additional exported format in addition to the POSIX 1387.2 standard external format and their own internal representation.
The POSIX 1387.2 standard software packaging layout is also used for transferring information about installed software objects.
This design is also impacted by the security model. In the XDSA-DCE security model, read access to distribution includes the permission to list all of the products in the distribution. Thus the entire global INDEX may be transferred. However, product files are only accessible for analysis and execution (loading) if the user has read access to the product.
In a model where products may only be listed by those with read access to the product, then only those products with read access would be included in the global INDEX tranferred.
Both the source and target agent define
sessions
that maintain state from one call to the next,
as shown in
There are a number of points in this design:
The concept of a session is important primarily to reserve (read or write lock) the software collection resource for the duration of the operation. This increases reliability of multiple target operations, since the resources are committed before the operation begins.
For the interactive interface, the user has immediate feedback if the operation will fail due to the target already being unavailable.
In the case of the source agent, significant overhead (such as security and database access) is avoided for the file retrieval RPC by caching information.
By maintaining the session until an explicit end session call is made, the interactive user can query the agent for results of an operation even after the operation execution has completed.
Having a separate interface to initiate a source or target agent allows for a number of flexible implementations from an implementation of a separate daemon and agent, to a single daemon process that also performs the agent tasks (the latter simply returns an RPC binding to itself).
Some implementations may use a separate, smaller, daemon since the daemon must always be resident in memory and memory utilization is critical for smaller systems. Also, on source systems, a single process would require up front memory allocation for the maximum number of source connections.
The separate daemon interface also logically maps to a different level of managed object than the agent (the host as opposed to the software collection). Its possible to envision that the host object may have a single daemon (part of the management framework) for disparate managed objects, and separate agent programs for each type of object.
The XDSA-DCE RPC interface also reflects a need to not have any requirements on management frameworks, while still allowing integration with these frameworks. This is important since installed software collection is needed for initial install of an operating system where the management framework may never exist, and for installed software collection and update of the management framework itself.
Each RPC interface has a results array return parameter that contains a list of event types and severity, and additional information that usually contains the number of occurrences of the event.
The RPC also has return parameters for each software object that was analyzed or executed. This contains a summary of the events that occurred on each object (results of that operation). This information is used by XDSA-DCE to present per software object results to the user.
While the XDSA-DCE specification is not currently integrated into an event notification service, there is a single interface that could optionally send events to the event service while still building the results array for manager not using that service.
Similarly, an implementation does not require
a logging service, but does not preclude the
eventual use of one either.
The status of the task (analysis or execution)
is not implemented by events. Rather, the
agent keeps track of its progress (bytes loaded,
percent complete, time to completion, etc) and
returns that to the manager when requested
through the same interface as the logfile.
The first aspect of the XDSA-DCE security model is authentication. When operating in a DCE cell, the DCE RPC automatically provides the information needed to authenticate the caller. The manager user is authenticated by the target agent and source agent. The target agent is authenticated by the source agent.
The XDSA-DCE interface also supports a mode of secure operation that does not depend on the run-time DCE needed to maintain a DCE cell, and also supports operations across DCE cells. While not as reliable as DCE authentication, the XDSA-DCE internal method still is reliable (more so than ARPA/Berkeley for example) through its use of an encrypted, configurable, "secret". Both the secret, and the caller information is communicated using the same options parameter that is used for the POSIX 1387.2 standard and other XDSA-DCE specific options.
In the distributed model described above, the target agent contacts the source agent for software files to install or copy. Delegation allows the agent to also notify the source agent not only of itself (the caller), but also of the manager user that is requesting the software (the initiator).
Since run-time DCE does not support delegation directly, the RPC interface options parameters are used to pass the initiator information in any case, in the same way that the caller options are used for XDSA-DCE internal authentication.
The second aspect of the XDSA-DCE security model is authorization for access to particular objects. The authorization model is fairly flexible in how it relates to the RPC interface. The interface is responsible for communicating the information necessary to determine authorization to an object (via caller and initiator information). The target and source agent (by examining their ACLs, next) can then refuse a particular request (for example, creation of a new distribution collection object) or part of a request (for example, modification of, or access to a particular product in a list of products).
Thus, authorization (ACL) information is not communicated via the XDSA-DCE interfaces, just the refusals of authorization in the results of those calls.
Authorization to objects is determined by the access control lists associated with the objects. XDSA-DCE supports a security ACL scheme that includes a set of permission types (read, write, insert, test, control) for a set of principal (caller) types (object_owner, object_group, user, group, host, other, any_other) on a set of object types (host, distribution, installed software collection, product). Which permissions are needed for which objects for each task type are listed with the descriptions of the task types.
Product level ACLs are defined for products in distributions. A distribution can contain products for a large variety of consumers and eventual installed software collections. Product level ACLs are not defined for products in installed software collections. Installed products share the same filesystem, the POSIX 1387.2 standard supports different installed software objects sharing the same filesystem installed software collection for the purpose of different management (including security) domains, and the semantics of update and multiple versions would be significantly complicated by product level security in installed software collections.
XDSA-DCE also provides a distributed ACL management command, swacl. This command supports a similar syntax to the other POSIX 1387.2 standard commands (that is, options, software selections and target selections).
The RPC interface used to implement this command are the standard RDACL interface definitions supplied with DCE, and are not documented here. In an XDSA-DCE implementation, the server side of RDACL interface is implemented in the daemon. The manager then uses standard client DCE security interfaces to manage ACLs.
Naming is used in XDSA-DCE for locating sources and targets. As with other management framework services, XDSA-DCE is designed to be operated both with and without run-time DCE Naming Services. Using DCE Naming Services, lists of target hosts and source hosts, along with the RPC protocols for contacting those host's daemons, can be retrieved.
Like some aspects of security, the use of naming is somewhat independent of the RPC interface. For example in XDSA-DCE, the manager can resolve the location of a distribution using naming, then pass the source information to the agent the same way it would if not using a naming service.
Independent of run-time DCE, there is an XDSA-DCE interface
to query hosts for available (registered) distributions and installed
software collections on that host.
XDSA-DCE also provides a distributed command to register distributions
in the host object,
swreg.
(Distributions and installed software collections
are also automatically registered and unregistered
as part of the POSIX 1387.2 standard
swcopy
command).
There are four XDSA-DCE RPC interfaces for managing registration of
distribution and installed software collections:
see
Related to naming are other features that abstract source location. There are two main aspects to this feature: supporting access to software from more than one source in a session, and supporting the use different sources by different agents in one task.
The latter is supported by XDSA-DCE implementation where different targets can be configured for different sources. This can be used to support two step install (copying to the target before installing from a local copy), hierarchical distribution, and distributed installed software collection optimized for source proximity and performance.
The impact on the XDSA-DCE RPC is an additional option to communicate to the agent to choose its own source. Additionally, even though XDSA-DCE does not currently support an agent installing different products from different sources, the RPC interface does support this since each software specification can have a different source associated with it (allowing the manager to still perform selection).
There are two additional XDSA-DCE RPC interfaces defined which support transfer of detailed disk space analysis from the target agent to the manager. This can be used by a manager GUI to show the impact of each software item (product or fileset) on each target filesystem, or can be used for verbose output in a CLI manager.
| Contents | Next section | Index |