BMC PATROL KM for UNIX and Linux remote monitoring FAQ

This section addresses common questions about using the BMC PATROL Knowledge Module (KM) for UNIX and Linux to perform remote monitoring.

• • Which version of PATROL KM for UNIX and Linux supports remote monitoring?
  • Which data collection method is used by remote monitoring?
  • What is the role of pukremotexec.xpc in remote monitoring?
  • What hardware do I need to monitor multiple UNIX computers remotely?
  • Which operating systems can I monitor remotely?
  • What are the pre-requisites for enabling remote monitoring?
  • Configuration requirements for the remote host
  • Which authentication mechanisms are used in remote monitoring?
  • What are “user profiles” in remote monitoring?
  • Which application classes are supported for remote monitoring?
  • Which system commands do application classes refer to?
  • How many remote hosts can one PATROL Agent monitor?
  • Can I use an earlier version of PATROL Agent?
  • Can I monitor UNIX and Linux systems from PATROL Agent for Windows?
  • How do I configure PATROL KM for UNIX and Linux for remote monitoring?
  • Can I simultaneously use the DCM method to monitor the local host and the PSL method to monitor a remote host?
  • Does each collector have its own dedicated SSH session?
  • Is the SSH connection to a remote host persistent?
  • Can I specify a different polling cycle for each application class?
  • Can I change threshold values for a specific remote host instance?
  • What instance hierarchy is displayed for remote hosts?
  • How does BMC ProactiveNet discover remote hosts?
  • What are the Performance and Scalability metrics for remote monitoring?
  • How do I configure remote hosts via the PATROL Configuration Manager (PCM)?
  • Can I monitor more than 175 remote hosts on a single computer?
  • Troubleshooting SSH

Which version of PATROL KM for UNIX and Linux supports remote monitoring?

PATROL KM for UNIX and Linux started supporting remote monitoring from version 9.8.00 onwards.

Which data collection method is used by remote monitoring?

Remote monitoring uses the PATROL Scripting Language (PSL) data collection method to discover instances and to get data through the remote External PSL Call (XPC).

What is the role of pukremotexec.xpc in remote monitoring?

PATROL KM for UNIX and Linux uses an XPC-based collection mechanism to support monitoring of the remote hosts. The pukremotexec.xpc stand-alone executable communicates with PATROL Agent through standard input (stdin) and output (stdout) channels connected with pipes. The communication between PATROL Agent and the XPC server is handled by the SDK libraries through PSL function calls.

pukremotexec.xpc is an XPC-based SSH2 client that opens sessions with remote hosts, runs commands on those hosts, and returns the output to the PSL collectors. For the PSL collectors, the command execution is transparent and the same PSL collectors work well with the local host and the remote host.

The XPC-based SSH2 client has following advantages:

• A single SSH2 client (process) can handle multiple remote sessions simultaneously.
• Multiple system commands can be executed over a single remote session simultaneously.

The XPC-based client is responsible for collecting information from the remote host for the application classes.

What hardware do I need to monitor multiple UNIX computers remotely?

The following table lists the hardware requirements for a single PATROL Agent running on a dedicated computer and monitoring 175 remote hosts.

Hardware requirements for remote monitoring on multiple UNIX computers

Which operating systems can I monitor remotely?

The following operating systems that are supported by PATROL Agent and PATROL KM for UNIX and Linux can be monitored remotely:

• Red Hat Enterprise Linux 4.x, 5.x, and 6.x
• SUSE Linux Enterprise Server 10 and 11
• Oracle Enterprise Linux 5.x and 6.x
• VMware ESX Server 2.5, 3.0, 3.5, and 4.0
• Solaris 9, 10, and 11
• IBM AIX 6.1, and 7.1
• HP-UX 11.11, 11.23, and 11.31
• CentOS 5.x and 6.x

What are the pre-requisites for enabling remote monitoring?

