Fortinet Document Library

Version:


Table of Contents

User Guide

21.4.0
Copy Link

Linux Agent

Unable to download the FortiMonitor Agent 

If you are using Redhat or Centos and you can not download the Agent from our repositories, perform the following:

  1. Run the following command to clear your repositories cache:


yum clean all --disablerepo="*" --enablerepo=panopta.repo

2. Try the installation again. 

3. If it does not work, run the following command and send the output to FortiMonitor support:

yum --disablerepo=""*"" --enablerepo=""panopta.repo"" list available

Agent not running 

If you notice the agent is not running after the initial install, the agent’s cron entry may be getting blocked by the system.

  1. Check /var/log/syslog to see if some other server-level security it blocking the panopta-agent cron from running. Servers using PAM or AppArmor often suffer from this and require the panopta-agent user to be added to access.conf

  2. You may also have to add the panopta-agent user to cron.allow file. 

  3. For users running CageFS on their machines, you would need to disable cagefs for the panopta-agent user in order for the Agent to run properly. You can do this using the following command: 

    /usr/sbin/cagefsctl --disable panopta-agent

Agent not running due to locked account 

The FortiMonitor agent installation creates a limited user account in order to scope all execution properly. By default, that user has no shell login allowed and has password set to never expire. That being said, some security tools/agents will force passwords to expire. Once the password is expired, the agent may not continue to run on it's schedule. In order to resolve this, you need to set the password to never expire.

  1. Check password expiration by running the following command: 

    sudo chage -l panopta-agent

You will see an output similar to the following:

Last password change : Mar 13, 2018
Password expires : Jun 11, 2018
Password inactive : Jul 11, 2018
Account expires : never
Minimum number of days between password change : 7
Maximum number of days between password change : 90
Number of days of warning before password expires : 7 ​

If lines 2 and 3 indicate an expired password, change the password to never expire by running the following command:

sudo chage -I -1 -m 0 -M 99999 -E -1 panopta-agent

Agent not running due to permission problems in log files 

In some cases, when the Agent is originally run from root to debug a situation, permissions on log files can be set improperly. To resolve the issue: 

  1. Set the ownership on the Agent log files back to panopta-agent.

Error with a partial Linux installation 

If you run into an error with a partial installation:

  1. Uninstall the Agent.

  2. Reinstall the Agent. 

If you get an error with the uninstallation, you can force remove the Agent by running the following commands:

Redhat

rpm -e --noscripts panopta-agent
yum clean all

Debian

apt-get purge panopta-agent
dpkg --purge panopta-agent

After this, reinstall the agent and wait for the sync to happen. If the agent does not begin to sync, look in the contents of panopta_agent.cfg in /etc and see if the aggregator URL is there. If not, please add the URL to the file. The aggregator URL (if not using the OnSight as a proxy) is aggregator2.panopta.com.

Agent not seeing network attached storage/partitions 

If your Agent isn't able to see your network-attached storage or partitions, it's likely a permissions issue for the Agent User.

  1. You can confirm this by first checking if the Agent User can see the drives. 

  2. Test to see if root can see the drives.
    If root sees them, and the Agent User does not, you'll need to give the Agent User permission to access those drives.

  3. Once that's complete, you need to force a metadata rebuild on the Agent from the control panel. 

Non-root users are unable to run cronjobs 

Cron is only working for root users. When a cron job is run, it fails with the following error in /var/log/messages

Mar 19 15:06:01 p123456s crond[27xxx]: Permission denied
Mar 19 15:06:01  p123456s crond[27xxx]: CRON (panopta-agent) ERROR: failed to open PAM security session: Success
Mar 19 15:06:01  p123456s crond[27xxx]: CRON (panopta-agent) ERROR: cannot set security conte

This solution only applies if you wish to use a custom access*.conf file to list which users are allowed to use cron.

  1. Ensure that /etc/pam.d/crond is referencing the correct access*.conf file:


$ cat /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
auth         sufficient    pam_env.so
auth         required      pam_rootok.so
auth         include       system-auth
account      sufficient    pam_succeed_if.so uid = 0 use_uid quiet
account      sufficient    pam_listfile.so onerr=succeed item=user sense=allow
file=/etc/security/access-cron.conf
account      include       system-auth
session      required      pam_loginuid.so
session      include       system-auth

2. Ensure that the user running cron (in this case cron_user) is listed in /etc/cron.allow:


# cat /etc/cron.allow
root
user1
cron_user

3. Ensure the user is allowed to log in via /etc/security/access.conf:


+ : root : ALL
+ : cron_user : ALL
+ : @u1_dbadmin : ALL
+ : @u2_sysadmin : ALL
- : ALL : ALL

4. A custom list of users that can run cronjobs is at /etc/security/access-cron.conf. However, PAM does not reference /etc/security/access-cron.conf when authenticatingfor crond. The default for pam_access.so is to reference /etc/security/access.conf when access file is not used.

Installation issues on RHEL 5.x servers

When installing the FortiMonitor Linux Agent on RHEL 5.x servers, you may run into the following errors:

Error checking SSL compatibility - cannot import SSL libraries!

or

[Errno -3] Error performing checksum

This means that you will need to update the sha256 ciphers to calculate the checksums for newer RedHat repositories.

You can do this by the following method:

Use yum to install `python-hashlib` on the machine and then try to install the FortiMonitor agent via the repo again.

yum install python-hashlib

How to Uninstall the Agent 

To uninstall the Agent, run the following commands:

Debian

apt-get remove panopta-agent

Redhat

yum remove panopta-agent

Still having trouble? 

Please send the FortiMonitor Agent logs to our support team so we can further assist you. You can find the logs in:

