[Top] [Prev] [Next] [Bottom]

9 - Miscellaneous Topics

Since management applications can cover a wide range of uses, it is not always easy to present manager-writing topics in a cohesive fashion. This chapter attempts to gather various hints and recommendations related to writing manager applications not covered by the previous chapters. While many of these subjects touch on issues not directly related to the Manager Services library, they are things manager writers may need to know.

This chapter does not discuss high-level topics such as user-interface strategies, data reduction, analysis and presentation, and so on.

9.1 The Agent Schema

The agent schema is a file that describes the types and names of the object attributes an agent can get. Attributes are collected into groups for convenience, such as "input", "output," and so on. The agent schema is "built in" to most agents. The UNIX file manager applications use is the published interface specifications for the agent, written by the agent writer. The manager application uses this specification to know what information the agent can return from the managed objects. While it is not necessary for managers to use the agent schema to send requests and collect reports from agents, it is the supported method for agents to publish their available management information.

When a request is sent to an agent, the agent examines the request for the group and attribute names it understands so it can do the requested operation. If it does not understand the names in the request, it will reply with an error message.

The agent schema is contained in a regular UNIX file in ASCII format. The format is straightforward so manager applications--whether standard UNIX tools or custom applications--can spend as little time as possible parsing this file. The format of the agent schema is listed in snm_schema (5).

snm_parser(1) is an example application that parses schema files; the parser program is provided in source form. See the source program for more information.

9.2 Agent Identification

As objects change, so does the information they can provide. Since agents describe the information they can obtain via the agent schema, it is important for a manager to ensure the versions of the agent and schema file are equivalent, so the manager has an accurate picture of the agent's information base.

The Manager Services library function netmgt_request_agent_ID (3n) sends a request to the agent for any identifying information it can provide. The information returned includes the name of the agent, agent schema serial number, and the architecture of the machine where it is running. Not all data is always returned. For instance, the host architecture information may not be available.

The manager application can use this information to compare the agent schema serial number with the serial number the agent says represents its information base.

9.3 Security

From the manager application's standpoint, there's not much to do. Security is handled through the Manager/Agent Services library by: For more information on security, see the Administration Guide.

9.4 Dispatching Incoming RPC Calls

After you have registered a transient callback (with netmgt_register_callback (3n)) and optionally registered it with the event dispatcher (with netmgt_register_rendez (3n)), you need to pass control to the RPC libraries so incoming RPC calls are dispatched to your code. Normally, you do this by calling the procedure svc_run (3n). However, since svc_run never returns, it may be too restrictive for your management application. This section describes two alternatives to using svc_run.

If you are writing a manager that runs under XView, you can request that the XView notifier handle all the incoming RPC dispatching for you. To do this, call the XView procedure as follows:

 

notify_enable_rpc_svc(TRUE);
  

before you call xv_main_loop. Then, any incoming RPC calls will be dispatched to your code by the XView notifier. Note that the function notify_enable_rpc_svc(TRUE) is not documented in the XView Programming Manual.

If you are not writing an XView application and svc_run is too restrictive, you can use a select(2) loop to "wait for work." To use the select loop, you must build a mask consisting of the interesting file descriptors: both yours and any used by the incoming RPCs. To aid in building this mask, the RPC libraries export a global variable that has all the incoming RPC file descriptors set. The global variable is:

fd_set svc_fdset
When select returns, you should determine if any of the file descriptors indicate that an RPC operation requires service, and if so, call the routine svc_getreqset(). Refer to the man pages for more information on usingsvc_fdset(3n) and svc_getreqset (3n).

9.5 Blocking RPCs in XView

If your XView application makes requests, you may wish to fork a process to make the requests so that your application will not block if the request times out. Blocking occurs only when the request to an agent is made. There is no blocking while results are being received from an agent.

9.6 Agents and Managers that Generate Traps

If your agent or manager wishes to generate traps, you must fork a separate UNIX process to generate the traps. In addition, if you wish to send traps to multiple systems, each system requires a separate process.

9.7 Summary

You now have the knowledge to take advantage of the facilities in the Manager Services library. While the library does not provide every amenity possible for manager application writers, it does provide a straightforward means of using the services to communicate with agents and other Site/SunNet/Domain Manager applications.

[Top] [Prev] [Next] [Bottom]

Copyright 1996 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA 94043-1100 USA. All Rights Reserved