The PATROL Agent computer should be a dedicated server for remote monitoring. The SSH client should be installed on the PATROL Agent computer to communicate with the remote host on which the SSH server is installed. The SSH server should be available and running on port 22 on the remote host before adding it into a PATROL Agent.

Configuration requirements for host computers (PATROL Agent)

• The operating system that is supported by PATROL Agent and PATROL KM for UNIX and Linux must be installed.
• PATROL Agent and PATROL KM for UNIX and Linux version 9.8.00 or later must be installed.

Configuration requirements for the remote host

• The SSH2 server must be installed and running.
• The SSH2 server must be configured as follows:
  • To configure the remote host for password-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:
    PasswordAuthentication yes
  • To configure the remote host for key-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:
    PubkeyAuthentication yes
  • To configure a port number on the remote host, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:
    Port 22

You must restart the SSH2 server after making configuration changes.

The following figure illustrates a configuration with multiple remote hosts.

Monitoring configuration with multiple remote hosts

Which authentication mechanisms are used in remote monitoring?

PATROL KM for UNIX and Linux supports the following types of user authentication mechanisms.

Password-based

When you configure a remote host for monitoring, you must provide a user name and a password to access the remote host. PATROL KM for UNIX and Linux stores these login credentials in a secure key store. The SSH2 client submits the credentials to the remote host in order to initiate a remote connection. If the credentials are validated successfully, the SSH2 client starts collecting data for the remote host.

To configure the remote host for password-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:

Key-based

When you configure a remote host for monitoring, you must provide the public and private key file paths, and the passphrase (if applicable). The key file paths must be absolute paths (for example, /home/user/id_rsa.pub), and the PATROL user must have read permissions to access the key files. PATROL KM for UNIX and Linux stores the key file paths in a secure key store.

To configure the remote host for key-based authentication, add the following entry to the SSH2 server configuration (sshd_config) file, if it is not already present:

What are “user profiles” in remote monitoring?

User profiles provide a way share credentials among multiple hosts. The hosts that have the same credentials can be grouped into a user profile. You can then assign that profile to all hosts.

Which application classes are supported for remote monitoring?

The remote monitoring functionality in version 9.8.00 and later of PATROL KM for UNIX and Linux, supports the following application classes:

• COLLECTORS
• CPU
• DISK
• FILESYSTEM
• MEMORY
• PROCESS
• PROCESS_PRESENCE
• SMP
• UNIX_OS
• USERS
• AIX_VIRTUALIZATION (version 9.10.00 onwards)
• KERNEL (version 9.10.00 onwards)
• NETWORK (version 9.10.00 onwards)
• NFS (version 9.10.00 onwards)
• SWAP (version 9.10.00 onwards)
• ZPOOL (version 9.10.00 onwards)

Limitations

The following application class limitations apply for remote monitoring on UNIX and Linux computers:

• Discovering an application class depends on the system command. Discovery might not work if the command is not available, the output is invalid, or the user account that you provided while adding the remote host does not have permission to execute the command.
• The PROCESS_PRESENCE application class discovers and creates all default instances for the respective remote host.
  • The Synchronization functionality does not work for remote hosts.
  • Solaris non-global zone processes cannot be monitored if you are monitoring a Solaris global zone computer as a remote host. This functionality works only for local monitoring.
• The SMP application class will not be discovered if a single processor is running on the remote host.
• The FILESYSTEM application class is discovered 5 minutes after the discovery of the remote host.
• The filesystems on which the PATROL user does not have read and execute permissions are not monitored. The parameters for these filesystems remain offline unless the required permissions are granted to the PATROL user.
• The menu commands that require root credentials are not supported.

Which system commands do application classes refer to?

The following table lists the application classes and the system commands that they use.

System commands used by PATROL KM for UNIX and Linux application classes

How many remote hosts can one PATROL Agent monitor?

There is no maximum limit to the number of remote hosts that one PATROL Agent can monitor. However, in the PATROL Performance, Scalability and Reliability (PSR) lab, the largest configuration tested was 175 hosts.

Can I use an earlier version of PATROL Agent?

Yes. You can use any one of the earlier PATROL Agent versions supported. BMC recommends you to use the latest version of the PATROL Agent for better performance.

Can I monitor UNIX and Linux systems from PATROL Agent for Windows?

No, you cannot monitor UNIX or Linux systems from a Microsoft Windows computer.

How do I configure PATROL KM for UNIX and Linux for remote monitoring?

The REMOTE_HOST and REMOTE_CONT application classes are supported to monitor remote hosts.

To add a remote host for monitoring

1. Install PATROL Agent and PATROL KM for UNIX and Linux version 9.8.00 or later on a computer.
2. Add the computer in step 1 in the PATROL console as a Managed Node.
3. Load UNIX3.kml and Remote.kml.
   By default, all the application classes in the DCM collection method are discovered.
4. To switch to the PSL collection method, right-click UNIX OS and choose KM Commands > Knowledge Module Admin > Toggle PSL/DCM Collection.

5. After full discovery, right-click the Remote Monitoring container and choose KM Commands > Manage List of Monitored Hosts.

   When the Manage List of Monitored Hosts dialog box appears, the Add New Host option is selected by default.

6. Click OK, and in the Add New Host dialog box, provide the host name, user name, and password of the remote host to be monitored.

   Note

   The host can also be added by using a profile, and public and private keys.

To modify a remote host

1. Right-click the Remote Monitoring container and choose KM Commands > Manage List of Monitored Hosts.
2. In the Manage List of Monitored Hosts dialog box, select the remote host that you want to modify, and select the Modify Host option.
3. Click OK.
4. Edit the host information as necessary, and then click OK to save the changes.

To delete a remote host

1. Right-click the Remote Monitoring container and choose KM Commands > Manage List of Monitored Hosts.
2. In the Manage List of Monitored Hosts dialog box, select the remote host that you want to modify, and select the Delete Host option.
3. Click OK.

Can I simultaneously use the DCM method to monitor the local host and the PSL method to monitor a remote host?

No, you cannot use the DCM method for local monitoring and the PSL method for remote monitoring, simultaneously. You must switch from DCM collection to PSL collection to enable remote monitoring on UNIX computers.

Does each collector have its own dedicated SSH session?

No, all of the collectors for a remote host use the same SSH session.

Is the SSH connection to a remote host persistent?

Yes, a persistent SSH connection is maintained for each remote host being monitored.

Can I specify a different polling cycle for each application class?

Yes, you can specify a different polling cycle for each application class.

Can I change threshold values for a specific remote host instance?

You can configure threshold values for a specific remote host using the BMC PATROL KM for Event Management.

What instance hierarchy is displayed for remote hosts?

The instance hierarchy that is displayed for a remote host is the same as that of a local host.

How does BMC ProactiveNet discover remote hosts?

BMC ProactiveNet discovers remote host instances as devices.

What are the Performance and Scalability metrics for remote monitoring?

The following table lists the metrics based on 2 processors and 2 GB of RAM for 175 remote hosts monitored for 120 hours.

Performance and Scalability metrics for remote monitoring with PATROK KM for UNIX and Linux

How do I configure remote hosts via the PATROL Configuration Manager (PCM)?

You can add remote hosts in the PATROL Agent by creating the following rulesets in PCM:

To add a remote host in the PATROL Agent, create:

• "/REMOTE/HOSTS/remoteHost/hostInfo" = {REPLACE = "remoteHost<Ctrl+B>NONE<Ctrl+B>0<Ctrl+B>UserName"}
• "/SecureStore/REMOTE_HOSTS/remoteHost/passWord" = {REPLACE = "COLLECTORS;FILESYSTEM;KERNEL;LDOM;LVIRT;MEMORY;NETWORK;NFS;POOL;PROCCONT;PROCESS;PROJECT;REMOTE_CONT;REMOTE_HOSTS;UNIX_OS;USERS;VIRTUALIZATION;WPAR;ZFS;ZPOOL;ZONE/EncryptedPassword"}

