• No results found

(Optional) Enable the self-describing agent capability

For the Tivoli Enterprise Monitoring Server you are configuring to correctly "seed" agents built with the self-describing capability (for version 6.2.3, these are only the distributed agents; in other words, no z/OS agent is self-describing), you must first enable the hub monitoring server with which these agents will communicate to receive and process self-description data. (For additional information about this capability, see “Whether to enable the self-describing agents capability” on page 15.) To enable the self-describing agent capability, complete the following procedure:

1. From the Configure the TEMS panel, enter 4 (Configure TEMS Self-Describing Agent Parameters) to display the Configure TEMS Self-Describing Agent Parameters (panel ID KDS62MC4), shown in Figure 24.

This panel lays out the remaining steps required for you to authorize the processing of self-describing agent data; they are:

a. Specify TEMS Self-Describing Agent values

Here you specify the parameters the monitoring server requires to process self-describing agent data.

b. Create configuration members

Here you generate a batch job that will configure the runtime members that create the HFS or zFS directories and copy files to z/OS UNIX system services (USS).

c. Create USS directories and copy files on USS

KDS62MC4 --- CONFIGURE TEMS SELF-DESCRIBING AGENT PARAMETERS ---Perform the following steps in the order presented:

Last selected

Date Time 1 Specify TEMS Self-Describing Agent values 11/08/05 22:34 2 Create configuration

members 11/08/05 23:14 3 Create

USS directories and copy files on USS 11/08/05 23:14

F1=Help F3=Back

Option ===>

Figure 24. Configure TEMS Self-Describing Agent Parameters panel

Here you generate a batch job that will create those HFS or zFS directories and copy the files to USS.

The remaining subsections describe each of these steps in turn.

Specify TEMS Self-Describing Agent values:

1. From the Configure TEMS Self-Describing Agent Parameters panel (see Figure 24 on page 58), select the Specify TEMS Self-Describing Agent values step: tab to line 1, and enter S.

The TEMS Self-Describing Agent Values panel (panel ID KDS62PP4), shown in Figure 25, is displayed.

2. Turn on the processing of self-describing agent data: set Enable TEMS Self-Description processing to Y.

3. If the address space of the monitoring server you're configuring will also contain z/OS monitoring agents (such as the OMEGAMON XE on z/OS agent or the OMEGAMON XE for Storage agent), turn on support for self-describing agents within this monitoring server: set Agent Self-Description Processing in TEMS to Y.

Note: For Version 6.2.3 of the IBM Tivoli Monitoring, there are no self-describing z/OS agents;

therefore, for now, leave this parameter set to N.

4. Supply the name of your site's Java root directory (initially /usr/lpp/java/IBM/J6.0) within UNIX System Services (USS).

The self-describing agent capability uses this directory to locate and load the jar utility.

5. Supply the name of your site's UNIX System Services procedure (CLIST) library (initially SYS1.SBPXEXEC).

6. Press Enter to save these parameter values.

Create configuration members: From the Configure TEMS Self-Describing Agent Parameters panel (see Figure 24 on page 58), select the Create configuration members step: tab to line 2, and enter S.

KDS62PP4 --- SPECIFY TEMS SELF-DESCRIBING AGENT VALUES ---Enable TEMS Self-Description processing (KMS_SDA)

==> N (Y, N) Agent Self-Description processing in TEMS (TEMA_SDA) ==> Y (Y, N)

JavaRoot directory for TEMS_JAVA_BINPATH (case sensitive):

/usr/lpp/java/IBM/J6.0________________

______________________________________

______________________________________

______________________________________

______________________________________

USS CLIST library (Required) ==> SYS1.SBPXEXEC

Press F1=Help for information about the TEMS_MANIFEST_PATH USS SDA Home Directory.

Enter=Next F1=Help F3=Back

OPTION ===>

Figure 25. Specify TEMS Self-Describing Agent Values panel

The DS#6T623 batch job is created and submitted.

Create USS directories and copy files on USS: From the Configure TEMS Self-Describing Agent Parameters panel (see Figure 24 on page 58), select the Create USS directories and copy files on USS step: tab to line 3, and enter S.

The DS#UT623 batch job is created and submitted.

Note: This job must be submitted on a machine that can access the USS directories. In addition, the job must be submitted by a TSO userid that has write access to the HFS/zFS directories.

Note about security definitions for the new USS files

To create the runtime environment's new UNIX System Services directories, the DS#UT623 job invokes mkdir commands similar to the following:

mkdir ’RTE_USS_RTEDIR/COMPUSS/kds/support/TEMS/META-INF’ MODE(7,7,7)

Note that these directories are created with MODE(7,7,7), which grants write permission to these directories to all users. This MODE value is specified because the TSO userid of the person running ICAT or PARMGEN is not necessarily the same userid as that associated with the monitoring server started task. However, both userids require write access to the runtime USS directories for the following reasons:

v To support the self-describing agents feature, the monitoring server running on z/OS must be able to add and remove files from these USS directories. A more restrictive MODE setting would prevent the monitoring server from doing so.

v If a subsequent uninstall is performed from ICAT, the TSO userid of the person running ICAT must have write access to these same directories.

If your site requires a more secure access scheme for these runtime USS directories, you can accomplish this using group-based security. Here's how:

1. The configurator's userid is dayce as in the above example, and it is connected to three security groups: GROUP1, GROUP2, and GROUP3.

Since GROUP1 is dayce's default group, all of the newly created RTE USS directories are owned by GROUP1 by default.

2. The userid of the monitoring server started task is stcuser, and it is connected to two security groups: GROUP2 and GROUP4.

Since both userids have GROUP2 in common, the dayce userid could log on to USS and issue a chgrp command to set GROUP2 as the owner of the runtime environment's USS directories, as in this example:

> chgrp -R GROUP2 COMPUSS

3. Next, the dayce userid can issue a chmod command to change the original MODE(7,7,7) value to something more restrictive, such as:

> chmod -R 775 COMPUSS

After issuing this chmod command, only users who are connected to GROUP2 have write access to the runtime USS directories.

If the configurator's userid and the userid associated with the monitoring server started task do not have any security groups in common, you must either connect both userids to a common security group or define a new security group and connect both userids to that group. Whichever option you choose, you must still perform the chgrp and chmod actions described above.

This information applies to users of either the Configuration Tool (ICAT) or PARMGEN.