Once Symantec Mobility: Suite is installed in a RHEL/CentOS VM, registered, and configured, the operations staff must monitor the system and react to any issues that arise. This section discusses monitoring the system, which services are crucial to business continuity, configuration files that can be modified to change notifications, and appropriate remedial actions.
The on-premises software supports SSL termination on the Mobility Suite server (mobility: suite instance). A load balancer or third-party monitoring software can be configured for the following Keepalive URL to ensure that the system is available:
The Mobility Suite server configures monit to monitor disk size, memory, CPU usage, CPU wait, and the Symantec-required services. If one of the limits is reached for memory or CPU, the system sends emails with the output from top until the test succeeds. Monit checks to make sure that the services are running, and if not, attempts to restart them.
The installation process dynamically configures the monit config file from a template. It uses the operations email provided during the registration process. The monit config does not get reset when you change the operations alias via the Admin Console Settings or Notifications page. If you want to change the monit config file, you must edit it directly. For example:
Symantec Mobility: Suite leverages cron to run daily and hourly checks. Mobility Suite does not modify the default cron configuration. It simply adds files in the appropriate directories (cron.hourly, cron.daily, and so on). The Mobility Suite server checks daily to make sure it can access the Android GCM service and run a sanity check on the database. The sanity report is mailed daily to the operations email address configured during registration. All cron job error output uses the default cron setting, which is root.
Mobility Manager Configurations
From the Admin Console, you can configure the "From Email" and "From Name" for system-generated emails that go to end-users (e.g., the Invitation Emails). By default, these originate from email@example.com. We recommend that you change the default to reflect your domain. In the Admin Console, go to Settings > Branding and look for the "From Email" and "From Name", fill these in with appropriate administrative information, and save.
On the Branding page, you see the support email alias which is used for the Android Work Hub in the event that an end user has an issue. To have these emails sent to you, change this alias to one of your support emails. When you click Save, the Android client is rebuilt. Note that end users must update their client to see this change.
In the Admin Console under Settings > Notifications, you can modify the "Operations Email" address that was entered during initial registration. This does not modify any config files. It only modifies values stored in the database. You must edit the monit config file directly (see above) if you want to change the monit configuration.
You also see an option to "not send emails for debug". The debug emails are useful in troubleshooting software issues and let the operations team see customer issues. These emails can be forwarded to Symantec to diagnose a problem. If you prefer not to receive these emails, you can turn them off. If you have an issue that you want to escalate to Symantec (with emails for debug disabled), you must provide the log files in the /var/log/nukona and /var/log/httpd directories to assist Symantec in debugging the problem.
Symantec services and software uses the operations email address configured during registration to send errors. If monit, one of the Symantec services, or the software hits an error condition, an email is generated to the operations alias. If the error is not self-explanatory and does not correlate to a maintenance event, contact Symantec Support for assistance.
If the database is not reachable when the Symantec services initialize, it reads the operations email alias from the local configuration files (/usr/local/nukona/etc/*), and if none is present, it defaults to firstname.lastname@example.org. In the event that Symantec receives an email from one of your systems, you are be contacted immediately. You can also check the log files in /var/log/nukona directory to see these errors.
If you need to restart the Symantec services but don't want to restart the server, run the following commands:
If your Mobility Suite server loses connectivity to the database and connectivity is then restored, but you continue to receive messages from the Symantec services, then you should use the restart option above. If this does not resolve the issue, contact Symantec Support.
If you receive emails from monit that you are running low on memory or CPU, then you may need to adjust the number of httpd processes running on the system, the amount of memory, or the CPU you have available.
To change the number of httpd processes
Issue the following command:
Adjust the number of processes (default value is 10):
<VirtualHost _default_:443> WSGIDaemonProcess App Center user=apache group=apache processes=10 threads=1 display- name=nukonawsgi maximum-requests=100Save the file service httpd graceful
Save the ssl.conf file.
If you are not receiving memory or CPU alerts, but the Mobility Suite server is not keeping up with client requests, you may need to increase the number of processes to improve performance. Symantec does not recommend exceeding processes=20 with 4G of memory. If you modify the ssl.conf file, you should push these config file changes to the database.
If you receive emails from monit indicating that disk space is running low, determine what is using the disk space and then either adjust the system or add more disk space. Log files are in the /var/log/nukona directory. Log files are configured to rotate; however, if you need to adjust the log rotation configuration, use the following procedure.