To add a remote host in the PATROL Agent with public and private key, create:

• "/REMOTE/HOSTS/remoteHost/hostInfo" = {REPLACE = "remoteHost<Ctrl+B>NONE<Ctrl+B>0<Ctrl+B>UserName<Ctrl+B><Ctrl+B>PublicKey<Ctrl+B>PrivateKey"}
• "/SecureStore/REMOTE_HOSTS/remoteHost/passPhrase" = {REPLACE = "COLLECTORS;FILESYSTEM;KERNEL;LDOM;LVIRT;MEMORY;NETWORK;NFS;POOL;PROCCONT;PROCESS;PROJECT;REMOTE_CONT;REMOTE_HOSTS;UNIX_OS;USERS;VIRTUALIZATION;WPAR;ZFS;ZPOOL;ZONE/EncryptedPassword"}

To add a remote host in the PATROL Agent using profiles, create:

• "/REMOTE/PROFILE/profileName/credential" = {REPLACE = "ProfileName<Ctrl+B>UserName"}
• "/SecureStore/REMOTE/PROFILE/profileName/passWord" = {REPLACE = "COLLECTORS;FILESYSTEM;KERNEL;LDOM;LVIRT;MEMORY;NETWORK;NFS;POOL;PROCCONT;PROCESS;PROJECT;REMOTE_CONT;REMOTE_HOSTS;UNIX_OS;USERS;VIRTUALIZATION;WPAR;ZFS;ZPOOL;ZONE/EncryptedPassword"}
• "/REMOTE/HOSTS/remoteHost/hostInfo" = {REPLACE = "Hostname<Ctrl+B>ProfileName<Ctrl+B>0<Ctrl+B>UserName"}
• "/SecureStore/REMOTE_HOSTS/remoteHost/passWord" = {REPLACE = "COLLECTORS;FILESYSTEM;KERNEL;LDOM;LVIRT;MEMORY;NETWORK;NFS;POOL;PROCCONT;PROCESS;PROJECT;REMOTE_CONT;REMOTE_HOSTS;UNIX_OS;USERS;VIRTUALIZATION;WPAR;ZFS;ZPOOL;ZONE/null"}

The following table gives a description of the items to be entered in the preceding rulesets:

For information on configuring remote hosts in the PATROL console, see Configuring-PATROL-KM-for-UNIX-for-remote-monitoring.

Can I monitor more than 175 remote hosts on a single computer?

Yes, you can monitor more than 175 remote hosts on a single computer. To do this, you have to run another PATROL Agent on a port different from the one you are already using and add upto 175 remote hosts. In the PATROL PSR lab, a maximum of two PATROL Agents have been tested to function simultaneously. To monitor more than 175 hosts at the same time, ensure that you have enough hardware resources to support this configuration in your environment. For more information, see the recommended hardware configurations.

Troubleshooting SSH

The following information addresses common questions about SSH, and issues that you might face while configuring remote monitoring.

How do I debug PATROL KM for UNIX and Linux for remote monitoring?

You can enable and disable debugging at the XPC and SSH library levels for the remote XPC for a remote host.

To enable debugging for the remote XPC for a remote host

1. Access the UNIX OS application menu for the remote host in the Remote Monitoring container.
2. Choose Debug and Diagnostics > PUK Remote XPC Debug Admin.
3. In the PUK Remote Host Debug Admin dialog box, select the Enable XPC Debug check box to start debugging at the XPC level.
4. Select the Enable Libssh2 TRACE check box to start debugging at the library level.
5. Enter the absolute path and name of the log file in which you want the KM to store the debug information (for example, /tmp/PukRemoteDebug.txt).
6. Click Accept.
   The log file is generated in the format, /tmp/PukRemoteDebug.txt~pid, where pid is the process ID of the running pukremotexec.xpc.

To disable debugging for the remote XPC for a remote host

1. Access the UNIX OS application menu for the remote host in the Remote Monitoring container.
2. Choose Debug and Diagnostics > PUK Remote XPC Debug Admin.
3. In the PUK Remote Host Debug Admin dialog box, clear the Enable XPC Debug check box to stop debugging at the XPC level.
4. Clear the Enable Libssh2 TRACE check box to stop debugging at the library level.
5. To close the generated log file, select the Close debug file check box.
6. Click Accept.

Where I can find the sshd_config file on the system?

The sshd_config file resides in /etc/ssh/, but the location might vary depending upon the operating system or distribution:

• For Linux, Solaris, and AIX: /etc/ssh/sshd_config
• For HP-UX: /opt/ssh/etc/sshd_config

Can I modify the sshd_config file as a standard user?

By default, a root user has permissions to modify this file. However, the environment can be configured to allow a standard user to modify this file.

How do I start and stop the sshd service?

You can use the following commands to start and stop the sshd service:

• Red Hat Enterprise Linux:
  #service sshd restart
• SUSE Linux:
  # /etc/rc.d/sshd restart
• Oracle Enterprise Linux:
  # /etc/init.d/sshd stop
  # /etc/init.d/sshd start
  # /etc/init.d/sshd restart
• Solaris 9 and earlier versions:
  # /etc/init.d/sshd stop
  # /etc/init.d/sshd start
• Solaris 10:
  # svcadm disable ssh
  # svcadm enable ssh
• AIX:
  # stopsrc -s sshd
  # startsrc -s sshd
• HP-UX:
  # /sbin/init.d/secsh stop
  # /sbin/init.d/secsh start

How do I verify and debug the SSH connection for a specific remote host?

You can use the following commands to verify and debug the ssh connection with a remote host. The debug log appears only on that same session of system.

• For password-based authentication:
  # ssh -2 –v –v –v –l userName -o PreferredAuthentications=password remoteHostsys_command
• For key-based authentication:
  # ssh -2 –v –v –v –l userName -o PreferredAuthentications=publickey remoteHostsys_command

You must execute these commands on monitoring servers (PATORL Agent computer).

How do I create RSA public and private keys?

An RSA key pair must be generated on the client system. The public portion of this key pair must reside on the servers that the client will access, and the private portion must reside on a secure local area of the client system (by default in the ~/.ssh/id_rsa directory).

The following figure shows the RSA key pair on client and server systems.

RSA key pair on client and server systems

You can generate the keys by using the ssh-keygen utility.

To generate the RSA key pair

1. Enter the following command on the client system to create the ~/.ssh directory:
   mkdir ~/.ssh
2. Enter the following command on the client system to change permissions on the ~/.ssh directory:
   chmod 700 ~/.ssh
3. Enter the following command on the client system:
   ssh-keygen -q -f ~/.ssh/id_rsa -trsa
4. Enter the passphrase if required.
5. Enter the passphrase again.

The file permissions should be locked to prevent other users from being able to read the key pair data. OpenSSH might also refuse to support public key authentication if the file permissions are too open. These fixes should be done on all systems involved.

To lock file permissions

1. Enter the following commands on the client system:

   • chmod go-w ~/

   • chmod 700 ~/.ssh
   • chmod go-rwx ~/.ssh/*

To enable public key authentication

1. Copy the public portion of the RSA key pair to the servers that the client will access.
   The public key information to be copied should be located in the ~/.ssh/id_rsa.pub file on the client.
2. Append the public key information to the ~/.ssh/authorized_keys file on the servers.
   You can use the scp or ssh-copy-id utility for copying the ID on the server.
3. Verify that public key connections to the servers work properly by executing the following commands:
   • client$ ssh -o PreferredAuthentications=publickey sshServerName
   • Enter passphrase for key '/…/.ssh/id_rsa': passphrase
   • passphrase
   • server$

Remote monitoring flowchart

The following figure represents the workflow for remote monitoring: