Chatee ahora con Soporte
Chat con el soporte

Foglight Agent Manager 7.1.0 - Foglight Agent Manager Guide

Configuring the embedded Agent Manager Installing external Agent Managers
Understanding how the Agent Manager communicates with the Management Server Deploying the Agent Manager cartridge Downloading the Agent Manager installer Installing the Agent Manager Starting or stopping the Agent Manager process Frequently asked questions
Configuring the Agent Manager Advanced system configuration and troubleshooting
Configuring Windows Management Instrumentation (WMI) Configuring Windows Remote Management (WinRM) UNIX- and Linux-specific configuration
Monitoring the Agent Manager performance Deploying the Agent Manager to large-scale environments

Reviewing application event logs

WinRM logs activity to an event log on the target machine. This includes both success and failure messages for authentication.

To view application event logs:
1
On the target machine, right-click My Computer and select Manage.
2
In the navigation tree on the left, choose System Tools > Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Remote Management > Operational.
The default Operational log contains the most common events.
To enable additional debug logging information:
1
Click View.
2
Click Show Analytic and Debug Logs.
3
Right-click the log file you want to view.
4
Select Enable Log.

Enabling connection type debugging

If the only information you are interested in is the types of connections that are being established, there is a command-line setting that enables logging the connection types.

Run the Agent Manager with the following switch:

-Dquest.debug.windowsinfo.types

 
* 
NOTE: This logging occurs every time a connection is established and can be very verbose. It is recommended for debugging purposes only.

UNIX- and Linux-specific configuration

This 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
•
SSH IPv6 connection support
•
About supported remote monitoring protocols
•
Configuring the Agent Manager to run as a daemon
•
Configuring Agent Manager agent privileges
•
Using the HP patch checking tool
•
About Agent Manager installations on AIX
•
Preventing Agent Manager core dumps on Linux

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
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación