The HP-UX Admin Man: Service Control Manager

This month, Fred covers another free product from HP - Service Control Manager (SCM). You could say it is remsh, sudo, rdist, shutdown.allow, SAM and all the other setuserid-type tools rolled into one.

• 07/01/2000

Since "good stuff free" is so rare, this column (just like last month’s) will deal with free stuff. Last time, we covered the System Configuration Repository (SCR). This month is about another free product from HP named Service Control Manager (SCM). SCM is a role-based system management service. You could say it is remsh, sudo, rdist, shutdown.allow, SAM, and all the other "setuserid"-type tools rolled into one. What HP means by a "role-based" mechanism, is that an administrator is often responsible for only a certain part of administration in the network. For example, someone might be responsible for creating and maintaining users, another for ensuring backups, and yet another for monitoring performance or availability of Web servers. You might say that to perform a certain administrative role, a person would require a set of commands and programs (call them tools). In other words, in SCM, a role is a set of tools for which you can grant a person execution access against a set of hosts. What is nice about this tool is that you can define the roles by assigning tools to them, make select persons members of any "role," and authorize a person to perform a role against a host, or group of hosts. There are some built-in tools, for Ignite-UX, SD-UX, system recovery, SAM and some system information gathering. You can also build tools fairly easily, and make them part of the SCM system.

SCM is meant to make administration of multiple machines:

• Simpler – Perform the same task against multiple hosts at once

• More Efficient – Execute a task in parallel across a group of hosts

• More Secure – Everyone that performs administration tasks does not need root access

• Consistent – Copy files to, and make changes to, a group of hosts at once to ensure configuration consistence

In order to ensure this, HP has based SCM on a "master" central management server, called the CMS in documentation. The CMS must be running HP-UX 11 in order to install the SCM software. It does not have to be dedicated, since it uses little system resource when you are not performing admin tasks. All task, tool, logs and authorization information is saved on the CMS. This is called the repository. The CMS will probably also be an SD-UX software depot if you plan to use SCM to distribute updates or patches (or Ignite machines). This means that there will be some disk space requirements on the CMS.

All tasks are invoked by running SCM on the CMS. This can be done remotely with the command line interface, remote X display, or using the Web interface, if you set up a Web server on the CMS. Multiple tasks can be launched at once through one SCM session. There are some limitations on how many can be invoked at once, especially in version 1.0, until impacts are better sorted out.

Any host that you want to manage with SCM must have the SCM agent SD software loaded, and an "add host" step performed on the CMS. Loading the SCM "managed host" software installs the Distributed Task Facility (DTF) agent on the host (and other required software). The CMS machine runs a DTF Daemon that initiates, controls and logs tasks. The managed hosts’ DTF agent performs any file copies configured into a task on a pull basis, and does the actual execution of any commands in a task. There are other agents required if you want SCM to perform system configuration repository duties (Scragent), SD-UX pushes (Sdagent) or Event Monitoring Service (EMSagent).

First off, whenever SCM documentation mentions a user, they are referring to a standard passwd type login name. This is a good thing, meaning you don’t have to setup additional names for users; logging into HP-UX does all authentication required by SCM (in other words, SCM uses your UID to determine privileges and authorizations).

Before using SCM, you will probably do most of the following things: Add users, add tools, create roles, configure authorizations and add hosts. Together these steps combine users, tasks and hosts into groups of related tasks, to be performed by certain users, on specific hosts.

There are several tools that exist in SCM when installed. To add new tools, you can create text files (Tool Definition File) that describe them, using supplied tools as templates, or do so in the SCM GUI. A newly added tool will be assigned to the role of "Master Role." You can have up to 16 roles, but "Master Role" must be one of them, so really there are 15 available for limited user configurations at version 1.0 (it is likely that only root password holders will be in the master role). Roles can also be disabled and enabled, as needed, such as for consultants. Tools can copy up to 16 files to the target before execution. A tool can be a script, command or application to be executed, or just copy files. It could also copy files, then execute a command or script that uses those files. In some cases, different tools might require that options be changed when you run them. This is allowed under SCM. The tool definition language allows for supplying an optional set of arguments to the command line for a tool.

After a set of tools is created and assigned to roles, it is time to add the users that will be allowed to perform that role. You must be logged in as a privileged user to control SCM itself. You must also add hosts to the list of managed hosts. This must be done after the SCM agent software is loaded on the targeted host. Hosts can be grouped into administrative boundaries. Hosts might be grouped by person or department responsible, or it could be by related usage, to align with tools that need to be run on the machine.

The actual granting of rights to perform a role (actually the tasks or tools, assigned to a role) on a host is called authorization. You assign authorizations based on a user->role->host. It will typically take many authorizations to set up a set of managed hosts.

Executing a task can be done with the GUI, the Web interface to the GUI, or the command line, but only from the CMS. Some tasks will require user input, others can be automated. The user running the task can specify which targets to apply it to. If they are not authorized for any host or task, the entire task fails. A user can specify output files, and monitor a task while it runs. Log files are stored in the repository so that you can look back and see what was performed. Additionally, even when a task must be run by root, the log will indicate whom actually executed it. The mxexec command allows command line running of tasks.

There are a few limitations. First off, at the time of this writing, version 1.0 was the most current that I could find. First versions are always scary. You may want to look and see if there are any patches while you download it. The second limitation is that at version 1, series 700s are not supported, so the tool is more for managing servers than end user hosts. There are also several limitations on a number of tasks, roles and concurrently running tasks. The indications I think I heard from the HP presentors of this subject at the Interworks conference was that these limitations might change in the future, but some actual customer feedback was needed before those decisions were made.

So, if you decide to try this product, be sure to pay HP back for their work by supplying some feedback on what you think of it. I suppose that makes it not quite a free product, but the price sure is right.