Novell Home

My Favorites


Please to see your favorites.

Report and Notification Services (RNS) FAQ sheet

(Last modified: 20Jun2003)

This document (10080526) is provided subject to the disclaimer at the end of this document.


Report and Notification Services (RNS) FAQ sheet




Debugging the RNS: 

Debug information and error messages associated with the RNS can be piped to the DSTrace screen and log file by turning on the “misc” DS trace option. All messages generated by the Report and Notification Service are preceded with “RNS:” for easy identification.

-Supported eDirectory versions:

The RNS is currently installed with eDirectory 8.7 and with DirXML 1.1a. The service can be loaded on any version of eDirectory that is supported by DirXML 1.1a.

-RNS configuration without iManager:

The RNS can be configured without iManager on a server by server basis by manually editing the “slconfig.xml” configuration file. The configuration file may be edited using any text editor, however a XML editor may be helpful in identifying potential errors in the XML document. The file is located in the same directory as the DS module for windows and all Unix platforms, on NetWare the file is located in the SYS:\ETC directory. NOTE: RNS only reads from the SLCONFIG.XML file if a Report & Notification configuration hasn't been created via iManager, or the Report & Notification isn't available.

-Refreshing Configuration Settings:

Configuration settings for the 1.0 version of the RNS do not happen immediately, including changes to Cashe Processing and Refresh Configuration Intervals, after making changes within iManager or saving the configuration file. The default refresh interval is 10 minutes. The interval may be changed however, by adding a <config-delay> element to the default configuration section of the RNS configuration file. The minimal interval allowed is 1 min. To force the RNS to refresh the configuration parameters immediately the service (STATUSLG.NLM or STATUSLG.DLM) must be restarted.

-Cashe Processing Interval and Refresh Configuration Interval:

The RNS guarantees delivery of messages, for example if the target SMTP server is down the RNS saves any messages that should generate an email and tries to send them later. The Cache Processing Interval is the interval in which the RNS tries to resend the message(s). The Refresh Configuration Interval is the interval in which the RNS refreshes its configuration settings.

-RNS and DirXML:

 DirXML 1.1a attempts to auto-create a RNS module configuration section for the Driver Set every time DirXML loads and when a driver starts. To override this auto-creation feature instead of deleting the module configuration sections for a Driver Set or Driver leave an empty element in the RNS configuration file.

For example:

                <module name=”DriverSet”/>

                <module name=”DriverRDN”/>

This will prevent DirXML from auto creating module configuration sections for the driver set or drivers and allow the configuration to be setup as desired. In addition, events that occur for the empty module configurations will be handled by the Global Configuration.

-Debugging SMTP requests through the RNS:

The latest patch available for the RNS has additional debug messages added to print out the SMTP error codes and message strings returned from the SMTP server. This information is helpful to identify configuration problems with the RNS and the SMTP server.

-Formatting RNS Emails through DirXML style sheets:

It is possible through a DirXML style sheet and an xsl:message command to generate messages that will be sent to the RNS which can then be routed to any of the RNS logging devices. The first child element of the xsl:message element must be a <status> element, but the content of the status element can be any valid XML data. However optional <module>, <subject&g.t; and <message-body> elements if provided in the status document can be used to route and format the email message. For example, the following xsl:message command if routed through the RNS to a email would have “This is the email subject” as the email subject and “This is the body of the message” as the email body.


<status level="debug">


<message-body>This is the body of the message</message-body>

<subject>This is the email subject</subject>



The optional <module> element and the value of the level attribute can be used to setup specific operations in the RNS configuration file. For example if the following was added to the RNS configuration file any debug status message with a level equal to debug that was sent to the RNS with the module name of stylesheet1 would generate an email message.

<module name="sytlesheet1">



<route level="debug">

<device name="email-message"/>




Note the value of the level attribute and content of the module element can be any string. However in order to setup specific configurations the strings must match between the style sheet and configuration file.

Using the <message-body> element in the status document along with the attachment attribute of the <email-address> control element administrators may also control the format of the email message.

1.        To specify a message body and add the content of the incoming status document as an attachment set attachments equal to true for the email address and provide a <message-body> element in the message. 

2.        If attachments are equal to true for the email address control element but the incoming status document does not contain a <message-body> element the content of the status document will be added as an attachment and specific elements from the document will be used as the message body.

3.        To specify the message body without adding the status document as a attachment set attachments equal to false on the email address control element and provide a <message-body> element in the incoming status document.

4.        Other wise the entire incoming status document will be used as the message body.

Optional SMTP Control Elements: 

Some SMTP servers can be configured to verify the originating email address is a valid address in order to process an SMTP request. In this configuration for the RNS to operate correctly a <email-origin> element must be added to the RNS configuration file to specify a valid email address that will be used as the sending address. The <email-origin> may be added as a child element of a <default-config>, <module> or <device> element in the configuration file.

SMTP servers may also be configured to restrict relaying SMTP requests from a specific email address or domain to avoid being used as a SPAM relay. To allow the RNS to operate in this configuration the IP address of the eDirectory server must be added to the list addresses allowed to send messages to the server. It is also possible to specify an optional domain name in the configuration file that should be used as the sending domain name in the HELO SMTP request. The <email-domain> element may be added as a child element of a <default-config>, <module> or <device> element in the configurat.ion file.

-RNS Supported Logging Devices: 

The 1.0 release of the RNS supports log-file, email and ds-events as logging devices. LDAP is not supported in the 1.0 release even though it appears as an available logging device in the iManager plug-in.

DS Event as a RNS Logging Device: 

The RNS can generate a DS event as one of the supported logging devices. The RNS event name is DSE_STATUS_LOG, number 241 and the format of the DS event data is as follows:

Event Log Time:   4 bytes

Module name:       length-preceded 2-byte LoHi unicode string, aligned on 4 byte boundary

Message level:     length-preceded 2-byte LoHi unicode string, aligned on 4 byte boundary

Message event:    length-preceded 2-byte LoHi unicode string, aligned on 4 byte boundary

Message code:     length-preceded 2-byte LoHi unicode string, aligned on 4 byte boundary

Message desc:     length-preceded 2-byte LoHi unicode string, aligned on 4 byte boundary

XML Data:            length-preceded 2-byte LoHi data buffer, aligned on 4 byte boundary

DirXML Messages and the RNS: 

By default DirXML sends only error and warning status documents to the RNS for each DirXML driver. Therefore even if the RNS is setup to route DirXML status documents with level equal to success no messages will ever be processed. To change the default setting, change the trace level attribute on each specific driver through iManager to the desired level.

The DirXML engine sends all error and warning messages to the RNS and it cannot be changed or turned off.

RNS core on Linux:

Problem: Some Linux configurations were core dumping when the NDS daemon loaded in the shared library.

Solution: Download the latest support patch for Linux that contains an updated shared library. 

High CPU Utilization on NetWare:

Problem: CPU utilization pegs at 100% after the statuslg.nlm is loaded.

Solution: There is not a patch available yet to fix this problem however it seems to have something to do with a large number of RNS cache files. To get around the problem, delete or move all of the RNS cache files in the appropriate directory.

                  Windows: dibfiles\statlog\*.slg

                NetWare:  sys:\system\statlog\*.slg

                Unix: /var/nds/dib/StatLog/*.slg


Maximum Log file size: When the log file reaches its maximun size the oldest half of the log file is removed.


Route Message Level:  Currently, when you select a Route Message level it only handles message of that level. For example, suppose you select Warning. If it worked the way DSTrace levels worked, both the Fatal and Error would also be logged. RNS handles each message type separately, but work is in progress to change that in the next release to match the functionality of DSTrace levels.



The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10080526
  • Solution ID: NOVL87374
  • Creation Date: 24Feb2003
  • Modified Date: 20Jun2003
    • NovellManagement Products


Did this document solve your problem? Provide Feedback