This section lists common issues you might encounter with Novell Audit. These include:
If the Secure Logging Server does not load, check the log for any errors that occurred during startup.
NOTE:In previous versions of Novell Audit on Solaris and Linux systems, the error messages appeared on the server console.
Table 10-1 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 aborts 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 Novell Audit. For more information, see Section I.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 logging applications from authenticating with the Secure Logging Server.
Table 10-2 Problems that might prevent logging applications from authenticating with the Secure Logging Server:
Cause |
Explanation/Solution |
---|---|
The Secure Logging Server Certificate is not valid |
The Secure Logging Server uses digital certificates and Application IDs to verify the identity of all its logging applications. In fact, the Secure Logging Server only accepts connections from applications that have a valid Logging Application Certificate and Application Identifier. This ensures that unknown or spoofed entities cannot submit events to the data store. The Secure Logging Server’s certificate (the Secure Logging Certificate) is the logging system’s root certificate. Therefore, every instrumented application must have a certificate signed by the Secure Logging Server’s certificate. The Secure Logging Server and all logging applications ship with their own embedded certificates. Using these certificates, the Secure Logging Server is able to validate each logging application’s identity; however, the embedded certificates are not necessarily “secure” because the same certificates are distributed with every copy of the software. If you want to further secure your logging system, you can use certificates generated with the AudCGen utility. If logging applications are unable to authenticate with the Secure Logging Server, you might have a problem with your custom certificates. For information, see Section 9.3, Managing Certificates. |
Solaris 8 does not have GCC 3.3 and zlib 1.2.3 |
Solaris 8 requires GCC 3.3 and zlib 1.2.3 to function as a Secure Logging Server. Without GCC 3.3, applications will fail to authenticate to the logging server. The resulting error in nproduct.log will be, “Failed SSL Handshake.” |
Table 10-3 Problems that 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 are 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 |
If a single application is not logging events,
|
Table 10-4 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
|
Table 10-5 Problems that cause the 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 consumes approximately 500 MB of disk space for the database table and 150 MB for the index in a 24-hour period. |
Table 10-6 Problems that 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 Novell 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 Novell Audit. These events are not reported by platform agents, and are not intended to be logged to the data store.
This can be confusing because the Secure Logging Server console might show these events as having occurred, but they are not logged to the data store. Only events reported by your platform agents are logged to the data store.
When troubleshooting your connection, make sure that you cause an event that will be reported by a platform agent.
If you are using Novell Identity Manager 2 without the DR1 update, do not upgrade to Novell Audit 2.0 until you have applied the DR1 update. Without the DR1 update, your Identity Manager server might not be able to log events to Novell Audit 2.0.
Systems with more than one IP address have problems running Novell Audit because MDB does not know which IP address to use with eDirectory. You can point Novell Audit to a specific IP address using an MDB configuration file.
The required filename and path for the MDB configuration file is as follows:
Table 10-7 MDB Configuration File
Platform |
Directory |
---|---|
NetWare |
sys:\etc\mdb.cfg |
Windows |
\windows\mdb.cfg |
Linux |
/etc/mdb.conf |
Solaris |
/etc/mdb.conf |
To point Novell Audit to a specific IP address for eDirectory, the MDB configuration file must store the following parameter:
driver=mdbds referral=eDirectory_IP_ Address
For example,
driver=mdbds referral=192.168.123.45