The Secure Logging Server, the server component in the Novell auditing system, is implemented in the shared library, lengine. For more information on program binaries, see Section I.1, Program Files and Directories.
The Secure Logging Server manages the flow of information to and from the Novell auditing system. It receives incoming events and requests from the Platform Agents, logs information to the data store, monitors designated events, and provides filtering and notification services. It can also be configured to automatically reset critical system attributes according to a specified policy.
The Logging Server object represents the physical server where you have installed the Secure Logging Server. However, because the Logging Server object is specific to Novell Audit, it does not replace the NCP Server object. Instead, each Logging Server object is associated with a host NCP Server object.
The Secure Logging Server is configured through eDirectory. The Logging Server object is represented as a container with server attributes: it can contain Novell Audit objects and it stores all the properties and attributes for the Secure Logging Server. Consequently, the server must have access to eDirectory and the Logging Server object before it can launch the Secure Logging Server.
To minimize server reaction time and ensure high system performance, you should create a local replica of the Logging Server object and its associated objects on the logging server.
The following sections review the configuration objects and options for the Secure Logging Server:
The Windows installation program automatically creates the Logging Server object in the Logging Services container. On NetWare, Linux, and Solaris systems, the Secure Logging Server object can be created automatically in the Logging Services container during installation or it can be created manually anywhere in the tree after installation. Which option you choose depends, to a degree, on your system design.
IMPORTANT:You can create only one Secure Logging Server object for each server.
Locating the Secure Logging Server object in the Logging Services container is ideal for organizations that need a simple, easy-to-manage logging system. It also suits organizations that are implementing Novell Audit as an auditing solution and, for security reasons, want to centrally manage their systems. Using the
option, these systems are immediately operational after install.Conversely, Secure Logging Server objects can be created and managed outside the Logging Services container to facilitate distributed system administration. In fact, in distributed environments, Logging Servers and their associated objects should be created in a context assigned to their administrator. To create Logging Server objects outside of the Logging Services container, you must manually create the objects using iManager.
For information on creating objects in your respective administrative tool, see Section 3.0, Novell Audit iManager Plug-in.
The Logging Server Options task in iManager allows you to configure a specific Logging Server object in the tree. It also allows you to create Channel, Notification, and Application objects in the server’s supported containers.
NOTE:Channel, Notification, and Application containers cannot be created from the Logging Server Options task. Container objects can be created only from the Object view. For general information on creating objects from the Object view, see Creating Objects in iManager.
To configure the logging server using the Logging Server Options task:
Click the
button on the iManager toolbar.In the Roles and Tasks view, expand the
Role, then select .Specify the Logging Server object you want to modify, then click
.or
To move up or down in the tree, click the navigation arrows. You can also search the tree by typing the object name and context in the Search tab.
Modify the Logging Server object’s attributes. For a description of the Logging Server object attributes, see Logging Server Object Attributes .
IMPORTANT:If you modify attributes in multiple tabs, you must click Apply in each page to save your changes.
When finished, click
.The following table provides an explanation of the Logging Server object’s attributes.
Table 4-3 Secure Logging Server Object Attributes
Menu Option |
Description |
---|---|
|
The General page provides three submenus: Configuration, Memory, and Status. |
|
The Configuration settings allow you to specify information about the Secure Logging Server, driver directories, and encryption. |
|
The distinguished name of the NCP Server object associated with the current logging server. Click the button to select the Host Server in the tree. |
|
The port at which the Platform Agents connect to the Secure Logging Server. |
|
Indicates the Secure Logging Server can communicate over an SSL connection. If this option is selected, the Platform Agents are allowed to connect to the Secure Logging Server in SSL mode when the Secure Logging Server is configured to use SSL. You must restart the Secure Logging Server to implement this setting. |
|
The directory in which the channel drivers (lgd*) are located. The default channel driver directories are as follows:
|
|
The Channel object the logging server uses to create the central data store. Click the button to select the Channel object in the tree.WARNING:The JDBC and Java channels do not work on NetWare 5.x. These channels require JVM* 1.4.2 which is not compatible with NetWare 5.x. Attempting to run either the JDBC or Java channel on NetWare 5.x abends the server. |
|
The path and filename for the Logging Server Certificate. This attribute enables the logging server to use an SSL certificate. If this field is left blank, the logging server uses the default embedded certificate. Novell Audit uses certificates to authenticate client connections. The logging server accepts connections only from applications that have a valid Logging Application Certificate. For general information on how certificates are used in Novell Audit, see Section 9.0, Security and Non-Repudiation. |
|
The path and filename for the Secure Logging Certificate’s private key file. If this field is left blank, the logging server assumes the private key is included with the certificate and uses the path and filename for the Secure Logging Certificate. Again, this is only required if you do not use the Novell Audit program’s embedded certificates. IMPORTANT:Novell Audit only recognizes certificates and private keys that are generated with the AudCGen utility. For more information, see Creating a Root Certificate for the Secure Logging Server. |
|
The signature setting for Platform Agent events. If this option is selected, the Platform Agent always logs events with a digital signature and to sequentially chain events. This option provides a convenient way to centrally manage Platform Agents from the Secure Logging Server. IMPORTANT:This option is implemented only if the LogSigned setting in the Platform Agent’s logevent.cfg file is set to Server. For more information on the logevent.cfg file, see Section 4.1.2, Logevent, |
|
The Platform Agent debug setting. If this option is selected, the Platform Agent always logs debug events. This option provides a convenient way to centrally manage Platform Agents from the Secure Logging Server. IMPORTANT:This option is implemented only if the LogDebug setting in the Platform Agent’s logevent.cfg file is set to Server. For more information on the logevent.cfg file, see Section 4.1.2, Logevent, |
|
The memory configuration settings allow you to optimize your logging server’s performance. You should adjust these settings based on logging traffic and the amount of memory available to your system. Reasonable values depend on your network. In organizations that require high-performance logging, these parameters should be set high enough to accommodate peak loads. For organizations that must minimize potential data loss, these settings should be very small. Although this can slow performance, it minimizes the amount of data that might be lost in the event of server failure. If incoming log events exceed the amount of memory you have allocated on your logging server, the Platform Agents temporarily write events to their Disconnected Mode Caches until the logging server clears its cache. This prevents any logged events from being lost. |
|
The amount of memory the server automatically allocates at boot time to handle logging processes. Because allocating additional memory on the fly can slow down code execution, this setting should represent the minimum amount of memory needed to handle your system’s baseline level of logging traffic. Pre-allocating the minimum amount of memory required by your system reduces additional blocking delays when the system is under high load and facilitates faster processing of incoming events. |
|
The amount of memory the server can immediately allocate if logging traffic exceeds the Minimum memory setting. |
|
The maximum amount of memory that can be allocated to logging processes. Setting a maximum prevents Novell Audit from monopolizing the server’s resources. Ideally, this should be set close to the Normal memory setting. If logging traffic exceeds the Normal memory setting, the server incrementally increases the logging cache 4 KB at a time. (4 KB is the amount of memory required to process a single event.) When the Maximum memory allocation is reached, the server begins dropping Platform Agent connections. If the logging server drops its connection, the Platform Agent simply logs events to its Disconnected Mode Cache, thereby ensuring no information is lost. When free cache is available, the logging server once again accepts Platform Agent connections. |
|
This option allows you to enable or disable the Secure Logging Server. By default, the logging server is enabled. If you select the option, you must either restart the server or manually unload the Secure Logging Server for the setting to become effective. Thereafter, the server cannot launch the Secure Logging Server (lengine) until you select .For information on unloading the logging server, see Section H.3, Secure Logging Server Startup Commands. |
|
The Channels page allows you to add or remove the Channel containers supported by the current Logging Server object. It also allows you to view, create, modify, and delete Channel objects within supported Channel containers. IMPORTANT:The logging server scans Channel containers and objects only at startup. Therefore, if you add, remove, or modify a Channel container or object, you must restart the logging server for the change to take effect. For more information, see Section H.3, Secure Logging Server Startup Commands. For more information on Channel objects, see Section 6.0, Configuring System Channels. WARNING:The JDBC and Java channels do not work on NetWare 5.x. These channels require JVM 1.4.2, which is not compatible with NetWare 5.x. Attempting to run either the JDBC or Java channel on NetWare 5.x abends the server. |
|
Adds an existing Channel container to the logging server’s list of supported containers. Adding a container means that the logging server scans that container for Channel objects at startup. The Channel container in Logging Services is added to this list by default. Channel containers cannot be created from the Logging Server Options task. Container objects can only be created from the Object view. For general information on creating objects from the Object view, see Creating Objects in iManager. To add a Channel container to the logging server’s list of supported Channel containers:
To move up or down in the tree, click the navigation arrows. You can also search the tree by specifying the object name and context in the Search tab. |
|
Removes the selected Channel container from the logging server’s list of supported containers. Removing a container means that the logging server no longer scans that container for Channel objects at startup. Removing a Channel container from the list does not delete the container or any of its associated objects. To remove a Channel container from the logging server’s list of supported Channel containers:
|
|
Creates a new Channel object in the selected container.
The new Channel object now appears under the designated Channel container. |
|
Allows you to modify the selected Channel object’s configuration. To define or modify a Channel object’s attributes:
|
|
Deletes the selected Channel object. Deleting a Channel object completely removes the object from the system.
|
|
Renames the selected Channel object.
|
|
The Notifications page allows you to add or remove the Notification containers supported by the current Logging Server object. It also allows you to view, create, modify, and delete Notification objects within supported Notification containers. IMPORTANT:The logging server scans only Notification containers and objects at startup. Therefore, if you add, remove, or modify a Notification container or object, you must restart the logging server for the change to take effect. For more information, see Section H.3, Secure Logging Server Startup Commands. For more information on Notification objects, see Section 7.0, Configuring Filters and Event Notifications. |
|
Adds an existing Notification container to the logging server’s list of supported containers. Adding a container means that the logging server scans that container for Notification objects at startup. The Notification container in Logging Services is added to this list by default. Notification containers cannot be created from the Logging Server Options task. Container objects can only be created from the Object view. For general information on creating objects from the Object view, see Creating Objects in iManager. To add a Notification container to the logging server’s list of supported Notification containers:
To move up or down in the tree, click the navigation arrows. You can also search the tree by specifying the object name and context in the Search tab. |
|
Removes the selected Notification container from the logging server’s list of supported containers. Removing a container means that the logging server no longer scans that container for Notification objects at startup. Removing a Notification container from the list does not delete the container or any of its associated objects. To remove an Application container from the logging server’s list of supported Application containers:
|
|
Creates a new Notification object in the selected container.
The new Notification object now appears under the designated Notification container. For more information on Notification objects, see Section 7.0, Configuring Filters and Event Notifications. |
|
Allows you to modify the selected Notification object’s configuration. To define or modify a Notification object’s attributes:
For detailed information on Notification object attributes, see Section 7.3, Notification Filters and Section 7.4, Heartbeat Objects . |
|
Deletes the selected Notification object. Deleting a Notification object completely removes the object from the system.
|
|
Renames the selected Notification object.
|
|
The Log Applications page allows you to add or remove the Application containers supported by the current Logging Server object. It also allows you to view, create, modify, and delete Application objects within supported Application containers. IMPORTANT:The logging server scans application containers and objects only at startup. Therefore, if you add, remove, or modify an Application container or object, you must restart the logging server for the change to take effect. For more information, see Section H.3, Secure Logging Server Startup Commands. For more information on Application objects, see Section 5.0, Managing Applications that Log to Novell Audit. |
|
Adds an existing Application container to the logging server’s list of supported containers. Adding a container means that the logging server scans that container for Application objects at startup. The Application container in Logging Services is added to this list by default. Application containers cannot be created from the Logging Server Options task. Container objects can only be created from the Object view. For general information on creating objects from the Object view, see Creating Objects in iManager. To add an Application container to the logging server’s list of supported Application containers:
To move up or down in the tree, click the navigation arrows. You can also search the tree by specifying the object name and context in the Search tab. |
|
Removes the selected Application container from the logging server’s list of supported containers. Removing a container means that the logging server no longer scans that container for Application objects at startup. Removing an Application container from the list does not delete the container or any of its associated objects. To remove an Application container from the logging server’s list of supported Application containers:
|
|
Creates a new Application object in the selected container. Application objects are automatically created when Novell Audit-enabled applications are installed into your tree; however, if necessary, Application objects can also be manually added to the tree.
The new Application object now appears under the designated Application container. |
|
Allows you to modify the selected Application object’s configuration. To define or modify an Application object’s attributes:
For information on the Application object’s attributes, see Section 5.3, Application Object Attributes. |
|
Deletes the selected Application object. Deleting an Application object completely removes the object from the system.
|
|
Renames the selected Application object.
|
|
The Monitor page provides real-time statistics on the number of events processed by the current logging server. For specific information, see Section 4.2.4, Logging Server Statistics. The Monitor page provides two statistics pages: Server and System. |
|
Opens the Server statistics page. The Server page lists the total number of events logged over the current server uptime and the average number of events logged per second. For specific information, see Server Statistics. NOTE:The number of events logged per second is averaged over a three second interval. |
|
Opens the System statistics page. The System page lists the IP addresses and descriptions of the clients (Platform Agents) currently logging events to the logging server, the number of applications logging events to each agent, and the total number of events logged by each agent. These statistics reflect events logged over the life of the server, not the server uptime. For specific information, see System Statistics. |
The Monitor page in the Logging Server object provides real-time statistics on the number of events processed by the current logging server. The Monitor page provides two levels of statistics: Server and System.
IMPORTANT:The Monitor channel must be enabled to provide statistics in the Monitor page. For more information, see Section 6.10, Monitor.
The following sections review the Server and System statistics.
The Server page lists the total number of events logged over the current server uptime and the average number of events logged per second.
NOTE:The number of events logged per second is averaged over a three-second interval.
To view the Server statistics:
Click the
button on the iManager toolbar.In the Roles and Tasks view, expand the
Role, then select .Specify the Logging Server object you want to modify, then click
.To move up or down in the tree, click the navigation arrows. You can also search the tree by specifying the object name and context in the Search tab.
iManager only links valid entries.
Click the
tab.The Server page displays.
The following table provides a description of the options and statistics provided on the Server page.
Table 4-4 Server Page Options and Statistics
Option/Statistic |
Description |
---|---|
|
The Refresh option sets the refresh interval for the Server page statistics. To set the refresh interval:
|
|
The Events category provides statistics on events processed over the server uptime. If the logging server is rebooted, the statistics are reset to zero. |
|
The total number of events received by the logging server over the current server uptime. |
|
The total number of events currently waiting to be written to the data store. Depending on its cache settings, the logging server can handle more than 30,000 events per second. If logging traffic exceeds the capabilities of the logging server, or if the logging server is unable to write events to the database, the events are queued until they can be written to the data store. |
|
The total number of events written to the data store over the current server uptime. |
|
The total number of events processed by notification filters. |
|
The number of events that are being monitors by logging applications. For more information about monitoring events, see the Novell Audit SDK |
|
The Counters category lists the number of drivers, channels, and Platform Agent connections active on the logging server. |
|
The number of Platform Agents currently connected to the logging server. |
|
The number of channel drivers currently running on the logging server. |
|
The number of Channel objects currently enabled on the logging server. |
|
The Memory category provides a snapshot of the logging server’s allocated and available memory. |
|
The amount of memory currently allocated to handle logging processes. For more information, see the Memory Allocation Settings in Logging Server Object Attributes . |
|
The maximum amount of memory that can be allocated to handle logging processes. |
|
The number of days, hours, minutes, and seconds in which the Secure Logging Server has been consecutively running. |
The System pages provide information and statistics that reflect events logged over the life of the server; not the server uptime.
To view the System statistics:
Click the
button on the iManager toolbar.In the Roles and Tasks view, expand the
Role, then select .Specify the Logging Server object you want to modify, then click
.To move up or down in the tree, click the navigation arrows. You can also search the tree by specifying the object name and context in the Search tab.
iManager only links valid entries.
Click the
tab, then click .There are three levels of information provided in the System pages:
The following sections provide descriptions of each System statistics page.
The System page displays when you click the
link in the Monitor page. It lists the IP addresses and descriptions of the Platform Agents currently logging events to the current Secure Logging Server.Figure 4-1 System Page
The following table provides a description of the options and statistics provided on the System page:
Table 4-5 System Page Options and Statistics
The Applications page lists the logging applications and instrumentations currently logging events to a given Platform Agent. To view the Applications page, click the IP address for one of the Platform Agents listed in the System page.
Figure 4-2 Applications Page
The following table provides a description of the options and statistics provided on the Applications page:
Table 4-6 Applications Page Options and Statistics
Option/Statistic |
Description |
---|---|
|
Removes the statistics for the currently selected logging application from the Applications page. |
|
The Refresh option sets the refresh interval for the Applications page statistics. To set the refresh interval:
|
|
The logging application’s Application Identifier; that is, the name the logging application uses to identify itself to the logging server. For more information, see Section 5.3, Application Object Attributes. |
|
The Application ID; that is, the four-digit hex value assigned to the current application. For more information, see Section 5.3, Application Object Attributes. |
|
The number of events logged by the logging application over the life of the current logging server. |
|
The logging application status. An enabled status indicates the logging application is currently logging events to the Platform Agent. A disabled status indicates the logging application cannot log events to the Platform Agent. The logging application’s status is managed in the Application object. For more information, see Section 5.3, Application Object Attributes |
|
The time and date the logging application was loaded and started logging events to the Platform Agent. |
The Events page lists the specific events that have been logged for a given logging application. To view the Events page, click one of the logging applications listed in the Applications page.
Figure 4-3 Events Page
The following table provides a description of the options and statistics provided on the Events page:
Table 4-7 Events Page Options and Statistics
Option/Statistic |
Description |
---|---|
|
Resets the count for a given event.
|
|
Removes an event from the logging application’s list of logged events. If the event occurs again, it is relisted in the events list. However, the event count is reset to 1. |
|
Allows you to define a query for the selected events.
|
|
Sets the refresh interval for the Events page statistics.
|
|
The name of the event. This information is read from the logging applications log schema file (*.lsc). For more information, see Section A.4, Log Schema Files. |
|
The severity level assigned to the event. This information is read from the logging applications log schema file (*.lsc). For more information, see Section A.4, Log Schema Files. |
|
The number of times the event has been logged since the logging application was loaded and started logging events to the Platform Agent. |
|
The most recent occurrence of the event. |
|
The date and time the count for a given event was reset. |
By default, the installation program creates the Secure Logging Server in the Logging Services container. The logging server then reads its channel and notification configuration information from the Channels.Logging Services and Notifications.Logging Services containers and loads the channels and notifications located within these containers.
If you want to provide system redundancy or load balancing in your logging system, you can create multiple Secure Logging Server objects for servers on the same platform in the default Logging Services container. In this way, all the logging servers load the same channels and send data to the same database.
However, if you want to log data to different databases (such as in a WAN environment); load different channels and notifications on each logging server; if you have an extremely large eDirectory tree; or if you are running Novell Audit Secure Logging servers on multiple platforms, we recommend that you create separate eDirectory organizational units as containers for each Secure Logging Server’s configuration object.
If you want a combination of both configurations—for example, you want to provide system redundancy or load balancing in a WAN environment—you can create multiple eDirectory organizational units with multiple Secure Logging Server objects.
The following sections review how to implement multiple Secure Logging Servers in your logging system based on whether you want to locate the Secure Logging Server objects in the same container, different containers, or a combination of both:
IMPORTANT:Creating multiple Novell Audit Secure Logging Server objects in a single eDirectory container works best if the objects are use the same platform. If you create multiple Novell Audit Secure Logging Server objects from different platforms in the same container, it can mix the servers’ configuration information. If you are running Novell Audit Secure Logging servers on multiple platforms, we recommend that you create separate eDirectory organizational units as containers for each Secure Logging Server’s configuration objects. For more information, see Creating Secure Logging Server Objects in Different eDirectory Containers.
To provide redundancy in your logging system:
Create multiple Secure Logging Server objects in the default Logging Services container so that all the logging servers load the same channels and send data to the same database.
Configure the Platform Agents to shut down and start logging to another log server if the Secure Logging Server goes down.
To configure the Platform Agents to connect to multiple logging servers in a failover manner:
Add the IP address of each failover logging server to the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file.
List the logging servers in the order you want to use them in the event of a failover.
The Platform Agents connect to the servers in the order specified in the configuration file. Therefore, if the first logging server goes down, the Platform Agent tries to connect to the second logging server, and so on.
Separate each IP address in the LogHost entry with commas. For example, LogHost=192.168.0.1,192.168.0.3,192.168.0.4.
For a failover configuration, you might also consider running the database server on a server separate from the logging servers.
The logevent configuration files can also be modified for load balancing. A Novell Audit logging server can log approximately about 5,000 events per second on a P4 Xeon class server to a MySQL database; however, the database is capable of processing much more data than that. If you run multiple logging servers with the same configuration from the same eDirectory container, all logging servers log to the same location and process the same notification list. As a group, the logging servers can then log much more data to the data store.
To configure load balancing:
Modify the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file for each Platform Agent so that it logs to a different Secure Logging Server.
For example, one Platform Agent sends data to 192.168.0.1, while another Platform Agent sends data to 192.168.0.3. In this way, you can maximize the number of events that can be logged to your data store.
Creating separate eDirectory organizational units as containers for each Secure Logging Server’s configuration objects is an effective option under the following circumstances:
The following sections review how to configure multiple Secure Logging Servers in different eDirectory containers.
The ability to create organizational units is not a function of the Novell Audit install utility. It must be done with iManager or another eDirectory management utility.
The following steps outline the process required to separate the Novell Audit containers.
IMPORTANT:This procedure assumes that you installed Novell Audit with the default containers.
Within iManager, create a new organizational unit for Novell Audit objects (such as NAudit or Logging Services).
(Optional) If you are running Secure Logging Servers on multiple platforms, create organizational units for each platform——that is, NetWare, Windows, Linux, and Solaris— under the Naudit or Logging Services container.
Verify that eDirectory is healthy by checking replica synchronization.
For more information, see TID10060600, NDS / eDirectory Health Check Procedures - Cross Platform.
Use iManager's
task to create partitions for all subcontainers and objects under the default Logging Services container—that is Channel, Application, Notification, and Logging Server objects—in preparation to move these objects.Use iManager's Step 2.
task to move the Channel, Application, Notification, and Logging Server objects to the new organizational unit created inUse iManager's
task to merge the partitions for the Channel, Application, Notification, and Logging Server objects back into the parent partition.Use iManager's
tasks to add the Logging Server object as a Trustee of its parent organizational unit.If you are running Secure Logging Servers on multiple platforms, the parent organizational unit is the associated platform container (NetWare, Windows, Linux, or Solaris).
Each Secure Logging Server object needs Read and Compare attribute rights and Compare entry rights for its parent container and contents.
To verify that Audit is functioning correctly, unload lengine at the server, then reload it.
Remove the default Logging Services container at the root to prepare for the next Secure Logging Server installation.
After you remove the default Logging Services container, the tree is ready for you to install the next Secure Logging Server.
When the installation programs asks, Use
Default Container? Y
during subsequent Secure Logging Server
installations, choose N and select the organizational unit you created
in Step 2.
To configure a logging server to use a custom channel container:
Click the
button on the iManager toolbar.In the Roles and Tasks view, click
> > .On the Create Novell Audit Channel Container page, specify a channel name and context, then click
.For the context, browse to and select the appropriate Logging Server object in the tree.
In Roles and Tasks, click
> , browse to and select the Logging Server object, then click .Click the
tab or select from the drop-down menu, depending on your browser.Click
> .On the Object Selector page, browse to the new container you created in the logging server container.
To remove the original Channels container from the logging server configuration, go to the Channels page, select the
check box, then click > .Repeat this process for each logging server.
To configure a logging server to use a custom notification container:
In iManager, click
> > > .On the Create Novell Audit Notification Container page, specify a notification name and context, then click
.For the context, browse to and select the appropriate Logging Server object in the tree.
In Roles and Tasks, click
> ; browse to and select the Logging Server object, then click .Click the
tab or select from the drop-down menu, depending on your browser.Click
> .On the Object Selector page, browse to and select the new container created in the logging server container.
To remove the original Notifications container from the logging server configuration, select the
check box in the Notifications page, then click > .Repeat this process for each logging server.
If you want to provide system redundancy or load balancing in a large eDirectory tree or a WAN environment, you must configure multiple Secure Logging Server objects in multiple eDirectory containers.
The following steps outline the general process required to implement this configuration:
Identify the Secure Logging Servers that should load the same channels and send data to the same location.
Create a custom Channels container in the default Logging Services container for each server group.
For information on creating a custom Channels containers, see Creating Multiple Containers for Audit Configuration Objects.
Add the Secure Logging Server objects in each server group to the Trustees List for their associated Channels container.
Each Secure Logging Server object needs Read and Compare attribute rights and Compare entry rights for the Channels container and its contents.
Configure each Secure Logging Server object’s channel configuration so it references the server’s associated Channel container.
Remove the original Channels.Logging Services container object from each Secure Logging Server object’s channel configuration.
Configure the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file for each Platform Agent so that it logs events to a specific server group.
To configure the Platform Agents to connect to multiple logging servers in a failover manner:
The Platform Agents connect to the servers in the order specified in the configuration file. Therefore, if the first logging server goes down, the Platform Agent tries to connect to the second logging server, and so on.
To configure load balancing:
For example, one Platform Agent sends data to 192.168.0.1, while another Platform Agent sends data to 192.168.0.3. In this way, you can maximize the number of events that can be logged to each server group’s data store.
Secure Logging Servers 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 4-8 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.