<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>opt bluelance &#8211; Blue Lance</title>
	<atom:link href="https://bluelance.com/docs-tag/opt-bluelance/feed/" rel="self" type="application/rss+xml" />
	<link>https://bluelance.com</link>
	<description></description>
	<lastBuildDate>Mon, 01 Jun 2026 19:30:58 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0</generator>

<image>
	<url>https://bluelance.com/wp-content/uploads/2025/11/fevicon-ic-1.png</url>
	<title>opt bluelance &#8211; Blue Lance</title>
	<link>https://bluelance.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Managing the NSS Audit Service</title>
		<link>https://bluelance.com/docs/managing-the-nss-audit-service/</link>
		
		<dc:creator><![CDATA[peter thomas]]></dc:creator>
		<pubDate>Thu, 28 May 2026 16:24:19 +0000</pubDate>
				<guid isPermaLink="false">https://bluelance.com/?post_type=docs&#038;p=15918</guid>

					<description><![CDATA[Once the NSS Audit Agent is installed and configured on an OES server, day-to-day management of the ltaudit service is straightforward. This article covers how to start, stop, restart, and check the status of the NSS Audit Agent service using both systemctl and the built-in control script, and when to use each management action. Understanding [&#8230;]]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">Once the NSS Audit Agent is installed and configured on an OES server, day-to-day management of the ltaudit service is straightforward. This article covers how to start, stop, restart, and check the status of the NSS Audit Agent service using both systemctl and the built-in control script, and when to use each management action.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Understanding the ltaudit service:</strong></p>



<p class="wp-block-paragraph">The ltaudit service is the NSS Audit Agent daemon that runs continuously on each OES server, collecting NSS file activity and forwarding it to the LT Auditor <sup>MP</sup> server via syslog. It is registered with systemd during installation and can be managed using standard systemctl commands or the agent&#8217;s built-in control script located at /opt/bluelance/bin/ltaudit.rc.</p>



<p class="wp-block-paragraph">Both management methods produce the same result — use whichever is more familiar or appropriate for your environment.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>When you need to manage the service:</strong></p>



<figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><td><strong>Situation</strong></td><td><strong>Action Required</strong></td></tr><tr><td>Agent not forwarding events to LT Auditor <sup>MP</sup></td><td>Check status, restart if stopped</td></tr><tr><td>Configuration changes made via update_syslog_config.sh</td><td>Restart to apply new settings</td></tr><tr><td>OES server maintenance or reboot</td><td>Stop before maintenance, confirm restart after</td></tr><tr><td>Agent upgrade or package update</td><td>Stop before upgrade, start after</td></tr><tr><td>Troubleshooting forwarding or connectivity issues</td><td>Stop and restart to reset connections</td></tr><tr><td>Confirming agent is healthy after a server reboot</td><td>Check status</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Checking service status:</strong></p>



<p class="wp-block-paragraph">Always check the service status first before taking any other management action — it tells you whether the service is running, stopped, or in an error state.</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph">systemctl status ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc status</p>



<p class="wp-block-paragraph"><strong>Interpreting the status output:</strong></p>



<figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><td><strong>Status</strong></td><td><strong>Description</strong></td><td><strong>Action Required</strong></td></tr><tr><td>active (running)</td><td>Service is running normally</td><td>None</td></tr><tr><td>inactive (dead)</td><td>Service is stopped</td><td>Start the service</td></tr><tr><td>failed</td><td>Service encountered an error and stopped</td><td>Review logs and restart</td></tr><tr><td>activating</td><td>Service is in the process of starting</td><td>Wait and check again</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Starting the service:</strong></p>



<p class="wp-block-paragraph">If the service is stopped and needs to be started:</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph">systemctl start ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc start</p>



<p class="wp-block-paragraph">After starting, confirm the service is running:</p>



<p class="wp-block-paragraph">systemctl status ltaudit.service</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Stopping the service:</strong></p>



<p class="wp-block-paragraph">If the service needs to be stopped for maintenance, configuration changes, or troubleshooting:</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph">systemctl stop ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc stop</p>



<p class="wp-block-paragraph">Stopping the service suspends NSS file activity collection on that server. Any events that occur while the service is stopped will not be captured. Stop the service only when necessary and restart it as soon as possible to minimize monitoring gaps.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Restarting the service:</strong></p>



<p class="wp-block-paragraph">Restart the service to apply configuration changes or reset connections to the LT Auditor <sup>MP</sup> server:</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph">systemctl restart ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc stop</p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc start</p>



<p class="wp-block-paragraph">After restarting, confirm the service returns to an active (running) state:</p>



<p class="wp-block-paragraph">systemctl status ltaudit.service</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Enabling automatic startup on boot:</strong></p>



<p class="wp-block-paragraph">To ensure the ltaudit service starts automatically when the OES server reboots, enable it with systemctl:</p>



<p class="wp-block-paragraph">systemctl enable ltaudit.service</p>



<p class="wp-block-paragraph">Confirm the service is enabled:</p>



<p class="wp-block-paragraph">systemctl is-enabled ltaudit.service</p>



<p class="wp-block-paragraph">The output should return enabled. If it returns disabled, run the enable command again.</p>



<p class="wp-block-paragraph">Enabling automatic startup is strongly recommended for all production OES servers. Without it, NSS audit collection will not resume after a server reboot until an administrator manually starts the service — potentially leaving a significant monitoring gap.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Disabling automatic startup on boot:</strong></p>



<p class="wp-block-paragraph">If automatic startup needs to be disabled (e.g., for a server being decommissioned):</p>



<p class="wp-block-paragraph">systemctl disable ltaudit.service</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Reviewing service logs:</strong></p>



<p class="wp-block-paragraph">If the service fails to start or is behaving unexpectedly, review the agent logs for error details:</p>



<p class="wp-block-paragraph"><strong>General application logs:</strong></p>



<p class="wp-block-paragraph">ls /opt/bluelance/logs/</p>



<p class="wp-block-paragraph"><strong>NSS audit status log:</strong></p>



<p class="wp-block-paragraph">cat /opt/bluelance/log/nssstatus.log</p>



<p class="wp-block-paragraph"><strong>Syslog forwarding log:</strong></p>



<p class="wp-block-paragraph">cat /opt/bluelance/log/syslog_send.log</p>



<p class="wp-block-paragraph"><strong>systemd journal (for service startup errors):</strong></p>



<p class="wp-block-paragraph">journalctl -u ltaudit.service -n 50</p>



<p class="wp-block-paragraph">The -n 50 flag returns the last 50 log entries. Increase this number if you need to look further back.</p>



<p class="wp-block-paragraph">Common errors to look for:</p>



<ul class="wp-block-list">
<li>Connection refused — firewall blocking syslog port</li>



<li>Certificate errors — TLS configuration issue</li>



<li>Permission denied — agent lacks required access to NSS volumes</li>



<li>Failed to open live vigil file — NSS audit subsystem not available</li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Service management after a configuration change:</strong></p>



<p class="wp-block-paragraph">Whenever the syslog forwarding configuration is updated using update_syslog_config.sh, restart the service to apply the new settings:</p>



<p class="wp-block-paragraph">systemctl restart ltaudit.service</p>



<p class="wp-block-paragraph">Confirm the service is running after the restart, then verify that events are appearing in LT Auditor <sup>MP</sup> to confirm the new configuration is working correctly.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Best practices:</strong></p>



<ul class="wp-block-list">
<li>Always check the service status before investigating log collection issues — a stopped service is the most common cause of missing NSS audit data</li>



<li>Enable automatic startup on boot on every production OES server to prevent monitoring gaps after reboots</li>



<li>Restart rather than stop-and-start when applying configuration changes — it is faster and reduces the monitoring gap</li>



<li>Review the nssstatus.log and syslog_send.log as the first step when troubleshooting collection or forwarding issues</li>



<li>Include systemctl status ltaudit.service in your regular OES server health check routine alongside other service checks</li>



<li>Document any planned service interruptions (maintenance windows, upgrades) so the security team is aware of expected monitoring gaps</li>
</ul>



<p class="wp-block-paragraph"><em>[Your administrator should include </em><em>ltaudit</em><em> service status in any OES server monitoring dashboards or health check scripts used in your environment.]</em></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Installing &#038; Configuring the NSS Audit Agent (OES Servers)</title>
		<link>https://bluelance.com/docs/installing-configuring-the-nss-audit-agent-oes-servers/</link>
		
		<dc:creator><![CDATA[peter thomas]]></dc:creator>
		<pubDate>Thu, 28 May 2026 16:23:33 +0000</pubDate>
				<guid isPermaLink="false">https://bluelance.com/?post_type=docs&#038;p=15916</guid>

					<description><![CDATA[NSS file activity auditing requires a dedicated agent installed on every SLES OES server that hosts NSS volumes you want to monitor. The NSS Audit Agent collects file system activity from NSS volumes and forwards it to the LT Auditor MP server via syslog on port 5015 (or your configured port). This article covers the [&#8230;]]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">NSS file activity auditing requires a dedicated agent installed on every SLES OES server that hosts NSS volumes you want to monitor. The NSS Audit Agent collects file system activity from NSS volumes and forwards it to the LT Auditor <sup>MP</sup> server via syslog on port 5015 (or your configured port). This article covers the complete installation and configuration process for the NSS Audit Agent.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Understanding the NSS Audit Agent:</strong></p>



<p class="wp-block-paragraph">Unlike eDirectory auditing which is configured directly within eDirectory itself, NSS file activity auditing requires a separate agent component — the LT Auditor <sup>MP</sup> OES module — to be installed on each OES server hosting NSS volumes. The agent:</p>



<ul class="wp-block-list">
<li>Monitors file system activity on NSS volumes in real time</li>



<li>Captures file reads, writes, deletions, renames, and permission changes</li>



<li>Forwards collected activity to LT Auditor <sup>MP</sup> via syslog</li>



<li>Caches audit streams locally if the LT Auditor <sup>MP</sup> server is temporarily unavailable and automatically resends once connectivity is restored — no audit data is lost during outages</li>
</ul>



<p class="wp-block-paragraph">The agent must be installed individually on each OES server you want to monitor. Missing even one server results in a gap in your NSS file activity audit data.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Prerequisites:</strong></p>



<p class="wp-block-paragraph">Before installing the NSS Audit Agent, confirm the following on each target OES server:</p>



<figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><td><strong>Requirement</strong></td><td><strong>Details</strong></td></tr><tr><td>Operating System</td><td>SLES OES Linux</td></tr><tr><td>Privileges</td><td>Root access required</td></tr><tr><td>NSS Volumes</td><td>At least one NSS volume must be present on the server</td></tr><tr><td>Network Access</td><td>Outbound syslog traffic to the LT Auditor <sup>MP</sup> server on port 5015 must be permitted</td></tr><tr><td>LT Auditor <sup>MP</sup></td><td>Server must be installed and running with the NSS transformation rule configured on port 5015</td></tr><tr><td>Agent Package</td><td>LTAuditorMP-OES-xx.x.x.x-x.x86_64.rpm — obtain from your administrator or Blue Lance</td></tr></tbody></table></figure>



<p class="wp-block-paragraph"><em>[Your administrator should confirm the current version of the agent package and where to obtain it for your environment.]</em></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 1 — Copy the agent package to the OES server:</strong></p>



<p class="wp-block-paragraph">Copy the agent RPM package to the target OES server. The package filename follows the format:</p>



<p class="wp-block-paragraph">LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm</p>



<p class="wp-block-paragraph"><em>[Your administrator should note the current package filename and version used in your environment here.]</em></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 2 — Switch to root:</strong></p>



<p class="wp-block-paragraph">Open a terminal on the OES server and switch to root:</p>



<p class="wp-block-paragraph">su</p>



<p class="wp-block-paragraph">Enter the root password when prompted.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 3 — Install the agent package:</strong></p>



<p class="wp-block-paragraph">Install the RPM package using the following command:</p>



<p class="wp-block-paragraph">rpm -ivh LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm</p>



<p class="wp-block-paragraph">The agent installs to:</p>



<p class="wp-block-paragraph">/opt/bluelance/</p>



<p class="wp-block-paragraph">The installation process:</p>



<ul class="wp-block-list">
<li>Installs the agent binaries and configuration files to /opt/bluelance/</li>



<li>Registers the ltaudit service with systemd</li>



<li>Does not start the service automatically — configuration must be completed first</li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 4 — Configure syslog forwarding:</strong></p>



<p class="wp-block-paragraph">Navigate to the agent bin directory and run the configuration script:</p>



<p class="wp-block-paragraph">cd /opt/bluelance/bin</p>



<p class="wp-block-paragraph">./update_syslog_config.sh</p>



<p class="wp-block-paragraph">The script will prompt you for the following information:</p>



<p class="wp-block-paragraph"><strong>Host/IP of the LT Auditor <sup>MP</sup> server:</strong> Enter the IP address or hostname of your LT Auditor <sup>MP</sup> server:</p>



<p class="wp-block-paragraph">Enter LT Auditor <sup>MP</sup> host: &lt;LT_AuditorMP_IP_or_Hostname></p>



<p class="wp-block-paragraph"><strong>Port:</strong> Enter the port configured in the LT Auditor <sup>MP</sup> NSS transformation rule (default: 5015):</p>



<p class="wp-block-paragraph">Enter port [default: 5015]: 5015</p>



<p class="wp-block-paragraph"><strong>Protocol:</strong> Select the communication protocol to match your LT Auditor <sup>MP</sup> NSS transformation rule:</p>



<p class="wp-block-paragraph">Enter protocol [UDP/TCP/TLS, default: TCP]: TCP</p>



<p class="wp-block-paragraph"><strong>If TLS is selected</strong>, you will be prompted for additional settings:</p>



<figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><td><strong>Prompt</strong></td><td><strong>Description</strong></td><td><strong>Default</strong></td></tr><tr><td>CA Certificate Path</td><td>Path to the CA certificate file for server verification</td><td>None</td></tr><tr><td>Enable Mutual TLS</td><td>Require the agent to present a client certificate</td><td>No</td></tr><tr><td>Verify Server Certificate</td><td>Validate the LT Auditor <sup>MP</sup> server certificate</td><td>Yes</td></tr><tr><td>Server Name</td><td>SNI hostname for certificate validation</td><td>syslog.example.com</td></tr></tbody></table></figure>



<p class="wp-block-paragraph"><em>[Your administrator should update the TLS defaults above with the actual values used in your environment if TLS is selected.]</em></p>



<p class="wp-block-paragraph">Once all prompts are completed, the configuration script automatically saves the settings and starts the required daemons.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 5 — Configure the firewall:</strong></p>



<p class="wp-block-paragraph">Ensure no firewall is blocking outbound traffic from the OES server to the LT Auditor <sup>MP</sup> server on the configured syslog port.</p>



<p class="wp-block-paragraph">Test connectivity from the OES server:</p>



<p class="wp-block-paragraph">nc -zv &lt;LT_AuditorMP_Host&gt; &lt;Port&gt;</p>



<p class="wp-block-paragraph">A successful response confirms the connection is open. If the connection fails, review your firewall rules to permit outbound traffic on the configured port.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 6 — Verify the agent service is running:</strong></p>



<p class="wp-block-paragraph">After the configuration script completes, confirm the ltaudit service is running:</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph">systemctl status ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc status</p>



<p class="wp-block-paragraph">The service should show as <strong>active (running)</strong>. If the service is not running, check the agent logs for errors before proceeding.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 7 — Verify audit log collection:</strong></p>



<p class="wp-block-paragraph">After confirming the service is running, verify that NSS audit data is being collected and forwarded to LT Auditor <sup>MP</sup>:</p>



<p class="wp-block-paragraph"><strong>Check NSS audit status:</strong></p>



<p class="wp-block-paragraph">cat /opt/bluelance/log/nssstatus.log</p>



<p class="wp-block-paragraph">Confirm the file contains:</p>



<p class="wp-block-paragraph">Successfully opened live vigil file</p>



<p class="wp-block-paragraph">This message confirms the agent has successfully connected to the NSS audit subsystem and is collecting file activity data.</p>



<p class="wp-block-paragraph"><strong>Review general application logs:</strong></p>



<p class="wp-block-paragraph">ls /opt/bluelance/logs/</p>



<p class="wp-block-paragraph"><strong>Check for forwarding failures:</strong></p>



<p class="wp-block-paragraph">cat /opt/bluelance/log/syslog_send.log</p>



<p class="wp-block-paragraph">Review this log for any errors related to forwarding data to the LT Auditor <sup>MP</sup> server.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Step 8 — Verify data in LT Auditor <sup>MP</sup>:</strong></p>



<p class="wp-block-paragraph">Confirm that NSS file activity data is appearing in LT Auditor <sup>MP</sup>:</p>



<ol class="wp-block-list">
<li>Log in to the LT Auditor <sup>MP</sup> Web UI</li>



<li>Navigate to <strong>View</strong></li>



<li>Select the NSS environment and category</li>



<li>Set the date range to <strong>Last 15–30 minutes</strong></li>



<li>Perform a file operation on an NSS volume on the configured server (e.g., create or modify a file)</li>



<li>Confirm the event appears in the LT Auditor <sup>MP</sup> event list within a short period</li>
</ol>



<p class="wp-block-paragraph">If no events appear:</p>



<ul class="wp-block-list">
<li>Confirm the ltaudit service is running on the OES server</li>



<li>Confirm the nssstatus.log shows Successfully opened live vigil file</li>



<li>Confirm no firewall is blocking traffic on the configured syslog port</li>



<li>Confirm the port and protocol in the agent configuration match the LT Auditor <sup>MP</sup> NSS transformation rule settings</li>



<li>Review the syslog_send.log for forwarding errors</li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Managing the NSS Audit Agent service:</strong></p>



<p class="wp-block-paragraph">Use the following commands to manage the ltaudit service after installation:</p>



<p class="wp-block-paragraph"><strong>Using systemctl:</strong></p>



<p class="wp-block-paragraph"># Start the service</p>



<p class="wp-block-paragraph">systemctl start ltaudit.service</p>



<p class="wp-block-paragraph"># Stop the service</p>



<p class="wp-block-paragraph">systemctl stop ltaudit.service</p>



<p class="wp-block-paragraph"># Restart the service</p>



<p class="wp-block-paragraph">systemctl restart ltaudit.service</p>



<p class="wp-block-paragraph"># Check service status</p>



<p class="wp-block-paragraph">systemctl status ltaudit.service</p>



<p class="wp-block-paragraph"># Enable the service to start automatically on boot</p>



<p class="wp-block-paragraph">systemctl enable ltaudit.service</p>



<p class="wp-block-paragraph"><strong>Using the control script:</strong></p>



<p class="wp-block-paragraph"># Start the service</p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc start</p>



<p class="wp-block-paragraph"># Stop the service</p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc stop</p>



<p class="wp-block-paragraph"># Check service status</p>



<p class="wp-block-paragraph">/opt/bluelance/bin/ltaudit.rc status</p>



<p class="wp-block-paragraph">Enable the service to start automatically on boot using systemctl enable ltaudit.service to ensure NSS audit collection resumes automatically after a server reboot without manual intervention.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Caching behavior during LT Auditor <sup>MP</sup> outages:</strong></p>



<p class="wp-block-paragraph">If the LT Auditor <sup>MP</sup> server is temporarily unavailable, the NSS Audit Agent automatically caches audit streams locally on the OES server. Once connectivity to the LT Auditor <sup>MP</sup> server is restored, the cached data is automatically forwarded — no NSS audit events are lost during outages.</p>



<p class="wp-block-paragraph">This behavior is built into the agent and requires no additional configuration.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Repeating installation across all OES servers:</strong></p>



<p class="wp-block-paragraph">Repeat all steps in this article for every OES server in your environment that hosts NSS volumes you want to monitor. Each server must have the agent installed and configured individually.</p>



<p class="wp-block-paragraph">To confirm all servers are forwarding:</p>



<ol class="wp-block-list">
<li>Navigate to <strong>View</strong> in the LT Auditor <sup>MP</sup> Web UI</li>



<li>Filter by <strong>Source</strong> or <strong>Host</strong></li>



<li>Confirm NSS file activity events are appearing from each OES server</li>



<li>If any server is not appearing as a source, revisit the installation and configuration on that server</li>
</ol>



<p class="wp-block-paragraph"><em>[Your administrator should maintain a list of all OES servers in the environment, confirm each one has been installed and verified, and document the agent version, configuration date, and protocol used for each server.]</em></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Uninstalling the NSS Audit Agent:</strong></p>



<p class="wp-block-paragraph">If the agent needs to be removed from an OES server:</p>



<ol class="wp-block-list">
<li>Stop the service:</li>
</ol>



<p class="wp-block-paragraph">systemctl stop ltaudit.service</p>



<ol start="2" class="wp-block-list">
<li>Remove the RPM package:</li>
</ol>



<p class="wp-block-paragraph">rpm -e LTAuditorMP-OES</p>



<ol start="3" class="wp-block-list">
<li>Confirm the package has been removed:</li>
</ol>



<p class="wp-block-paragraph">rpm -qa | grep LTAuditorMP</p>



<p class="wp-block-paragraph">No output confirms the package has been successfully removed.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p class="wp-block-paragraph"><strong>Best practices:</strong></p>



<ul class="wp-block-list">
<li>Install the agent on all OES servers hosting NSS volumes before considering the deployment complete — a single unmonitored server is a gap in your audit coverage</li>



<li>Always verify the nssstatus.log after installation to confirm the agent has successfully connected to the NSS audit subsystem</li>



<li>Enable the ltaudit service to start automatically on boot on every OES server to prevent monitoring gaps after reboots</li>



<li>Use TCP or TLS in production environments for reliable log delivery</li>



<li>Test firewall connectivity before running the configuration script to catch network issues early</li>



<li>Document the agent version, configuration date, port, and protocol for each OES server</li>



<li>Include NSS Audit Agent installation in your OES server provisioning checklist so new servers are automatically configured for monitoring when they are deployed</li>
</ul>



<p class="wp-block-paragraph"><em>[Your administrator should revisit agent installations whenever the LT Auditor <sup>MP</sup> server IP address or NSS syslog port changes, as the agent configuration will need to be updated on every OES server to reflect the new values.]</em></p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
