Previous Topic: history Command—Show Previously Issued Commands

Next Topic: join[x] Command—Add Users to Internal Groups


hosts Command—Connect to a Remote CA Access Control Terminal

Valid in all environments

The hosts command specifies the hosts or Policy Models to which the selang commands are sent. It lets you connect to a remote CA Access Control computer with a different name, so you can remotely manage the computer while local CA Access Control services are running. By default, all selang commands are directed to the database on the local host.

The hosts command must be executed before executing the commands that are to be directed to the hosts.

To administer (update) a remote host database from the local host, you must meet one of the following criteria:

To list all the hosts and PMDBs that are currently available, specify the hosts command without any parameters.

Note: CA Access Control protects hosts through their canonical host names and not through aliases. To avoid the confusion caused by alias names, CA Access Control issues a warning when a HOST rule is defined for an alias name. Similarly, CA Access Control gives a warning if a HOST is defined with less than a fully qualified name, because CA Access Control uses fully qualified names (for example, mymachine.yourcompany.com) for hosts.

This command has the following format:

hosts [{systemIds|policyModel@[hostname]}]
systemIds

Specifies the system IDs of the hosts on which the selang commands are to be executed. When specifying more than one host, enclose the list of systems IDs in parentheses and separate the system IDs with a space or a comma.

policyModel@[hostname]

Specifies the addresses of the Policy Models on which the selang commands are to be executed. When specifying more than one Policy Model, enclose the list of Policy Model addresses in parentheses and separate the Policy Model addresses with a space or a comma.

If you do not specify hostname, CA Access Control tries to connect to the PMDB on the local host.

Note: The advantage of using a Policy Model over explicitly specifying the hosts is that the system where the Policy Model resides keeps on trying to update all the systems defined to the Policy Model, even if they are currently unavailable. For more information about Policy Models, see the Endpoint Administration Guide for your OS.

Example: Let a User or Group Update Remote Hosts

To give a user authorization to update the remote host database from the local database, on the remote host enter the command:

authorize TERMINAL local_host uid user_name access(write)

To give a group authorization to update the remote host database from the local database, on the remote host enter the command:

authorize TERMINAL local_host gid(group_name) access(write)

Example: Apply selang Commands to a Remote Policy Model

To apply all subsequent commands to the Policy Model on the station h1, type the command:

hosts Policy@h1

If the connection to Policy@h1 is successful, the following message appears.

Successfully connected to h1

All commands entered from now on are directed to Policy@h1 and not to the local host. The selang prompt changes to the following:

Remote_AC>

Example: Apply selang Commands to a Remote Host

To apply all future commands to the station athena, type the command:

hosts athena

If successful connections are made to athena, the following messages appear on the screen.

(athena)
Successfully connected
INFO: Target version is 2.50

Any command you enter is applied to athena and is not sent to the local host. If you add a new user, the user is only added to athena, as shown in this example:

Remote_AC>newusr steve
(athena) USER steve successfully added.