Log location 

/var/log/panopta-agent/

Linux Agent

Unable to download the FortiMonitor Agent 

If you are using Redhat or Centos and you can not download the Agent from our repositories, perform the following:

  1. Run the following command to clear your repositories cache:


yum clean all --disablerepo="*" --enablerepo=panopta.repo

2. Try the installation again. 

3. If it does not work, run the following command and send the output to FortiMonitor support:

yum --disablerepo=""*"" --enablerepo=""panopta.repo"" list available

Agent not running 

If you notice the agent is not running after the initial install, the agent’s cron entry may be getting blocked by the system.

  1. Check /var/log/syslog to see if some other server-level security it blocking the panopta-agent cron from running. Servers using PAM or AppArmor often suffer from this and require the panopta-agent user to be added to access.conf

  2. You may also have to add the panopta-agent user to cron.allow file. 

  3. For users running CageFS on their machines, you would need to disable cagefs for the panopta-agent user in order for the Agent to run properly. You can do this using the following command: 

    /usr/sbin/cagefsctl --disable panopta-agent

Agent not running due to locked account 

The FortiMonitor agent installation creates a limited user account in order to scope all execution properly. By default, that user has no shell login allowed and has password set to never expire. That being said, some security tools/agents will force passwords to expire. Once the password is expired, the agent may not continue to run on it's schedule. In order to resolve this, you need to set the password to never expire.

  1. Check password expiration by running the following command: 

    sudo chage -l panopta-agent

You will see an output similar to the following:

Last password change : Mar 13, 2018
Password expires : Jun 11, 2018
Password inactive : Jul 11, 2018
Account expires : never
Minimum number of days between password change : 7
Maximum number of days between password change : 90
Number of days of warning before password expires : 7 ​

If lines 2 and 3 indicate an expired password, change the password to never expire by running the following command:

sudo chage -I -1 -m 0 -M 99999 -E -1 panopta-agent

Agent not running due to permission problems in log files 

In some cases, when the Agent is originally run from root to debug a situation, permissions on log files can be set improperly. To resolve the issue: 

  1. Set the ownership on the Agent log files back to panopta-agent.

Error with a partial Linux installation 

If you run into an error with a partial installation:

  1. Uninstall the Agent.

  2. Reinstall the Agent. 

If you get an error with the uninstallation, you can force remove the Agent by running the following commands:

Redhat

rpm -e --noscripts panopta-agent
yum clean all

Debian

apt-get purge panopta-agent
dpkg --purge panopta-agent

After this, reinstall the agent and wait for the sync to happen. If the agent does not begin to sync, look in the contents of panopta_agent.cfg in /etc and see if the aggregator URL is there. If not, please add the URL to the file. The aggregator URL (if not using the OnSight as a proxy) is aggregator2.panopta.com.

Agent not seeing network attached storage/partitions 

If your Agent isn't able to see your network-attached storage or partitions, it's likely a permissions issue for the Agent User.

  1. You can confirm this by first checking if the Agent User can see the drives. 

  2. Test to see if root can see the drives.
    If root sees them, and the Agent User does not, you'll need to give the Agent User permission to access those drives.

  3. Once that's complete, you need to force a metadata rebuild on the Agent from the control panel. 

Non-root users are unable to run cronjobs 

Cron is only working for root users. When a cron job is run, it fails with the following error in /var/log/messages

Mar 19 15:06:01 p123456s crond[27xxx]: Permission denied
Mar 19 15:06:01  p123456s crond[27xxx]: CRON (panopta-agent) ERROR: failed to open PAM security session: Success
Mar 19 15:06:01  p123456s crond[27xxx]: CRON (panopta-agent) ERROR: cannot set security conte

This solution only applies if you wish to use a custom access*.conf file to list which users are allowed to use cron.

  1. Ensure that /etc/pam.d/crond is referencing the correct access*.conf file:


$ cat /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
auth         sufficient    pam_env.so
auth         required      pam_rootok.so
auth         include       system-auth
account      sufficient    pam_succeed_if.so uid = 0 use_uid quiet
account      sufficient    pam_listfile.so onerr=succeed item=user sense=allow
file=/etc/security/access-cron.conf
account      include       system-auth
session      required      pam_loginuid.so
session      include       system-auth

2. Ensure that the user running cron (in this case cron_user) is listed in /etc/cron.allow:


# cat /etc/cron.allow
root
user1
cron_user

3. Ensure the user is allowed to log in via /etc/security/access.conf:


+ : root : ALL
+ : cron_user : ALL
+ : @u1_dbadmin : ALL
+ : @u2_sysadmin : ALL
- : ALL : ALL

4. A custom list of users that can run cronjobs is at /etc/security/access-cron.conf. However, PAM does not reference /etc/security/access-cron.conf when authenticatingfor crond. The default for pam_access.so is to reference /etc/security/access.conf when access file is not used.

Installation issues on RHEL 5.x servers

When installing the FortiMonitor Linux Agent on RHEL 5.x servers, you may run into the following errors:

Error checking SSL compatibility - cannot import SSL libraries!

or

[Errno -3] Error performing checksum

This means that you will need to update the sha256 ciphers to calculate the checksums for newer RedHat repositories.

You can do this by the following method:

Use yum to install `python-hashlib` on the machine and then try to install the FortiMonitor agent via the repo again.

yum install python-hashlib

How to Uninstall the Agent 

To uninstall the Agent, run the following commands:

Debian

apt-get remove panopta-agent

Redhat

yum remove panopta-agent

Still having trouble? 

Please send the FortiMonitor Agent logs to our support team so we can further assist you. You can find the logs in:

Log location 

/var/log/panopta-agent/