UNIX- and Linux-specific configuration

This section contains platform-specific configuration information for configuring the Foglight Agent Manager on UNIX or Linux. If your database is installed on an HP-UX server, regardless of the operating system, see Using the HP patch checking tool.

This section provides solutions for the following issues:

Agent Manager service can’t start automatically when the operating system restarts

When the Agent Manager service is running in the following platforms, it might not be able to start automatically when the operating system restarts.

Operating system platform Operating system version
CentOS Linux 8.0
8.1
8.2
Red Hat Linux 8.1
8.2
Oracle Linux 8.0
8.1
8.2
SLES Linux 15
15 SP1
15 SP2

To fix this issue, follow the instructions provided below: Use the ausearch utility to check the Access Vector Cache (AVC) messages and see if SELinux denies any of the FglAM actions:

# ausearch -m AVC,USER_AVC -ts today time->Wed Nov 4 11:18:11 2020 type=AVC msg=audit(1604459891.164:117): avc: denied { open } for pid=1311 comm=“fglam” path="/root/ 5981fips/jre/1.8.0.265/jre/lib/jce.jar" dev=“dm-0” ino=11429653 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=1

The -m option specifies what kind of information ausearch returns. The -ts option specifies the time stamp. For example, -ts today returns messages from the whole day.

  • If any FglAM action has been denied, there are two options to fix the issue:

    • Disable SELinux service.

    • If you don’t want to disable SELinux, do the following: a. Open the /etc/selinux/config file and change SELinux mode to permissive. Using permissive mode will force SELinux to accept all FglAM actions. SELinux will log all the denials regarding to FglAM actions that would have been denied in enforcing mode, by identifying them one at a time as the FglAM gets permissions granted individually.
      b. Restart FglAM machine.
      c. Ensure FglAM service starts automatically. Then try all of the functions that FglAM and agents would perform, such as deploying agent gars, creating agent instances, releasing lockbox to FglAM, and so on. Therefore, it will reveal all the FglAM actions that would have been denied by SELinux if running in enforcing mode.
      d. Use the ‘journalctl -t setroubleshoot –since= [time]’ utility to view more information about the AVC message:

      # journalctl -t setroubleshoot –since=11:18 – Logs begin at Tue 2020-11-03 10:37:14 CST, end at Wed 2020-11-04 11:19:27 CST. – Nov 04 11:18:30 centos82-s1 setroubleshoot[1416]: SELinux is preventing quest-fglam from execute access on the file fglam. For complete SELinux messages run: sealert -l 06149362-e530- 4f52-a081-53751a98eab7 Replace [time] with the machine restart time.
      e. Use the ‘sealert -l [AVC message ID]’ utility to further inspect the AVC message:

      # sealert -l 06149362-e530-4f52-a081-53751a98eab7 SELinux is preventing quest-fglam from execute access on the file fglam. ***** Plugin catchall 100. confidence suggests**** If you believe that quest-fglam should be allowed execute access on the fglam file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c ‘quest-fglam’ –raw | audit2allow -M my-questfglam # semodule -X 300 -i my-questfglam.pp [trimmed for clarity]

      f. Perform actions according to suggestions provided in Step e.
      g. Repeat Step e to Step f for all FglAM action denials AVC messages found in Step d.
      h. Restore SELinux to enforcing mode and restart FglAM machine.
      i. Check if there are still denials about FglAM actions. If yes, repeat Step a to Step i until no denials to FglAM actions are found.

  • If it is not caused by SELinux, perform below command to check if it works. systemctl enable quest-fglam.service If it doesn’t work, fix the issue according to the error. For example, it may report below error, which instructs to install the tool insserv first and then run above command again to fix this issue. Executing: /usr/lib/systemd/systemd-sysv-install enable quest-fglam /sbin/insserv: No such file or directory

SSH IPv6 connection support

Starting with the Foglight Agent Manager version 5.9.1, the SSH connection with unique local IPv6 Address and link-local IPv6 Address is supported on the Agent Manager running on Windows, Linux, and Solaris.

About supported remote monitoring protocols

The Agent Manager supports the SSH (secure shell) protocol for remote monitoring of hosts running Linux and UNIX operating systems. SSH is a protocol which encrypts all traffic between the client and the server, and supports a wide variety of secure authentication mechanisms. SSH is available for installation on all platforms supported for remote monitoring by Foglight.

The Agent Manager does not support the older Telnet protocol for remote monitoring. Telnet is an insecure protocol which does not encrypt traffic, and requires that the passwords used to authenticate collections are sent in the clear. For that reason, supporting Telnet as a remote monitoring protocol potentially exposes monitored systems to trivial network eavesdropping attacks, disclosing passwords to attackers.

While it is possible to create a closed network with strong security boundaries within which it is safe to run the Telnet protocol, this use case is not common, and it is impossible for the Agent Manager to determine if Telnet is safe to use before offering it as an option for connectivity. Further, the effort required on the part of the user to maintain such a secure environment is far less than that required to simply enable SSH connections on a host. For these reasons, the Agent Manager does not support Telnet as a remote monitoring protocol.

Configuring the Agent Manager to run as a daemon

As described in Installing the Agent Manager using the installer interface and Installing the Agent Manager from the command line, you can install an init.d-style script called quest-fglam in the init.d directory on your system. This script is called when the host on which the Agent Manager is installed starts or shuts down, allowing it to run as a daemon.

Even if you choose not to install the init.d script during the installation, or if you do not perform the installation as the root user, the installer generates scripts that can perform the necessary setup.

These scripts are fglam-init-script-installer.sh and fglam-init-script.sh, and they are located in the <fglam_home>/state/default/ directory. The script fglam-init-script-installer.sh installs the script fglam-init-script.sh into your system’s init.d directory as quest-fglam. Your system’s init.d process then uses quest-fglam to run the Agent Manager as a daemon.

To install the init.d script:

  1. Launch a command shell on the Agent Manager machine and navigate to the <fglam_home>/state/default/ directory.
  2. Optional. If you want to make any edits to fglam-init-script.sh to customize it for your system, do so prior to running fglam-init-script-installer.sh.

    Any customizations that you make to the script fglam-init-script.sh are not supported by Quest Software Inc.

  3. Switch to the root user.
  4. From the command shell, run the script fglam-init-script-installer.sh with the install option: ./fglam-init-script-installer.sh install

    This script must be run as root.

    The setup script fglam-init-script-installer.sh installs the init.d script quest-fglam. See Locating the init.d script for the location in which it is installed.
  5. To start or stop the Agent Manager daemon manually, follow the instructions in To run the Agent Manager as a daemon on UNIX.

Locating the init.d script

Depending on the operating system you are running, the init.d-style script quest-fglam is installed to a different location either by the Agent Manager installer or after you run the script fglam-init-script-installer.sh.

The locations of the installed init.d script (listed by operating system) are as follows:

  • AIX: /etc/rc.d/init.d
  • All Linux operating systems: /etc/init.d
  • HP-UX: /sbin/init.d
  • Oracle Solaris: /etc/init.d

    The location of the init.d script depends only on the type of operating system, not on the specific architecture. For example, the location is the same for HP-UX running on either PA-RISC or Itanium, or for Oracle Solaris running on either SPARC or x86

Obtaining the Agent Manager daemon status

In addition to starting or stopping the Agent Manager process, the init.d script allows you to obtain the status of the daemon process when you run the script with the status option. When the status option is specified with the init.d script, the script returns one of the following status codes:

  • 0: The Agent Manager daemon process is running.
  • 1: The Agent Manager daemon process is dead and a pid file is generated.
  • 3: The Agent Manager daemon process is not running.
  • 4: The Agent Manager daemon process status is unknown.

Configuring Agent Manager agent privileges

On UNIX systems, certain Foglight agents require elevated privileges in order to gather the required system metrics. This is achieved by having the Agent Manager launch these agents with root privileges.

To give these agents the required access, the Agent Manager is configured to launch these agents using an external application like sudo, setuid_launcher, or any other tool that allows privilege escalation (without a password) and supports the same command-line semantics as sudo.

The tool setuid_launcher is included with the Agent Manager, in the <fglam_home>/bin/setuid_launcher directory.

Instructions for using sudo and setuid_launcher to give these agents the necessary privileges are provided below.

Certain agents that require root privileges to gather a more complete set of system metrics are able to function without these privileges.

If an agent is configured to be launched by an external application and fails to start, the Agent Manager logs a warning and then tries starting the agent without the launcher and without root privileges. The agent does not collect as much data as when it is run with root privileges.

Using sudo to configure secure launcher permissions

This section contains instructions for using sudo to give agents elevated permissions. To set up secure launcher permissions using the configuration interface and sudo:

  1. Launch the Agent Manager configuration command-line interface.
  2. Navigate to the Configure Secure Launcher or Secure Launcher step.
  3. Set the path to point to the sudo executable. This executable is typically located in /usr/bin/sudo (the default path provided by the Agent Manager installer).
  4. Exit from the configuration interface.
  5. Edit the sudoers file for your system to allow <fglam_home>/client/<fglam_version>/bin/fog4_launcher to be run as root by a specific user, without requiring a password, and only for the agents that require root privileges.

For example, to allow the user foglight to execute fog4_launcher for two specific agents without being prompted for a password: foglight ALL = NOPASSWD:
/<fglam_home>/client//bin/fog4_launcher /<fglam_home>/state/default///bin/<agent> ?@?* bin/<agent>,
/<fglam_home>/client//bin/fog4_launcher /<fglam_home>/state/default///bin/<agent2> ?@? bin/<agent2>* The example above also limits the acceptable arguments to match the expected pattern when the Agent Manager runs the agents. 6. Ensure that the requiretty option is disabled in the sudoers file. For example, to disable this option for the foglight user, add the following entry to the file: Defaults:foglight !requiretty 7. If the agent uses an ICMP ping service, edit the sudoers file for your system to allow <fglam_home>/client//bin/udp2icmp* to be run as root by a specific user, without requiring a password.

For sudo configuration, it is a best practice to use a wildcard for the version-specific Agent Manager and cartridge directories, as shown in the example above. Using a wildcard in a path is described in the Sudoers Manual located at: http://www.gratisoft.us/sudo/man/sudoers.html#wildcards Using a wildcard for the version-specific directories allows you to avoid updating each sudoers file that references these directories when you upgrade the Agent Manager or the agents.

If these permissions are no longer needed, remove the lines that you added to run fog4_launcher or udp2icmp with root permissions.

To set up secure launcher permissions using fglam.config.xml and sudo:

  1. Navigate to <fglam_home>/state/default/config.
  2. Open the fglam.config.xml file for editing.
  3. Edit the <config:path > element under <config:secure-launcher > to point to the sudo executable. This executable is typically located in /usr/bin/sudo (the default path provided by the Agent Manager installer).
  4. Edit the sudoers file for your system to allow <fglam_home>/client/<fglam_version>/bin/fog4_launcher to run as root by a specific user, without requiring a password, and only for the agents that require root privileges. For example, to allow the user foglight to execute fog4_launcher for two specific agents without being prompted for a password: foglight ALL = NOPASSWD:
    /<fglam_home>/client//bin/fog4_launcher /<fglam_home>/state/default///bin/ ?@? bin/,
    /<fglam_home>/client//bin/fog4_launcher /<fglam_home>/state/default///bin/ ?@? bin/ The example above also limits the acceptable arguments to match the expected pattern when the Agent Manager runs the agents.
  5. If the agent uses an ICMP ping service, edit the sudoers file for your system to allow <fglam_home>/client//bin/udp2icmp* to be run as root by a specific user, without requiring a password.

Using setuid_launcher to configure secure launcher permissions

This section contains instructions for using setuid_launcher to give agents elevated permissions.

To set up secure launcher permissions using the configuration interface and setuid_launcher:

  1. Launch the Agent Manager Installation and Configuration interface.
  2. Navigate to the Configure Secure Launcher screen or the Secure Launcher step.
  3. Set the path to point to the setuid_launcher executable. This executable is located in <fglam_home>/bin/setuid_launcher.
  4. Exit from the configuration interface.
  5. Use the command chmod u+s to set the sticky bit on <fglam_home>/bin/setuid_launcher.
  6. Change the owner of <fglam_home>/bin setuid_launcher to root. This permits the agents that need root privileges to be run as the root user without requiring a password.

If these permissions are no longer needed, issue the following command: chmod u-s <fglam_home>/bin/setuid_launcher

To set up secure launcher permissions using fglam.config.xml and setuid_launcher:

  1. Navigate to <fglam_home>/state/default/config.
  2. Open the fglam.config.xml file for editing.
  3. Edit the <config:path> element under <config:secure-launcher> to point to your local setuid_launcher executable. This executable is located in <fglam_home>/bin/setuid_launcher.
  4. Issue the command chmod u+s to set the sticky bit on <fglam_home>/bin/setuid_launcher.
  5. Change the owner of <fglam_home>/bin/setuid_launcher to root. This permits the agents that need root privileges to be run as the root user without requiring a password.
  6. If these permissions are no longer needed, issue the command: chmod u-s <fglam_home>/bin/setuid_launcher

Using the HP patch checking tool

If your database is installed on an HP-UX server, HP provides a tool for ensuring that all the patches required to run JavaTM on HP-UX are installed. For more information, refer to HPE Support Center.