10.1 Common Issues

This section lists common issues you might encounter with Novell Audit. These include:

10.1.1 Secure Logging Server Does Not Load

If the Secure Logging Server does not load, check the log for any errors that occurred during startup.

  • On NetWare®, check the console log (5.x) or logger screen (6.x) for any errors during load.
  • On Windows, check the drive:\nproduct.log file for any errors that were logged during startup.
  • On Linux, check the nproduct.log file in the /var/opt/novell/naudit/ directory for any errors during load.
  • On Solaris, check the nproduct.log file in the /opt/NOVLnaudit/ directory for any errors during load.

    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

  • Ensure that eDirectory™ is working properly on the host.
  • Configure the host to run the Secure Logging Server.

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

  • Check your Secure Logging Server configuration and adjust the cache settings accordingly.
  • Unload unneeded modules loaded during startup.

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.

10.1.2 Applications are Failing to Authenticate to the Secure Logging Server

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.”

10.1.3 Events Are Not Being Logged

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

  • On the Platform Agent, verify that the LogHost specified in the logevent file points to the intended server. For information on configuring the Platform Agent’s LogHost parameter, see Logevent.
  • Verify that the computer where the platform agent is running can actually reach the loghost via TCP/IP. (A ping will quickly tell.)
  • If the logging application logs only debug level events, check whether the LogDebug option is set to Never, in which case the Platform Agent does not send debug level events to the server. For information on configuring the Platform Agent’s LogDebug parameter, see Logevent.
  • If the logging application and Secure Logging Server are using custom certificates, make sure that the Logging Application Certificate has been signed with the Secure Logging Certificate. For more information, see Section 9.0, Security and Non-Repudiation.

A component is misconfigured

If a single application is not logging events,

  • Make sure that the application has an Application object in one of the Secure Logging Server’s supported Application containers. For more information on Application objects, see Section 5.0, Managing Applications that Log to Novell Audit.
  • Verify that the Application Identifier property in the Application object matches the Application Identifier stored in the logging application’s certificate. For information on Application Identifiers, see Section 5.3, Application Object Attributes.
  • If you recently created an Application object, you must restart the logging server to load the Application object’s configuration. For information on restarting the logging server, see Section H.3, Secure Logging Server Startup Commands.
  • Make sure that the Application container where your Application object is located is included in the logging server’s list of supported Application containers. For information on the logging server’s Application Container property, see Logging Server Object Attributes .

10.1.4 Notifications Are Not Being Executed

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

  • Make sure that the Notification container where your Notification Filter object is located is included in the logging server’s list of supported Notification containers. For information on the logging server’s Notification Container property, see Logging Server Object Attributes .
  • Ensure that the Notification object has a notification channel. For more information on the Notification Channels property, see Section 7.3, Notification Filters.
  • Check the console or the startup log to determine if the driver for the notification channel is being loaded.
  • Verify that the Notification Filter is configured to select the events you want to trigger the notification.

10.1.5 Volume Quickly Runs Out of Disk Space

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.

10.1.6 The Host Running the Platform Agent is Running Out of Memory

Table 10-6 Problems that cause the host running the Platform Agent to run out of memory:

Cause

Explanation/Solution

The Disconnected Mode Cache has run out of disk space.

When the Secure Logging Server is not available, the Platform Agent’s Logging Cache module writes incoming events to the Disconnected Mode Cache on disk. If the Disconnected Mode Cache runs out of disk space, the Logging Cache module falls back to memory.

The Disconnected Mode Cache and data store are on the same volume.

If you are running the eDirectory Instrumentation or the NetWare Instrumentation on the same host as the Secure Logging Server, you should ensure that the Platform Agent’s Disconnected Mode Cache and the Secure Logging Server’s data store are not on the same volume.

Otherwise, if the volume fills up, you will have a total logging failure. The Platform Agent has no room for the Disconnected Mode Cache and the Secure Logging Server has no place to log events.

10.1.7 Novell Audit MySQL Returns a Cannot Open File Error

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.

10.1.8 MySQL on Linux Returns a Socket Connection Error

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 .

10.1.9 Oracle on Linux Causes a Cannot Initialize the Logging Subsystem Error

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.

10.1.10 Novell Audit Events Sent During Initialization are Not Logged to the Data Store

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.

10.1.11 Novell Identity Manager 2 DR1 Update required to Use Novell Audit 2.0

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.

10.1.12 Running Novell Audit on Servers with More Than One IP Address

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