If you are using Redhat or Centos and you can not download the Agent from our repositories, perform the following:
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
If you notice the agent is not running after the initial install, the agent’s cron entry may be getting blocked by the system.
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
You may also have to add the panopta-agent user to cron.allow file.
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
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.
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
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:
Set the ownership on the Agent log files back to panopta-agent.
If you run into an error with a partial installation:
Uninstall the Agent.
Reinstall the Agent.
If you get an error with the uninstallation, you can force remove the Agent by running the following commands:
rpm -e --noscripts panopta-agent
yum clean all
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.
If your Agent isn't able to see your network-attached storage or partitions, it's likely a permissions issue for the Agent User.
You can confirm this by first checking if the Agent User can see the drives.
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.
Once that's complete, you need to force a metadata rebuild on the Agent from the control panel.
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.
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
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
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.
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!
[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
To uninstall the Agent, run the following commands:
apt-get remove panopta-agent
yum remove panopta-agent
Please send the FortiMonitor Agent logs to our support team so we can further assist you. You can find the logs in: