The Hardware Monitor consists of a daemon, named hardmon, and a set of client commands. The daemon executes on the control workstation and, using the RS-232 lines to each frame, polls the frames for the state of the hardware within the frame. The daemon also sends hardware-level commands to each frame to change the state of the hardware within the frame in some way. The client commands, spmon and hmmon, interact with the daemon to obtain the current or changing state of the hardware. The client commands, spmon and hmcmds, also interact with the daemon to change the state of (that is, control) the hardware. The splogd logging daemon is also a client of the hardware monitor for logging purposes.
The hardmon daemon reports variables representing the state of a frame, node, SP Expansion I/O Unit, and switch hardware. These state variables are made available through the spmon and hmmon client commands. You can find a list of these variables with descriptions by using the Event Perspective GUI. This list provides variable names, display attributes and descriptions for all variables available in the SP System Monitor. The hmmon command, with the appropriate flag, also provides a list of variable names and descriptions. You will see these variable names in the SP System Monitor log. They also serve as parameters to the spmon and hmmon commands.
To diagnose system monitor problems including SP-attached server problems involving the hardmon daemon, refer to the book PSSP: Diagnosis Guide.
The hardmon daemon reports the following variables so you can monitor the frame hardware status:
The hardmon daemon allows the authorized administrator to control the frame hardware state. This information includes:
The hardmon daemon reports the following variables so you can monitor the node hardware status:
The hardmon daemon allows the authorized administrator to control the node hardware state. This information includes:
The hardmon daemon reports the following variables so you can monitor the switch hardware status:
The hardmon daemon allows the authorized administrator to control the switch hardware state. This information includes:
The objects defined and controlled by the SP system monitor are the following:
The system object is the initial object and is the container for frame objects and frame objects are containers for slot objects which represent node or switch processors. Monitor and control operations are performed on frame and slot objects. The hardmon object represents the administration function.
Because of this hierarchical structure, you can determine for your installation, the level of granularity to use for access to hardware objects.
You can have potentially hundreds or thousands of objects and an access control list for each object. On the other hand, since the object structure is hierarchical you might decide to have only the system object ACL and set principals and groups with authority to control all the hardware in the entire system.
There are three levels of hardmon authorization possible on an SP system depending on the granularity of object protection you choose to have:
If you want different authorizations for different frames, you need frame objects and ACLs. If you want different authorizations on a node and switch basis, you need slot objects and ACLs.
Authorization is checked from the lowest level to the highest level. If the slot object and ACL does not exist for a node or switch, the frame object is checked. If a frame object and ACL does not exist, the system object and ACL is used to determine authorization. Every system has a system object. The ACL from a container is copied to a contained object by default when the object is created.
With DCE, the classes of authority for the SP System Monitor are the following:
When using DCE authentication, the root id has no special privilege. A hardmon client needs credentials to be authorized to run hardmon commands. The client needs to log in to DCE as a principal who is a member of an appropriate access group, or who is granted access by some other entry in the DCE ACL files for the objects affected by any action requested. Scripts running as background clients can use the dsrvtgt command.
With Kerberos V4, the classes of authority for the SP System Monitor are the following:
VFOP control authority is needed for microcode updates to the supervisor subsystem.
With Kerberos V4, hardmon still uses a single /spdata/sys1/spmon/hmacls file on the control workstation for its access control list. The entries in this file are on a per-frame basis.