Remote Administration Daemon Developer Guide

Exit Print View

Updated: July 2014
 
 

Remote Administration Daemon

The Oracle Solaris operating system is a set of cooperating components, and correspondingly administering Oracle Solaris is the act of manipulating those components in a variety of ways. The traditional solution consisted of locally applying $EDITOR to text files. More modern approaches include manipulating system components locally using a CLI or an interactive UI, remotely with a browser or client, en masse with an enterprise-scale provisioning tool, or automatically by policy logic employed by any of these methods. All of these methods require programmatic access to configuration. The Remote Administration Daemon is the central point where system developers can expose their components for configuration or administration, and where the various programmatic consumers can go to perform those activities.

To provide complete support to consumers written in a variety of languages, consumers running without privilege, and consumers running remotely, rad employs a client/server design. rad itself acts as a server that services remote procedure calls. rad consumers are the clients. The protocol rad speaks is efficient and easy to implement, which makes it simple to bring support for all administrative tasks exposed via rad to a new language.

By providing a procedure call interface, rad enables non-privileged local consumers to perform actions on behalf of their users that require elevated privilege, without needing to resort to a CLI-based implementation. Finally, by establishing a stream protocol, these same benefits can be extended to consumers on any machine or device over a variety of secure transport options.

rad differs from traditional RPC in a number of ways:

  • Procedure calls are made against server objects in a browsable, structured namespace. This process permits a more natural evolution of content than is afforded by the central allocation of program numbers.

  • These procedure calls need not be synchronous. Subject to the protocol in use, a client may have multiple simultaneous outstanding requests.

  • The interfaces exported by the server objects are fully inspectable. This facilitates interactive use, rich debugging environments, and clients using dynamically-typed languages such as Python.

  • In addition to defining procedure calls, rad interfaces can define properties and asynchronous event sources. Though the former provides more of a semantic than a functional improvement, the latter is a powerful tool for efficiently observing changes to the system being managed.


Note - 
  • rad supports alternate protocols without needing to update its content, which provides even greater flexibility.

  • rad's native protocol fully supports asynchronous procedure calls once the client has authenticated. An alternate protocol, e.g. one based on XML-RPC, might not support asynchronous calls due to limitations of the underlying technology.