This section lists common issues you might encounter with Novell Nsure Audit. These include:
If the Secure Logging Server does not load, check the log for any errors that occurred during startup.
The following table reviews the problems that might prevent the Secure Logging Server from loading.
Cause |
Explanation/Solution |
---|---|
The driver for the default log channel could not be loaded/Could not initialize logging subsystem |
If this is the case, the Secure Logging Server will abort loading. This is done to ensure that the administrator is aware of this potentially serious condition. Solution Check the error message and fix the indicated problem. For example, if the MySQL driver cannot connect to the MySQL server, load the MySQL server. |
Could not authenticate to MDB. |
This error occurs if the Secure Logging Server cannot successfully initialize the MDB interface or if the host is not configured to run the Secure Logging Server. MDB is the directory interface used by Nsure Audit. For more information, see Section H.1, Program Files and Directories. Solution
|
Not enough memory |
During startup, the Secure Logging Server allocates memory for its own operation and for the event cache. If this memory cannot be allocated, the Secure Logging Server will terminate. Solution
|
The server cannot log in to the database. |
The Secure Logging Server cannot log in to the data store. Solution Ensure that your MySQL password is correct. Try logging into the MySQL monitor using the exact settings that are configured on the MySQL channel. For example if the MySQL server IP address is 151.155.167.249, the surname is auditusr, and the password is auditpwd, log in to the MySQL monitor with the following syntax: mysql -h 151.155.167.249 -u auditusr -p If you cannot log in, then the MySQL rights are probably not set up correctly. |
The following table reviews the problems that might prevent events from being logged.
Cause |
Explanation/Solution |
---|---|
The logging application is logging events to cache |
If a logging application loads the Platform Agent while the Secure Logging Server is not, or not yet, loaded, its events will be logged to the Platform Agent's Disconnected Mode Cache. By default, the Platform Agent tries to reconnect to the Secure Logging Server only every ten minutes. The Logging Cache Module, on the other hand, tries to upload its cached files to the Secure Logging Server every two minutes. Solution Wait for the Platform Agent to reconnect to the Secure Logging Server. For information on changing the Platform Agent's reconnect interval, see Logevent. If you don’t see the events after the configured upload interval, verify that your configuration is correct. |
A component is misconfigured |
There can be a misconfiguration on the Platform Agent or the Secure Logging Server that prevents events from being logged. Solution
|
A component is misconfigured continued |
If a single application is not logging events,
|
The following table reviews the problems that might prevent notifications from being executed.
Cause |
Explanation/Solution |
---|---|
A component is misconfigured. |
There can be a misconfiguration on the Platform Agent or the Secure Logging Server that prevents events from being logged. Solution
|
The following table reviews the problems that might cause your data store volume to fill up quickly.
Cause |
Explanation/Solution |
---|---|
You aren't cycling the data store. |
Implement the available log-management functions.
|
You are logging ubiquitous events. |
Review your file system, eDirectory, and NetWare event settings on the NCP Server object and possibly disable some often-occurring events to avoid filling up your disk subsystem too quickly. |
The data store volume is too small to accommodate your logging system traffic. |
The space you need for your database depends on a number of factors which include, but are not limited to, how many events per second you are storing and how long you want to keep the data. To determine the required volume size for your logging system, log the desired events for about an hour during your host's peak utilization. Use the consumed disk space as a basis to calculate your logging system's required volume sizes. For some general statistics on MySQL data stores, a logging system that generates around 80 events per second with an average event size of 80 bytes will consume approximately 500 MB of disk space for the database table and 150 MB for the index in a 24-hour period. |
The following table reviews the problems that might cause the host running the Platform Agent to run out of memory.
If the MySQL database returns error number 145, Cannot Open File, you might need to repair the MySQL database. See Section C.0, Using MySQL with Nsure Audit for details on accessing the MySQL documentation to perform this procedure.
If the MySQL database on Linux returns the following error message:
Can’t connect to local MySQL server through socket ’/temp/mysql.sock’ (2) 2002
Open /etc/my.cnf in a text editor and change the socket path to /tmp/mysql.sock .
If you are using Oracle, and you receive a “cannot initialize the logging subsystem” error when loading the Secure Logging Server on Linux, make sure you have correctly configured the database. For more information, see Section D.2, Preparing the Oracle Database.
During initialization, several events are sent to the Secure Logging Server by Nsure Audit. These events are not reported by platform agents, and are not intended to be logged to the datastore.
This can be confusing, as the Secure Logging Server console might show these events as having occured, but they are not logged to the data store. Only events logged your platform agents are logged to the datastore.
When troubleshooting your connection, make sure that you cause an event that will be reported by a platform agent.
If you are using Nsure Identity Manager 2 without the DR1 update, do not upgrade to Nsure Audit 1.0.3 until you have applied the DR1 update. Without the DR1 update, your Identity Manager server might be unable to log events to Nsure Audit 1.0.3.