HP eIUM

HP eIUM
For the HP-UX, Redhat, Solaris, and Windows operating systems

Software Version: 8.0
Administrator's Guide
Document Release Date: September 2012
Software Release Date: E926

Legal Notices
Warranty
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained
herein.
The information contained herein is subject to change without notice.
Restricted Rights Legend

Confidential computer software. Valid license from HP required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.
Copyright Notice
Copyright 2012 Hewlett-Packard Development Company, L.P.
Trademark Notices
Oracle and Java are registered trademarks of Oracle and/or its affiliates, and shall not be used
without Oracles express written authorization. Other names may be trademarks of their respective
owners.
UNIX is a registered trademark of The Open Group.
Intel and Itanium are registered trademarks of Intel Corporation in the US and other countries
and are used under license.
Linux is a registered trademark of Linus Torvalds in the United States.
Red Hat and Enterprise Linux are registered trademarks of RedHat, Inc.
Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
Page 2 of 250 HP eIUM (8.0)

Documentation Updates
The title page of this document and the below print history contains the following identifying
information:
l Document Edition, which changes each time the document is updated.

l Software Version number, which indicates the software version.
l Software Release Date, which indicates the release date of this version of the software.
To check for recent updates or to verify that you are using the most recent edition of a document,
go to:
http://www.hp.com/support/usage
Contact your HP representative for additional support details.
The following table lists the version history since the last released edition.
Print History
Edition Version Release Date
First Edition Version 2.0 May 1999, HP SIU

Operations and Troubleshooting
Guide
Second Edition Version 2.01 August 1999
Third Edition Version 2.02 November 1999
Fourth Edition Version 3.0 September 2000, HP SIU

Administrators Guide
Fifth Edition Version 3.1 August 2001, HP IUM

Administrators Guide
Sixth Edition Version 4.5 Feature Pack 4 May 26, 2006
Seventh Edition Version 4.5 Feature Pack 5 & November 9, 2006

6
Eighth Edition Version 5.0 December 21, 2006
Ninth Edition Version 5.0 Feature Pack 1 July 16, 2007
Tenth Edition Version 5.0 Feature Pack 2 October 12, 2007
Eleventh Edition Version 5.0 Feature Pack 3 April 22, 2008
Twelfth Edition Version 6.0 November 6, 2008
Thirteenth Edition Version 6.0 Feature Pack 1 June 22, 2009
Fourteenth Edition Version 6.0 Feature Pack 2 May 20, 2010

Edition Version Release Date
Fifteenth Edition Version 7.0 October 9, 2010
Sixteenth Edition Version 7.0 Feature Pack 1 November 30, 2011
Seventeenth Version 8.0 September 26, 2012

Edition

Related Documents
Refer to the following documents (including this document) for further information.
HP eIUM documentation set

Document title Description
HP eIUM Release Provides release-specific topics, such as new features, software and hardware
Notes requirements, and known problems and workarounds.
HP eIUM Provides eIUM concepts and design guidelines, including:

Foundation
l Collectors and collector components
Guide
l Designing and configuring an eIUM deployment
l CDR detection and error handling
l File services and Data Delivery Agent
l Using NMEs and the NME Schema Editor
l Using the Common Codec Framework to structure and transform your data
l Creating reports and auditing
l Managing eIUM with OpenView
HP eIUM Provides installation-related topics, including:

Installation
l System requirements and installation prerequisites
Guide
l eIUM installation and activation instructions
l Product Extension setup (MySQL database installation and activation,
TimesTen database installation and setup on Linux, Real-Time Engine
installation)
l eIUM upgrade instructions
l How to activate additional components
l Securing eIUM
l Deactivating and uninstalling eIUM
HP eIUM Provides configuration and administrative guidelines, such as:

Administrator's
l Using the eIUM Launchpad, Operations Console access, eIUM commands,
Guide
and the eIUM Console command-line tool
l Using and configuring the Reference Data Manager
l Creating and managing collectors and other servers
l Managing host systems and the configuration server
l Managing users and security

Document title Description
l Correcting CDRs with the CDR Editor

l Backing up your deployment
l Maintaining and troubleshooting eIUM
l Tuning for performance
l Administrative functions related to the Operations Console
HP eIUM Provides Operations Console usage information (also in help system embedded
Operations in the web application), such as an orientation to the interface, monitoring
Console User capabilities for the deployment, groups, and processes, as well as common
Guide usage scenarios.
HP eIUM Provides eIUM available component information, indexed by category and

Component package, as well all attributes, and sample configurations.
Reference
HP eIUM Describes collector and Session Server templates pre-configured to read from
Template particular data sources. The templates can be used to create collectors and
Reference Session Servers quickly.
HP eIUM Provides eIUM available commands, all possible arguments/options, and

Command sample usage.
Reference
HP eIUM Real- Describes the Session Server, the Real-Time Charging Manager, and the Real-
Time Guide Time Engine in the eIUM system.
HP eIUM Studio Describes how to use the HP SNAP Studio to perform business, technical, or
User Guide administration tasks.
Real-Time Provides contextual help in HP SNAP Studio.

Engine Online
Help
HP eIUM Real- Describes the Real-Time Engine system and functionality overview,
Time Developer development considerations, and reference information.
Guide
HP eIUM Real- Provides performance tuning and sizing tips and guidelines for the Real-Time
Time Engine.
Performance
Tuning and
Sizing Guide
HP eIUM Load Describes how to use the optional Load Balancer capabilities of eIUM.
Balancer Guide
HP eIUM SPR Introduces the Subscriber Profile Repository (SPR) and describes how to install
Guide and configure the SPR in eIUM.

Contents
Administrator's Guide 1
Contents 7
Overview 19
Using the HP eIUM Launchpad and Operations Console 20
Running the Launchpad 20
Security 20
The Launchpad Interface 20
Status Icons 22
The Launchpad Menu 22
The Operations Console 25
Starting the Operations Console 26
Roles and Privileges Access 26
Using the Reference Data Manager 28

Getting Started 29
Starting the Reference Data Manager 29
Initial Configuration 30
Database Setup 30
Metatable Definitions 34
Reference Data Table Definition Example 36
RDM Database Selection 38
Refresh Cache View 39
Working with Tables 42
Table Edit View: Search, Add, Edit, and Delete 42
Bulk Search and Replace 47
Bulk Search and Delete 50
Audit Logging 53
Security 55
Authentication 55

Contents
Authorization 55
User Types in RDM 56
Default Security Configuration 56
Access Control for Multiple Categories 58
Using eIUMCommands 62
Security 63
Using the eIUMCommand Console 63
Running the Console 63
Command Autocomplete and Suggestion 64
Command History 64
Accessing Help 64
Executing Script Files 64
Executing Batch Files 65
Non-Interactive Mode 65
Chaining Commands 66
Console Command Reference 67
The Topology and Registry Service 69
Remote Service Access 72
Repository Service Integration 73
Example Scripts 76
Command Context Interface 77
Using processmanager 78
Commands 78
Scripting Support 79
Using configmanager 81
Commands 81
Creating Collectors 84
Methods of Creating Collectors 84
About Collector Configurations in the Configuration Server 85
Creating Collectors from Collector Templates 85
Creating Custom Templates 86

Contents
Testing Collectors 86
Deploying Collectors 87
Managing Collectors and Other Servers 88

Starting a Collector or Server 88
Stopping a Collector or Server 89
Automatically Starting a Collector or Server 89
Checking Collector, Host or Server Status 90
Viewing Collector or Server Statistics 90
Displaying Collector Data 90
Clearing Collector or Server Data 91
Creating a New Collector 91
Deleting a Collector or Server 91
Changing Collector and Server Configurations 91
Saving a Collector, Host or Servers Configuration in a File 92
Changing Collector and Server Start-up Properties 93
Viewing Collector, Host and Server Log Files 93
Using the Log File Viewer 94
Changing Collector, Host and Server Logging Level 94
Running Collector, Host and Server Diagnostics 94
Managing the MySQL Database 95
Diagnostic Tools for the Datastore 95
Managing Host Systems 96

Changing Default Host Properties 96
Enabling IPv6 97
The Environment Node 98
Overriding Default Host Properties 99
Restarting the Host Admin Agent 100
Windows Commands 100
UNIX Commands 100
Upgrading to a New Version of Java 101
Viewing Host Log Files 103
Changing Host Logging Level 103

Contents
Running Host Diagnostics 103
Adding a New Host 103
Saving a Hosts Configuration in a File 104
Managing Users and Security 106

Activating eIUM Security 107
Deactivating eIUM Security 107
Validating the Security Server Setup 107
Adding a Host to a Secure eIUM Deployment 108
Changing the Security Server Port Number 108
Changing the Security Server Shutdown Keyword and Port Number 108
Modifying the LDAP Data Organization Structure 109
Switching Authentication Methods and Authentication Servers 109
Disabling Data Encryption in a Secure eIUM Deployment 110
Setting up Users 111
Roles for a Junior Operator 111
Roles for a Senior Operator 112
Roles for an Administrator 112
User and Host Roles and Privileges 112
Managing Security Data for Users, Hosts and Servers 114
Identities Data 114
User identities 115
Host identities 115
Server Identities 115
Groups 115
Adding a New User Identity 115
Removing a User Identity 116
Adding a New Host Identity 117
Removing a Host Identity 117
Viewing and Verifying Security Data 118
Managing Your Security Certificates 118
Types of Certificates 118
The CA Certificate 118

Contents
Expiration of the CA Certificate 119
Changing the Validity Period of the CA Certificate 119
The Keystore File for the CA Certificate 119
Server Certificates 119
Changing the Validity Period of the Server Certificate 119
User Certificates 120
Certificate Expiration Alerts 120
Changing the Expiration Alerts for the Security Server 121
Changing the Expiration Alerts for Other eIUM Servers 121
Renewing the Host Certificate 123
Configuring an External CA Certificate 123
Renewing an Expired CA Certificate 123
Audit Logging 124
Controlling Audit Logging for the Security Server 124
Controlling Audit Logging for Other eIUM Servers 125
Managing the Configuration Server 128

Restarting the Configuration Server 128
Checking Configuration Server Status 128
Changing the Configuration Servers Start-up Properties 129
Viewing Configuration Server Log Files 129
Changing Configuration Server Logging Level 129
Running Configuration Server Diagnostics 129
Backing up the Configuration Server 129
Correcting CDRs with the CDR Editor 130

Starting the CDR Editor 131
Using the CDR Editor 131
Opening Files with the Editor 131
Navigating between Open Files 131
The Error File Display 132
Editing Fields in Error Files 132
Undoing and Redoing Changes 134
Bulk Editing (or Find and Replace) 134

Contents
Create a New Replace Rule 135
Use an Existing Replace Rule 141
Modifying Replace Rules 142
Removing Replace Rules 143
Bulk Editing Multiple Files 143
Navigating to a Particular CDR 143
Saving Files 144
Exporting to CSV Format 144
Extracting Corrected CDRs 145
Applying Filters 146
Configuring the CDR Editor 148
Changing Color Coding 149
Configuring Logging 149
Log Levels 150
Setting the Standard Logging Level 151
Saving the Standard Log File 152
Setting the Audit Logging Level 153
Setting the Audit Log File Name and Directory 153
Setting the Backup File Directory 153
Setting the Corrected File Directory 154
Setting the CSV File Directory 154
Backing Up Your eIUM Deployment 156

Introduction and Backup Strategy 156
When and How to Back up 157
Backup Strategies 157
An Online Backup Scenario 157
eIUM Deployment Scenario 158
Server_1 - Leaf Collectors 158
Server_2 - Aggregation and Correlation Collectors 158
Server_3 - Distribution Collectors 158
Performing a Full Online Backup 158
1. Prepare for a Full Backup 159

Contents
2. Back up the Configuration Server 159
3. Back up All Collectors on Each Host 160
4. Back up Your Input Data 161
Streaming Data 161
File-Based Data 161
Reprocessing Collector Chain 162
Session Data 162
Repeat Above Steps for Each Remaining Host 162
5. Save Backup Data to Long-Term Archives 162
Preparing for the Next Backup 162
Performing an Incremental Backup 162
Restoring eIUM from a Backup 163
Recovery in a Collector Hierarchy 164
Collection from Service Access Logs 165
Lower Level Collector with Aggressive Aging Policies 165
Offline Backup Strategy 165
Restoring from Offline Backup Files 168
Troubleshooting Recovery 169
Commands for Backing Up eIUM 169
siubackup Command 169
Syntax 170
Examples 170
siurestore Command 171
Syntax 171
Examples 171
eIUM Logging 172

Overview of eIUM Logging 172
Basic Logging 173
Advanced Logging 173
Basic Log File Names and Locations 174
Log Message Format 174
Additional Log File Types 175

Contents
Launchpad Log Files 175
Collector Log Files 175
Configuration Server Log Files 176
Host Log Files 176
Windows Service Log Files 176
UNIX Daemon Log Files 176
MySQL Log Files 177
Executing SQL Statements to Enable Logging 177
Command Log Files 177
Web Application Log Files 177
Log Levels 178
Warning About Using Debug Log Levels 179
Audit Log Levels 179
Viewing Log Files in the Launchpad 180
To View Log Files in the Launchpad 180
Basic Logging Configuration 180
Precedence of Settings 181
Setting the Log Level from the Launchpad 181
Setting the Log Level from the Properties Node 181
Setting the Log Level from the Command Line 181
Controlling Log File Rollover and Aging 182
Changing the Default LOGLINELIMIT 182
Reading and Processing Log Files with a Collector 183
Advanced Logging Configuration 184
Configuring Server and Process Logging 184
Configuring Logging for a Package or Class 184
Setting the Log Level in a Secondary Property File 185
/Logging Configuration Node 185
Loggers Configuration Attribute 186
HandlerNames Configuration Attribute 186
Example Configurations with Loggers and HandlerNames 187
Using Linked Configurations 188

Contents
Setting Up Centralized Logging 188
Logging System Components 189
Logging Control Flow 190
Logging SDK Javadocs 190
Configuring Centralized Logging Using Syslog 190
Syslog Message Format 191
SYSLOG Components 192
Step 1: Invoking a Handler 192
Step 2: Configuring the Handler as a UDPHandler 192
Step 3: Configuring the SyslogFormatter 193
Step 4: Configuring the File Roll Policy 193
Example Configuration with Syslog 194
Specify the Syslog File Location 194
Launch Central Log Viewer 194
Syslog Levels Corresponding to eIUM Log Levels 195
Setting Up Centralized Logging with LogConsolidator 195
Step 1: Configuring Collectors 196
Step 2: Configuring the LogConsolidator 197
Step 3: Configuring the JMS Provider 197
Step 4: Modifying eIUM Configuration 199
Client Libraries 200
Configuring Centralized Logging Using OpenView Operations 200
Before Configuring Centralized Logging Using OVO 200
Sending Non-CRITICAL Messages to OVO 201
Making eIUM Log Files Available to OVO 201
Mapping eIUM Log Levels to OVO Severity Levels 201
Notifying OpenView Operations of eIUM Process Status Changes 202
eIUM Log Levels and OVO Severity Levels 203
Maintaining and Troubleshooting eIUM 206

Troubleshooting 207
Check for Known Problems 207
How to Connect to a Remote eIUM Host 207

Contents
Check Your eIUM Installation 207
Determine Your eIUM Instance Name 207
Check Collector Statistics 208
Test Collectors with Sample Data 208
Query the Collectors Data 208
Check the IOR URL and the IOR 208
Ensure eIUM Components are Running 209
Check the Status of eIUM Processes 209
Check the Launchpad 209
Check the Collectors 209
Check the Configuration Server 209
Check the Admin Agent Server 210
Check the MySQL Database 210
Check the Process Identifiers 210
Perform Diagnostics 211
Deployment Diagnostics 211
Host Diagnostics 211
Collector Diagnostics 211
Configuration Server Diagnostics 212
Check Log Files 212
Check that the Configuration is Valid 212
Check Initialization Files 213
Check the SIU.ini File 213
Check the SIUJava.ini File 213
Check the MySQL Configuration File and Log Files 214
Check the JVM Options 214
Troubleshooting Windows Services 215
Verifying that a Windows Service is Running 215
Viewing Windows Event Logs 216
Troubleshooting UNIX Daemons 216
Checking Runtime Parameters 216
Starting and Stopping the UNIX Daemons 217

Contents
Starting and Stopping Daemons Individually 217
Solving Specific Problems 218
Collectors Run Out of Disk Space 218
Performance Problems 218
eIUM License Expired or About to Expire 218
Cannot Communicate with Configuration Server 218
SQL Exception: Column Count vs. Value Mismatch 219
MySQL Activation Errors 219
Security Issues 220
Invalid Command Syntax or Command Usage 220
Improper Command Sequence 220
Required Files or Resources Missing 221
Overriding the Existing Configuration 221
LDAP Login and Lookup Common Issues 222
LDAP Directory Layout (external-dir.properties) Common Issues 223
Kerberos Time Synchronization 224
Tuning for Performance 226

Examining Performance Statistics 226
JVM Maximum Heap Size 226
Heap Size Considerations 227
Changing Maximum Heap Size for eIUM Collectors 227
Optimizing ManagementServer Performance 227
eIUM Host Heap Memory Requirement 228
Adjusting MySQLs Memory Requirement 228
Verifying and Changing OS Heap Memory on Windows 229
Verifying and Changing OS Heap Memory on HP-UX 229
Directories and Files 230

Product Root Directories 230
Start-Up Properties 230
Property Precedence 231
Operations Console Administrative Functions 232

Operations Console Localization 232

Contents
Policy File Configuration 232
Operations Console Attribute-Value Mappings 233
Switching Languages for your Locale 247
Management Server Statistics 247
License Audit Reports 248
Generating the Activity File in the Operations Console 248

Overview
Overview
This documentation provides information pertinent to eIUMadministrators, such as the following:
l Orientation to the eIUMLaunchpad and Operations Console

l eIUMcommands and eIUMConsole usage
l Creating collectors and other eIUM processes and servers
l Operations you can perform on working collectors, which are also applicable to other eIUM
servers, such as a file collection service, file distribution service, and session server
l Managing host systems, the host admin agent and other aspects of each eIUM host
l Managing users and security
l Managing the configuration server
l Using the CDR Editor to correct CDRs
l Backing up and restoring your eIUMdeployment
l Logging and how you can use logs and configure logging for your deployment
l Techniques and strategies you can use to troubleshoot eIUM
l Performance tuning for your eIUMdeployment
l Commonly used directories and files in eIUM
l Operations Console administrative functions, such as instructions for localization, history
collection, and license audit reports

Chapter 1
Using the HP eIUM Launchpad and Operations Console

You can use the HP eIUM Launchpad to accomplish most development and maintenance tasks with
your eIUM deployment, from implementation, configuration and testing to day-to-day monitoring
and administration. Alternatively, you can use the Operations Console for daily operational tasks, or
the eIUM commands described in the eIUM Command Reference. Also see "Using eIUMCommands"
(on page 62).
This documentation assumes you are familiar with eIUM and basic eIUM and mediation concepts. For
more information, see the eIUM Foundation Guide. For overall usage instructions and a description of
the Operations Console, see the eIUM Operations Console User Guide.
Running the Launchpad 20
Security 20
The Launchpad Interface 20
Status Icons 22
The Launchpad Menu 22
The Operations Console 25
Starting the Operations Console 26
Roles and Privileges Access 26
Running the Launchpad

To run the Launchpad on Windows platforms, select Start -> Programs -> Internet Usage Manager
8.0 -> SIU -> Launchpad. On UNIX platforms, run /opt/SIU/bin/launchpad.
NOTE: In example commands in this manual, SIU is the default instance name. If you installed
using a different instance name, use that instead of SIU in the examples. See the eIUM
Installation Guide for information on how to install the eIUM product.
Security
If you have installed the optional eIUM security module, you must log in to the Launchpad and when
using any eIUM command. Provide a valid user name and password. The default administrators user
name and password were set when you installed HP eIUM security.
For more information on security, see "Managing Users and Security" (on page 106).
The Launchpad Interface

The Launchpad is a window interface that lets you create, modify, monitor and control collectors
and other eIUM processes and servers.

Chapter 1: Using the HP eIUM Launchpad and Operations Console
l The menu provides all the operations you can perform with the Launchpad. For a complete list,
see "The Launchpad Menu" (on page 22).
l Right-clicking on the collector or any other process icon brings up a menu of operations you
can perform on that object. For example, if you right click on a collector you can start or stop the
collector, display its log file, view statistics about the process, query its data, perform diagnostics
or perform several other operations.
l The buttons provide quick access to common operations. Hold the mouse pointer over each
button to see what it does. With the buttons you can:
n Start and stop collectors and other servers
n Create and edit collectors and other servers.

n Clean up collectors and other servers, meaning remove all their data and reinitialize them.
n Zoom in and out the collector map.
n Find a particular collector or server on the collector map.
l The deployment hierarchy shows all the hosts, charging managers, collectors, and other
processes and servers running in your distributed eIUM deployment. This view is organized by
host. That is, it shows all the servers running on each host. Select a host, charging manager,
collector or server then click a button or choose a menu item to operate on the selected item.
l The charging manager, collector and server tabs let you see status information for any
charging manager, collector or server.
l The charging manager, collector and server icons, on the right side of the Launchpad window,
show all the collectors and servers in your deployment and their interrelationships. Select a
collector or server then click a button or choose a menu item to operate on the selected object.
You can use the mouse to draw a box around multiple objects to select them all. Select an icon or
a line between icons to see information about the selected object.

l The status panel displays valuable information about your deployment. It can display the
operational status of collectors, log files for collectors, and statistics about the data processed
by a collector.
l The additional tabs let you select whether to view operational status, statistics or log files for a
collector, host or other server.
Status Icons
The icon beside each collector, host and server in the Launchpad tells you the status of that object,
as follows:
Launchpad Status Icons

Icon Meaning
The collector or server is running.
The collector or server is not running.
The collector or server has never been run or is in an unknown state.
The Launchpad Menu

The following table describes each of the Launchpads menu items. Many of the menu items require
you to select a collector, a host or a process before they can be selected. Note that you can right-
click on a collector or other process to bring up many of these menu items directly.
NOTE: The Actions menu changes depending on what is selected in the deployment map. The
menu items are customized to the particular collector or server that has been selected.
Launchpad Menu Options

Menu Item Description
File: New... Creates a new collector from a collector template.

Collector
File: New... File Creates a new file collection service from a template. Use the Tools:
Collection Deployment Builders: Create File Service Components menu instead of this
Service menu item. For more information, see the eIUM Foundation Guide.
File: New... File Creates a new file distribution service from a template. Use the Tools:
Distribution Deployment Builders: Create File Service Components menu instead of this
Service menu item. For more information, see the eIUM Foundation Guide.
File: Import Reads configuration information from one or more files into the configuration
Configuration... server.
File: Export Writes configuration information from the configuration server to one or more
Configuration... files.
File: Save Remembers the arrangement of collector and server icons on the right side of
Layout the Launchpad screen. This is useful when you have a large number of
collectors and servers to retain the way you have arranged them. See also the
Options: Preference menu item below.

File: Exit Closes the Launchpad interface.
View: Opens or closes a Status window at the bottom of the Launchpad screen.
Operational
Status
View: Zoom In Makes the collector and server view larger or smaller on the right side of the
and Zoom Out Launchpad.
View: Redraw Repositions all the collectors and servers in the view on the right side of the
Launchpad.
View: Refresh Updates the contents of all Launchpad windows.
Actions: Audit (Deployment must be selected.) Displays audit information. For more
Data information on audit, see the eIUM Component Reference.
Actions: Displays a screen where you can select one or more diagnostics to perform on
Diagnostics the selected server.
Actions: View (A host must be selected.) Displays all log messages for the host. See the eIUM
Central Log Foundation Guide for details on consolidated logging.
Actions: Open (A host must be selected.) Displays a window where you can view log messages.
Central Log See the eIUM Foundation Guide for details on consolidated logging.
Viewer
Actions: Log File Displays the selected processs log file at the bottom of the Launchpad.
Actions: Open Displays a window where you can view log messages.
Log Viewer
Actions: Set Log Opens a window where you can change the amount of information being
Level logged for the selected process. See the eIUM Foundation Guide for more
information on logging.
Actions: Host (A host must be selected.) Opens a window where you can change how all
Default processes on the host run unless specifically overridden by a particular
Properties process. See "Changing Default Host Properties" (on page 96) for more
information.
Actions: Opens a window where you can view and change how a particular process runs.
Properties See "Overriding Default Host Properties" (on page 99) for more information.
Actions: Edit (A collector or other server must be selected.) Opens a window where you can
modify a collectors or other servers configurations.
Actions: Start Starts or stops the selected process. For more information on the file service
and Stop and on reporting, see the eIUM Foundation Guide.
Actions: Cleanup (A collector, file collection service or file distribution service must be selected.)
Removes all data stored by the selected collector or service. The collector or
service must be stopped. Returns the collector or service to the state as if it

had never been run.
Actions: Delete (A collector, file collection service or file distribution service must be selected.)
Removes the selected collectors or servers configuration, effectively deleting
the collector or server.
Actions: Displays detailed information about the data the selected collector has read,
Statistics processed and stored.
Actions: Query Opens a window that displays the data stored in the selected collectors
Data datastore.
Actions: Open (A collector must be selected.) Opens a window that displays audit information
Audit Log from selected collectors audit log file. For more information on auditing, see
Viewer the eIUM Foundation Guide.
Actions: Set Opens a window where you can change the amount of audit information being
Audit Log Level logged for the selected process. For more information on auditing, see the
eIUM Foundation Guide.
Actions: View Opens a window that displays the contents of an AMA/BAF data file.
AMA/BAF File
Actions: Save as Saves the selected collector as a collector template in the deployment under
Template /templates/custom. You can create collectors based on this template when
you create a new collector.
Actions: Find in Moves the selected collector to the center of the collector diagram on the right
Map side of the Launchpad.
Actions: Restart (The configuration server must be selected.) Stops and restarts the
Config Server configuration server process.
Tools: IUM Web Opens a web page that lists the available eIUM web applications. This list
Applications depends on what web applications you have installed:
l The Reporting application lets you generate reports about data processed
by collectors. See the eIUM Foundation Guide for details on reporting.
l The Audit Reporting application lets you generate reports about audit data
collected by eIUM. See the eIUM Foundation Guide for details on reporting.
l The Operations Console lets you monitor the run-time status of all the
processes in your eIUM deployment. See the eIUM Operations Console User
Guide for more information.
Tools: NME Opens a window that lets you view the NME Schema and add NME attributes.
Schema Editor
Tools: Collector Opens a window that lets you view and modify the collector templates defined
Templates in the configuration under the configuration path /templates.
Editor
Tools: Runs the file service wizard to create a file collection service, file distribution

Deployment service and collectors to read and process files from the file distribution
Builders: Create service. For more information on the file service and using the file service
File Service wizard, see the eIUM Foundation Guide.
Components
Tools: Opens the structured NME schema editor. For more information see the eIUM
Deployment Foundation Guide.
Builders:
Schema Editor
Tools: Opens a window that lets you view and modify your entire deployment, under
Deployment the configuration path /.
Editor
Tools: OV Opens a window that enables sending log messages to HP OpenView

Operations Operations Management Console for central monitoring and management.
Logging
Options: Lets you enable or disable automatic refreshing of the Launchpad screen,
Preferences removing of the Launchpad log file when exiting the Launchpad and saving of
the Launchpad screen layout when exiting the Launchpad. See also the File:
Save Layout menu item above.
NOTE: Restart the Launchpad for the new preferences to take effect.
Help: Contents Displays information on how to use the Launchpad.
Help: Displays information about the structured NME schema editor. For more
Components: information, see the eIUM Foundation Guide.
Structured NME
Schema Editor
Help: About Displays the Launchpad version and information about installed patches.
The Operations Console

The Operations Console is a web-based application designed for eIUM operators who need to
monitor and manage an eIUM deployment on a daily basis. Operators do not necessarily need to
configure a deployment or perform detailed operations, however, they need to know the status of
all eIUM processes. In contrast to the Launchpad, for an operator who needs to monitor and manage
an eIUM deployment on a day-to-day basis to ensure that processes are running smoothly, the
Operations Console is an ideal tool. Among its capabilities, it can give you an at-a-glance, global view
of the health of your eIUM deployment, view and monitor all the eIUM processes (including
collectors, charging managers, and file services), and see alarms and problems with eIUM processes
immediately. You can also use it to create process groups for easier monitoring and management,
create history graphs to show process activity over time, and drill down to process events for
troubleshooting. Operators can also perform routine management operations, such as starting and
stopping processes and groups, and changing log levels. The Operations Console also provides role-
based security to limit operations capabilities for different users. For more information on
Operations Console usage, see the Operations Console User Guide.

Starting the Operations Console

To start the Operations Console:
l From the Launchpad, select Tools -> Web applications. This launches your web browser and
displays the eIUM Web Tools page, which includes a list of the web-based tools enabled for your
deployment.
l Open your web browser and enter http://<Host or IP address>:8159 as the URL (for example,
http://iumserver.abc-co.com:8159. If you have enabled eIUM security, enter the URL as
https://<Host or IP address>:8159.
After opening the eIUM Web Tools page, click eIUM Operations Console to launch the application.
Roles and Privileges Access

For deployments where eIUM security has been enabled, access to the Operations Console and its
features can differ depending on the type of user (that is, whether minimal access has been
allowed, the user is an operator, or an administrator). For more information on setting up user roles
and security, see "Setting up Users" (on page 111).
In order for a user to have minimal access, the following roles must be assigned:
l User - This should refer to an Operations Console User.

l Monitor - Gives access for MBean notifications and basic management server communications.
l ConfigRead - This is required for any interaction with the configuration server.
This set of privileges will provide basic access to the Operations Console, allowing the user to view
processes and process status, and group views. This type of user will not be able to perform any
operations on a process, since it is largely view-only.

For a limited operator, in addition to the above basic roles, they must have the Diagnostics role,
which allows access to statistics, and view and query logging. This role allows the limited operator to
view the History and Log File tabs.
For a senior operator, in addition to all the assigned roles for a minimal user and a limited operator,
they must have the ServerAdmin role. This enables the Operations tab, which allows the operator to
start, stop, and clean up a process, as well set logging levels. The Operations Console interface
changes to accommodate this set of privileges by displaying the Start, Stop, and Clean Up buttons
appear for a process, as well as the Start Group and Stop Group buttons (allowing the ability to
select multiple processes via the Select column, to act on one or more processes simultaneously).
NOTE: Cleanup operations only become available once you have edited the security-policy.xml file
to allow it.
For an administrator, in addition to all the assigned roles for a minimal user, limited operator, and a
senior operator, the Management role must be enabled. It allows the administrator to create, edit,
and remove groups, and also enables the Group Admin menu.

Chapter 2
Using the Reference Data Manager

The Reference Data Manager (RDM) web application allows you to view, create, modify, and delete
reference data stored in the relational database. In concert with the related Reference Data Service
(RDS) or other lookup rules (such as JDBCLookupRule, SessionStore components), eIUM process
(session servers and collectors) behavior can be more readily controlled (indirectly) by an operator.
When eIUM processes have been properly configured beforehand to use RDS and the reference
data, the RDM tool can be used to interact with and edit reference data, without the need to change
the overall eIUM configuration and potentially impact other eIUM processes. The RDM table editing
function is aware of the kind of data stored in the reference tables, and includes table-specific and
column-specific validation for data entered. You can also reload the data from the reference tables
to eIUM caches using the Refresh Cache function. RDS can run in two modes: direct and cached. In
the case of cached mode, RDM can be used to notify RDS to refresh its caches. The following
diagram illustrates this process:
Meanwhile, RDM also includes an Audit Log feature to help track the kind of changes performed on
the database by different users of the RDM application. Lastlyand unlike traditional database
editorsRDM also has a robust table lookup functionality, which you can leverage to search for
exactly what you need. To begin working with RDM, select a database from the tree at left.
Getting Started 29
Starting the Reference Data Manager 29
Initial Configuration 30
RDM Database Selection 38
Refresh Cache View 39
Working with Tables 42
Table Edit View: Search, Add, Edit, and Delete 42
Bulk Search and Replace 47

Chapter 2: Using the Reference Data Manager
Bulk Search and Delete 50
Audit Logging 53
Security 55
Authentication 55
Authorization 55
User Types in RDM 56
Default Security Configuration 56
Access Control for Multiple Categories 58
Getting Started
This section discusses what you need to get started with the RDM web application. Namely:
l Starting RDM.
l Initial administrator configuration, such as database, metatables, and cache refresh settings, as
well as information on RDMlogs.
l Database selection.
l Refresh Cache View for a database.
Starting the Reference Data Manager

There are two methods of starting the Reference Data Manager web application:
l From the Launchpad, select Tools -> Web applications. This launches your web browser and
displays the eIUM Web Tools page, which includes a list of the web-based tools enabled for your
deployment.
l Open your web browser and enter: http://<Host or IP address>:8159 (for example,
http://iumserver.abc-co.com:8159)
After opening the eIUM Web Tools page, click IUM Reference Data Manager to launch the
application.

NOTE: RDM must also be enabled during activation of eIUM. See the eIUMInstallation Guide for
more information on installation and activation.
If security is enabled, you will be directed to a login page where you must provide the required
authentication credentials. Otherwise, you can begin using the RDM tool.
Initial Configuration
In order for the Reference Data Manager web application to function in your deployment, it must
first be activated during eIUMactivation (see the eIUM Installation Guide for more information on
activation details). For the initial setup in your deployment, two main tasks must be performed:
l A database needs to be created and set up to store the reference data. This can be an external
database or eIUM's MySQL product extension if preferred. As a related preparatory step, the
corresponding JDBC driver (whether Oracle or MySQL) should first be copied to
C:\SIU\var\webappserver\lib directory (Windows), or /var/opt/SIU/webappserver/lib (UNIX).
l Metatable definition setup for reference tables RDM uses.
l Optionally, enabling of cache refresh functionality.
NOTE: RDMalso has a corresponding log file, rdm.log. See "Additional Log File Types" (on page
175) for more information on eIUMlogging and the RDM log file location.
Database Setup
The first time you launch the Reference Data Manager, the Configuration View setup page is
displayed, which allows you to specify the settings for the database that the Reference Data
Manager will use.

The following table describes the fields and entries you must complete to set up the database that
RDM will use to store its data. Entering the information in these fields assumes you have already
installed and set up your database.
RDM Database Configuration Fields

Field Description
Database Specify the name of the databasethis can be any name you choose to identify the
Node particular database, and is what appears as the node name under Reference
Name Databases.
Connection Specify the URLto connect to the database. For example, using the eIUMMySQL
URL product extension, "jdbc:mysql://localhost:3306/siu20" ("jdbc" is the access
mechanism, "mysql" is the database vendor, "//localhost" is the system name where
the database is, "3306" is the port number, and "siu20" is a database schema). The
connection type can vary depending on the type of database being used. For an
Oracle thin connection, an example URL would be:
"jdbc:Oracle:thin:@IPaddress:1521:siudb".
Driver Specify the JDBC driver class of the database. For MySQL, an example would be:
Class "com.mysql.jdbc.Driver". For an Oracle thin connection, this would be: "Driver =
oracle.jdbc.Driver, connection".
NOTE: The corresponding JDBC driver (whether Oracle or MySQL) should be copied to
C:\SIU\var\webappserver\lib directory (Windows), or /var/opt/SIU/webappserver/lib
(UNIX). After copying the driver to this location, you may need to restart the Web
Application Server in order for the RDM setup process to detect the change in the
system.
User Name Specify the database user name.

Field Description
Password Specify the database password.
Create Create the metatables after adding the database (typically this is the most common
MetaData scenario).
Tables
Drop and Remove any pre-existing meta-tables and create new ones.
Create
MetaData
Tables
Do not Metatables are not created. See "Metatable Definitions" (on page 34) for more
Create information.
MetaData
Tables
Before adding the new database, click Check Connection to first test that you can connect to your
database. If successful, a status message is displayed.
After selecting the chosen metatable creation option, click Add. Your database appears as a node
under the Reference Databases pane, and the RDM welcome screen is displayed.

Click your database to open the Refresh Cache View.
For an initial RDMsetup, no reference tables exist yet. You must use external database tools to
manually create the reference tables, which must then be described in the RDMmetatables (also
using an external tool). Afterwards, RDM can be used to edit the reference tables. For more
information on metatable definitions and setup, see "Metatable Definitions" (on page 34).
The Refresh Cache View shown above is also the top-level page that is shown for a database, but
the refresh cache is not created by default. See "Reference Data Table Definition Example" (on page
36) for information on setting up cache refresh in RDM. Also see "Refresh Cache View" (on page 39)
for an example of where the reference tables are present and can be viewed and edited by an
operator or other RDM user.

Metatable Definitions
The information stored in the metatables defines the format of the reference data tables that are
used by eIUM processes, and managed by RDM. See the following metatable descriptions below for
definitions of what needs to be populated.
TABLE_LISTThis table contains the list of reference data tables that can be viewed and modified
in RDM.
Field Data Type Description Nullable Notes
TL_TABLE_ID INTEGER(6) Table ID. N Primary

Key
TL_TABLE_ VARCHAR2(100) Name of table. N

NAME
TL_ VARCHAR2(255) Description of table. Y

DESCRIPTION
TL_USER_ VARCHAR2(30) Name of the column that contains the user name of Y
COLUMN_ the last user updating the table.
NAME
TL_UPDATE_ VARCHAR2(30) Name of the column that contains the time at which Y
TIME_ the row was created or updated.
COLNAME
TL_ VARCHAR2(30) Use this field to categorize tables and give Y

CATEGORY_ category-based permissions for RDMusers in
NAME secure mode.
COLUMN_LISTThis table contains the column details of all reference data tables that can be
viewed or edited through RDM.
CL_COLUMN INTEGER(6) Column ID. N Primary

_ID Key
CL_COLUMN_ VARCHAR2 Name of column. N

NAME (100)
CL_TABLE_ID INTEGER(6) Table ID. N Foreign

key to
TABLE_
LIST
CL_ VARCHAR2 Description of column. Y

DESCRIPTION (256)

CL_DATATYPE VARCHAR Type of data used for field population and validation, N
(10) for example: STRING, INTEGER, DATE, ALPHA,
ALPHANUM.
CL_REF_ INTEGER(6) Foreign column ID from where data for this column Y Foreign
COLUMN_ID should be populated from. key to
COLUMN_
LIST
CL_REF_ INTEGER(6) Column ID of the reference table column which Y Foreign

COLUMNNAME_ should be mapped with the CL_REF_COLUMN_ID for key to
ID easy recognition by the user. For example: COLUMN_
LIST
l 1Google
l 2Apple
CL_OPTLENGTH INTEGER(2) Optimum length of the field displayed. In the user N

interface, the actual length of the text box for the
column in edit mode in the interface will be
approximately equal to the number of characters
specified in this field, or it will be equal to the
number characters in the column name, whichever is
greater.
CL_PRIMARY_ INTEGER(1) Specifies the primary key. For example: N

KEY
l 1Primary key
l 0Non-primary key
CL_NULLABLE INTEGER(1) Specifies whether the column is nullable or not. N
l 1Nullable
l 0Not nullable
The COLUMN_LIST table possesses several validation types that are performed on the RDMdata.
These validation types are specified in the Data Type column of the table.
l STRING: This is used to specify any string.

l ALPHA: Allows only alphabetic characters.
l ALPHANUM: Allows alphanumeric characters.
l NUMBER(x,y): Allows defining numbers with slight variations to specify different kinds of
numbers.
Floating point numbers: For this the notation, NUMBER(x,y) is used, where x denotes the number
of digits, while y specifies the number of digits after the decimal point. For example, using
"NUMBER(4,3)" for "9.999" is valid.

Integers: For this the notation, NUMBER(x) is used, where x is the total number of digits in the
number. For example, using "NUMBER(3)" would make "324" a valid value.
NOTE: If you do not specify the number of digits, that is, if the notation is NUMBER, then the
default behavior is that the system will allow only integers and there is no restriction on the
length of the number. Out-of-database range values will be handled with the standard error
handling mechanism.
l DATE: Allows specifying the date using the MMM-dd-yyyy HH:mm:ss format.
l TIMESTAMP: Allows specifying a timestamp using the MMM-dd-yyyy HH:mm:ss format.
l IP4: Allows specifying an IPv4 data type, but validation does not check for accuracy of the IP
address when using expressions such as "starts with", "ends with", and so on. Accurate validation
is only performed when the search expression is "equals".
l HOSTIP: Allows validating both IPv4 addresses and host names.
SERVER_LISTThis table contains the list of eIUM servers that should have their cache refreshed.
Field Data Type Description Nullabe Notes
SERVER_ VARCHAR2(100) Name of server. N

NAME
PORT_ INTEGER Session server port number. N

NUMBER
CACHE_ VARCHAR2(100) Name of the query/cache/map in that server N Primary

NAME which should be refreshed. Key
TABLENAME VARCHAR2(100) Name of table. N
PROCESS_ VARCHAR2(100) Unique process name. N Primary

NAME Key
Reference Data Table Definition Example

To set up the cache refresh feature in RDM, you must first configure a ReferenceDataService
component (RefDataServiceManager) in your eIUM process (session server or collector), and you
need to configure a CachedQuery component that reads the database table into the memory. For
example, for a query that is caching the BSID_LOCATION table in memory, the configuration is the
following:
[/deployment/ServerName/ProcessName/ReferenceDataService]
ClassName=RefDataServiceManager
QueryNames=BsidLocation
[/deployment/ServerName/ProcessName/ReferenceDataService
/BsidLocation]
ClassName=CachedQuery
ResultAttribute=VID_MatchFoundInteger
ResultIndexAttribute=VID_ResultIndexInteger

/BsidLocation/Cache]
ClassName=HashMapLookupCache
CacheAttributes=SUBS_DB_LatitudeDouble
CacheAttributes=SUBS_DB_LongtitudeDouble
CacheAttributes=SUBS_DB_ZIPCODEString
CacheKeyAttributes=SUBS_DB_BsidInteger
NMEKeyAttributes=SUBS_BsidInteger

/BsidLocation/Loader]
ClassName=JDBCLoader
FieldExtracted=BSID,SUBS_DB_BsidInteger
FieldExtracted=LATITUDE,SUBS_DB_LatitudeDouble
FieldExtracted=LONGITUDE,SUBS_DB_LongtitudeDouble
FieldExtracted=ZIPCODE,SUBS_DB_ZIPCODEString
JDBCDataSourceConnectorName=ExternalDataSourceConnector
QueryString=SELECT %FIELDS FROM BSID_LOCATION
Secondly, you must configure a SocketConnector component in your eIUM process (session server or
collector). You need this connector to be configured in order for the eIUM process to be able to
receive the cache refresh signal. Once configured, you should be able to execute the
refreshcache command. For example:
refreshcache -ip <ip address of the server where eIUM process runs>
-port <socket connector listen port>
-map <CachedQuery name - for example, BsidLocation>
After executing this command you should see the cache being reloaded in the eIUM process log file.
See the eIUMCommand Reference for more information on this command.
Next, configure RDM to enable editing of the reference data table, for example, the BSID_LOCATION
used in the RDS CachedQuery above. The configuration is done through populating the necessary
meta-information about the BSID_LOCATION reference table in the metatables. In this example,
RDM can be configured to edit the reference data table "BSID_LOCATION", which is used to store the
information about base station location. The table has the following columns:
l BSID (base station ID)

l LATITUDE (BS latitude)
l LONGTITUDE (BS longitude)
l ZIPCODE (BS location ZIP CODE)
l USERID (ID of the user who edited the data)
l LASTUSERID (Last update timestamp)
Once RDM is configured to enable editing of this table, the remainder of this section will show how
to configure it to work with the RDS that is configured to cache this table in memory, and how to use
the cache refresh function. For the TABLE_LIST and COLUMN_LIST tables:

TABLE_LIST specification for BSID_LOCATION

TL_ TL_USER_ TL_
TABLE_ TL_TABLE_ COLUMN_ TL_UPDATE_ CATEGORY_
ID NAME TL_DESCRIPTION NAME TIME_COLNAME NAME
1 BSID_ Base Station USERNAME LASTUPDATETIME CAT1

LOCATION Location
COLUMN_LIST specification for BSID_LOCATION

CL_ CL_ CL_ CL_ CL_
COLUMN COLUMN TABLE CL_ DATA PRIMARY CL_
_ID _NAME _ID DESCRIPTION TYPE _KEY NULLABLE
1 BSID 1 ID NUMBER(8) 1 0
2 LATITUDE 1 BS Latitude NUMBER(12,6) 0 0
3 LONGITUDE 1 BS Longitude NUMBER(12,6) 0 0
4 ZIPCODE 1 ZIP Code STRING 0 0
5 USERNAME 1 User STRING 0 0
6 LASTUPDATETIME 1 Update Time TIMESTAMP 0 0
NOTE: For demonstration purposes and page spacing considerations, the CL_REF_COLUMN_ID,
CL_REF_COLUMNNAME_ID, and CL_OPTLENGTH columns (normally appearing between CL_
PRIMARY_KEY and CL_NULLABLE) were intentionally removed from this example table since they
have no values in this example. Ordinarily, however, these are included columns in the COLUMN_
LIST table. For more information on the COLUMN_LIST metatable, see "Metatable Definitions" (on
page 34).
Once you populate the above table data, you should see the BSID_LOCATION reference table in the
RDMtable list, and you should be able to view and edit the data accordingly.
Lastly, configure the SERVER_LIST table to map the BSID_LOCATION table to a particular
CachedQuery. For example:
SERVER_LIST mapping of BSID_LOCATION

SERVER_NAME PORT_NUMBER CACHE_NAME TABLE_NAME PROCESS_NAME
ServerName/IP address 9000 BsidLocation BSID_LOCATION ProcessName
Once you configure these details, you will be able to trigger the cache refresh of the BsidLocation
CachedQuery in the configured ProcessName eIUM process that runs on the ServerName physical
server. ProcessName must have the SocketConnector component configured and must use port
number 9000. For details on the RefDataServiceManager, SocketConnector, and CachedQuery
components, see the eIUMComponent Reference.
RDM Database Selection

After successfully logging in and after RDM has been properly set up by your administrator
(described in "Initial Configuration" (on page 30)), the main database selection screen is displayed.

This view displays the list of all databases which can be connected to through RDM. The interface
allows you to interact with multiple databases, if configured in your deployment. To begin, select a
database from the tree at left. After selecting a database, the Refresh Cache view for the chosen
database is displayed. See "Refresh Cache View" (on page 39) for more information.
Refresh Cache View

This view allows you to search for caches and refresh them.
eIUM maintains a master list of lookup table caches in-memory to avoid delays in connecting and
fetching data from the database. The Refresh Cache function in RDMprovides the ability to have
the tables be refreshed to load their updated data. eIUM can work with reference data in two modes

for the processes, whether the session server or collector. The first mode is for processing
requests, and will directly query the database, while in the second mode, RDM will not query the
database for every request, but once it starts it will cache the entire table in memory, and then it
will use the information in the cache for processing (that is, it will not go to the database for every
request, but instead use the cache).
In such cases, it is necessary to refresh the cache when you need to change some information in the
tables. RDM would then need to refresh the cache of the processes, to let the process know that the
data has changed in the tables. When you select a database, the main Refresh Cache View for the
database shows all possible processes that use the reference data, and that are caching the
reference data (as shown in the above figure). Refresh Cache functionality is also available in the
Table Edit View for a particular table, except that you can only refresh, but cannot search for, a
cache.
The main database-linked page, however, allows you to both search for and refresh a cache. Under
the Search section, you can search for a cache based on the Server Name, Cache Name, or Table
Name. Combined search parameters can be defined by selecting the Equals, Starts With, Ends With,
Contains, or Regex (regular expressions) options from the drop-down list.
The Caches section consists of a table indexed by the following:
Caches Table
Field Descrption
Process Specifies the name of the process.

Name
Cache Specifies the name of the cache to refresh.

Name
Server Indicates the host name or the IP address of the server.

Name
Port Refers to which port the refresh cache signal is sent to for the particular process.
Number

Field Descrption
Table Specifies the (database) table name which is cached. The corresponding Refresh Cache
Name function will be available in the corresponding table's Refresh Cache function.
Specifying search criteria from the Search fields section will filter the table under Caches according
to the parameters you specify. By default, if no search criteria is used then all the caches will be
displayed and fetched within their respective page views. To view/refresh specific caches you can
use the search function.
By default, the first 10 entries are shown (if that many caches are available). To cycle through these,
use the navigation buttons at the top of the table to move through the entries. The following table
describes these:
Caches Table Navigation

Field Description
Rows/page Controls the number of rows you can view per page. Default is 10.
Refresh Click to refresh the table after selecting a different value for Rows/page (for
example, if you want to view 20 rows per page, click this to reload the Caches table
view).
First When multiple pages are available, jumps directly to the first page.
Prev Click to move back through the entries list.
Next Click to move forward through the entries list.
Last When multiple pages are available, jumps directly to the last page.
Page Indicates the current page being viewed, versus the total. You can enter a page
number to go directly to the desired page.
To refresh a cache(s), select it from the Caches table and click Refresh Cache. Click Toggle
Selection to invert which cache checkboxes are currently selected. After clicking Refresh Cache, a
message is displayed at top to indicate whether or not the refresh was successful.

Working with Tables

The following sections describes the Table Edit View, where you can view, edit, add and delete table
entries, as well as perform bulk search and replace or delete operations.
Table Edit View: Search, Add, Edit, and Delete

The core of RDM functionality is the ability to interact with the reference data tables in the chosen
database. To begin, select a table from the tree at left (see "Refresh Cache View" (on page 39)). The
Table Edit View is displayed, as shown below (in this example, the navigation tree has been resized
out of view for demonstration purposes).
The Table Edit View has three main sections, corresponding to the related function: Add, Search, and
Search Results. By default, the Search Results section displays all the current entries in the table. By
default, the first 10 entries are shown. To cycle through these, use the navigation buttons at the top
of the table to move through the entries. The following table describes these:
Search Results Table Navigation

Field Description
Rows/page Controls the number of rows you can view per page. Default is 10.
Refresh Click to refresh the table after selecting a different value for Rows/page (for
example, if you want to view 20 rows per page, click this to reload the Search Results
table view).
First When multiple pages are available, jumps directly to the first page.
Prev Click to move back through the entries list.
Next Click to move forward through the entries list.

Field Description
Last When multiple pages are available, jumps directly to the last page.
Page Indicates the current page being viewed, versus the total. You can enter a page
number to go directly to the desired page.
The Search Results table also includes several buttons that correspond to various table entry
functions (such as editing, canceling, deleting, and saving). Namely:
Search Results Task Buttons

Button Description
Edit row
Cancel proposed row changes
Save edits
Delete a single row
Searching Tables
In this section you can search table entries by specifying values for each column (that is, table field).
To perform a search, click the Search bar, which opens the search parameter interface, shown
below.
Select the column name/field from the drop-down list (these correspond to the column names in
the Search Results table).

Selecting a column then populates the adjacent field with search expressions you can choose
(Equals, Less Than, Greater Than).
Selections from the drop-down list are also populated based on the field type. For example, date
columns will have a date selector, while lookup tables will have a lookup table component. You can
click the plus icon to chain together multiple search parameters. Some tables, however, have fields
whose values need to be referenced or are associated with IDs from another table. In such cases,
you do not need to go back to the table in question to fill in values. Instead, a search icon will be

available adjacent to the search text field, which you can click to open a new pop-up window for the
table being referenced. This pop-up provides a listing of ID-name pairs you can choose from.
Click the value you want, which will then appear in the text field (the pop-up selection window closes
after making your choice). When finished defining all of your search settings, click Search. The
Search Results table at bottom will be refreshed to display your search results.
Adding Table Entries

To add entries to a table, click the Add bar. An entry form appears as shown below.

The fields in this section are mapped to the columns (fields) in the table. Required fields are marked
with a red asterisk (*). When adding an entry, your input is validated to check for entry of incorrect
data types and required fields.
Editing Tables
To edit a table entry, click the Edit Row button, which is found in the Search Results table.
After clicking this button, the selected row becomes available for editing.

When editing, required fields are also indicated by the red asterisk. Notice that the Edit button
changes to an Update Row button. Edit the desired fields and click the Update Row button, or the
adjacent Cancel button to cancel any changes. The table then refreshes to include your changes.
Deleting Table Entries

To delete a single table entry, click the entry's Delete button.
The table is refreshed after deleting the entry.
NOTE: You can also delete items in bulk, either via what you see in the current Search Results
table, or after searching for specific entries and then deleting the search set. See "Bulk Search
and Delete" (on page 50) for more information.
Bulk Search and Replace

RDMallows you to perform bulk search-and-replace operations on the reference data tables. You
can specify the columns to be updated, in addition to the values for those columns (fields). Updating
can be performed via one of two methods:
l Update only the selected rowsThis method corresponds to which row(s) you may have checked
from the Toggled column of the Search Results table, so that only the selected rows are
updated.
l Update the searched resultsUpdating via this method updates according to everything that
matches the search criteria. For more information on table searches, see "Table Edit View:
Search, Add, Edit, and Delete" (on page 42).
Updating Selected Rows
To update specific rows from the Search Results table, first open the Search bar, and then click the
Replace bar.

Specify one or more Replace conditions by selecting them from the drop-down list, and then specify
the columns to be updated by selecting the rows in the Toggle column. To replace the selected rows,
select the Selected Results option.
In the above example, the selected rows will have their current ASP_ID and Profile_ID values
replaced with "11" and "90" as their new ASP_ID and Profile_ID, respectively. When ready to replace
the values, click Replace.

Updating Searched Results

Updating searched results is functionally similar, except that this method assumes you have just
searched for a subset of rows from the table. For example, in the figure below, all entries with ASP_
ID equal to "1" have previously been searched for, and are displayed in the Search Results table with
4 entries found.
In this example, the Searched Results option is selected, so when the replace operation is executed,
these rows will all be replaced to have their ASP_ID set to "11" and their Profile_ID set to "90".
Clicking Replace replaces with these values.

Since all the table rows whose ASP_ID value was previously "1" are now "11", the Search Results
table is empty and no longer applicable (due to the original search filter being applied based on an
ASP_ID of "1", which no longer exists). If you refresh the table, the replaced values can now be
observed.
Bulk Search and Delete

In much the same way that RDM allows you to perform bulk search-and-replace operations on table
content (see "Bulk Search and Replace" (on page 47)), you can specify entries to be deleted via one
of two methods:

l Delete only the selected rowsThis method corresponds to which row(s) you may have checked
from the Toggled column of the Search Results table, so that only the selected rows are deleted.
l Delete the searched resultsDeleting via this method removes data according to everything
that matches the search criteria. For more information on table searches, see "Table Edit View:
Search, Add, Edit, and Delete" (on page 42).
NOTE: You can also delete rows individually by clicking the red Delete button found in the Toggle
column.
Deleting Selected Rows

To delete specific rows from the Search Results table, first open the Search bar, and then click the
Delete bar.
In the Search Results table, specify the entries to be deleted by selecting the rows in the Toggle
column. To delete the selected rows, select the Selected Results option.

The table entries you selected are deleted from the Search Results table.
Deleting Searched Results

Deleting searched results is similar, except that this method assumes you have just searched for a
subset of rows from the table. For example, in the figure below, all entries with ASP_ID equal to "11"
have previously been searched for, and are displayed in the Search Results table with 4 entries
found.

In this example, the Searched Results option is selected, so when the Delete button is clicked, the
entries in the table are deleted.
Since the entries with the ASP_ID value of 11 have now been deleted, the Search Results table is
empty (since the original search filter no longer applies).
Audit Logging
The Audit Logging functionality in RDMhelps to determine which user performed certain changes on
the reference data. The database operations that are logged and that can be seen are:
l Insert
l Update
l Delete
l Selective update
l Selective delete
l Bulk update
l Bulk delete
The data and the order of the data that is logged are configurable for any operation, and each data
event has a specific code associated with it per below:
l {OP_NAME} Operation Name

l {USER_NAME} User Name
l {DB_NAME} Database Name
l {TABLE_NAME} Table Name
l {OLD_VALUES_ALL} Old Values (entire row)

l {OLD_VALUES_CHANGED} Old Values (only changed columns)

l {NEW_VALUES_ALL} New Values (entire row)
l {NEW_VALUES_CHANGED} New Values (only changed columns)
l {PRIMARY_KEY} Primary Key Values
l {SEARCH_KEY} Search criteria
The default formats used for the database operations in RDM are the following:
l Insert={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{NEW_VALUES_ALL}
l Update={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{OLD_VALUES_CHANGED}{NEW_
VALUES_CHANGED}{PRIMARY_KEY}
l Delete={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{OLD_VALUES_ALL}
l SelectiveUpdate={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{NEW_VALUES_
ALL}{PRIMARY_KEY}
l SelectiveDelete={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{PRIMARY_KEY}
l BulkUpdate={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{NEW_VALUES_
CHANGED}{SEARCH_KEY}
l BulkDelete={OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{SEARCH_KEY}
For example, if you want to specify a format such as:
{OP_NAME}{USER_NAME}{DB_NAME}{TABLE_NAME}{OLD_VALUES_CHANGED}{NEW_VALUES_
CHANGED}{PRIMARY_KEY}
for the update operation, then the following log is generated:
2011-02-14 16:18:41.136 INFO http-8159-Processor23 (DBAUDIT): UPDATE|viveka |Oracle1|ASP_

FILTER|[ PROFILE_ID=21 , START_DATE=Wed Feb 09 00:00:00 IST 2011 , END_DATE=Wed Feb 09
00:00:00 IST 2011 , USERID=viveka , UPDATE_TIME=2011-02-14 16:18:40.424 ]|[ PROFILE_ID=6 ,
START_DATE=2011-02-09 00:00:00.0 , END_DATE=2011-02-09 00:00:00.0 , USERID=viveka , UPDATE_
TIME=2011-02-14 16:18:40.424 ]|[APP_ID=21,ASP_ID=21]
The RDMAudit Log configuration is stored in the configuration server under the
/webApplications/rdm x/AuditLogFormats node, as shown below (this can also be modified as
required).

NOTE: For general RDM logging information, see "Additional Log File Types" (on page 175).
Security
The following sections describe RDM-related security topics, related to authentication,
authorization, user roles, and access control.
Authentication
The Reference Data Manager uses the eIUM security infrastructure in exactly the same manner as
other Web Applications in eIUM, and any authenticated user that has appropriate roles assigned will
be able to login to RDM. For more information on security roles and privileges, see "Managing Users
and Security" (on page 106).
Authorization
In order to access RDM, a particular user needs to have the ConfigRead role assigned. This is
required to read the application-specific configuration, such as database details, audit log formats,
and so on from the eIUM configuration (ConfigServer). Apart from this role, the user needs to have
specific RDM roles to access certain content or perform operations. The LDAP roles that are
authorized by default in RDM are as follows (also see "User and Host Roles and Privileges" (on page
112)):
l RefdataRead
l RefdataWrite
l ServerAdmin

l ConfigRead
l ConfigWrite
l User
The following are the permission types available in RDM:
l view (view the data, perform search operations)

l edit (perform the update on single row or bulk update)
l add (add a row)
l delete (perform the delete of single row or bulk delete)
l refreshcache (to refresh caches)
l view caches
In order to provide flexible control of the access level to different tables, a table category has been
introduced. Each table has to have the specific category assigned. The category to which the table
belongs is specified in the TL_CATEGORY_NAME column of the TABLE_LIST table (see "Metatable
Definitions" (on page 34) for more information). By default, only one category is defined in the eIUM
security policy configuration: DEFAULT. However, users can add any categories that are required.
User Types in RDM

Usually three types of users are configured to access RDM: an administrator, a data provisioner, and
data viewer:
l RDMAdmin has the following roles assigned: ServerAdmin, RefdataWrite, RefdataRead,

ConfigRead, ConfigWrite. This user gets full access to RDM, such as viewing, adding, editing,
deleting, refreshing cache, and administrator tasks (currently the only administrator task in RDM
is first-time database setup described in "Database Setup" (on page 30)).
l RDMProvisioner has the following roles assigned: RefdataWrite, RefdataRead and ConfigRead
for tables belonging to a specific category. Users with these roles can view, edit data, and
refresh caches related to tables of a specific category.
l RDMViewer has the following roles assigned: RefdataRead and ConfigRead for tables belonging
to a specific category. Users with these roles can only view data related to tables of a specific
category, but cannot refresh caches.
Default Security Configuration

The configuration related to RDM roles and permissions can be set in the
$IUMHOME/var/webappserver/webapps/rdm/WEB-INF/security-policy.xml file (Windows), or
/var/opt/IUMHOME/webappserver/webapps/rdm/WEB-INF/security-policy.xml (UNIX). The default
security configuration of RDM uses a category name called DEFAULT. This is the only category
present initially, and the users will be able to edit or view tables of only this category. Below is the
default security policy configured for the category DEFAULT.

DEFAULT Tables
DEFAULT
Tables
Refresh
RDM User: User Rules: view edit add del Cache Admin
RDMAdmin RefDataRead, RefDataWirite, Y Y Y Y Y Y

ConfigRead,
Config Write, Server Admin
RDMProvisioner1 RefDataRead, RefDataWirite, Y Y Y Y Y N

ConfigRead
RDMViewer RefDataRead, ConfigRead Y N N N N N
The policy configuration file (security-policy.xml) that implements the above setup is the following:
<!RDMAdmin -->
<policy>
<grant>
<principals>
<principal class="com.hp.usage.security.auth.Role"
name="ServerAdmin"/>
name="RefdataWrite"/>
name="RefdataRead"/>
name="ConfigRead"/>
name="ConfigWrite"/>
</principals>
<permissions>
<permission class="com.hp.usage.rdm.security.RDMSActionsPermission"
target="DEFAULT" actions="view,edit,add,delete,refreshcache" />
<permission class="com.hp.usage.rdm.security.RDMSPermission"
target="rdm.view.cache"/>
</permissions>
</grant>
<!RDMProvisioner1 -->
<grant>
<principals>
name="ConfigRead"/>
</principals>
<permissions>


</permissions>
</grant>

<grant>
<principals>
name="ConfigRead"/>
</principals>
<permissions>
target="DEFAULT" actions="view" />
</permissions>
</grant>
</policy>
In the above example, RDMAdmin has the roles ServerAdmin, RefdataWrite, RefdataRead,
ConfigRead, ConfigWrite and permissions to view, edit, add, delete, view the caches, refresh the
caches, and administrative tasks. The RDMProvisioner1 has all permissions on DEFAULT CATEGORY,
and the RDMViewer has only view permissions for the tables that belong to the category DEFAULT.
Access Control for Multiple Categories

You can have multiple categories of tables to have more control of the Reference tables. For
example, assume two new created table categories: "CATEGORY1" and "CATEGORY2". In order to
provide flexible access control to these categories, new LDAP roles need to be created: Cat1Read,
Cat1Write, and Cat2Read, Cat2Write. (you of course can create names that are more meaningful to
your particular solution, for example, "USER_DATA", "NETWORK_DATA", and so on). RDM can be
configured to provide the following permissions to the categories mentioned above:
DEFAULT Tables
DEFAULT
Tables
Refresh

ConfigRead,
RDMProvisioner1 Cat1Wirte, Cat1Read, ConfigRead N N N N N N
RDMProvisioner2 Cat2Wirte, Cat2Read, ConfigRead N N N N N N
RDMViewer Cat1Read, Cat2Read, ConfigRead N N N N N N

CATEGORY1 Tables
CATEGORY1
Tables
Refresh

ConfigRead,
RDMProvisioner1 Cat1Wirte, Cat1Read, ConfigRead Y Y Y Y Y N
RDMProvisioner2 Cat2Wirte, Cat2Read, ConfigRead Y N N N N N
RDMViewer Cat1Read, Cat2Read, ConfigRead Y N N N N N
CATEGORY2 Tables
CATEGORY2
Tables
Refresh

ConfigRead,
RDMProvisioner1 Cat1Wirte, Cat1Read, ConfigRead Y N N N N N
RDMProvisioner2 Cat2Wirte, Cat2Read, ConfigRead Y Y Y Y Y N
RDMViewer Cat1Read, Cat2Read, ConfigRead Y N N N N N
In the above table examples, it can be seen that the RDMAdmin has (1) permission to view, add, edit,
and delete all the tables of all the categories; (2) can refresh the caches related to all the tables;
and (3) is authorized for administration tasks. The RDMProvisioner1 and RDMProvisioner2 have
access to only tables of CATEGORY1 and CATEGORY2, respectively. The RDMViewer has only view
permission for the tables belonging to CATEGORY1 and CATEGORY2.
The corresponding security-policy.xml file as per the table and the configuration would be as below:

name="ServerAdmin"/>

name="ConfigRead"/>
name="ConfigWrite"/>
</principals>
<permissions>

target="CATEGORY1" actions="view,edit,add,delete,refreshcache" />
target="rdm.view.cache" />
</permissions>
</grant>

<grant>
<principals>
listed below -->
name="Cat1Write"/>
<principal class="com.hp.usage.security.auth.Role" name="Cat1Read"/>
name="ConfigRead"/>
</principals>
<permissions>
permissions -->
target="CATEGORY2" actions="view" />
</permissions>
</grant>


<grant>
<principals>
listed below -->


name="Cat2Write"/>
name="ConfigRead"/>
</principals>
<permissions>
permissions -->
</permissions>
</grant>

<grant>
<principals>
listed below -->
</principals>
<permissions>
permissions -->
</permissions>
</grant>
Above it can be seen that Provisioner1 has full permission on CATEGORY1, with read permission on
CATEGORY2. Similarly, Provisioner2 has full permissions on CATEGORY2, while read permission on
CATEGORY1. Note that you can even remove the view permission on unrelated categories,
depending on how you want to give access.

Chapter 3
Using eIUMCommands
You can use eIUM commands to accomplish most development and maintenance tasks with your
eIUM deployment, from implementation, configuration and testing to day-to-day monitoring and
administration. The eIUM commands are particularly useful for creating automated scripts that
perform routine tasks such as back ups.
See the eIUM Command Reference for complete details on all eIUM commands.
NOTE: When you use the Launchpad or the siucontrol command to start a process, the Launchpad
and the siucontrol command use the start-up properties stored in the configuration server. When
you use any other eIUM command to start a process, the command uses the start-up properties
in the file SIU.ini. For more information on start-up properties, see "Changing Collector and Server
Start-up Properties" (on page 93) and "Start-Up Properties" (on page 230).
Security 63
Using the eIUM Command Console 63
Running the Console 63
Command Autocomplete and Suggestion 64
Command History 64
Accessing Help 64
Executing Script Files 64
Executing Batch Files 65
Non-Interactive Mode 65
Chaining Commands 66
Console Command Reference 67
The Topology and Registry Service 69
Remote Service Access 72
Repository Service Integration 73
Example Scripts 76
Command Context Interface 77
Using processmanager 78
Commands 78
Using configmanager 81
Commands 81

Chapter 3: Using eIUMCommands
Security
If you have installed the optional HP eIUM Security module, you must provide a valid user name and
password with the -login and -pw options whenever you use any eIUM commands. If you have not
installed the optional HP eIUM Security module, use the eIUM commands without providing a user
name and password.
See the eIUM Installation Guide for details on installing eIUM security. See "Managing Users and
Security" (on page 106) for information on creating users and setting their privileges.
Using the eIUMCommand Console

The eIUM Command Console is part of a command-line framework in eIUM for executing commands
in an eIUM-specific command line shell. It offers a wide range of features, such as command history,
command auto-complete, in addition to displays of command help and prompting of necessary
arguments. The eIUM Console provides for custom scripting support, access to eIUM services, as well
as security services (such as login and logout).
Running the Console

To run the console from within eIUM, you can execute the following iumconsole command via
%BINROOT%/bin (C:\SIU\bin on Windows or /opt/SIU/bin on UNIX):
C:\SIU\bin>iumconsole
Connected to the repository at: null
Successfully checked out: [iumconsole] to
C:\SIU\var\iumconsole\.scripts-1282726394607\iumconsole
iumconsole>>help
core
import imports a descriptor file dynamically
help Prints the list of available commands with
description.
Type help -c commandName for individual commands.
exit exit interactive mode
security
login Authenticates a user identity and stores the user
identity
certificate in an in-memory keystore on successful
authentication.
logout logout
log
loglevel sets the log level of the application
builtin
exec executes a script file
run runs a batch file of CLI commands
register registers a script file as a new command
unregister unregisters a previously registered command
get Prints the value of a variable from the environment
set Sets the value of a variable in the environment

file
ls lists the files in the current working directory
pwd prints the current working directory
cd Changes the current working directory to the one
specified
iumconsole>>
When you execute the iumconsole command from the %BINROOT%/bin directory of your eIUM
installation, it opens the eIUM-specific shell with the basic commands loaded (shown above).
Connection to the repository and checkouts are done automatically when iumconsole starts up
and shuts down (see "Repository Service Integration" (on page 73) for more information). To exit the
console, use the exit command.
NOTE: Commands executed via the eIUM console are specific to the console environment only. By
contrast, the eIUM commands described in the eIUM Command Reference are of a different nature
and cannot be run inside the iumconsole shell.
Command Autocomplete and Suggestion

The eIUM console can automatically complete your command text entry based on a starting letter,
and then allow you to cycle through the available commands. For example, while in the command
shell, type h and then the Tab key. The eIUM Console will automatically fill in the command (starting
with h) for you at the prompt, and wait for you to execute the command by pressing Enter. By
pressing the Tab key, the console looks up all the available commands and selects the one that
matches the selected character.
You can also type the first letter of a known command, and for cases when there are multiple
commands matching what you enter, the eIUM console will suggest the commands beginning with
that character. For example, in the command shell, type e and then press the Tab key. The eIUM
console detects that there are two commands starting with the letter e, exec and exit, and
suggests these on separates lines. When more than one command exists that matches the
character(s) you enter, pressing the Tab key makes the eIUM console suggest all the available
commands that match the specified characters. Otherwise, when there is only one item that
matches what you have entered, the command line will be filled in with the specified command.
Command History
For the current console session, the eIUM console can remember each command you have executed
in the shell. Similar to other command shell environments, you can access the history of entered
commands by pressing the up and down arrow keys.
Accessing Help
You can review help information regarding the arguments taken by each command. To do this, enter
help -c <CommandName>, where <CommandName> is the name of the command you want help
with. For example, to get help on the import command:
help -c import
Executing Script Files

Using the exec command, you can execute script files from within the eIUM command console. For
example, given a script file a.txt, whose contents are the following:
context.output("hello world");

You can execute the a.txt sample script file using exec like the following (where -f is the
argument to call a file):
iumconsole>>exec -f a.txt
hello world
iumconsole>>
The script file should be written in the MVEL (2.0) scripting language, and use the special context
variable to print the text to the console. See http://mvel.codehaus.org/ for more information on
MVEL, and "Command Context Interface" (on page 77) for more information on this variable.
Executing Batch Files

Using the run command, you can execute batch files that contain a list of eIUM console commands,
derived from the eIUM console itself. For example, given a batch file called b.txt whose contents
are as follows:
set -name age -value 40
get
The batch file first sets a variable called age to the value of 40 using the eIUM console set
command. It then uses the console get command to print all the variables in the system. You can
execute this example script from within the eIUM console shell as follows:
iumconsole>>run -f b.txt
Variable age set to 40
age=40
iumconsole.metadir=C:\SIU\var\iumconsole\.meta-1282726394607
repository.client=com.hp.usage.jcr.repository.RepositoryClient@4d4f6e
$descdir=file:/C:/SIU/var/iumconsole/.scripts-
1282726394607/iumconsole/
secure=false
iumconsole>>
In this example, the repository.client, $descdir, and secure settings are internal variables used
by the eIUM console.
Non-Interactive Mode
You can execute iumconsole in non-interactive mode by passing the commands to be run as
command-line arguments. For example:
C:\SIU\bin>iumconsole help
core
description.
security

identity
authentication.
logout logout
log
builtin
file
specified
There are no changes
Checkout discarded for: [iumconsole]
Disconnected from the repository
C:\SIU\bin>
In the above example, iumconsole is executed with the help command, which it executes and
returns to the operating system prompt, without going into interactive mode. This is a feature of
iumconsole, whereby it executes the commands and exits without going into interactive mode when
commands are provided as command-line arguments of iumconsole.
Chaining Commands
You can execute multiple, subsequent commands in the console using the double-hyphen (--)
command separator. In this manner, the eIUM console will execute these commands and then exit
back to the operating system prompt. For example:
C:\SIU\bin>iumconsole help -- get
Successfully checked out: [iumconsole] to C:\SIU\var\iumconsole\
.scripts-1286283832263\iumconsole
core
description.
security
identity
authentication.
logout logout
log


builtin
file
specified
iumconsole.metadir=C:\SIU\var\iumconsole\.meta-1286283832263
repository.client=com.hp.usage.jcr.repository.RepositoryClient@8a0573
$descdir=file:/C:/SIU/var/iumconsole/.scripts-
1286283832263/iumconsole/
secure=false
There are no changes
Checkout discarded for: [iumconsole]
C:\SIU\bin>
In the above example, iumconsole is executed with the help command, followed by the get
command, which it executes and returns to the operating prompt, without going into interactive
mode.
Console Command Reference

The following is a reference summary for eIUM console functions.
NOTE: All commands include a -silent option, which runs the command in non-interactive mode.
Console Command Reference

Command Usage Description Options
import import -file Imports a descriptor file -file <arg>Location of the

<arg> [-silent] dynamically. descriptor file that should be
imported.
help help [-command Prints the list of available -command <arg>Name of

<arg>] [-silent] commands with a description. command for which help is
You can type help -c needed.
<commandName> at the console
prompt for information on
individual commands.
exit exit [-silent] Exits interactive mode.
login login -password Authenticates a user identity, and -password <password>The

<password> [- stores the user identity user password.

silent] -user certificate in an in-memory -user <user>The user

<user> keystore on successful name.
authentication.
logout logout [-silent] Logs out of the eIUM console.
loglevel loglevel [- Sets the log level of the -component <component>

component application. The component whose log
<component>] [- level needs to be changed.
level <log level>]
-level <log level>Specifies
[-silent]
a log level between 0 to 8,
with log level 8 logging the
most information.
exec exec -file <path> Executes a script file. -file <path>Location of the
[-silent] script file that should be
executed.
run run -file <path> Runs a batch file of eIUM console -file <path>Location of the
[-silent] commands. batch file that should be
executed.
register register [-args] Registers a script file as a new -argsWith this parameter
[-description command. set, the register command
<description>] - will prompt you for
file <path> - arguments for the new
name command.
<command> [-
-description <description>
silent]
Description of the command
being registered.
-file <path>Location of the

script file that should be
executed for the new
command.
-name <command>Name
of the command under which
the script will be registered.
unregister unregister - Unregisters a previously- -name <command>The

name registered command. name of the command to be
<command> [- unregistered.
silent]
get get [-name Prints the value of a variable -name <variable>The

<variable>] [- from the environment. name of the varible whose
silent] value is to be retrieved. When
this argument is not
specified, all the variables

are printed.
set set -name Sets the value of a variable in the -name <variable>The
<variable> [- environment. name of the varible whose
silent] -value value is to be set.
<value>
-value <value>The value of
the varible to be set.
ls ls [-dir <arg>] [- Lists the files in the current -dir <arg>The name of the
silent] working directory. directory, relative to the
current working directory, for
which files should be listed.
pwd pwd [-silent] Prints the current working

directory.
cd cd [-silent] -to Changes the current working -to <arg>The name of the
<arg> directory to the one specified. directory, relative to the
current working directory,
which should be set as the
current working directory.
The Topology and Registry Service

The configuration server hosts two new services through its HTTP interface: the topology service
and the registry service. The topology service provides details of the eIUM deployment (the hosts,
the eIUM processes, and the services they host), while the registry service provides a handle to each
service for remote invocation.
These services can be accessed through the configuration server HTTP URL. In eIUM, the ability to
fetch the IOR of the configuration server has been available by using http://localhost:8158/. This
URL, however, can also fetch the IOR of any eIUM service (eIUM admin agent, collectors query
interface, and so on), and can give you information about the topology of eIUM (specifically, its
collectors and hosts in the entire deployment). For example, entering the
http://localhost:8158/topology/* URL in your web browser displays the following XML as output:
<results>
<host name="testhostid" path="/host[@name='testhostid']">
<server name="AdminAgent" path="/host[@name='testhostid']/server[@name='AdminAgent']"
type="AdminAgent">
<service location="/deployment/testhostid/@AdminInterface" name="AdminAgent"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='AdminAgent']"
type="corba"/>
<service location="/deployment/testhostid/@ProcessManagerInterface" name="ProcessManager"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='ProcessManager']"
type="corba"/>
<service location="/deployment/testhostid/@AdminInterface" name="Admin"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='Admin']"
type="corba"/>
<service location="/deployment/testhostid/@DiagManagerInterface" name="DiagManager"

path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='DiagManager']"
type="corba"/>
<service location="/deployment/testhostid/@FileManagerInterface" name="FileManager"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='FileManager']"
type="corba"/>
<service location="/deployment/testhostid/@ManagementServiceInterface"
name="ManagementService"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='ManagementService']"
type="corba"/>
<service location="/deployment/testhostid/@SafeFileHandlerInterface" name="SafeFileHandler"
path="/host[@name='testhostid']/server[@name='AdminAgent']/service[@name='SafeFileHandler']"
type="corba"/>
</server>
<server name="Demo" path="/host[@name='testhostid']/server[@name='Demo']"
type="Collector">
<service location="/collectors/Demo/@AdminInterface" name="Collector"
path="/host[@name='testhostid']/server[@name='Demo']/service[@name='Collector']"
type="corba"/>
<service location="/collectors/Demo/@AdminInterface" name="Admin"
path="/host[@name='testhostid']/server[@name='Demo']/service[@name='Admin']"
type="corba"/>
<service location="/collectors/Demo/@BackupOperationInterface" name="BackupOperation"
path="/host[@name='testhostid']/server[@name='Demo']/service[@name='BackupOperation']"
type="corba"/>
<service location="/collectors/Demo/@QueryInterface" name="Query"
path="/host[@name='testhostid']/server[@name='Demo']/service[@name='Query']" type="corba"/>
<service location="/collectors/Demo/@UsageChannelControlInterface"
name="UsageChannelControl"
path="/host[@name='testhostid']/server[@name='Demo']/service[@name='UsageChannelControl']"
type="corba"/>
</server>
<server name="Parlay" path="/host[@name='testhostid']/server[@name='Parlay']"
type="SessionServer">
<service location="/collectors/Parlay/@AdminInterface" name="Admin"
path="/host[@name='testhostid']/server[@name='Parlay']/service[@name='Admin']"
type="corba"/>
<service location="/collectors/Parlay/@QueryInterface" name="Query"
path="/host[@name='testhostid']/server[@name='Parlay']/service[@name='Query']"
type="corba"/>
<service location="/collectors/Parlay/@TransactionManagerInterface"
name="TransactionManager"
path="/host[@name='testhostid']/server[@name='Parlay']/service[@name='TransactionManager']"
type="corba"/>
<service location="/collectors/Parlay/@UsageChannelControlInterface"
name="UsageChannelControl"
path="/host[@name='testhostid']/server[@name='Parlay']/service[@name='UsageChannelControl']"
type="corba"/>
</server>
<server name="ConfigServer" path="/host[@name='testhostid']/server[@name='ConfigServer']"
type="ConfigServer">
<service location="/" name="Config"

path="/host[@name='testhostid']/server[@name='ConfigServer']/service[@name='Config']"
type="corba"/>
<service location="/ConfigServer/ConfigServer/@AdminInterface" name="Admin"
path="/host[@name='testhostid']/server[@name='ConfigServer']/service[@name='Admin']"
type="corba"/>
</server>
<server name="RepositoryServer"
path="/host[@name='testhostid']/server[@name='RepositoryServer']" type="RepositoryServer">
<service location="/deployment/@RepositoryService" name="RepositoryService"
path="/host[@name='testhostid']/server[@name='RepositoryServer']/service[@name='RepositoryService']"
type="webservice"/>
</server>
</host>
</results>
This XML output shows the entire deployment with its single host (testhostid), five servers under
that host (AdminAgent, ConfigServer, Demo collector, Parlay session server, and RepositoryServer)
and the corresponding services under each server. eIUMs topology is organized in terms of hosts in
the uppermost node in the hierarchy, with servers (collectors, session servers, file collection servers,
and so) subsumed under each host. Meanwhile, each server contains a list of services.
The topology information, however, does not contain the runtime state of any of the processes.
Rather, it just shows the list of servers available under each node, and the list of services applicable
for each server. A server/service appearing in the topology service denotes that it is configured and
available under that node and does not mean it is actually running.
The eIUM topology output (derived above using http://localhost:8158/topology/*) can be searched by
specifying an XPath-like expression in the URL. For this example, an asterisk (*) was appended, which
signifies an XPath expression to fetch everything in the topology data. You can also, for example,
specify alternative XPath expressions to refine your search to a particular host:
http://localhost:8158/topology/host[@name='testhostid']
or a particular type:
http://localhost:8158/topology/host/server[@type='Collector']
The following are some additional XPath combinations you can use.
XPath Expressions
XPath Result
/topology/host/server[@name='AdminAgent'] Get all admin agents in the entire

deployment.
/topology/host[@name='testhostid']/server[@name='AdminAgent'] Get admin agent under the

testhostid host.
/topology/host/server[@name='Demo'] Get the collector named Demo.
/topology/host/server[@name='ConfigServer'] Get the configuration server.
/topology/host/server[@name='Demo']/service[@name='Collector'] Get the collector service from

Demo collector.

Each service exposes a path variable which can be used to get its IOR from the registry service. For
instance, browsing to
"http://localhost:8158/registry/host[@name='testhostid']/server[@name='Demo']/service[@name='Collector']"
returns the IOR of the Collector service of the Demo Collector in testhostid. Note that the URL has a
registry instead of a topology in its path. This tells the ConfigServer HTTP process to fetch the IOR
instead of the topology information.
Remote Service Access

The eIUM console integrates with the topology and registry services to look up the appropriate
service, and obtain a CORBA stub to its remote interface. For example, given the following script
(called script.txt) that can later be executed from within the eIUM console:
context.output("ConfigServer.Config = " +
context.getService("ConfigServer")
.getConfigAttribute("/deployment/testhostid/Demo/Datastore",
"ClassName").value[0]);
context.output("ConfigServer.Admin = " +
context.getService("ConfigServer",
"Admin").getStartTime());
context.output("AdminAgent.AdminAgent = " +
context.getService("AdminAgent")
.getIPAddr());
context.output("AdminAgent.Admin = " +
context.getService("AdminAgent", "Admin")
.getStartTime());
context.output("Demo.Collector = " +
context.getService("Demo").getStatus());
context.output("Demo.Admin = " + context.getService("Demo",
"Admin").getStartTime());
The first line gets the ConfigServers Config interface from the registry interface and calls the
getConfigAttribute() method upon it. Next, it gets the Datastore configuration node and prints the
value of the ClassName attribute under it. The second line gets the ConfigServers Admin interface
and prints the starting time of the configuration server. Notice that the first method call had only
one argument while the second line has two arguments. Each server has a default interface which
will always be fetched by default. Calling the two-argument getService() method will explicitly fetch
that particular service of the server.
The third line fetches the AdminAgents AdminAgent interface and prints the IP address of the
host on which it is running. The fourth line prints the start time of the admin agent from its Admin
interface, while the fifth line prints the status of the Demo collector. Lastly, the sixth line prints the
start time of the Demo collector from its Admin interface.
Executing the above script will print the following:

iumconsole>>exec -f script.txt
ConfigServer.Config = FileJDBCDatastore
ConfigServer.Admin = 1273471760
AdminAgent.AdminAgent = 16.181.55.38
AdminAgent.Admin = 1273471784
Demo.Collector = 0

Demo.Admin = 1273483594
iumconsole>>
The eIUM console will prompt you for any variable in the script that it cannot understand. For
example, consider the following script (called start.txt):
procManService = context.getService("testhostid/AdminAgent",
"ProcessManager");
process = procManService.getProcessByName("/deployment/testhostid/"
+ name);
process.startProcess(new com.hp.siu.corba.PropertyList(new
com.hp.siu.corba.PropertyInfo[] {}));
The above script uses the AdminAgents ProcessManager service to start a service. The second
line tries to get the process ["/deployment/testhostid" + name], where name is unknown to the
eIUM console. To resolve this issue, the eIUM console prompts you to enter the value for name as
follows:
iumconsole>>exec -f start.txt
name=Demo
...
With the value you have entered, it then tries to start the process identified by
/deployment/testhostid/Demo.
Repository Service Integration

The eIUM console allows you to save your scripts as custom commands in a repository so that these
custom commands will also be available in other hosts in your deployment. The register
command saves a script file as a custom command and uploads it to an eIUM repository server.
Starting iumconsole in any other machine will automatically import this custom command from
the repository and make it immediately available in that machine.
To remove a custom command, the unregister command allows you to remove it from the
repository server, thereby making it unavailable to other eIUM hosts. This process is illustrated in
the example steps below.
1. Start the eIUM Console. It will connect to the repository server automatically.
C:\Temp\console>c:\SIU\bin\iumconsole.exe
iumconsole>>
2. Register the script.txt file as a command named custom.

iumconsole>>register -name custom -file script.txt
Registered script admin.txt as command custom
iumconsole>>
3. Since the help command lists help information for all the commands, you can use the help
display to confirm if the new custom command has been properly registered.

iumconsole>>help
core
description.
security
identity
authentication.
logout logout
log
builtin
file
specified
custom
custom command to custom
iumconsole>>
4. Execute the new custom command and verify its output.

iumconsole>>custom
iumconsole>>
5. Exit from the eIUM console. It will automatically save the registered custom command to the
repository.
iumconsole>>exit
=== Changes to submit for: [iumconsole] ==
Added:
C:\SIU\var\iumconsole\.scripts-1282726394607\custom-cli.txt
C:\SIU\var\iumconsole\.scripts-1282726394607\custom-cli.xml
--------------------------
=== Changes have been successfully submitted for: [iumconsole] ==
Added:

--------------------------
C:\Temp\console>
6. Preferably from a different host, start the iumconsole again. It will automatically import the
custom command from the repository.
C:\Temp\console>c:\SIU\bin\iumconsole.exe
C:\SIU\var\iumconsole\.scripts-1282726394607
imported from repository: custom-cli.xml
custom>>
7. Execute the custom command to ensure it is imported correctly.

custom>>custom
custom>>
8. Unregister the custom command.

iumconsole>>unregister -name custom
Unregistered command custom
iumconsole>>
9. View the console help to ensure the custom command does not appear in the list of available
commands.
iumconsole>>help
core
description.
security
identity
authentication.
logout logout
log
builtin


file
specified
iumconsole>>
10. Exit the console. The custom command will be deleted from the repository server, as shown
below.
iumconsole>>exit
=== Changes to submit for: [iumconsole] ==
Deleted:
--------------------------
=== Changes have been successfully submitted for: [iumconsole] ==
Deleted:
--------------------------
C:\Temp\console>
Example Scripts
The following are some sample scripts. As mentioned previously, scripts are composed using the
MVEL 2.0 scripting language (http://mvel.codehaus.org/), and can have any file extension. For
example, the following is a sample script to start a process:
"ProcessManager");
process = procManService.getProcessByName("/deployment/testhostid/" +
name);
To stop a process:
"ProcessManager");
process = procManService.getProcessByName("/deployment/testhostid/" +
name);
process.stopProcess();
To list all processes in a host:

"ProcessManager");
procList = procManService.getProcessNames();
foreach (proc : procList) {

context.output(proc);
}
This script starts a process when loading a text configuration file. It adds the processes into the
configuration server using the addProcess() function, where the processes can then be started:
procManService = context.getService("iumindt28/AdminAgent",
"ProcessManager");
procManService.addProcess("/deployment/iumindt28/" + name);
process = procManService.getProcessByName("/deployment/iumindt28/" +
name);
Command Context Interface

In your scripts, you can access the environment through the CommandContext variable, which
supports the following methods.
CommandContext Methods
Method Description
void error(String message) throws Outputs the message to the error stream of
IOException; standard output.
void error(Exception e) throws IOException; Outputs the exception stack trace to the error
stream of standard output.
void output(String message) throws Outputs the message to the standard output
IOException; stream.
boolean confirm(String question) throws Outputs the question to the user, waits until they
IOException; enter an answer, and returns with a Boolean
response.
String input(String question) throws Outputs the question to the user, waits until they
IOException; enter an answer, and returns with the response.
String input(String question, boolean mask) Same as input(String), but the users answer is
throws IOException; masked based on the masking flag.
String getArgumentValue(String argName) Gets the value of the argument that was entered
throws ArgumentNotFoundException; while executing the command.
String getArgumentValue(String argName, Same as getArgumentValue(), but will force the

boolean forcePrompt) throws user to enter a value if not already available when
ArgumentNotFoundException; the force flag is true.
String[] getArgumentValues(String Gets all the values of the argument that was
argName) throws entered while executing the command.
ArgumentNotFoundException;
String[] getArgumentValues(String Same as getArgumentValues(), but will force the

argName, boolean forcePrompt) throws user to enter a value if not already available when
ArgumentNotFoundException; the force flag is true.

Method Description
String[] getVariableNames(); Gets the list of all variables set in the application
environment.
Object getVariable(String name); Gets the value of the specified variable from the
application environment.
void setVariable(String name, Object value); Sets the value of the specified variable to the
specified value.
Object execute(String commandName, Executes another command with the specified

String... args) throws IOException; arguments.
Object execute(String commandName, Executes another command with the specified

String allArgs) throws IOException; arguments.
Object execute(String... commandWithArgs) Executes another command with the specified

throws IOException; arguments.
Object execute(String commandWithArgs) Executes another command with the specified

throws IOException; arguments.
Command getCommand(); Gets the command object for this command.
Remote getService(String name) throws Gets a remote service object from the registry
NotBoundException, RemoteException; service based on its name.
Remote getService(String name, String Gets a remote service object from the registry
type) throws NotBoundException, service based on its name and type.
RemoteException;
Using processmanager
processmanager is an eIUMConsole-based command that allows you to perform administrative
operations on eIUM processes, such as starting and stopping processes, obtaining process status,
performing cleanup, or setting the log level. processmanager also supports fetching the JMX
attribute values of managed components in the deployment.
Commands
The processmanager tool inherits all iumconsole commands and adds the following new
commands. Also see the eIUMCommand Reference for additional details.
processmanager Commands
Command
Name Description
start Starts one or more eIUM processes or services. Processes under localhost can be
referenced by just the process name. Processes under different hosts should be
referenced by the full path name, as seen in the configuration server
(/deployment/host2/collector2). FileCollectors under a File Collection Service can also
be started by referencing them using the full configuration path of the service under
the process (/deployment/host1/FCS1/DataSource1).

Command
Name Description
stop Stops one or more eIUM processes or services. Processes under localhost can be
referenced by the full path name, as seen in the configuration server
(/deployment/host2/collector2). FileCollectors under a File Collection Service can also
be stopped by referencing them using the full configuration path of the service under
the process (/deployment/host1/FCS1/DataSource1).
list Shows the list of processes under the local host, or under other hosts in the
deployment. The list can be filtered based on the process type (Collector,
SessionServer, and so on).
show Shows details about eIUM processes under the local host or other hosts in the
deployment. Processes under the local host can be referenced through just the
process name. Processes under other hosts should be referenced using the full
configuration path of that process (/deployment/host2/collector2). When no
argument other than the process name is provided, the status of that process will be
shown.
loglevel Sets the log level of the process or command. Processes under localhost can be
referenced by the full path name as seen in the configuration server
(/deployment/host2/collector2). When no process name is provided, the log level of
the processmanager command will be set. When no log level is specified, the current
log level of the process or processmanager command will be shown.
cleanup Cleans up one or more eIUM processes. Processes under localhost can be referenced
by just the process name. Processes under different hosts should be referenced by
the full path name as seen in the configuration server
(/deployment/host2/collector2).
jmx Shows the JMX attributes and its values exposed by a managed component in eIUM.
See the eIUM Command Reference guide for examples.
Scripting Support
processmanager supports a scripting interface for accessing the JMX attributes exposed by
managed components. Scripts can be executed using the iumconsole exec command, and saved
to the repository server using the register and unregister commands (see "Console
Command Reference" (on page 67) for more information on iumconsole commands, and
"Repository Service Integration" (on page 73) for more on the repository service). The scripting
interface has the following methods:
Scripting Methods
Method Signature Description
ManagedComponent[] Gets the list of managed components in the

getManagedComponents() entire deployment. For example:
getManagedComponents();

ManagedComponent[] Gets the list of managed components under a

getManagedComponents(String host) particular host. For example:
getManagedComponents("Host01");
ManagedComponent[] Gets the list of managed components under a

getManagedComponents(String host, String particular host and a particular eIUM process. For
process) example:
getManagedComponents("Host01",
"server01");
ManagedComponent Gets the specified managed component under a

getManagedComponent(String host, String particular host and eIUM process. For example:
process, String component)
comp1 =
getManagedComponent("Host01",
"server01", "httpClient");
String[] Gets the list of JMX attributes exposed by the

getManagedAttributes(ManagedComponent specified managed component. For example:
component)
getManagedAttributes(comp1);
Object Gets the current value of the specified JMX

getManagedAttributeValue(ManagedComponent attribute (name) under the specified managed
component, String name) component. For example:
getManagedAttributeValue(comp1,
"NumPendingRequests");
This interface can be obtained in the script as follows:

client = context.getVariable("jmx.client");
The following is a script that prints all the values of the JMX attributes exposed by the managed
component "http" under process "HttpTextXML", running under host "testhostid":
client = context.getVariable("jmx.client");
comp1 = client.getManagedComponent("testhostid", "HTTPTextXML",
"http");
attributes = client.getManagedAttributes(comp1);
int i=0;
for (i=0; i < attributes.length; i++) {
context.output(attributes[i] + " = " +
client.getManagedAttributeValue(comp1,
attributes[i]));
}
The resulting output is as follows:
processmanager>>exec c:\temp\processmanager\jmx.txt
NumConnections = 1
TotalErrorMessages = 0
BytesReceived = 0

TotalRequestProcessingTime = 18416
NumPendingRequests = 0
NumPendingResponses = 0
TotalRequestsReceived = 22
BytesSent = 1299
TotalResponsesSent = 22
processmanager>>
Using configmanager
configmanager is an eIUMConsole-based command that allows you to load and save configurations
from the configuration server, and then find the changes made to a configuration file versus the
time it was saved on the configuration server. This allows you to track changes to your configuration
file and avoid overwriting other eIUM users' changes on the configuration server. The tool also
allows script files to get and make point changes on the configuration server, such as obtaining and
setting the value of a configuration attribute. This is useful in cases where the configuration tree is
too large and can take too long to load in the Launchpad to edit.
Commands
The configmanager tool inherits all iumconsole commands and adds the following new
commands. Also see the eIUMCommand Reference for additional details.
configmanager Commands
Command
Name Description
checkout Saves the specified configuration sub-tree on the configuration server to a file at
the specified location. The command also saves a copy as a backup file in its
meta-directory (%VARROOT%/configmanager/%login-name%/.checkouts), so
that it can find the changes made to the file checked out. The files checked out
are maintained across configmanager sessions. For this purpose, a list is
maintained of all files that have been checked out at
%VARROOT%/configmanager/%login-name%/.checkouts/list.xml.
undocheckout Discards a file that has been checked out, in addition to its associated meta-
information. All changes done to the checked out file will be lost. The file that was
checked out, as well as the backup file, will both be deleted after this operation.
checkin Loads a file that has been checked out to the configuration server, after ensuring
that the configuration on the server has not been modified by another user after
this file was checked out. This is accomplished by comparing the latest
configuration on the server with the backup file created when the user checked
out this file. The checkin operation will fail when the configuration on the server
was found to have been modified by another user.
changes Lists the changes made to the file that has been checked out, by comparing it
with the backup file created during the checkout operation.
list Lists the files that have been checked out so far. The files that have been
checked out are maintained across configmanager sessions. For this purpose, a
list is maintained of all files that have been checked out at
%VARROOT%/configmanager/%login-name%/.checkouts/list.xml.

Scripting Support
As with processmanager, configmanager supports a scripting interface for accessing the
configuration server via scripts. Such scripts can be executed using the iumconsole exec
command and saved to the repository server using the register and unregister commands
(see "Console Command Reference" (on page 67) for more information on iumconsole
commands, and "Repository Service Integration" (on page 73) for more on the repository service).
The interface has the following methods:
Scripting Methods
String[] Gets all the values of the specified attribute (name) under the specified
getAttributeValues configuration node (path). For example:
(String name,
getAttributeValues("NMEFields",
String path)
"/deployment/host01/collector01/Encapsulator");
String[] Gets the names of all the attributes under the specified configuration node
getAttributeNames (path). For example:
(String path)
getAttributeNames("/deployment/host01
/collector01/Encapsulator");
boolean Adds an attribute with the specified name and specified values under the
addAttribute specified configuration node (path) of the configuration tree. If an attribute
(String name, with the specified name already exists, the specified values will be appended
String[] to the existing value. For example:
values, String path)
addAttribute("NMEFields", new String[]
{"SrcIPv6,,::0::255,1"}, "/deployment/host01
/collector01/Encapsulator");
void setAttribute Replaces the specified attribute (name) with the new values specified, under
(String name, the specified configuration node (path) of the configuration tree. When the
String[] attribute does not exist, a new attribute will be created. For example:
values, String path)
setAttribute("NMEFields", new String[]
{"SrcIP,,15.0.0.1,15.0.0.19", "SrcIPv6,,::0::255,1"},
String setAttribute Replaces the specified index of the multi-valued attribute (name) with the
(String name, new value specified, under the specified configuration node (path) of the
String value, int configuration tree. When the attribute does not exist, a new attribute will be
index, String path) created. When the specified index does not exist, an
ArrayOutOfBoundsException error will be generated. For example:
setAttribute("NMEFields", "SrcIPv6,,::0::255,1",
0 "/deployment/host01/collector01/Encapsulator");
boolean Deletes the specified attribute (name) under the specified configuration
deleteAttribute node (path) of the configuration tree. When the attribute does not exist, the
(String name, delete operation returns false. For example:
String path)

deleteAttribute("NMEFields", "/deployment
/host01/collector01/Encapsulator");
String Deletes the specified index of the multi-valued attribute (name) under the
deleteAttribute specified configuration node (path) of the configuration tree. When the
(String name, int attribute does not exist, the delete operation will return null. Otherwise, the
index, older value being deleted will be returned. For example:
String path)
deleteAttribute("NMEFields", 0,
String[] Gets the names of all the configuration sub-nodes under the specified
getConfigNames configuration node (path). For example:
(String path)
getConfigNames("/deployment/host01");
void Sets a new configuration sub-node with the specified path in the
createConfigEntry configuration tree. All nodes in the path will be created if necessary. If a node
(String path) with that name exists already, it will be replaced with an empty entry. For
example:
createConfigEntry("/deployment/host01/collector01");
boolean delete Deletes the configuration sub-node at the specified path of the configuration
ConfigEntry tree. If a node with that name does not exist, this method will return false.
(String path) For example:
deleteConfigEntry("/deployment/host01/collector01");
This interface can be obtained in the script as follows:

client = context.getVariable("config.client");
The following example script prints all the values of the "NMEFields" attribute at
/deployment/testhostid/Demo/Encapsulator:
client = context.getVariable("config.client");
nmeFields = client.getAttributeValues("NMEFields",
"/deployment/testhostid/Demo/Encapsulator");
int i=0;
for (i=0; i < nmeFields.length; i++) {
context.output("NMEFields[" + i + "]=" + nmeFields[i]);
}
The resulting output is as follows:
configmanager>>exec -f c:\temp\configmanager\attrs.txt
NMEFields[0]=StartTime,,0,20,*10
NMEFields[1]=EndTime,,20,30,*10
NMEFields[2]=SrcIP,,15.0.0.0,15.0.0.19
NMEFields[3]=SrcIPv6,,::0,::255,1
NMEFields[4]=NumBytes,800,100,5000,+100
configmanager>>

Chapter 4
Creating Collectors
This documentation describes how to create collectors and other eIUM processes and servers. For
background information on eIUM collectors and servers, see the eIUM Foundation Guide. This
documentation assumes you are familiar with the eIUM Launchpad interface. For details on the
Launchpad, see "Using the HP eIUM Launchpad and Operations Console" (on page 20).
Methods of Creating Collectors 84
About Collector Configurations in the Configuration Server 85
Creating Collectors from Collector Templates 85
Creating Custom Templates 86
Testing Collectors 86
Deploying Collectors 87
Methods of Creating Collectors

You can use any of the following methods to create new collectors and servers:
l Create a collector or server from a template using the Launchpad then customize it for your
needs. This is the simplest way to create collectors and servers. HP eIUM includes many
preconfigured collector and server templates you can use to create your own collectors and
servers. See the HP eIUM Template Reference for a list of available templates. You can also create
your own templates from the collectors and servers you have already configured. See "Creating
Custom Templates" (on page 86).
l Create a collector using the deployment editor in the Launchpad. Open the deployment editor by
selecting a host and selecting the Tools -> Deployment Editor menu item. Open the desired
collector configuration node under /deployment/host/collector and right-click any node to
display the edit menu. Note that you must be familiar with configurations and the configuration
structure to use the deployment editor. For complete details on configurations of eIUM
components, see the eIUM Component Reference.
l Create a collector by loading a text configuration file into the configuration server with the
loadconfig command. You can use the saveconfig command to save the configuration for a
collector in a text file, edit the text file and load the modified configuration with the loadconfig
command. See the eIUM Command Reference for information on the saveconfig and loadconfig
commands. Note that you must be familiar with configurations and the configuration structure
to use the loadconfig command.
CAUTION: Make sure only one person modifies your configuration at a time. You can modify the
configuration with the Launchpad or the loadconfig command. If multiple people modify the
configuration simultaneously, some changes could be lost.

Chapter 4: Creating Collectors
CAUTION: Loading the configuration for a collector while it is running can cause the collector to
be unreachable if the IOR information is overwritten. Be sure to stop a collector before loading its
configuration.
NOTE: When loading configurations with the Launchpad or the loadconfig command, make sure
you load valid configurations as the configurations are simply copied into the configuration
server.
About Collector Configurations in the Configuration Server

All collectors and eIUM servers are defined by configuration attributes stored in the configuration
server. Configuration attributes are parameters that determine the behavior of collectors and
other servers. When a collector or server starts up, it reads its configuration values from the
configuration server to determine what kind of server it is and how it should operate. When you
create a collector, you specify the collectors configuration attributes in the configuration store.
Configuration attributes reside in a particular place in the configuration server. The configuration
server is a tree structure similar to a UNIX or Windows directory structure. Each node in the tree
contains configuration attributes and each node may have subnodes.
For example, collector configurations reside at /deployment/<host name>/<collector name> where

<host name> is the name of the system where the collector is to run, and <collector name> is the
name of the collector. For example, /deployment/sys01/my_voice_collector would contain the
configuration attributes for the collector named my_voice_collector running on host sys01.
Additional nodes exist in the tree under this node for the collectors encapsulator, aggregator, and
datastore components. See the HP eIUM Component Reference for complete information on all eIUM
components and their attributes.
Creating Collectors from Collector Templates

HP eIUM includes many collector templates pre-configured for specific data sources such as voice
switches, IP routers, multimedia servers, mail servers, ftp servers, proxy servers, Diameter and
RADIUS servers, other collectors, SNMP MIBS, and many more. You can use these templates to
create collectors and other servers. See the eIUM Template Reference for a list of available collector
templates.
You can also create your own collector templates customized for your environment and create
collectors from them. See "Creating Custom Templates" (on page 86).
Create a collector from a collector template in the Launchpad as follows.
1. Select the File-> New Collector button or click on the Create Collector button. This opens the
New Collector window that lists all the available templates.
2. Select a template to use to create your collector or server. Select the custom template button
to see the templates you have created. See "Creating Custom Templates" (on page 86) for how
to create your own templates. Click Next.
3. Select the host on which this collector or server is to run.
4. Enter the collector or server name.

NOTE: Collector and server names must be unique across your entire deployment, even
across different hosts. These names must not start with a number and must not contain
dashes or spaces. Do not name any collector security because it is a reserved name. If you
are using an Oracle database, the sum of the number of characters in the collector name
and scheme name must not exceed 20 characters.
5. Enter a text description of the collector that will help you remember the collectors purpose.
6. Check the default configurations for the template and modify any as needed for your
requirements.
7. Click the Create button. This creates a collector on the specified host based on the template
you selected.
Creating Custom Templates

You can create your own custom templates for collectors and other servers and use these custom
templates to create additional collectors and servers quickly and accurately based on your exact
needs. This is useful when you have created and tested collectors for your environment and you
need to quickly create more collectors.
For example, if you have a large number of voice switches or other devices you need to collect from,
you can save a lot of time and trouble by creating a collector for your device, then creating a
template based on that collector and creating additional collectors based on your custom template.
1. In the Launchpad, select the collector you want to create a template based on.
2. Select the Actions -> Save as Template menu item.
3. Enter a name for your template and click OK. The next time you create a new collector, select
the Custom Template button and your custom templates will be available.
4. Use your new custom template when creating collectors as described in "Creating Collectors
from Collector Templates" (on page 85).
Do not modify any HP supplied collector templates under /templates/factory. These may be
overwritten in future releases and your changes would be lost. Create your own templates in
/templates/custom.
See also the white paper Managing Large Deployments from the HP eIUM customer support web site.
See the eIUM Release Notes for how to get to the HP eIUM customer support web site.
Testing Collectors
After you have created a collector, try starting it as described in "Starting a Collector or Server" (on
page 88). You may be able to use the sample input data files at C:\SIU\SampleData on Windows or
/opt/SIU/SampleData on UNIX. Or you can test with one of the demo collectors to generate pseudo-
random data based on the encapsulator configurations. Create a demo collector using one of the
Demo collector templates.
Check the collector's status with the Launchpad. If the collector is not running, check the collector's
log file with the Launchpad to determine why it would not run. Change the collector's configuration
as needed, clean up the collector and try starting it again.
If the collector runs, check the collectors status, statistics, log file, and diagnostics. Check the NMEs
being saved by the collector. If anything does not appear as you expect, stop the collector, modify

the collector's configurations, clean up the collector and run it again until you have the collector
configured properly.
Each of the tasks mentioned above is described in "Managing Collectors and Other Servers" (on
page 88). See also "Maintaining and Troubleshooting eIUM" (on page 206).
Once one collector is running properly, create and test the next collector in your deployment. Once
all your collectors are running correctly, integrate your deployment with the business application
you are using with eIUM, for example billing, reporting, capacity planning, and so forth.
Deploying Collectors
Once all your collectors are working properly and your application is integrated with eIUM,
automatically start the collectors as described in "Automatically Starting a Collector or Server" (on
page 89).
Add backing up of eIUM configuration data and collected data to your backup plans. See "Backing Up
Your eIUM Deployment" (on page 156).
If you are using OpenView or some other network management tool, integrate eIUM into that tool.
For more information, see the eIUM Foundation Guide.

Chapter 5
Managing Collectors and Other Servers

This topic describes operations you can perform on working collectors. Most of these operations can
also be performed on other eIUM servers such as:
l A file collection service.

l A file distribution service.
l A session server.
For more information on these and other eIUM servers, see the eIUM Foundation Guide.
Starting a Collector or Server 88
Stopping a Collector or Server 89
Automatically Starting a Collector or Server 89
Checking Collector, Host or Server Status 90
Viewing Collector or Server Statistics 90
Displaying Collector Data 90
Clearing Collector or Server Data 91
Creating a New Collector 91
Deleting a Collector or Server 91
Changing Collector and Server Configurations 91
Saving a Collector, Host or Servers Configuration in a File 92
Changing Collector and Server Start-up Properties 93
Viewing Collector, Host and Server Log Files 93
Using the Log File Viewer 94
Changing Collector, Host and Server Logging Level 94
Running Collector, Host and Server Diagnostics 94
Managing the MySQL Database 95
Diagnostic Tools for the Datastore 95
Starting a Collector or Server

Start a collector or another eIUM server from the Launchpad as follows:

Chapter 5: Managing Collectors and Other Servers
1. In the Launchpad, select the collector to start.

2. Do one of the following:
n Click on the Start Collector button, or
n Select the Actions: Start menu item, or

n Press Ctrl+F9, or
n Right click the desired collector and select the Start menu item.
HP eIUM displays the status of the start collector request. You can also use the siucontrol command
as described in the eIUM Command Reference.
Stopping a Collector or Server

Stop a running collector or another eIUM server from the Launchpad as follows:
1. In the Launchpad, select the collector to stop.

n Click on the Stop Collector button, or
n Select the Actions: Stop menu item, or

n Press Ctrl+F10, or
n Right click the desired collector and select the Stop menu item.
HP eIUM displays the status of the stop collector request. You can also use the siucontrol command
as described in the eIUM Command Reference.
Automatically Starting a Collector or Server

When you create a collector or other eIUM server with the Launchpad, it is typically in manual mode,
which means it will not be started automatically when your system starts. If you want the collector
to start automatically, you must put it in automatic mode.
Each collector and server running on a host uses the host default properties, unless the collector or
server explicitly overrides the host default properties. When the collector starts, it uses all the
explicitly set properties and host default properties for all other properties.
The STARTUPMODE property can be any of the following:
l Automatic The host admin agent will start the collector whenever it starts up. The host admin
agent is a Windows service or UNIX daemon so it will start the collector whenever the system is
rebooted.
l Manual The collector will not be started when the host admin agent starts. You must start the
collector manually using the Launchpad or the siucontrol command.
l %DEFAULTS% The collector will use the host default value for STARTUPMODE.
To make the collector start automatically, do the following:
1. Select the collector you want to automatically start.

2. Select the Actions: Properties menu item, or right click and select the Properties menu item.

3. Double click the STARTUPMODE property, or right click the STARTUPMODE property and select
the Edit Value menu item.
4. Modify the value to be either Automatic or Manual. If the host default value for STARTUPMODE
is automatic, you can set the value to be %DEFAULTS%.
5. Click OK. The collector will start automatically the next time the host admin agent is restarted
or whenever the system reboots.
Checking Collector, Host or Server Status

The icons displayed beside each process in the Launchpad tell you the processs status. See "Status
Icons" (on page 22) for what each icon means.
You can also determine whether or not a host, collector or server is running as follows: In the
Launchpad, select a collector, host or other server and do either of the following:
l Hold the mouse pointer over the collector, host or server until the Launchpad displays the name,
host, state and description.
l Select the Status tab at the bottom of the Launchpad window. If the Status tab is not displayed,
select the View: View Operational Status menu item.
Viewing Collector or Server Statistics

You can view collector statistics such as the total number of NMEs processed by a collector, number
of NMEs flushed, and other information as follows:
1. In the Launchpad, select a collector.

2. Do either of the following:
n Right click the collector and select the View Statistics menu item, or
n Select the Actions: Statistics menu item.

This displays the collectors statistics in a tabbed pane at the bottom of the Launchpad screen.
Displaying Collector Data

You can query a collector and display collected data as follows:

2. Do either of the following:
n Right click the collector and select the Query Data menu item, or
n Select the Actions: Query Data menu item.

This displays a Query Data window showing the datasets the collector has processed and flushed for
each aggregation scheme. You can select which scheme and which dataset to display. Select a
dataset and click the View Collected Data button to display the actual data in the dataset.
You can also use the siuquery command and the reporting application to view collector data. See the
eIUM Command Reference for information on the siuquery command. See the eIUM Foundation Guide
for information on reporting.

Clearing Collector or Server Data

You can remove all of a collectors or other servers data storage, log files, and data files as follows.
You typically do this when testing or before starting a collector or other server and after making
significant changes. First make sure the collector or server is stopped as described under "Stopping
a Collector or Server" (on page 89).
CAUTION: Clearing a collectors or servers data removes all the data they have collected.
1. In the Launchpad, select a collector or file collection service or file distribution service.
n Right click the server and select the Cleanup menu item, or
n Select the Actions: Cleanup menu item, or

n Click the Cleanup button.
You can also use the siucleanup command as described in the eIUM Command Reference for a
collector and the siucontextcleanup command for a session server.
Creating a New Collector

To create a new collector in the Launchpad, do any one of the following.
l Click the New Collector button, or

l Select the File: New Collector menu item, or
l Press Ctrl+1
Each of these brings up the New Collector window that let you create a new collector from a
template and customize it to your needs.
Alternatively you can create a new collector with the deployment editor or by importing a
configuration file using the File: Import Configuration menu item or the loadconfig command.
See "Creating Collectors" (on page 84) for complete details on how to create a new collector.
Deleting a Collector or Server

When you remove a collector or other server, the Launchpad stops the collector and permanently
removes the collectors configuration from the configuration store and removes all the collectors
data. To remove a collector, do the following:
1. In the Launchpad, select the collector or other server to delete.

2. Select the Actions: Delete menu item.
This removes all the collectors configuration information from the configuration server, all log files
and all data files created by the collector or server.
Changing Collector and Server Configurations

Each collector and eIUM server has many configuration attributes you can adjust as needed to
modify the behavior of the collector or server. The values of these attributes determine the
behavior of the collector or server. Changing a collectors attributes nearly always requires that the

collector be stopped, cleaned up and restarted before the change can take effect. All components
and their attributes are described in the eIUM Component Reference.
CAUTION: Make sure only one person modifies the configuration at a time. Multiple simultaneous
changes can cause some changes to overwrite other changes.
Change a collectors attributes as follows:

2. Do any one of the following:
n Right-click the collector and select the Edit menu item, or
n Select the Actions: Edit menu item, or
n Double-click on the collector.
Any one of these displays the Collector Configuration window.
3. In the Collector Configuration window, select the tab corresponding to the collector component
you want to view or modify. Alternatively, under either the General tab or the Setup tab you can
click the Advanced Edit button to display the Advanced Edit window, which displays the entire
collectors configuration.
4. Select the subcomponent or attribute you want to modify and do either one of the following:
n Double-click on the subcomponent or attribute.
n Right click on the subcomponent or attribute to bring up the edit menu and select a menu
item.
5. After making all your modifications, click the Apply or OK buttons to save the changes. At this
point you have only modified the collectors configuration information in the configuration
server.
6. Stop the collector, if it is running, as described in "Stopping a Collector or Server" (on page 89).
7. Clean up the collector unless you have made only very minor modifications to the collector.
Most changes to collector configurations require you to clean up the collector. See "Clearing
Collector or Server Data" (on page 91).
8. Start the collector, as described in "Starting a Collector or Server" (on page 88).
Saving a Collector, Host or Servers Configuration in a File

You can copy a collector, host, or servers configuration information to one or more text files. The
collector files can be edited and used to create other similar collectors, or as a part of a backup
procedure. You can use either the saveconfig command described in the eIUM Command Reference
or the Launchpad.
1. In the Launchpad, select a collector, host or server.

2. Select the File: Export Configuration menu item. This displays the Export Configuration window.
3. Optionally change the configuration tree root. The default is to save only the selected items
configuration, which for a collector is everything under /deployment/<host>/<collector>/.

4. To save the configuration in one file, select the File button and type in the path and name of a
file. To save the configuration in separate configuration files, one file for each node under the
item, select the Directory button and enter a directory path. Or use the Browse button to select
a directory.
5. Click the Ok button. This either saves one file containing the items entire configuration tree in
the specified file, or it saves the configuration in separate files corresponding to each item
under the specified item in the configuration tree. Each file is named with the configuration
tree node with a suffix of .config. For example, for a collector it saves Encapsulator.config,
Aggregator.config, Datastore.config, Properties.config and License.config in the specified
directory.
Changing Collector and Server Start-up Properties

You can change how a collector or server starts up in either of two ways:
l Change the host default properties, which affects all processes running on the host unless the
process explicitly overrides the host default properties. See "Changing Default Host Properties"
(on page 96) for how to change host default properties.
l Specify that the collector should override the host default properties as follows.
1. In the Launchpad, select a collector or server.
(Not all servers have properties you can set.)
3. Double click the property you want to modify, or right click the property and select the Edit
Value menu item.
4. Modify the value. Set the value to be %DEFAULTS% if you want to use the host default property
value.
5. Click OK or Apply.
6. Stop the collector or server
7. Clean up the collector if needed.
8. Start the collector or server.
Viewing Collector, Host and Server Log Files

Each collector, host and server process has a log file where it writes status messages about many of
its activities, including error messages. All log files are in C:\SIU\var\log on Windows or
/var/opt/SIU/log on UNIX in the file <collector name>.log or <host name>log or <server name>.log.
You can view these files directly or as described below. See also "eIUM Logging" (on page 172) for
information about log files.

2. Do either one of the following to display the log file in the status panel at the bottom of the
Launchpad window.
n Right click the collector, host or server and select the View Log File menu item, or
n Select the Actions: Log File menu item.

Using the Log File Viewer

To open the log file in a separate window that provides search and filtering capabilities, do the
following:

2. Do either one of the following to display the log file in the status panel at the bottom of the
Launchpad window.
n Right click the collector or server and select the Open Log Viewer menu item, or
n Select the Actions: Open Log Viewer menu item.
The log file viewer displays the log file and continuously updates the display as messages are
written to the file. Use the pause check box to stop the continuous update.
Changing Collector, Host and Server Logging Level

Each collector, host and server has a log file in C:\SIU\var\log on Windows or /var/opt/SIU/log on
UNIX. You can set the amount of information logged by the process as described below. See also
"eIUM Logging" (on page 172) for information about log files.

2. Do either one of the following to display the log level selection screen:
n Right click the collector, host or server and select the Set Log Level menu item, or
n Select the Actions: Set Log Level menu item.
3. Choose a value from the list. The lower numbered values log less information and the higher
numbered values log more information. Each level is cumulative. The 4 = Informative level is the
default. See "Log Levels" (on page 178) for what each log level means.
4. Click on the OK button.
NOTE: The host admin agent must be running to change log levels using the Launchpad. See
"Ensure eIUM Components are Running" (on page 209) for more information.
NOTE: Using any of the Debug log levels can significantly reduce collector and server
performance. Only use the Debug levels temporarily when debugging a collector or server. Debug
log messages produce a large number of detailed log messages in a short amount of time. The
internal nature of many Debug messages can make them difficult to understand. The normal log
file rolling and aging process will remove old log files when they are full. Also see "Controlling Log
File Rollover and Aging" (on page 182), and "eIUM Logging" (on page 172).
Running Collector, Host and Server Diagnostics

You can run any of several diagnostic routines on collectors, hosts and servers to determine how
they are running. See also "Perform Diagnostics" (on page 211).

2. Do either one of the following to display the diagnostics selection screen.

n Right-click the collector, host or server and select the Diagnostics menu item, or
n Select the Actions: Diagnostics menu item.
3. Select one or more diagnostics to run.
4. Click the Execute button to perform the diagnostics and display the results of the diagnostic
tests. Click the Save button to save the results of the diagnostic tests to a file.
Managing the MySQL Database

This section describes some ways to manage the MySQL database. The JDBCDatastore uses the
MySQL database to store collector metadata and usage data. Even if you use another datastore
(such as the FileJDBCDatastore), metadata is stored in the MySQL database by default (assuming
you installed the MySQL database with eIUM, selected it during activation, and the specific collector
configuration did not overwrite this).
During eIUM activation, a database is selected. This can be MySQL if you purchased this product
extension with eIUM, or it can be some other external database (such as Oracle) that you maintain.
Several configuration variables are assigned with values corresponding to this database. As
described in "The Environment Node" (on page 98), these values are stored under
/deployment/<host>/Environment and can be used in the collector configuration. For example, when
creating a Demo collector and then examining its /Datastore] configuration node, the following can
be observed:
[/deployment/host01/collector1/Datastore]
ClassName=JDBCDatastore
Database=${DATABASEURL}
DatabaseClass=${DATABASECLASS}
Password=${DATABASEPASSWORD}
User=${DATABASEUSER}
The ${DATABASEURL}, ${DATABASECLASS}, ${DATABASEPASSWORD}, and ${DATABASEUSER} variables

refer to the default database configured with eIUM. Other values can be specified if you want this
specific collector to use a non-default database. If you elect to use another database technology,
you are responsible for maintaining that database externally. For more information on installation
and activation of eIUM and MySQL, see the eIUM Installation Guide.
Diagnostic Tools for the Datastore

In general, the MySQL database is installed with the product and managed by eIUM, and does not
require any separate maintenance beyond standard backups. To run diagnostics however, you can
use the mysql command-line tool (if you installed MySQL with eIUM), which can typically be found in
C:\SIU\mysql\bin (Windows), or /opt/SIU/mysql/bin (UNIX). Typically, you can start it and connect to
the corresponding MySQL server instance using the %BINROOT%/sbin/mysql.sh script (UNIX only),
and use the connect option, along with providing the user name and password:
$>./mysql.sh connect -usiu20 -psiu20
See http://dev.mysql.com/doc/refman/5.1/en/mysql.html for more information on the mysql

command-line tool. Also see "Backing Up Your eIUM Deployment" (on page 156) for more
information on backing up your deployment.

Chapter 6
Managing Host Systems

Your eIUM deployment consists of one or more host systems on which the configuration server,
collectors and other servers run. Each host has a Host Admin Agent, a process that manages all the
other eIUM processes on the host. This section describes how to manage the host admin agent and
other aspects of each eIUM host.
Changing Default Host Properties 96
Enabling IPv6 97
The Environment Node 98
Overriding Default Host Properties 99
Restarting the Host Admin Agent 100
Windows Commands 100
UNIX Commands 100
Upgrading to a New Version of Java 101
Viewing Host Log Files 103
Changing Host Logging Level 103
Running Host Diagnostics 103
Adding a New Host 103
Saving a Hosts Configuration in a File 104
Changing Default Host Properties

Each process (collector, configuration server, host admin agent, report server, and any other server)
on the host uses several properties whenever it starts running, for example Java run-time
properties. Each host defines default values for these properties. Each process on the host can
either use these host default properties or override one or more of them.
You can change the host default properties on each host system as described here. See also
"Changing Collector and Server Start-up Properties" (on page 93).
Change the host default properties as follows:
1. In the Launchpad, select a host.

2. Select the Actions: Host Default Properties menu item or right-click on the host and select the
Host Default Properties menu item. This displays the host default properties.
3. Double click the property you want to change, or right-click a property to display the edit menu.
If a property is not listed, it is not yet defined. To add a property, right-click the Defaults node

Chapter 6: Managing Host Systems
and select the Add Attribute menu item. Enter the name of the property to add and a value for
the property (see the below table).
4. Select Apply or OK to save the changes.
5. Restart the host admin agent as described in "Restarting the Host Admin Agent" (on page 100).
Any process started on the host with the Launchpad uses the new property values.
The host default properties are stored in the configuration tree under
/deployment/<host>/Defaults. Any properties for a particular process that override the host
defaults are stored in the configuration tree under that processs configuration node under
/Properties. For example, the property STARTUPMODE for a collector named C1 on host H1 would be
at /deployment/H1/C1/Properties/STARTUPMODE.
The table below describes the host default properties.
Host Default Properties

Property Description
CLASSPATH The locations for Java to look for Java classes.
JVM The location of the Java virtual machine.
JVMOPTS Command line options when running Java.
JVMPROPERTIES Start-up properties used by Java.
JVMW The location of the Java virtual machine using windows.
KEEPPROCESSALIVE Specifies whether the process should continue running even if the host
admin agent stops running. Set to TRUE or FALSE or %DEFAULTS%.
STARTUPMODE Determines whether the process should be started automatically when the
host admin agent starts, for example whenever the system is rebooted. If
you want the collector or server to be started automatically, set
STARTUPMODE=AUTOMATIC. Otherwise set STARTUPMODE=MANUAL. You can
also set STARTUPMODE=%DEFAULTS% to use the host default property value.
RESTARTWAITTIME Specifies how many seconds to wait before attempting to restart a collector
that has stopped running unexpectedly. The default is 60 seconds.
MAXRESTARTTIMES Specifies the maximum number of times to attempt to restart a collector

that has stopped unexpectedly. The default is 3 times.
Enabling IPv6
To enable IPv6 on some systems, you will need to explicitly instruct the JVM to use the IPv6 stack.
You can enable this by specifying the following arguments in the eIUM Launchpad Actions -> Host
Default Properties JVMPROPERTIES settings: "java.net.preferIPv6Addresses=true" and
"java.net.preferIPv4Stack=false". See Oracle's web site for more information about IPv6 support in
Java.
eIUM components that support configuration and handling of IPv6 addresses include the following:

l NMESchema: the new "com.hp.siu.utils.IPv6AddrAttribute" NME attribute type can be configured

in the NMESchema to represent IPv6 address attributes, and Datastore components support
saving IPv6 addresses.
l The AdornmentRule, ConditionalRule, DemoEncapsulator, and FilterRule can generate and
process IPv6 attributes through configuration.
l The following components are certified to be capable of communicating with remote IPv6 hosts:
CiscoCSGGTPpConnector, CorbaConnector, CorbaQueryConnector, DeliveryFTP, DeliverySFTP,
DiameterAdapter, ESMEConnector, FTPSource, JDBCSessionStore, JNDILookupRule,
MultiClientPCubeEncapsulator, NMERPCClientAdapter, NMERPCServerAdapter, and SFTPSource.
For additional information about these components, see the eIUM Component Reference.
The Environment Node

A further Environment configuration node contains environment variables as its attributes, which
are common at the root, host, or server levels. Attributes in different collectors meanwhile refer
back to the environment variables. The Environment node can be configured at different levels:
l Root: /Environment
l Host: /deployment/<host>/Environment
l Server: /deployment/<host>/<server>/Environment
The environment variables are defined in terms of ${variable} notation (for example,
${DATABASEURL}), and use a system of precedence based on the setting of the lowest-level node in
the configuration tree, versus the Environment levels above. For example, the precedence order is
defined as follows:
l /Environment (lowest precedence)

l /deployment/<host>/Environment (overrides /deployment/Environment)
l /deployment/<host>/server/Environment (overrides all others, takes the highest precedence)
For example, since /deployment/<host>/server/Environment takes precedence over
/deployment/<host>/Environment, the following configuration shows that the value of MyVariable
under [/deployment/Host1/DemoCollector/Environment/] at runtime will be value1.
[/deployment/Host1/DemoCollector/Environment/]
MyVariable=value1
[/deployment/Host1/Environment/]
MyVariable=value2
For attribute values that are repeated throughout a configuration, such a system allows you to set
environment variables globally (without having to manually search and replace all values), and also
control which Environment node in the configuration takes precedence over another. In eIUM, the
host-level environment (/deployment/<host>/Environment) exists by default and contains
database-related variables for the host. Root- and server-level environments can be created and
populated manually.
NOTE: During an upgrade installation of eIUM with the MySQL product extension, all existing
configurations in your deployment are updated to work with MySQL. This includes updating of: (1)
the /deployment/<host>/Environment node with values pointing to MySQL, and (2) all

configurations (including templates) with database values pointing to the Environment variables.
See "Managing the MySQL Database" (on page 95) for more information on these variables.
Overriding Default Host Properties

Each process (configuration server, collector, host admin agent, report server, and so forth) running
on a host uses either the host default property values or its own local values when starting. You can
override any of the host default property values by defining local values for individual processes as
follows.

(Not all servers have properties you can set.)
3. Double click the property you want to modify, or right click the property and select the Edit
Value menu item.
4. Modify the value. Set the value to be %DEFAULTS% if you want to use the host default property
value.
5. Click OK or Apply.
6. Stop the collector or server
7. If you are setting properties for a collector, clean up the collector, if needed.
8. Start the collector or server.
The table below lists other server-specific properties you can set.
Other Server-Specific Properties

Propertty Description
KEEPPROCESSALIVE This property only applies to the host admin agent.
MAXRESTARTTIMES This property only applies to the host admin agent.
NotifyCommand This property only applies to the host admin agent. It specifies an external
command that is executed whenever a process on the host starts or stops.
No host default exists for NotifyCommand.
See the white paper Controlling eIUM with HP OpenView for an example of
how this can be used to integrate eIUM with HP OpenView.
PROCESSARGS This specifies command arguments to use when running an eIUM Java
process. No host default exists for PROCESSARGS. Each process must
specify its own PROCESSARGS.
RESTARTWAITTIMES This property only applies to the host admin agent.
STARTCONFIGSERVER This applies only to the host admin agent on the host where the
configuration server is to run. It specifies whether or not the host admin
agent should start the configuration server.

The property value %DEFAULTS% means use the host default values. Some multi-valued properties,
for example CLASSPATH, can use the host default values in addition to the overridden values. Specify
%DEFAULTS% as one of the values. Specify any values to be used in addition to the host defaults.
When the selected process starts, it uses all the overridden values and default values for properties
not overridden. To force the process to use the new configuration values immediately, stop and
restart the process.
Restarting the Host Admin Agent

The host admin agent is a process on each eIUM host system that controls all other eIUM collectors
and servers on that host. The host admin agent must always be running on every eIUM host.
The host admin agent is installed as a Windows service or UNIX daemon. Normally you do not need to
stop or start the host admin agent because it is started automatically after installation is complete
and whenever the system is rebooted. However, if you change any host start-up properties, you
need to restart the host admin agent for the changes to take effect.
Windows Commands
On Windows restart the host admin agent using one of the following ways. In a command window,
enter the following commands:
net stop SIU_AdminAgentServer
net start SIU_AdminAgentServer
Or, use the Windows Services Administrative Tool as follows.
1. Select Start -> Control Panel.

2. Open the Administrative Tools.
3. Open Services.
4. Select SIU_AdminAgentServer.
5. Click the Stop Service button.
6. Click the Start button.
This starts the host admin agent and all the processes it controls on the host. You can also use the
siucontrol command to restart the host admin agent. See the eIUM Command Reference for details
on eIUM commands.
UNIX Commands
On UNIX restart the host admin agent as follows:
1. Log in as root to the UNIX host.

2. Enter one of the following commands:
/sbin/init.d/SIU stop_agent # on HP-UX
/etc/init.d/SIU stop_agent # on Linux and Solaris
3. Start the host admin agent with one of the following commands:

/sbin/init.d/SIU start_agent # on HP-UX

/etc/init.d/SIU start_agent # on Linux and Solaris
This starts the host admin agent and all the processes it controls on the host. You can also use the
siucontrol command to restart the host admin agent. See the eIUM Command Reference for details
on eIUM commands.
Upgrading to a New Version of Java

This section describes how to install and run a new version of the Java SDK (Software Development
Kit). This section presumes you have installed a Java SDK and eIUM according to the instructions in
the eIUM Installation Guide.
See the eIUM Customer Support web site at http://www.hp.com/support/usage/supported/ for the
specific versions of Java that are supported by eIUM. For the user name and password to access the
web site, see the eIUM 8.0 Release Notes.
You must also download and install the Java Cryptography Extension (JCE) when eIUM security will be
enabled. See Securing eIUM in the eIUM Installation Guide for instructions.
To install a new version of Java, do the following.
1. Install the new version of the Java SDK and required patches, if any, according to the
instructions accompanying the software.
2. Determine where the java executable file is for the version of the Java SDK you have installed.
On Windows, also locate the javaw.exe executable file. The following table shows sample
directories.
NOTE: The following are only typical locations of Java executables. Be sure to check the Java
location before installation.
On HP-UX and Solaris, the default JVM supports both 32- and 64-bit address spaces. On such
64-bit platforms, the eIUM installer defaults to 32-bit mode, whereby certain instructions
must be followed when enabling the 64-bit version of eIUM. In addition, eIUM can be returned
to the 32-bit version by following the same setup instructions. For Linux and Windows, there
are dedicated 32- and 64-bit Java binaries, while for Solaris there are 32-bit installers plus
add-ons for 64-bit support. Conversely for HP-UX, a single installer supports both 32- and 64-
bit modes.
See the eIUM Installation Guide section After Installation - Enabling the 64-bit Version of
eIUM for more information.
Typical Locations of Java Executable Files

Operating System Typical Location
HP-UX /opt/java1.6/bin/java
32-bit HP-UX uses the same Java executable for both 32- and 64-bit.
HP-UX /opt/java1.6/bin/java
64-bit HP-UX uses the same Java executable for both 32- and 64-bit.
Solaris /opt/java1.6/bin/java

Operating System Typical Location
32-bit Solaris uses the same Java executable for both 32- and 64-bit.
Solaris /opt/java1.6/bin/java
64-bit Solaris uses the same Java executable for both 32- and 64-bit.
Linux /opt/java1.6_32/bin/java
32-bit
Linux /opt/java1.6_64/bin/java
64-bit
Windows C:\Program Files\Java\jdk1.6.0_04\bin\java.exe

32-bit C:\Program Files\Java\jdk1.6.0_04\bin\javaw.exe
Windows C:\Program Files\Java\jdk1.6.0_04\bin\java.exe

64-bit C:\Program Files\Java\jdk1.6.0_04\bin\javaw.exe
3. In the Launchpad, select the host where you have installed the new Java SDK.
4. Select the menu item Actions -> Host Default Properties. This displays the properties that are
used by default by all eIUM processes running on the host.
5. Change the JVM and JVMW properties to refer to the appropriate version of the java executable
file. On Windows, set the JVMW property to the javaw.exe file. See the table below for example
settings.
Sample JVM and JVMW Properties
Operating System Sample JVM and JVMW Properties
HP-UX JVM=/opt/java1.6/bin/java
32-bit JVMW=/opt/java1.6/bin/java
HP-UX JVM=/opt/java1.6/bin/java
Solaris JVM=/opt/java1.6/bin/java
Solaris JVM=/opt/java1.6/bin/java
Linux JVM=/opt/java1.6_32/bin/java
32-bit JVMW=/opt/java1.6_32/bin/java
Linux JVM=/opt/java1.6_64/bin/java
64-bit JVMW=/opt/java1.6_64/bin/java
Windows JVM=C:\Program Files\Java\jdk1.6.0_04\bin\java.exe

32-bit JVMW=C:\Program Files\Java\jdk_1.6.0_04\bin\javaw.exe
Windows JVM=C:\Program Files\Java\jdk1.6.0_04\bin\java.exe

64-bit JVMW=C:\Program Files\Java\jdk1.6.0_04\bin\javaw.exe

6. Click Ok to save your changes.

7. Exit the Launchpad.
8. Stop the eIUM Host Admin Agent. See "Restarting the Host Admin Agent" (on page 100) for
specific instructions.
9. Use the activateSIUJava command to activate the desired mode. For example, the following
activates the 64-bit version of eIUM and creates 64-bit command aliases for all eIUM
commands in the BINROOT directory:
java -jar /opt/SIU/sbin/activateSIUJava.jar /opt/SIU -act64
The following activates the 32-bit version of eIUM and creates 32-bit command aliases for all
eIUM commands in the BINROOT directory:
java -jar /opt/SIU/sbin/activateSIUJava.jar /opt/SIU -act32
The following just creates command aliases for all eIUM commands in the BINROOT directory
based on the current size setting:
java -jar /opt/SIU/sbin/activateSIUJava.jar /opt/SIU -createAliases
For more information, see the eIUM Command Reference.

10. Restart the eIUM Host Admin Agent. See "Restarting the Host Admin Agent" (on page 100) for
specific instructions.
Viewing Host Log Files

On each host, the admin agent process controls all collectors and other eIUM processes on the host.
You can view the host admin agents log file by selecting the host in the Launchpad and right-
clicking the host in the Launchpad and selecting Log File.
See also "Viewing Collector, Host and Server Log Files" (on page 93) and "Maintaining and
Troubleshooting eIUM" (on page 206) for more information about log files.
Changing Host Logging Level

Each host admin agent has a log file in C:\SIU\var\log\<host name>.log on Windows and
/var/opt/SIU/log/<host name>.log on UNIX where many host activities are recorded. You can set the
amount of information logged by right-clicking the host in the Launchpad and selecting the Set Log
Level menu item.
See also "Changing Collector, Host and Server Logging Level" (on page 94) and "Maintaining and
Troubleshooting eIUM" (on page 206) for more information about log files.
Running Host Diagnostics

You can run any of several diagnostic routines on hosts to determine how the host admin agent is
running. See "Running Collector, Host and Server Diagnostics" (on page 94) for detailed instructions.
See also "Maintaining and Troubleshooting eIUM" (on page 206).
Adding a New Host

To add another host to your eIUM environment you install eIUM on the new host and specify the
IORURL to the configuration server. This adds the host to the configuration. See the HP eIUM

Installation Guide for details.
Saving a Hosts Configuration in a File

You can copy a hosts configuration information to a text file. For complete instructions, see "Saving
a Collector, Host or Servers Configuration in a File" (on page 92).


Chapter 7
Managing Users and Security

With the optional eIUM security module, you can secure your environment by requiring users to log
in to eIUM before viewing or modifying your eIUM deployment. The optional security module also
provides secure communications between eIUM components by using SSL encryption.
NOTE: You must install the optional eIUM security module before you can create user logins. See
the eIUM Installation Guide for instructions on installing security.
eIUM security uses an LDAP directory for authentication and authorization. This documentation
assumes you are familiar with LDAP directories and commands and with your enterprise LDAP
directory structure.
CAUTION: It is strongly recommended you plan to restart your servers before their security
certificates expire to avoid the servers shutting down unexpectedly. See "Certificate Expiration
Alerts" (on page 120) for more information.
CAUTION: It is strongly recommended you change the security server port number and the shut
down command to custom values for added security. For instruction see "Changing the Security
Server Port Number" (on page 108) and "Changing the Security Server Shutdown Keyword and
Port Number" (on page 108).
Activating eIUM Security 107
Deactivating eIUM Security 107
Validating the Security Server Setup 107
Adding a Host to a Secure eIUM Deployment 108
Changing the Security Server Port Number 108
Changing the Security Server Shutdown Keyword and Port Number 108
Modifying the LDAP Data Organization Structure 109
Switching Authentication Methods and Authentication Servers 109
Disabling Data Encryption in a Secure eIUM Deployment 110
Setting up Users 111
Roles for a Junior Operator 111
Roles for a Senior Operator 112
Roles for an Administrator 112
User and Host Roles and Privileges 112
Managing Security Data for Users, Hosts and Servers 114
Identities Data 114

Chapter 7: Managing Users and Security
Groups 115
Adding a New User Identity 115
Removing a User Identity 116
Adding a New Host Identity 117
Removing a Host Identity 117
Viewing and Verifying Security Data 118
Managing Your Security Certificates 118
Types of Certificates 118
Audit Logging 124
Controlling Audit Logging for the Security Server 124
Controlling Audit Logging for Other eIUM Servers 125
Activating eIUM Security

When you install eIUM, security is not installed by default. To install and activate eIUM security, you
must follow the instructions in the eIUM Installation Guide.
Deactivating eIUM Security

To remove security from your eIUM deployment, you must follow the instructions in the eIUM
Installation Guide.
Validating the Security Server Setup

This section shows you how to make sure your security server is set up and running properly. The
eIUM Security Server is responsible for facilitating secure access to a secured deployment. Unless
the Security Server is correctly configured and available, the secure eIUM deployment cannot
operate correctly. To ensure your Security Server is correctly configured and is accessible follow this
procedure.
1. Open an internet browser and go to the following URL:

https://<security server host>:<security server port>/security/directory
For example, if your security server host were system1 and the port number were 8443, you
would enter the following URL in the web browser:
https://system1:8443/security/directory
2. If your SecurityServer is running and available, you will be prompted to authenticate your
identity. Enter the name and password of a user that has the SecurityAdmin role. See "User and
Host Roles and Privileges" (on page 112) for details on roles.
3. If the given identity is authenticated and authorized to have the SecurityAdmin privileges, you
will be presented with a tree view of the security data tree. The security data tree is organized
as /treeview/securitydata/<domain component 1>/ <domain component 2>/.../<identity

name>/<Role name nodes>

4. Inspect the security data tree view to ensure that the Security Server is using the correct
security data and that the roles are correctly associated with the required identities.
Adding a Host to a Secure eIUM Deployment

To add a host to a secure eIUM deployment, you must follow the instructions in the eIUM Installation
Guide.
Changing the Security Server Port Number

Communication exchanges between the eIUM Security Server and eIUM deployment entities use the
HTTPS protocol. By default the Security Server listens for HTTPS requests at port 8443. You can
change the Security Server to use another port for HTTPS requests as follows.
1. Stop the eIUM Security Server using the following command:

$SIUHOME/bin/securityserver stop
2. Open the configuration file %VARROOT%/securityserver/conf/server.xml in a text editor and go

to the following section:

<Connector port="8443" maxHttpHeaderSize="8192"
3. Change the port attribute value to the new port number.

4. Restart the Security Server using the following command:
$SIUHOME/bin/securityserver start
5. On each eIUM host, run the following command to regenerate the %VARROOT%/security-
login.config file with the updated Security Server port number.
secactivate init
Changing the Security Server Shutdown Keyword and Port Number

The eIUM Security Server process listens for management commands at port 8007 by default. The
process can be shut down by sending the command SHUTDOWN to this port. You can change the
default shut down command name as follows.
Do not place an empty string in the shutdown command string.
1. Stop the eIUM Security Server using the following command:

2. Open the configuration file $VARROOT/securityserver/conf/server.xml in a text editor and go to

the following section:
<Server port="8007" shutdown="SHUTDOWN">
3. Change the port number, if desired. Change the shutdown attribute value to the new command
name.


Modifying the LDAP Data Organization Structure

If you want to modify the LDAP data organization in the secondary LDAP server that hosts your eIUM
security data, you must repeat some of the steps that are part of the activation process, as
described below.
1. Locate the properties file containing your eIUM security server directory layout that you
created during eIUM activation. This file is based on the example layout properties file provided.
See the eIUM Installation Guide for more information.
2. Modify the directory layout properties file to reflect your new directory structure.
3. Regenerate the LDIF files for security identities as described in the eIUM Installation Guide. Use
the ldifgen command to generate the LDIF files.
4. Load the LDIF files into your secondary LDAP directory server.
5. Restart the eIUM security server to make the directory layout change take effect.
Switching Authentication Methods and Authentication Servers

You can switch between LDAP bind or Kerberos authentication methods anytime using the
procedure described below. You can also use this procedure to switch to different a LDAP server or a
different Kerberos Key Distribution Center (KDC) server.
For complete instructions on installing eIUM security, see the eIUM Installation Guide.
To switch to LDAP bind authentication method or to use a different LDAP server, do the following.
1. Stop the security server by running the following command:

2. Run a command like the following specifying your own LDAP server URLs and your own user and
password:
For Active Directory:
$SIUHOME/bin/secserveractivate init
-loginldapserver "ldap://primaryserver:10389/"
-lookupldapserver "ldap://secondaryserver:10389/"
-layout my-edited-external-dir.properties
-user "CN=Administrator,CN=Users,DC=example,DC=hp,DC=com"
-password "password" -force
For ApacheDS:
-loginldapserver "ldap://primaryserver:10389/"
-user "uid=admin,ou=system"
-password "secret" -force

3. Restart the security server by running the following command:

For details on the securityserver and secserveractivate commands, see the eIUM Command
Reference. To switch to the Kerberos authentication method or to use a different KDC server, do the
following.
1. Stop the security server by running the following command:

2. Run a command like the following specifying your own Kerberos host, port and realm and your
own user and password:
For Active Directory:
$SIUHOME/bin/secserveractivate init -krb -kdchost "<kdc host name>"
-kdcport "<kdc port>" -dr "<kerberos realm name>"
-layout external-dir.properties
-user "CN=Administrator,CN=Users,DC=example,DC=hp,DC=com"
-password "password" -force
For ApacheDS:
-krb -kdchost "<kdc host name>" -kdcport "<kdc port>"
-dr "<kerberos realm name>"
-user "uid=admin,ou=system"
-password "secret" -force
3. Restart the security server by running the following command:

For details on the securityserver and secserveractivate commands, see the eIUM Command
Reference.
Disabling Data Encryption in a Secure eIUM Deployment

This section describes how to turn off data encryption in your secure eIUM deployment while
keeping user authentication and authorization. When security is enabled in your eIUM deployment,
CORBA remote procedure calls encrypt the data exchanged between eIUM components at the
transport layer using SSL encryption. You can disable transport layer SSL data encryption by
configuring system properties as described below.
1. Stop all eIUM processes on each eIUM host, except for the host admin agent. This includes all
charging managers, collectors, file services, Launchpads, Operations Consoles and so forth.
2. On any one of your eIUM hosts, open a command window in the directory SIUHOME\lib\patches.
3. Run the following command. This creates the file SIUHOME\lib\patches\jacorb.properties.
JDK_HOME\bin\jar -xvf ..\siuutils.jar jacorb.properties

For example, if your Java JDK were in the directory C:\Program Files\java\jdk1.6.0_04, then the
command would look the following:
C:\Program Files\java\jdk1.6.0_04\bin\jar -xvf ..\siuutils.jar
jacorb.properties
4. Open the file jacorb.properties in a text editor.

5. Locate the following lines in this file and uncomment them by removing the # character at the
beginning of each line.
#jacorb.security.ssl.server.cipher_suites=SSL_RSA_WITH_NULL_
SHA,SSL_RSA_WITH_NULL_MD5
#jacorb.security.ssl.client.cipher_suites=SSL_RSA_WITH_NULL_
SHA,SSL_RSA_WITH_NULL_MD5
The lines should look as follows:

jacorb.security.ssl.server.cipher_suites=SSL_RSA_WITH_NULL_SHA,SSL_
RSA_WITH_NULL_MD5
jacorb.security.ssl.client.cipher_suites=SSL_RSA_WITH_NULL_SHA,SSL_
RSA_WITH_NULL_MD5
6. Restart the host admin agent. For instructions, see "Restarting the Host Admin Agent" (on page
100).
7. Copy the file you modified, jacorb.properties, to each of your other eIUM hosts. Place the file in
the directory SIUHOME\lib\patches.
8. Restart the host admin agent on each of your other eIUM hosts. For instructions, see
"Restarting the Host Admin Agent" (on page 100).
Setting up Users
When you create a new eIUM user in a secure eIUM environment, you must give the user appropriate
privileges based on what they will be doing with eIUM. This section describes three possible positions
and the corresponding roles. Also see "User and Host Roles and Privileges" (on page 112) for more
information on privileges.
For instructions on adding a new user to a secure eIUM deployment, see the eIUM Installation Guide.
Roles for a Junior Operator

This section describes the roles to assign to a junior operator who would have only the ability to
monitor eIUM processes in the deployment. This person would have the following roles:
l User - This role is required for all eIUM users.

l Monitor - View status of eIUM processes.
l Diagnostics - View log files and process statistics.
l ConfigRead - View the eIUM deployment topology.
l ReportUser - View reports produced by the eIUM reporting web applications.
l RefdataRead - View Reference Data Manager tables that belong to the DEFAULT category.

Roles for a Senior Operator

This section describes the roles to assign to a senior operator who would have all the privileges of
the junior operator plus the ability to create groups of eIUM processes, query the data stored in
eIUM collectors and start and stop eIUM processes. This person would have the following roles:

l Query - View collected data from eIUM processes.
l Management - Create, modify and delete groups of eIUM processes in the Operations Console.
l ServerAdmin - Start and stop eIUM processes.
l ReportUser - View reports produced by the eIUM reporting web applications.
l RefdataRead - View Reference Data Manager tables that belong to the DEFAULT category.
l RefdataWrite - View and edit Reference Data Manager tables that belong to the DEFAULT
category. See "Security" (on page 55) for more information on RDMsecurity.
Roles for an Administrator

This section describes the roles to assign to an eIUM administrator who would have full capabilities
including modifying configurations and setting up the eIUM security environment. This person would
have the following roles:

l Query - View collected data from eIUM processes.
l Management - Create, modify and delete groups of eIUM processes in the Operations Console.
l ServerAdmin - Start and stop eIUM processes.
l ConfigWrite - Create and edit eIUM configurations.
l SecurityAdmin - Perform security administrative tasks.
l ReportAdmin - Manage all reports (create, edit, and deletion operations).
User and Host Roles and Privileges

This section describes eIUM roles and corresponding privileges. When you set up users for eIUM
tools such as the Launchpad, the Operations Console, the Reference Data Manager, SNAP Studio,
and eIUM commands, you must give each user the roles that allows them to perform the tasks they
need to perform. See the following tables for eIUM roles and the privileges accorded to each role.

eIUM User Roles and Privileges

User Role Privileges
User Designates a person who will use eIUM (as opposed to an eIUM host or
process.) Give this role to every user.
Monitor Allows the user to view the status of eIUM processes. See also the
Diagnostics role.
Diagnostics Allows the user to run diagnostics activities such as viewing log files and
process statistics. See also the Monitor role.
ConfigRead Allows the user to view the deployment configurations in the configuration
server, for example through the Launchpad or the saveconfig command. In
the Operations Console, this allows the user to see the deployment topology
of charging managers, collectors and so forth.
Query Allows the user to query the data of an eIUM process such as a collector or
charging manager using, for example the Launchpad or the siuquery
command.
ReportUser Allows view-only access to web applications, such as Reports and Audit
Reports. Users must have this role in order to access web applications.
RefdataRead View Reference Data Manager tables that belong to the DEFAULT category.
RefdataWrite View and edit Reference Data Manager tables that belong to the DEFAULT
category. See "Security" (on page 55) for more information on RDMsecurity.
RTPStudioViewer Allows the user to view the SNAP Studio with only read-only permissions. For
additional details on SNAP Studio, see the eIUMStudio User Guide.
RTPStudioDesigner Allows the user to create, update, and delete entities under Technical View
and Business View of SNAP Studio.
RTPStudioOperator Allows the user to manage operations under OMC and Administration.
The following table describes the administrative roles and privileges.
eIUM Administrator Roles and Privileges

Administrator
Role Privileges
ConfigWrite Allows the user to modify the configurations in the configuration server, for
example through the Launchpad or the loadconfig command.
Caution - This capability allows a user to modify your eIUM deployment.

Administrator
Role Privileges
ServerAdmin Allows the user to perform administrative operations on eIUM processes, for
example start, stop and clean up charging managers, collectors, file services
and other eIUM processes. Also allows the user to perform administrative
actions on the eIUM security server such as generating the host key.
SecurityAdmin Designates the eIUM security administrator. Allows the user to perform all
security-related activities such as security setup and configuration.
Management Allows the user to create, delete and modify groups of servers in the eIUM
Operations Console. For more information about the Operations Console, see
the Operations Console User Guide.
UserAdmin This role is deprecated and is only retained for backward compatibility.
ReportAdmin Allows report management, such as creating, editing, and deleting of reports.
ReportAdmin is required to access the Web Application server and Audit Report
server for access to eIUM web applications and managing reports when security
is enabled. ReportAdmin is needed if you create, edit, or delete reports (while in
contrast, only ReportUser is needed to just view the reports).
RTPStudioAdmin Allows the user to manage the SNAP Studio with all permissions. For additional
details on SNAP Studio, see the eIUMStudio User Guide. This role also includes
the permissions of all Real-Time Engine based-roles (namely, RTPStudioViewer,
RTPStudioDesigner, and RTPStudioOperator).
The following table lists additional eIUM roles only for eIUM hosts and processes.
eIUM Host Roles

Host
Role Description
Server Designates an eIUM server such as a charging manager, a collector, the configuration
server, the Launchpad and so forth.
Host Designates an eIUM host system where eIUM processes are running.
Managing Security Data for Users, Hosts and Servers

The eIUM Security Server relies on security data to authenticate claimed identities and authorize
requested operations. The security data primarily consists of identities data and groups data.
Identities Data
Identities data consists of distinguished names of all the identities that can be claimed in a secure
eIUM deployment. Identities data can be further classified into user identities representing a

person, host identities representing an eIUM host system and server identities representing eIUM
processes such as the configuration server, charging managers, collectors and so forth.
User identities
A user identity represents the identity of a human user in the deployment. Typically it is a subset of
the set of user identities in the enterprise and is stored in a database accessible to the
authentication server used. The user identity information includes information required to verify the
claimed identity such as a user password depending on the authentication method used.
If the authentication method used is LDAP bind, you can find your authentication server URL that is
in use in the ExternalUserLogin.java.naming.provider.url login module configuration attribute in the
configuration file SIUVARROOT/securityserver/conf/external-login.properties.
If the authentication method used is Kerberos, you can find your authentication server URL that is in
use in the kdc property of realms configuration in the kerberos client configuration file
SIUVARROOT/securityserver/conf/krb5.conf.
Host identities
Host identities represent eIUM host systems that are part of a secure eIUM deployment. These
identities are stored in the eIUM-specific LDAP server. You can find the eIUM security data LDAP
server URL that is in use in the LdapDirectoryUserLookupModule.java.naming.provider.url login
module configuration attribute in the configuration file SIUVARROOT/securityserver/conf/external-
login.properties.
Server Identities
Server identities represent eIUM servers that are part of a secure eIUM deployment, such as the
configuration server, charging managers, collectors and so forth. These identities are stored in the
eIUM-specific LDAP server relative to the identities of the hosts on which the server is hosted. You
can find the eIUM security data LDAP server URL that is in use in the
LdapDirectoryUserLookupModule.java.naming.provider.url login module configuration attribute in
the configuration file SIUVARROOT/securityserver/conf/external-login.properties.
Groups
Groups represent eIUM deployment roles that any identity can be associated with to give the
identity a set of privileges associated with the given role. Groups are stored in the eIUM-specific
LDAP server. See the eIUM Installation Guide for details on setting up the Group entries for your
eIUM deployment.
You can find the eIUM security data LDAP server URL that is in use in the
LdapDirectoryUserLookupModule.java.naming.provider.url login module configuration attribute in
the configuration file SIUVARROOT/securityserver/conf/external-login.properties.
Adding a New User Identity

The first step in adding a new user identity is to add the new user identity into your authentication
server using administration tools provided by the authentication server. If you are using a shared
enterprise authentication server, this step is not typically required as the user identity would
already exist in the server. The second step is to associate the user identity with an eIUM
deployment group by generating and importing an LDIF file into the LDAP server containing your
eIUM security data as described below.
Run one of the following commands depending on the LDAP server type:

l For Microsoft Active Directory LDAP server:

ldifgen gen -type active-directory -user "<user name>" -roles
"<group1>, <group2>, ..."
l For ApacheDS LDAP server:

ldifgen gen -type apache-ds -user "<user name>" -roles "<group1>,
<group2>, ..."
l For RedHat Directory Server:

ldifgen gen -type redhat -user "<user name>" -roles "<group1>,
<group2>, ..."
l For OpenLDAP Server:

ldifgen gen -type open-ldap -user "<user name>" -roles "<group1>,
<group2>, ..."
Upload the generated $VARROOT/ldif/<user name>/user-add-<user name>.ldif file into the primary
LDAP server (ApacheDS, OpenLDAP, RedHat DS), or use vendor-specific administrative tools to create
the required user profile (Active Directory, RedHat DS). Upload the generated $VARROOT/ldif/<user
name>/user-groups-add-<user name>.ldif file into the secondary LDAP server.
NOTE: In a single-directory configuration, this is the same as the primary LDAP server.
You do not need to restart the Security Server.
Removing a User Identity

You can remove a user identity from an eIUM deployment by disassociating the identity from all
eIUM deployment groups. Do this by generating and importing an LDIF file into your LDAP server
containing the eIUM security data as described below.
Run one of the following commands depending on your LDAP server type.

ldifgen gen -type active-directory -user -remove "<user name>" -
roles "<group1>, <group2>, ..."

ldifgen gen -type apache-ds -user -remove "<user name>" -roles

ldifgen gen -type redhat -user -remove "<user name>" -roles

ldifgen gen -type open-ldap -user -remove "<user name>" -roles
Upload the generated $VARROOT/ldif/<user name>/user-groups-remove-<user name>.ldif file into

the secondary LDAP server to disassociate given roles from the user profile.

NOTE: In a single-directory configuration, this is the same as the primary LDAP server.
If required, upload the generated $VARROOT/ldif/<user name>/user-remove-<user name>.ldif file

into the primary LDAP server (ApacheDS, OpenLDAP, RedHat DS), or use vendor-specific
administrative tools (Active Directory, RedHat DS) to delete the user profile permanently from the
directory. You do not need to restart the Security Server.
Adding a New Host Identity

To add a new host identity, you must create a new host identity entry under the hosts group in the
security data tree stored in the eIUM security data LDAP server. The identity must be associated
with a set of groups. This can be accomplished by generating and importing an LDIF file into the
LDAP server containing your eIUM security data, as described below.
Run one of the following commands, depending on the LDAP server type.

ldifgen gen -type active-directory -host "<eIUM host name>"

ldifgen gen -type apache-ds -host "<eIUM host name>"

ldifgen gen -type redhat -host "<eIUM host name>"

ldifgen gen -type open-ldap -host "<eIUM host name>"
Upload the generated LDIF file $VARROOT/ldif/<eIUM host name>/host-add-<host name>.ldif into
the eIUM security data LDAP server. You do not need to restart the Security Server.
Removing a Host Identity

You can remove a host identity from an eIUM deployment by disassociating the identity from all
eIUM deployment groups it was associated with and removing the host identity entry from the hosts
group in the LDAP tree. Do this by generating and importing an LDIF file into the eIUM security data
LDAP server as described below.
Run one of the following commands, depending on the LDAP server type.

ldifgen gen -type active-directory -host -remove "<eIUM host name>"

ldifgen gen -type apache-ds -host -remove "<eIUM host name>"

ldifgen gen -type redhat -host -remove "<eIUM host name>"

ldifgen gen -type open-ldap -host -remove "<eIUM host name>"

Upload the generated LDIF file $VARROOT/ldif/<eIUM host name>/host-remove<host name>.ldif into
the eIUM security data LDAP server. You do not need to restart the Security Server.
Viewing and Verifying Security Data

You can view the security data available to the Security Server in an Internet browser by accessing
the URL https://<security server host>:<security server port>/security/directory. You must have
SecurityAdmin privileges to access this data. The security data tree is organized as
/treeview/securitydata/<domain component 1>/ <domain component 2>/.../<identity
name>/Roles/<Role name nodes>. For details on the SecurityAdmin role and all other roles, see
"User and Host Roles and Privileges" (on page 112).
Managing Your Security Certificates

This section describes your security certificates. A secure eIUM deployment uses a number of digital
certificates for its operation. Digital certificates are used to validate the authenticity of claimed
identities during a secure exchange between various eIUM deployment entities and also as
authorization tokens that encode roles associated with the claimed identity. Each certificate is
digitally signed by a Certificate Authority (CA) to vouch for the authenticity of the encoded public key
of the claimed identity.
Each of the certificates issued by the CA is valid only for a certain period of time. A certificate
expires once it passes its validity period and must be renewed.
The eIUM Security Server hosts the CA function in a secure eIUM deployment and associates the CA
with itself. All the certificates used in eIUM except for the CA certificate itself are signed and issued
by the CA in the Security Server in a secure deployment. The default CA certificate is self-signed.
Types of Certificates
Certificates in a secure eIUM deployment fall into the following three categories based on the type
of claimed identities:
l CA Certificate issues certificates for eIUM servers and users.

l Server Certificate is issued for each eIUM host and for each eIUM process such as the admin
agent on each eIUM host, the configuration server, the Security Server, each charging manager,
file service, collector and so forth. This certificate only allows server activities.
l User Certificate is issued for each person when they use an eIUM tool. This certificate only allows
client activities.
Each certificate type has a different validity period. Each certificate type is described below.
The CA Certificate
The Security Server acts as the CA (Certificate Authority) in a secure eIUM deployment. The CA
attests that the public key contained in an eIUM secure deployment belongs to a user, a server or a
host identity. The CA identity is provided by the CA certificate and is typically attested by a trusted
third party. The CA certificate is the most important certificate in the deployment and forms the
basis of trust between all deployment entities.
The default CA certificate is self-signed and automatically generated by the Security Server. It is
recommended that you configure the Security Server to use a CA certificate issued by a trusted
third party. However, using a CA certificate attested by a trusted third party is not necessary for the
operation of a secure eIUM deployment.

Expiration of the CA Certificate
Among the three types of certificates, a CA certificate expiration has the biggest impact on a secure
eIUM deployment as the CA certificate forms the basis of trust for every other certificate in the
deployment. Renewing the CA certificate requires refreshing the certificates of all the identities
that exist in the deployment. The default validity period for the self-signed CA certificate is 10 years.
Changing the Validity Period of the CA Certificate
The default validity period for the self-signed CA certificate is 10 years. You can configure the
validity period of this certificate as follows:
1. Open the following file in a text editor. This is the Security Server environment context
configuration file.
$SIUVARROOT/securityserver/conf/Catalina/localhost/security.xml
2. Locate the following line in this file. Modify the value attribute. The value 87,600 represents the
number of hours in ten years.
<Environment name="certificate/CA/duration" type="java.lang.Long"
value="87600" override="true" description="Duration in hours"/>
The Keystore File for the CA Certificate
The CA certificate is provided to the Security Server as a keystore file. The default CA certificate
keystore is in the following file:
$SIUVARROOT/securityserver/keystore/issuer.p12
You can configure your own CA certificate keystore file by editing the Security Server environment
context configuration file $SIUVARROOT/securityserver/conf/Catalina/localhost/security.xml in a
text editor and modifying the value attribute:
<Environment name="keystore/CA/file" type="java.lang.String"
value="${catalina.base}/keystore/issuer.p12" override="true"
description="CA key store file"/>
Server Certificates
The eIUM CA (Certificate Authority) issues a server certificate to each eIUM server identity. Server
certificates are issued to the identities of each eIUM host, each eIUM admin agent, each charging
manager, file service, collector, the security server, the configuration server, the management
server, the web application server and the eIUM Operations Console.
The server certificate represents the identity of a specific server instance or host identity and
encodes the roles associated with the identity. The associated roles determine the privileges the
identity has in a secure eIUM deployment. For more information on roles and privileges, see "User
and Host Roles and Privileges" (on page 112).
Changing the Validity Period of the Server Certificate
The default validity period for a server certificate is one year. You can configure the validity period
of the server certificate as follows:

configuration file.
2. In this file, locate the following line and modify the value attribute. The value 8,760 represents
the number of hours in one year.
<Environment name="certificate/server/duration" type="java.lang.Long" value="8760"
override="true" description="Duration in hours"/>
3. Stop then restart the Security Server using the following commands:
NOTE: When a server certificate expires, the server will be automatically shut down.
The server exit status is set to CMDR_CRASH which means the Admin Agent will attempt to
restart the shut down server automatically and renew its certificate.
It is highly recommended you set the server certificate expiration time and plan to restart your
servers before their certificates expire to avoid the servers shutting down unexpectedly. See
"Certificate Expiration Alerts" (on page 120) for more information.
User Certificates
The eIUM CA issues a user certificate to each authenticated user identity, that is, for each person,
when they begin a session by using any eIUM tool. The user certificate has the shortest default
validity period of the three types of certificates. By default, it is valid for only three days. Each user
certificate is valid only until the active user session terminates or until the validity period expires,
whichever occurs first.
As in the case of a server certificate, a user certificate also represents the identity of an
authenticated user (a person) and encodes the roles associated with the person. The associated
roles determine the privileges the user has in the secure eIUM deployment.
You typically do not need to do anything with user certificates because they are not persisted on
disk and the user login process renews the certificate held in the in-memory keystore.
Certificate Expiration Alerts

All eIUM server processes monitor their own certificates for expiration and can log warning
messages about the approaching expiration. You can configure multiple levels of certificate
expiration alert messages. The default configuration provides two levels of certificate expiration
alert messages.
l Level 1 Expiration Warning - The first level warns when the expiration is still relatively far away,
by default seven days and repeats once each day.
l Level 2 Expiration Warning - The second level warns when the expiration is nearer, by default one
day and repeats each thirty minutes.

The Security Server logs certificate expiration alert messages when the CA certificate expiration
date approaches and when the Security Server certificate expiration approaches. The warning
messages are similar to the following messages:
2008-08-19 09:58:05.035 WARNING Timer-0 (CERTIFICATE_MONITOR): CA
certificate stored in [Key Store
C:\sbin\siu\SIU\var\securityserver\keystore\issuer.p12] will expire on
[Tue Aug 19 10:58:05 IST 2008]. Please plan a CA certificate renewal
procedure to continue using the secure IUM deployment.
2008-08-19 08:43:11.004 WARNING Timer-1 (CERTIFICATE_MONITOR): Server

C:\sbin\siu\SIU\var\securityserver\keystore\sec-server.p12] will
expire on [Tue Aug 19 10:58:05 IST 2008]. The expired certificate will
be automatically renewed and the server will shut down. The server
needs to be restarted to allow the server using the renewed
certificate.
Changing the Expiration Alerts for the Security Server
You can change the times of the multiple levels of the Security Server certificate expiration alerts
as follows.
configuration file.
2. Locate the following line in this file and modify the value attribute.
<Environment name="certificate/CA/expiry-alert"
type="java.lang.String" value="7d/12h,1d/3h,0" override="true"
description="Expiry alert configuration for the CA and the Security
Server certificates"/>
The format of the value attribute is <alert start interval/alert repeat period,
alert start interval/alert repeat period, , certificate expiry
handling>. The default is <7 days/12 hours, 1 day/3 hours, 0>. According to this
configuration, the Security Server certificate first-level expiration warnings start one week
prior to the expiration of the certificates, with the warning repeated twice daily. The second-
level alerts start on the expiration day and repeat every three hours. Finally, the certificate
expiration handler launches at the time the certificate expires (0 minutes before the
expiration).
3. Stop the Security Server using the following command:

Changing the Expiration Alerts for Other eIUM Servers
Every eIUM server will attempt to automatically renew its certificate before it expires. This attempt
can be repeated several times before the certificate finally expires. If automatic renewal logic fails,

the server process will automatically shut down at the time the certificate expires, and then the
certificates will get renewed on the next server restart. The host admin agent (when present) will
detect the server shut down and restart the server process.
CAUTION: You should plan to shut down and restart your servers during a normal maintenance
period before the certificates expire and the servers shut down automatically.
The host certificate is automatically renewed using the same scheme and configuration if the host
admin agent is running. You can manually renew the host certificate using the
$SIUHOME/bin/secactivate hostkey command as described in "Renewing the Host
Certificate" (on page 123).
By default, the certificate expiration first-level warnings start one week prior to the expiration of
the certificates, with the warning repeated twice daily. The second-level alerts start on the
expiration day and repeat every three hours. Subsequently, 30 minutes before the expiration, the
automatic renewal routine attempts to renew the server/host certificate and apply it to the running
server process. This attempt will be repeated every 10 minutes in case of failure.
The server logs certificate expiration alert messages when the server certificate expiration date
and the host certificate expiration approach. The warning messages are similar to the following
messages:
2008-08-19 09:58:05.035 WARNING Timer-0 (CERTIFICATE_MONITOR): Server
C:\sbin\siu\SIU\var\ConfigServer\keystore.p12] will expire on [Tue Aug
19 10:58:05 IST 2008]. Please plan a server certificate renewal to
avoid an unexpected shutdown.
2008-08-19 08:43:11.004 WARNING Timer-1 (CERTIFICATE_MONITOR): Host

certificate stored in [Key Store C:\sbin\siu\SIU\var\host.p12] will
expire on [Tue Aug 19 10:58:05 IST 2008]. Please plan a host
certificate renewal to avoid an unexpected system malfunction.
You can change the frequency of certificate expiration alert messages for all eIUM servers other
than the Security Server as follows. For instructions on changing the frequency of alert messages
for the Security Server, see "Changing the Expiration Alerts for the Security Server" (on page 121).
1. Open the file $SIUHOME/SIU.ini in a text editor.

2. Locate and modify the following property in this file.
# Server certificate expiry alert configuration
CERTIFICATE_EXPIRY_ALERT=7d/12h,1d/3h,30m/10m,0
The format of the CERTIFICATE_EXPIRY_ALERT attribute is <alert start

interval/alert repeat period, alert start interval/alert repeat
period, , certificate renewal start/certificate renewal repeat
attempt period, certificate expiry handling>. The default is <7 days/12
hours, 1 day/3 hours, 30 minutes/10 minutes, 0>.
3. Stop and restart any running eIUM servers.

Renewing the Host Certificate

The host certificate is automatically renewed without stopping any eIUM processes. The admin
agent server is responsible for automatically renewing the host certificate. However, if the admin
agent server is not running at that time, the automatic renewal will not occur. If the host certificate
is expired, you will not be able to start the eIUM admin agent or any other eIUM servers. In this
event, you must run the following command to manually renew the host certificate before
restarting the servers:
$SIUHOME/bin/secactivate login -user <security admin user> -password
<password> -- hostkey
See the eIUM Command Reference for more information on the eIUM security commands, such as
secactivate.
Configuring an External CA Certificate

The default CA certificate is self-signed and automatically generated by the eIUM Security Server. It
is recommended that you configure the Security Server to use a CA certificate issued by a trusted
third party. To configure the security server use an external CA certificate, do the following.
1. Copy the keystore file that contains your external CA certificate in a location accessible to the
eIUM Security Server. eIUM supports the keystore file formats PKCS12 and JKS.
NOTE: The keystore contains not only the CA certificate, but also a private key, which is
required for generating other certificates.
configuration file.
3. Locate the following line in the file and modify the value element to point to the external
keystore file path.
<Environment name="keystore/CA/file" type="java.lang.String"
value="${catalina.base}/keystore/issuer.p12" override="true"
description="CA key store file"/>
Renewing an Expired CA Certificate

When a CA certificate expires, all the certificates issued using the expired CA certificate must be
renewed. Follow the procedure described below to renew your certificates.
1. Stop the admin agent service on all eIUM hosts in your deployment. This shuts down all the eIUM
servers in your deployment. For instructions, see "Restarting the Host Admin Agent" (on page
100).
2. On the eIUM host where the Security Server is running, stop the Security Server using the

following command:
3. Run the following command on each eIUM host to clean up the existing keystore files that store
certificates issued by the expired CA certificate. Use the -force option to ensure the host
certificate already installed will be overwritten.
$SIUHOME/bin/secactivate cleanup -force
4. If the Security Server is configured to use an external CA certificate, copy the keystore file that
contains the renewed CA certificate to the configured location. Continue with Step 5.
If the Security Server is not configured to use an external CA certificate, start the Security
Server to automatically create a self-signed CA certificate and then stop the Security Server so
that the renewed certificate will take effect on the next start up. Use the following commands.

6. Run the following secactivate command on each host to create the host keystore file.
$SIUHOME/bin/secactivate login -user <security admin user> -
password <password> --hostkey -force
7. Start the admin agent and restart the required eIUM servers. For instructions on starting the
admin agent, see "Restarting the Host Admin Agent" (on page 100).
Audit Logging
The Security Server can log information about its activities and user activities for audit purposes.
This section describes how you can control this audit logging.
Controlling Audit Logging for the Security Server

This section describes audit logging for the eIUM Security Server. For details on the audit logging for
other eIUM servers, see "Controlling Audit Logging for Other eIUM Servers" (on page 125).
The Security Server audit logging provides a security trail in an audit log file. The audit trail can be
used to verify each users access to privileged operations provided by the Security Server. The audit
trail can also be used for troubleshooting access control. By default, the audit log messages are
written to the following file: SIUVARROOT/securityserver/logs/SecurityService.<year>-<month>-
<day>.audit.log.
You can configure the volume of Security Server log messages by setting the appropriate property
to one of the values in the following table. By default, the Security Server logs all INFO level audit
messages.
Security Server Audit Log Levels

Level Description
TRACE Gives the most amount of information and the largest number of audit messages.

Level Description
DEBUG Gives fewer than TRACE and more than INFO levels of audit log messages.
INFO Gives a medium number of audit log messages.
WARNING Gives fewer than INFO and more than ERROR levels of audit log messages.
ERROR Gives the least number of audit log messages.
To configure the audit log level for the Security Server, do the following.
1. Open the following configuration file in a text editor: SIUVARROOT/securityserver/conf/security-

logging.properties.
2. Change the value of the property AUDIT.level. The possible values are TRACE, DEBUG, INFO,
WARNING and ERROR as described in the table above. To minimize the number of audit logging
messages, set the value to ERROR.
Controlling Audit Logging for Other eIUM Servers

This section describes audit logging for all eIUM servers other than the Security Server. For details
on the Security Server audit logging, see "Controlling Audit Logging for the Security Server" (on page
124).
Audit logging provides a security trail for each eIUM server. Each eIUM server logs audit information
in its own separate audit log file. The audit trail can be used to verify user access to privileged
operations of the server. The audit trail can also be used for troubleshooting access control.
CAUTION: There can be a performance impact when enabling audit trails for high-traffic services
(such as the Management Server). In addition, audit log settings will always be applied to all
processes running on the given eIUM host system.
You can configure the volume of server log messages to one of the values in the following table, as
described below. By default, eIUM servers log all ERROR level audit messages.
By default, the audit log file is SIUVARROOT/log/<server name>.audit.log.
Level Level
Number Name Description
1 CRITICAL Message explaining a fatal error just before a component goes down. An
example would be messages about being unable to connect to a necessary
eIUM component.
2 ERROR Message about a situation where the component cannot operate properly or
carry out a request. These error situations could eventually be fatal but the
component will continue to run.
Examples are corrupt input files or corrupt configuration store, cannot

Level Level
connect to a component even after retry, invalid user input values,

unexpected errors encountered in requests such as to query usage data or
age NMEs, cannot save a file or data, files not found and no default file name
available, or internal errors.
3 WARNING Message about an unexpected event that might lead to further problems.
Examples are messages about connections lost but that will be retried,
parameters not specified and default values used instead, skipping invalid
input log records, packets dropped, files not found, and warnings about eIUM
license expiration.
4 INFO Messages about normal events such as commands received, messages

about successful connections made, and results of requests for statistics.
These messages are useful for tracing activities in servers.
5 DEBUG Least detailed and frequent debug messages. Debug messages are useful
only for developers.
6 DEBUG2 Medium detail and frequency debug messages.
7 DEBUG3 Very detailed and frequent debug messages.
8 DEBUG4 Most detailed and frequent debug messages.
To configure the audit log level for eIUM servers other than the Security Server, do the following.
1. Open the configuration file CFGROOT/SIU.ini in a text editor.

2. Change the value of the property AUDITLOGLEVEL to a number as specified in the above table.
Level 1, CRITICAL, gives the fewest audit log messages. Level 8, DEBUG4, gives the most audit
log messages.
3. Restart all running eIUM servers.
CAUTION: If you raise the audit log level from ERROR to a level such as INFO or any of the DEBUG
levels, the increased logging activity may impact the server performance. This is especially
significant for the Management Server.
Alternatively, instead of modifying the SIU.ini file, you can also configure audit logging for other
servers using the following method:
1. Save the server node configuration by executing the following command:

saveconfig -f servername.config -p
/deployment/<hostname>/<servername>
2. Open the servername.config file, and add a Logging node under the server as the following:
[/deployment/<hostname>/<servername>/Logging]
ClassName=com.hp.siu.serverutils.logging.SvrLogManager
Loggers=AUDIT,<AUDIT_LOG_LEVEL>

3. Load the updated server node configuration back to the configuration store:
loadconfig -f servername.config
4. Open the Launchpad Deployment Editor and verify the Logging subnode has been added to the
server node.

Chapter 8
Managing the Configuration Server

The eIUM Configuration Server stores and manages all configuration information for your entire
eIUM deployment. When you install eIUM, you install the configuration server on one host. All hosts,
collectors and servers download their respective configuration information from the configuration
server when they start.
Normally the configuration server runs as a process controlled by the host admin agent. A host
admin agent runs on each eIUM host as a Windows service or UNIX daemon that is started when you
install eIUM and whenever you reboot. The host admin agent and the configuration server must
always be running. If the configuration server stops running, your entire eIUM deployment will not
function.
All eIUM processes communicate with the configuration server. The configuration server exports its
CORBA address (IOR, or Interoperability Object Reference) to all other eIUM hosts. At installation, the
configuration server writes its IOR to a file, typically C:\SIU\var\ConfigServer.ior on Windows and
/var/opt/SIU/ConfigServer.ior on UNIX. The name of this file is in the property file SIU.ini with the
keyword IORFILE. A URL referring to the IOR file is in SIU.ini with the keyword IORURL. Each eIUM
process uses the IORURL to read the IORFILE and get the configuration servers IOR.
Restarting the Configuration Server 128
Checking Configuration Server Status 128
Changing the Configuration Servers Start-up Properties 129
Viewing Configuration Server Log Files 129
Changing Configuration Server Logging Level 129
Running Configuration Server Diagnostics 129
Backing up the Configuration Server 129
Restarting the Configuration Server

You must restart the configuration server whenever you change its start-up properties. To stop and
restart the configuration server:
1. In the Launchpad, select the ConfigServer under the host where it is running.
2. Either right-click on the ConfigServer and select the Restart Config Server menu item, or select
the Actions: Restart Config Server menu item. This stops and restarts the configuration server.
Checking Configuration Server Status

You can determine whether or not the configuration server is running by examining the icon next to
the ConfigServer object in the deployment pane. See "Status Icons" (on page 22) for the meaning of
status icons. See also "Checking Collector, Host or Server Status" (on page 90) for instructions on
checking the configuration server status.

Chapter 8: Managing the Configuration Server
Changing the Configuration Servers Start-up Properties

You can change the properties the configuration server uses whenever it starts up in either of two
ways:
l Change the host default properties on the host where the configuration server is running. This
affects all processes running on the host, including the configuration server. See "Changing
Default Host Properties" (on page 96).
l Specify that the configuration server override the host default properties. See "Overriding
Default Host Properties" (on page 99) for details.
After changing the configuration servers start-up configurations, restart it as described in
"Restarting the Configuration Server" (on page 128).
Viewing Configuration Server Log Files

You can view the configuration servers log file by right-clicking the ConfigServer in the Launchpad
and selecting Log File. See also "Viewing Collector, Host and Server Log Files" (on page 93) and
"Maintaining and Troubleshooting eIUM" (on page 206) for information about log files.
Changing Configuration Server Logging Level

The configuration server has a log file in C:\SIU\var\log\ConfigServer.log on Windows and
/var/opt/SIU/log/configserver.log on UNIX where many configuration server activities are recorded.
You can set the amount of information logged by right-clicking the ConfigServer in the Launchpad
and selecting the Set Log Level menu item. See also "Changing Collector, Host and Server Logging
Level" (on page 94) and "Maintaining and Troubleshooting eIUM" (on page 206) for information
about log files.
Running Configuration Server Diagnostics

You can run any of several diagnostic routines on the configuration server to determine how it is
running. See "Perform Diagnostics" (on page 211) for more information. You can also use the siudiag
command to run diagnostics on the configuration server. See the eIUM Command Reference for
details on the siudiag command.
Backing up the Configuration Server

It is very important that you periodically back up the data in the configuration server. You do not
have to stop any eIUM components to back up the configuration server. See "Backing Up Your eIUM
Deployment" (on page 156) for more information.

Chapter 9
Correcting CDRs with the CDR Editor

A large voice network typically has many voice switches. Each switch generates files of usage data in
the form of call detail records (CDRs). During the reading and processing of large numbers of CDRs,
the eIUM mediation system inevitably encounters invalid or corrupt CDRs. If the mediation system
cannot process the error records, the erroneous records can be parked in the form of NME files in a
separate directory. The leaf collectors error scheme can specify where to park the error NME files.
Once such an NME file is obtained from the error handling subsystem, you can edit and correct the
NMEs in the file with eIUMs error correction subsystem the CDR Editor utility.
You can use the CDR Editor to view the erroneous NMEs that are stored in the file and edit the NMEs
to make corrections. You can save the corrected NMEs to a file and reprocess them by sending them
to another collector, thereby feeding the corrected NMEs back into the mediation stream.
The following topics describe how to use the CDR Editor and perform various operations on the error
NMEs. For additional information and background on detecting and handling error data using eIUM,
see the eIUM Foundation Guide.
Starting the CDR Editor 131
Using the CDR Editor 131
Opening Files with the Editor 131
Navigating between Open Files 131
The Error File Display 132
Editing Fields in Error Files 132
Undoing and Redoing Changes 134
Bulk Editing (or Find and Replace) 134
Navigating to a Particular CDR 143
Saving Files 144
Exporting to CSV Format 144
Extracting Corrected CDRs 145
Applying Filters 146
Configuring the CDR Editor 148
Changing Color Coding 149
Configuring Logging 149
Setting the Backup File Directory 153
Setting the Corrected File Directory 154
Setting the CSV File Directory 154

Chapter 9: Correcting CDRs with the CDR Editor
Starting the CDR Editor

To launch the CDR Editor, open a command window and run the following command:
<eIUM-HOME-DIRECTORY>/bin/cdreditor
This starts the CDR Editor.
NOTE: If eIUM is in secure mode, the CDR Editor will prompt you to log in with a valid user name
and password. See "Managing Users and Security" (on page 106) and the eIUM Installation Guide
for details on secure mode.
Using the CDR Editor

The editor work area is the main view of the CDR Editor. This pane displays the file that is currently
open along with the toolbars and menu that allow you to perform various actions.
Opening Files with the Editor

Open error files by selecting the File -> Open menu or the Open icon on the toolbar. A file dialog
opens and allows you to navigate through the local file system and select the error files. You can
choose a single file or multiple files to edit. The status bar at the lower end of the editor displays an
appropriate message. The editors main window shows the file last opened.
NOTE: To test the editor you can use the sample files provided in the SampleData directory
under the CDR editor plug-in directory.
Navigating between Open Files

You can switch to another file by selecting the file from the Window menu.

The Error File Display

The editor displays NMEs in a tabular format. The different attributes of the NMEs are displayed in
the first row. The following color codes identify the error fields and the type of error for that field:
l Pink: An NME attribute that could not be parsed from the input data.
l Orange: An NME attribute that is successfully parsed but the value is invalid.
l In addition, a marker at the beginning of each NME displays the NME status.
l Red cross: This indicates that the NME contains error fields.
l Green check mark: This indicates that all the fields in that NME have been corrected.
You can navigate between different NMEs by using the scroll bar at the right side of the screen.
Hovering the mouse pointer over a particular erroneous cell displays the reason the cell is invalid.
Editing Fields in Error Files

You can edit attributes of the NME by double-clicking the cell for an erroneous attribute in the
display. A dialog lets you enter a valid ASCII or Hexadecimal value.

In the case of a parse error, if you enter a hex value, this new value will be checked for correctness
by parsing it using the parselet configured for the attribute.
In the case of a validation error, the new value is set into the corresponding attribute without
performing any further checks.
When correcting the values, the right column shows the current value and cannot be edited.
Meanwhile, the left column is available for editing and allows you to compare the previous value in
the right column with the new value you enter.

The color coding of the cell (pink or orange) is then removed to indicate successful correction.
Initially, the column that displays the NME row numbers also displays the correction status for that
NME; a red cross is displayed if any attribute is uncorrected for that NME. Once every erroneous
attribute is corrected for an NME, a green check mark appears in the cell that displays the NME row
number.
Undoing and Redoing Changes

With the CDR editor you can undo or redo a sequence of operations on individual NME records (see
"Editing Fields in Error Files" (on page 132) for an example). Use Edit-> Undo or Edit -> Redo, or the
Undo/Redo arrow buttons.
NOTE: Undo during Find-Replace is not supported.
Bulk Editing (or Find and Replace)

With bulk editing you can search for CDRs with particular NME attribute values and modify one or
more NME attributes of the CDRs that match the search criteria. A Bulk Edit rule is also called a
Replace Rule.
A Replace Rule consists of one or more Filter Expressions and one or more Replace Expressions.
l The Filter Expressions define the search criteria. You can create Filter Expressions and later edit
them, if you have saved them as part of the new Replace Rule.
l The Replace Expression defines which NME attribute values to change in the CDRs selected by
the Filter Expressions. The Filter Expressions can also be saved if saved as part of the larger
Replace Rule (if you cancel the dialog, any Filter or Replace Expressions will disappear unless
saved as part of the overall Replace Rule).

Only CDRs that match the Filter Expressions are modified by the Replace Expression. You can create
and name Replace Rules for common bulk editing tasks you perform regularly.
Create a New Replace Rule

You create a new Replace Rule using the Find-Replace dialog. With a file open in the CDR Editor,
start the Find-Replace dialog by selecting either Edit -> Find-Replace, or the Find-Replace button.
This opens the Find-Replace dialog.
1. Press the Add button to create a new Replace Rule. This displays an input dialog where you can
enter a name for your rule.

2. Enter a descriptive name for your rule in the dialog. After pressing OK, the rule name appears in
the drop-down list at the top of the Find-Replace dialog.
3. Under Replace Rule Properties, Filter Expression, press the Add button to create a new filter
expression. This adds a filter expression entry in the Filter Expression window that you can
create or edit.

4. Select the row corresponding to the filter expression entry, and in the associated fields, select
an NME attribute, an operator, and enter a value for the NME attribute. The Attribute field will
have its drop-down selections defined based on the NME attributes in the NME file you have
open. Also, the Operator drop-down has operator conditions that you can select, such as =, !=, >,
>=, <, <=, within, !within, starts, !starts, ends, !ends, contains, !contains.

5. To specify multiple logical expression conditions (AND or OR), select a condition (AND or OR)
from the Condition field, and repeat steps 3 and 4 above. The set of conditions will be combined
with a logical AND or a logical OR as specified, to create a single composite condition, as shown
below. To delete a particular Filter Expression, select the entry and press Remove.

6. Now that the filter (that is, the find) expression(s) are created, create a Replace Expression by
pressing the Add button. This adds an undefined Replace expression entry in the Replace
expression window.

7. Select an NME attribute and enter the new value, as shown below. The specified NME attributes
in all the NMEs selected by the Find Condition will be changed to the new value. Repeat the
previous step and this step for all the NME attributes you want to change. To remove a Replace
Expression, select the entry and press Remove.

8. Press Save to complete creation of the Replace Rule.

Once you have created one or more Replace Rules, follow the steps under "Use an Existing Replace
Rule" (on page 141) to execute your Replace Rule, or follow the steps under "Modifying Replace
Rules" (on page 142) to edit your Replace Rules.
Use an Existing Replace Rule

You perform a bulk edit using a Replace Rule that you have defined as follows.
1. With a file open in the CDR Editor, select either Edit -> Find-Replace, or press the Find-Replace
button. The Find-Replace dialog is displayed (see "Create a New Replace Rule" (on page 135) for
an example).
2. Select one of your Replace Rules from the drop-down list.
3. Under Files Selected, you can select one or more files you have already open, in order to
execute a bulk replacement across all the files.
4. Press Replace, which executes your Replace Rule.

NOTE: The undo history of all the edits performed on the file currently open will be lost after the
Replace Rule runs. The bulk edit operation, as well as any other operations performed before it,
cannot be reversed after this operation. By contrast, you can only undo changes when editing
individual errors in NME records (see "Editing Fields in Error Files" (on page 132) for more
information).
Since bulk editing can be time consuming, the editor indicates the progress of the operation as
shown below.
CAUTION: Use bulk editing carefully because it can affect large portions of CDR files, and the
operation cannot be undone.
Modifying Replace Rules

You can modify any of the Replace Rules you have created by using the Find-Replace dialog. The
procedure for editing a Replace Rule is nearly the same as when creating a new one. To modify
Replace Rules using the Find-Replace dialog:

an example).
2. Select one of your Replace Rules from the drop-down list.
3. Edit the Replace Rule properties, and then press Save.
Removing Replace Rules

You can also remove any of the Replace Rules you have created by using the Find-Replace dialog. To
remove Replace Rules:
an example).
2. Ensure the Replace Rule is viewable in the drop-down list.
3. Press Remove to delete the Replace Rule.
Bulk Editing Multiple Files

You can perform find and replace operations across multiple files. To perform this operation on a
set of files, all the files must have the same NME structure. The primary prerequisite when
performing find and replace on multiple files is to have all the files opened beforehand. In other
words, if you have multiple files you want to edit, open them first in the same way you would open
error files, by selecting File -> Open or the Open icon on the toolbar (see "Opening Files with the
Editor" (on page 131)). In this manner, the opened files can be read by the Find-Replace dialog (see
"Use an Existing Replace Rule" (on page 141) for an example where multiple files are included in the
Find-Replace operation).
NOTE: As with individual Find-Replace operations on a single file, the undo history of all the edits
performed on the file currently open will be lost after a multi-file bulk edit. The bulk edit
operation, as well as any other operations performed before it, cannot be reversed after this
operation. Accordingly, ensure that you save any unsaved changes before performing the bulk
edit.
Navigating to a Particular CDR

You can navigate to a certain CDR with Edit -> Go to CDR or by selecting the Go to CDR button on
the toolbar.
A dialog prompts you to enter the CDR row number for the CDR to navigate to. When you enter a
valid row number, the editor displays the specified CDR.

After pressing OK, the file view will jump to the entry you are searching for and highlight it
accordingly.
Saving Files
The file currently being edited can be saved by selecting File -> Save, or using the Save button on the
toolbar.
All changes made up to that point are saved. When you save the current file using File -> Save or the
Save icon, the CDR Editor saves a backup copy of the previous version of the file in the specified
backup directory, and then it saves the current changes in the open file. For more details, see
"Setting the Backup File Directory" (on page 153).
Exporting to CSV Format

You can save CDR files in Comma-Separated Value (CSV) format using File -> Export to CSV. This
format is useful to import into a spreadsheet program, for example. Files can only be exported
individually, one at a time. Column headers are also written to the exported CSV file.
1. Open the file to be converted to CSV format.

2. Select File -> Export to CSV.
3. A confirmation dialog is displayed, which also indicates the directory path to the exported CSV-
format file.

4. This saves the CDRs in a file named the same as the original file with a .csv extension, in the
directory specified in the CDR Editor options. See "Setting the CSV File Directory" (on page 154)
for more information on how to specify where the CSV files are saved.
Extracting Corrected CDRs

The Edit -> Extract Corrected CDRs menu and the Extract Corrected CDRs button in the CDR Editor
toolbar, shown below, do three things:
1. Moves all the corrected CDRs to a separate file named with a .corrected file name extension
in the corrected file directory. You can set the location where the .corrected files are saved by
selecting Configure -> Options or the Options button, selecting the General Config tab and
changing the corrected file directory. See also "Setting the Corrected File Directory" (on page
154).
2. Saves all the remaining uncorrected CDRs in the original file.
3. Saves a copy of the original file, the file before the corrections were done, in the backup
directory with a .bak file name extension. You can set the location where the .bak files are
saved by selecting Configure -> Options or the Options button, selecting the General Config tab,
and changing the backup file directory. See also "Setting the Backup File Directory" (on page
153).
For example, if you were editing the file VoiceCDRs.log and you selected Extract Corrected CDRs, the
CDR editor would:
l Save the corrected CDRs in the file VoiceCDRs.log.corrected in the corrected file directory.
l Save the uncorrected CDRs in the file VoiceCDRs.log.
l Save the original file in the file VoiceCDRs.log.bak in the backup directory.
NOTE: If you have more than one file open, this only affects the displayed file. Use the Window
menu to display each file and extract the corrected CDRs from each file.
Each time you select Extract Corrected CDRs, the corrected CDRs are appended to the .corrected
file. When you correct all the CDRs and select Extract Corrected CDRs, the CDR editor deletes the
original file.
The Extract Corrected CDRs button is shown below:

Applying Filters
You can display a subset of the CDRs in the file by using content-based filtering. Content-based
filtering displays only those NMEs that satisfy certain logical conditions that are applied to selected
NME attributes. To apply a content-based filter, do the following:
1. Select Configure -> Create Filters or the Create Filters button from the toolbar.
2. This displays the CDR Filters window that allows you to create one or more content-based
filters.
3. To create a filter, press the Create button. This displays the Edit Filters window.

4. Enter a name for the filter you are creating and press Add. A new row appears in the Edit Filters
window.
5. Select an NME attribute (Attribute field), an operator (Operator field) and enter a value for the

NME attribute (Value field). You can specify the same set of operators as when creating a Find-
Replace Filter Expression (see Step 4 in "Create a New Replace Rule" (on page 135)).
6. To specify another logical expression, select a condition (AND or OR) and press Add again.
Repeat the previous step. The set of conditions will be combined with a logical AND or a logical
OR as specified, to create a single composite condition. Conversely, if you want to remove a
filter during this process, select the entry and press Delete.
7. Press OK in the Edit Filters window when all your filter conditions are defined.
8. To apply one or more filters, select the check box next to the filters you want in the Enabled
column.
9. Press OK to display only those CDRs that match all of the specified conditions. That is, the
conditions are combined with a logical AND operation.
10. You can enable or disable individual filters from the CDR Filters list by selecting or clearing the
respective check boxes. Press OK to apply the selected filters.
11. To disable all filters, clear all selections (under Enabled) in the CDR Filters window and press OK.
This displays all the CDRs in the file.
Configuring the CDR Editor

You can change various aspects of the CDR editor using Configure -> Options or the Options button.

Changing Color Coding

You can change the color settings for the display of each type of error in the input file through the
Configure -> Options menu or the Options button, as shown below. Select the Change Color button
for Parse Errors or for Validation Errors. Select the desired color and click OK.
Configuring Logging
The CDR editor writes log messages to two different log files during its operation.
l Standard logging saves information such as when the CDR editor starts, when it opens a file,
saves a file and closes a file, when it performs a bulk edit operation and the number of CDRs
modified. It saves this information in the log file IUM_CCU.log typically under /SIU/var/log on
Windows or /var/opt/SIU/log on UNIX. For more information see "Setting the Standard Logging
Level" (on page 151) and "Saving the Standard Log File" (on page 152).
l Audit logging logs more detailed information about the changes made to CDRs. It saves this
information in a separate audit log file for each eIUM user and each CDR editor session. The audit
log file contains the following information:
n When the CDR editor starts, it logs the user name of the person starting it. If security is not
installed, it logs that it is running unsecured. For more information on security and eIUM users,
see "Managing Users and Security" (on page 106).
n The directory and name of each file opened, saved and closed.
n For each changed CDR, the following information is logged:
o Which CDR was modified. That is, the CDRs ordinal position in the file.
o The name of the NME attribute that has changed.

o The NME attribute values before and after the change.

l For bulk edit operations, the operation performed including the number of CDRs that were
modified.
For more information see "Setting the Audit Logging Level" (on page 153) and "Setting the Audit Log
File Name and Directory" (on page 153).
Log Levels
You can control the type of log messages the CDR editor produces by setting the standard log level
and the audit log level. Select Configure -> Options or the Options button, and select the General
Config tab or the Audit Config tab. Select the log level from the available list. eIUM uses the following
log levels. Each level includes all messages from the levels above it. For example, the Error level
includes Accounting and Critical messages, but not Warning, Informative or any of the Debug
messages.
Log Levels
Level Description
0 = CRITICAL Messages explaining a fatal error just

before a component goes down. An
example would be a message about being
unable to connect to a necessary eIUM
component.
1 = ACCOUNTING Messages noting a normal occurrence,

such as a request to age NMEs or request
for collector shut down. These few
messages are useful for tracing even
though the logging severity is greater than
the INFORMATIVE level.
2 = ERROR Messages about a situation where the

component cannot operate properly or
carry out a request. These error situations
could eventually be fatal but the
component will continue to run.
Examples are corrupt input files or corrupt

configuration store, cannot connect to a
component even after retry, invalid user
input values, unexpected errors
encountered in requests such as to query
usage data or age NMEs, cannot save a file
or data, files not found, no default file
name available, or internal errors.
3 = WARNING Messages about an unexpected event that

might lead to further problems. Examples
are messages about connections lost that
will be retried, parameters not specified
therefore explaining the defaults used

Level Description
instead, skipping invalid input log records,

packets dropped, files not found, and
warnings about your eIUM license.
4 = INFORMATIVE Messages about normal events. Examples

are commands received, successful
connections made, and results of requests
for statistics. These messages are useful
for tracing, as are ACCOUNTING level
messages, but are much more frequent.
This is the typical logging level because it

provides the most commonly needed
information about eIUM operations.
5 = DEBUG Least detailed and frequent debug

messages. Debug messages are typically
useful only for developers and HP support.
This level can produce very large log files
very quickly!
6 = DEBUG2 Medium detail and frequency debug

messages. This level can produce very
large log files very quickly!
7 = DEBUG3 Very detailed and frequent debug

messages This level can produce very
8 = DEBUG4 Most detailed and frequent debug

messages This level can produce very
Setting the Standard Logging Level

You can set the level at which the CDR editor writes standard log messages by selecting Configure -
> Options or the Options button, selecting the General Config tab, and selecting one of the available
Log Levels, as shown below. See "Log Levels" (on page 150) for a description of the log levels.

Saving the Standard Log File

By default, the CDR editor removes the standard log file when you exit the CDR editor. You can save
the standard log file by using Configure -> Options or the Options button, selecting the General
Config tab, and setting Purge log on exit to No, as shown below.

Setting the Audit Logging Level

You can set the level at which the CDR editor writes audit log messages by selecting Configure ->
Options or the Options button, selecting the Audit Config tab, and selecting one of the available Log
Levels. See "Log Levels" (on page 150) for a description of the log levels.
To turn audit logging off, set the level to Off. When you set the audit log level to Off, no audit
messages are logged by the CDR editor.
The new audit configuration takes effect only after you stop and restart the CDR editor. For the
current session there will not be any change in the log level or audit file name.
Setting the Audit Log File Name and Directory

You can set the location of the audit log file by selecting Configure -> Options or the Options button,
selecting the Audit Config tab, and entering the directory path in the Audit Dir text box, as shown in
the figure above. This location will be used the next time you start the CDR editor.
NOTE: The new audit configuration takes effect only after you stop and restart the CDR editor.
For the current session there will not be any change in the log level or audit file name.
Setting the Backup File Directory

Whenever you save the current file with File -> Save or the Save button, the CDR editor saves a
backup copy of the previous version of the file in the specified backup directory and then it saves
the current changes in the open file. You can set the location where the backup file is saved by
selecting Configure -> Options or the Options button, selecting the General Config tab, and changing

the Backup File Directory. See "Saving the Standard Log File" (on page 152) for an example of where
this can be configured in the interface.
Setting the Corrected File Directory

When you save corrected CDR files, the corrected files are saved in the directory specified in the
CDR Editor options. You can view and change this location by selecting Configure -> Options or the
Options button on the toolbar, shown below.
Set the Corrected File Directory as shown in the example in "Saving the Standard Log File" (on page
152).
Setting the CSV File Directory

When you save CDR files as Comma-Separated Value (CSV) files, the CSV files are saved in the
directory specified in the CDR Editor options. You can view and change this location by selecting
Configure -> Options or the Options button on the toolbar, shown below.
Set the CSV Export Directory as shown in the example in "Saving the Standard Log File" (on page
152).


Chapter 10
Backing Up Your eIUM Deployment

This administration series of topics describes how to back up and restore an eIUM deployment.
Introduction and Backup Strategy 156
When and How to Back up 157
Backup Strategies 157
An Online Backup Scenario 157
eIUM Deployment Scenario 158
Performing a Full Online Backup 158
Performing an Incremental Backup 162
Restoring eIUM from a Backup 163
Recovery in a Collector Hierarchy 164
Offline Backup Strategy 165
Restoring from Offline Backup Files 168
Commands for Backing Up eIUM 169
siubackup Command 169
siurestore Command 171
Introduction and Backup Strategy

A good backup strategy should be one component of an overall strategy addressing system failure.
The best method for dealing with system failures is to avoid them in the first place by removing
sensitivity to single points of failure, through redundant hardware and High Availability Solutions.
High Availability Solutions are available for all eIUM supported platforms (Windows, HP-UX, Linux and
Solaris). If your environment does not warrant a full High Availability Solution, alternative solutions
such as disk mirroring, duplexing, or RAID in the case of hard disks can help minimize the risk of
major failures and speed recovery. You should evaluate and design failure prevention and recovery
strategies based on your business requirements.
You should incorporate a comprehensive backup of all your eIUM hosts into your enterprise backup
strategy to enable recovery from a major system failure. You should back up the hard disk of all
your eIUM hosts using your standard backup strategy and backup systems.
Performing a full backup of eIUM hosts will facilitate the most rapid recovery in the event of a major
system failure. At a minimum, the eIUM backup strategy should include the following:
l Back up all directories containing eIUM information.

l Back up the MySQL configuration and all database files created by the MySQL backup process.

Chapter 10: Backing Up Your eIUM Deployment
NOTE: Automatic database backups with MySQL are not supported. If you need to perform this
type of backup, certain operating system utilities should be used instead (such as the UNIX
cron utility).
l Perform a regular saveconfig and back up the resulting ASCII configuration files.
l Back up any input files the system is using.
l Back up any output files the system is creating.
When and How to Back up

The timing of backups is usually determined by your overall backup strategy. In general, dynamic
components should be backed up daily or more frequently. Static components such as the operating
system and the eIUM software files should be backed up on a less frequent but regular schedule, for
example weekly. The Configuration Store can be included in the backup schedule as a static
component but should also be backed up following configuration changes.
For the fastest recovery in the event of a failure, perform a complete backup of the entire host on a
regular basis (weekly or daily) followed by an incremental backup (backing up only those files on the
host which have changed) daily or more frequently.
The ability to schedule regular backups (full, incremental, and other backup types) is already built in
to most standard backup solutions. The backup solution should determine which files need to be
backed up for a particular scheduled backup based on the backup type and verification of which
files on the host have changed since the last backup. It is strongly recommended that your eIUM
backup strategy be incorporated into your enterprise backup strategy.
Backup Strategies
There are two basic backup strategies to consider for eIUM: offline and online. Select the method
that works best for your environment.
An online backup strategy addresses how to back up an eIUM deployment while collectors and
other servers are running. This is the recommended strategy. See "An Online Backup Scenario" (on
page 157).
An offline backup strategy addresses how to back up an eIUM deployment if the collectors and
other servers can be shut down during backup. See "Offline Backup Strategy" (on page 165).
An Online Backup Scenario

This section describes a complete scenario of backing up an eIUM deployment while all collectors
and servers continue to run. It then describes how to restore a host after a system failure. It
describes a complete deployment scenario on three hosts and how to back them up. For an offline
backup strategy, see "Offline Backup Strategy" (on page 165)s.
NOTE: The default installation location for eIUM is /opt/SIU, /etc/opt/SIU and /var/opt/SIU on
UNIX, and C:\SIU on Windows. These instructions use these default locations. If you installed eIUM
in a different directory, alter these instructions accordingly. The eIUM commands are located in
C:\SIU\bin on Windows and /opt/SIU/bin on UNIX.

eIUM Deployment Scenario

For this scenario, assume 12 collectors distributed among three host systems as shown in the
diagram below.
Server_1 - Leaf Collectors

Server_1 is a UNIX system that hosts two leaf collectors, L1 and L2, reading CDRs (Call Detail
Records) from two voice switches. The switches write one CDR file approximately every hour. The
switches also update a control file on the switch that logs the creation of CDR files. The leaf
collectors read the control file, fetch the next available CDR file, update the control file, and write
the control file back to the switch. The leaf collector processes the new CDR file then moves it to
another directory. The backup strategy needs to ensure these files are backed up and restorable, as
well.
A third collector, R1, receives and writes error CDRs into files for manual repair and reprocessing.
The repaired CDRs are read by collector A3 running on Server_2.
Server_2 - Aggregation and Correlation Collectors

Server_2 is also a UNIX system that hosts six intermediate collectors. Collectors A1 and A2 read
from L1 and L2 and perform aggregation. A2 also reads reintroduced CDRs from A3. A3 reads
repaired CDRs from files created by R1 and performs aggregation. Collector C1 reads from A2 and
assembles partial CDRs. Collectors C2 and C3 read from A1, A2 and C1, and perform correlation.
Server_2 also hosts the Configuration Server.
Server_3 - Distribution Collectors

Server_3 is a Windows system that hosts three collectors, D1, D2 and D3. These collectors read from
C2 and C3 and perform formatting and output of IDR files that are then read and processed by the
billing system and other operations support systems.
Performing a Full Online Backup

This section describes how to perform a full online backup of the three systems shown in "eIUM
Deployment Scenario" (on page 158). The overall steps are listed below and described in detail in the

rest of this section.
1. Prepare for the full backup.

2. Back up the configuration in the configuration server.
3. Back up each collector on each host using the siubackup command.
4. Back up your input data files.
5. Save backup data using your enterprise backup solution.
NOTE: The default installation location for eIUM is /opt/SIU, /etc/opt/SIU and /var/opt/SIU on UNIX
and C:\SIU on Windows. The instructions here use these default locations. If you installed eIUM in
a different directory, alter these instructions accordingly. The eIUM commands are in C:\SIU\bin
on Windows and /opt/SIU/bin on UNIX.
1. Prepare for a Full Backup

Before you commence the full backup process, do the following:
1. Decide how frequently to perform backups. For example, weekly full backups and daily
incremental backups are recommended (and depending on the value of your data). For this
scenario, we will describe how to perform a full backup weekly, and an incremental backup
daily.
2. Make sure you have enough disk space to save all the backup files before moving them to long-
term storage.
3. Back up your eIUM software, including patches you have installed. If you have a CD with the
eIUM software, ensure it is stored safely and can be used to reinstall eIUM. Document any eIUM
patches you have installed and back up the patch install files.
4. Create a temporary directory on each host where you can place the backup files until they can
be stored in long-term archives. In this scenario, /tmp/usage/<host name> on UNIX and
C:\tmp\usage\<host name> on Windows are assumed. This allows keeping each hosts files
separate.
2. Back up the Configuration Server

The next step is to back up the Configuration Server, which resides on UNIX Server_2 in our scenario.
1. On Server_2, create a temporary directory /tmp/usage/server_2.

mkdir /tmp/usage/server_2
Make sure /tmp has enough disk space to hold the backup files.
2. Use the saveconfig command as follows:
saveconfig -p / -f /tmp/usage/server_2/deployment.config
This creates the file /tmp/usage/server_2/deployment.config which contains all the
configuration information for the entire deployment from the configuration server.
NOTE: You can run the saveconfig command from any eIUM host. See the eIUM Command
Reference for complete details on the saveconfig command.

3. Back up All Collectors on Each Host

The next step in a full backup is to back up every collector on the host using the siubackup
command with the -full option. The siubackup command saves all the usage data in the collector, all
metadata such as history and recovery data in the collector, and all configurations for the collector.
TIP: Write a backup script for each host to perform all these commands.
TIP: Back up the collectors in reverse order from the data flow, or in order from the highest level
collectors to the lowest level collectors. In our scenario, back up the Distribution collectors first
(D1, D2 and D3), then the correlation collectors (C2 and C3 followed by C1), then the aggregation
collectors (A1, A2 and A3), the repair collector (R1), and finally the leaf collectors (L1 and L2). This
helps ensure no data is lost if you ever have to restore from a backup.
Back up each collector as follows:
1. On Server_1, create the temporary directory /tmp/usage/server_1 and make sure it has
enough disk space to hold the backup files.
mkdir /tmp/usage/server_1
2. Create a separate directory under /tmp/usage/server_1 for each collector with the same name
as each collector. The collectors on Server_1 are named L1, L2, and R1.
mkdir /tmp/usage/server_1/L1 /tmp/usage/server_1/L2
/tmp/usage/server_1/R1
3. Use the siubackup command as follows. The following commands back up these three
collectors and place their backup files in their respective directories under /tmp/usage/server_
1:
siubackup -n L1 -full -backupDir /tmp/usage/server_1/L1
siubackup -n L2 -full -backupDir /tmp/usage/server_1/L2
siubackup -n R1 -full -backupDir /tmp/usage/server_1/R1
NOTE: To perform an incremental backup, use the following siubackup commands. These
commands back up only changed data from the three collectors since the last backup and
place their backup files in their respective directories under /tmp/usage/server_1:
siubackup -n L1 -incremental -backupDir /tmp/usage/server_1/L1

siubackup -n L2 -incremental -backupDir /tmp/usage/server_1/L2
siubackup -n R1 -incremental -backupDir /tmp/usage/server_1/R1
For more information see "Performing an Incremental Backup" (on page 162).
NOTE: You must run the siubackup command locally on each host. That is, you cannot back
up collectors remotely from a different host.
See "Commands for Backing Up eIUM" (on page 169) for information on the siubackup
command.
4. Create another directory to hold eIUM initialization files:

mkdir /tmp/usage/server_1/inifiles
5. Copy all the eIUM initialization files into this directory:

cp /etc/opt/SIU/* /tmp/usage/server_1/inifiles
6. Create a directory to hold your eIUM log files:

mkdir /tmp/usage/server_1/logfiles
7. Copy all the eIUM log files to this directory:

cp /var/opt/SIU/log/* /tmp/usage/server_1/logfiles
8. Save any other files you deem necessary, for example any eIUM files you have modified or files
you have created uniquely for your deployment. For example, your collectors might read from
map files with the AdornmentRule or write to files with the WriteToFileRule. Consider exporting
your report templates from the Reporting application. Back up these files as appropriate.
4. Back up Your Input Data

The next step is to back up all your raw input data. How you do this depends on the form and
location of this data. Because each input data source is different, this section gives suggestions and
guidelines you can use to design your backup solution.
Streaming Data
If your input data is streaming data, for example UDP packets from a router, and you have a
collector listening for these UDP packets, there is nothing to back up. If the collector receiving the
streaming data goes down, or the host it is running on goes down, the streaming data will be lost
until the collector can be brought up again.
Consider setting up a high availability solution so that if a collector or host goes down, a stand-by
collector can take over collecting from the streaming data source. If you are using a Session Server
for real-time authorization and charging, consider a high availability solution as well. A standby
Session Server can take over upon a system failure and minimize or eliminate loss of data.
File-Based Data
If your input data is in files, back these files up with the collectors other backup files. Place them in
a directory such as /tmp/usage/host/inputdata/. By backing up the data files with the collectors
backup data, you can ensure the input files are in sync with the collectors history and recovery
metadata.
Save the creation date and time of each input file. You can then determine which data files need to
be reprocessed after restoring a collector. The collectors recovery information determines which
input file it needs to process next. When you restore the collector, also restore the input files so the
collector can pick up where it left off.
If your input data is stored on an external device such as a voice switch and the collector fetches the
data files from the switch, check what happens to the files on the switch after they have been
transferred to the leaf collector. Back up the files on the switch itself if it supports backup. You
might also consider backing up each input file immediately after it is fetched from the switch (this is
sometimes a legal requirement). If a leaf collector terminates unexpectedly, its history and recovery
metadata can restore the collection to the appropriate input file.

TIP: Ensure your input data file aging policy is at least as long as the time between backups. This
will ensure no input data files are aged out before they have been backed up.
Reprocessing Collector Chain
If you have an error reprocessing collector chain, collector R1 in our scenario, you could use this
chain of collectors to reprocess the data between the last backup and when the system went down.
This means you have to identify, restore and reprocess the input data files that arrived between the
last backup and when the system went down. The siurestore command restores the collectors so
they can continue processing incoming data. Use your error reprocessing collectors to process the
files that arrived between the last backup and when the system came back up.
Session Data
The siubackup command saves current in-memory session data and siurestore restores this data.
You simply back up your session collectors the same as any other collector and restore the collector
using siurestore.
Repeat Above Steps for Each Remaining Host

The steps described in "1. Prepare for a Full Backup" (on page 159), "2. Back up the Configuration
Server" (on page 159), "3. Back up All Collectors on Each Host" (on page 160), and "4. Back up Your
Input Data" (on page 161) backed up all the relevant files on Server_1. Except for backing up the
configuration server, repeat these steps for Server_2.
Next, repeat the steps for Server_3, using corresponding Windows commands and tools, directories
and files.
5. Save Backup Data to Long-Term Archives

At this point all the data for all your hosts has been saved in the /tmp/usage directory of your UNIX
hosts and the C:\tmp\usage directory on Windows hosts. The final step is to save all these files using
your standard enterprise backup solution.
Preparing for the Next Backup

If the next backup is to be an incremental backup, you can delete all the files on the host that have
been saved to long-term archive except the two XML files in each collectors backup directory. The
siubackup command with the -incremental option uses these XML files to perform an incremental
backup.
If the next backup is to be a full backup, you can delete all the files on the host after they have been
saved to the long-term archive.
Performing an Incremental Backup

This section describes how to perform an incremental backup. An incremental backup saves only the
data that has changed since the last backup. It assumes you perform incremental backups between
full backups.
1. Prepare for an incremental backup by making sure the XML files from the previous backup (full
or incremental) are still in the backup directory for each collector. In our scenario, this would be
/tmp/usage/server_1/L1, for example. The siubackup command uses these XML files to

determine what data to back up in an incremental backup.

2. An incremental backup is identical to a full backup except the siubackup command uses the -
incremental option instead of the -full option. To perform an incremental backup, follow steps
"2. Back up the Configuration Server" (on page 159) through "5. Save Backup Data to Long-Term
Archives" (on page 162), however, use the -incremental option on all siubackup commands
instead of the -full option.
For example, the following command performs a full backup of the collector named Voice01 and
places the backup files in the directory /backup/Voice01:
siubackup -n Voice01 -full -backupDir /backup/Voice01
Assuming the existing backup files are in /backup/Voice01, the following command performs an
incremental backup of the collector named Voice01 and places the additional backup files in the
directory /backup/Voice01:
siubackup -n Voice01 -incremental -backupDir /backup/Voice01
Restoring eIUM from a Backup

This section describes how to restore eIUM on a host that failed unexpectedly. It assumes a
completely new host system without eIUM or any related data files installed. Follow the steps below
on the new host system.
1. Make sure all collectors to be restored have STARTUPMODE set to Manual, not Automatic.
If the Configuration Server is running on another host (that is, not the host being restored),
change all collectors on the host being restored to start manually. They must not start
automatically when you restore eIUM. In the Launchpad, select each collector and open the
Properties window either by right-clicking on the collector and selecting Properties, or by
selecting the collector and selecting the Actions:Properties menu. Change the STARTUPMODE
property to Manual if it is set to Automatic.
(If the system you are restoring hosts the Configuration Server, you cannot change the
STARTUPMODE property until the Configuration Server starts. You will modify the configuration
as described below before loading it from backup.)
2. Install the eIUM software from your original product CD or from your backup. Install any eIUM
patches, as appropriate.
3. Make sure eIUM is running properly on the host system. Check the log files and the status
information in the Launchpad.
4. Obtain the backup files you stored from the most recent backup (full or incremental) and place
them in the directory /tmp/usage/<host name> on the eIUM host.
5. For each collector to be restored, obtain all the backup files for each collector starting with the
last full backup, followed by each successive incremental backup in chronological order. Copy all
these files to the directory /tmp/usage/<host name>/<collector name>. Make sure you have
the XML files from the most recent incremental backup.
6. If you are restoring the host with the configuration server, edit the configuration file and make
sure the STARTUPMODE property for each collector on the host being restored is set to Manual.
Each collectors STARTUPMODE property is under the configuration node /deployment/<host
name>/<collector name>/Properties.

Otherwise, skip this step.

7. If you are restoring the host with the configuration server, import the configuration
information with the command as follows:
loadconfig -f /tmp/usage/<host name>/deployment.config
Otherwise, skip this step.
NOTE: When loading configurations with the Launchpad or the loadconfig command, make
sure you load valid configurations as the configurations are simply copied into the
configuration server. See the eIUM Command Reference for details on the loadconfig
command.
8. Restore each collector on the host using the siurestore command and the most recent backup
file. Use the full path to the backup file. Make sure the most recent full backup file is restored
and all following incremental backup files are restored.
siurestore -f /tmp/usage/server_1/L1_070620041725_1.jar
9. Copy the eIUM initialization files from the backup directory:

cp /tmp/usage/server_1/inifiles/* /etc/opt/SIU
10. Optionally copy the log files from the backup directory:
cp /tmp/usage/server_1/logfiles/* /var/opt/SIU/log
11. Restore any other files you backed up such as map files or other files used by the collectors.
12. Restore your input data, if applicable.
When the collector starts running, it first reads its recovery data to determine what input file it
processed last. Most encapsulators then read the next file they are configured to read. The
collector will start reading from where it was as of the last backup.
13. Start each collector. Check the collectors status in the Launchpad and its log files to make sure
it is running properly and processing the restored data files properly.
14. Restore each collectors STARTUPMODE property. In the Launchpad, select each collector and
open the Properties window either by right-clicking on the collector and selecting Properties or
by selecting the collector and selecting the Actions:Properties menu. Set the STARTUPMODE
property to Manual, Automatic, or %DEFAULTS%. See "Automatically Starting a Collector or
Server" (on page 89) for more information.
Recovery in a Collector Hierarchy

There are additional considerations in returning an entire eIUM deployment to its current state if a
single host in a hierarchy of eIUM hosts has failed.
In general, the recovery would be just like ungracefully shutting down a collector in the hierarchy.
For example, powering off the machine rather than stopping collecting. eIUM is designed to recover
in this situation. The failed collector will be behind the others once restored and will catch up from
the point of its restoration. If higher level collectors depend on it, these collectors will simply wait
for the recovering collector to catch up and pass its previous point, and then begin to read new
NMEs.

If the failed system is the configuration server, there are additional considerations if a collector on a
remote system was configured between the time of the last backup and the failure. In this case,
save the new collectors configuration and then load the new collector configuration information
after the Configuration Server is restored.
Depending on the type of input data, it is possible the restore would roll back the collector to a point
where input data is missing. In cases where the input data for the recovered collector is no longer
available, complete recovery from the last backup to the time of failure will not occur automatically.
Below are sample scenarios where this may occur.
Collection from Service Access Logs

The backup takes place at 5 PM, and failure occurs at 11 PM. The system is restored at 6 AM. The
logs record up to 5 PM. The 6 hours of data from 5 PM to 11 PM will not have been backed up and
therefore won't be recovered. The service was not running from 11 PM to 6 AM. When the system
restarts, eIUM would reprocess from the last flush prior to the backup (say 4 PM) through the
recovered information (up to 5 PM) and then there would be a jump ahead in time to service log
records beginning at 6 AM.
The best way to completely avoid losing data is to employ a high availability solution.
Lower Level Collector with Aggressive Aging Policies

Assume the same recovery time line as in the previous example. A second level collector system is
backed up at 5 PM. If the lower level collector it relies on ages data out every 6 hours, there will be
no data beginning at 4PM, the last recovery point. The data exists only from 0:00-6:00, so a gap
occurs.
When determining the backup strategy for an eIUM deployment with multiple hosts in a collector
hierarchy, it is important to understand the eIUM configuration including items like data sources and
data aging policies so that a strategy that minimizes opportunities for data loss can be avoided.
Offline Backup Strategy

This section describes how to back up and restore an eIUM deployment using an offline backup
strategy. For an online backup strategy, see "An Online Backup Scenario" (on page 157).
An offline backup strategy requires stopping all collectors and other eIUM components, performing
a backup, then restarting all the components and collectors. This approach allows individual
collectors to finish active processes, write information that is in memory to disk, and write recovery
information to disk. The information saved on disk while a collector is stopped enables the collector
to start processing from a precise point in time. This method ensures all data has been committed
to disk prior to backup and there are no inconsistencies in where the collector should start
processing.
If using an offline backup strategy, collectors may miss data during the shutdown period if collecting
from certain types of data sources. For example, a Netflow collector that consumes data
transmitted via UDP from an assigned port on a Netflow enabled Cisco device would miss UDP
packets transmitted during its shutdown period.
For an offline backup strategy, follow these basic steps for each eIUM host. These steps can be
automated using scripts executed at appropriate time intervals.

NOTE: The default installation location for eIUM is /opt/SIU, /etc/opt/SIU and /var/opt/SIU on
UNIX, and C:\SIU on Windows. The instructions use these default locations. If you installed eIUM in
a different directory, alter these instructions accordingly. The eIUM commands are in C:\SIU\bin
on Windows and /opt/SIU/bin on UNIX.
1. Stop all collectors on the host. Use the Launchpad or the siucontrol command to stop all
collectors. Stop the collectors in reverse order of the data flow. That is, stop the highest level
collectors first and work down, stopping the leaf level (or first level) collectors last.
2. Back up the Configuration Store for the entire eIUM deployment in an ASCII file.
The ASCII version of the configuration store is created manually using the saveconfig command
or the Launchpad. Prior to a backup, execute a saveconfig for the entire eIUM deployment. This
writes all configuration information into a single file or directory structure in ASCII format that
can be easily and cleanly backed up and restored. Be sure to select a specific directory location
and filename for saving the configuration file and use this directory consistently as the backup
location.
This does not need to be done daily but should be done as a part of a regular full eIUM backup
and after configuration changes have been made.
For example, the following command saves all configuration information under the
configuration tree root (the / path) to the file IUMHost01-07152004.config:
saveconfig -p / -f IUMHost01-07152004.config
Place the resulting configuration file in /var/opt/SIU/Backups or C:\SIU\var\Backups, or

somewhere else that will be backed up.
For complete details on the saveconfig command, see the eIUM Command Reference.
3. Stop the Configuration Server. Use an siucontrol command like the following:
siucontrol -n ConfigServer -c stopProc
For complete details on the siucontrol command, see the eIUM Command Reference.
4. Back up your database. For MySQL backups, use the mysqldump command-line utility. This
utility is included with eIUM, along with other mysql binaries, and is located in C:\SIU\mysql\bin
(Windows) or /opt/SIU/mysql/bin (UNIX).

Before backing up the database, the database server must be running when performing the
backup. The mysqldump utility produces an SQL script that contains the structure and content
of the database tables, and can be used to later restore your database.
To restore data from this backup file, use the mysql command line tool (also see "Managing the
MySQL Database" (on page 95) for more information on this tool). The following are detailed
backup steps you can use for both UNIX and Windows operating systems.
For UNIX, use the mysql.sh script (located in /opt/SIU/sbin), which also includes functionality for
various database operations (for example, starting/stopping/restarting the database server,
and connecting to the server with the mysql command-line tool). The script also includes a
backup option, which allows you to launch mysqldump with the appropriate arguments, and to
store the output to the /var/opt/SIU/mysql/backup directory (using date and time of backup as
the file name). User name and password details must also be passed, using the u and p
options, just as with the mysql tool. For example, a command to execute a backup is the
following:
[root@swtsscn sbin]# ./mysql.sh backup -usiu20 -psiu20
Backup file created:
/var/opt/SIU/mysql/backup/2010-08-10-07h-38m.sql
To restore the database, execute the following command:

[root@swtsscn sbin]# ./mysql.sh connect -usiu20 -psiu20 <
/var/opt/SIU/mysql/backup/2010-08-10-07h-38m.sql
NOTE: In the above examples, ./mysql.sh connect -usiu20 -psiu20 does not
itself restore a backup, but is instead a convenient way for you to start the command line
client and connect to the corresponding instance of the MySQL server (which corresponds to
the eIUM installation in question).
Using < /var/opt/SIU/mysql/backup/2010-08-10-07h-38m.sql on the

command line makes the tool execute the given .sql script and exit. In actuality, a command
line client is being started and passes a backup file (the SQL script) by using the < operator.
For Windows, there is no eIUM-specific script for MySQL operations, so the mysqldump utility
should be launched directly. For example:
C:\SIU\mysql\bin>mysqldump.exe -A -usiu20 -psiu20 > .\backup\2010-
08-10.sql
The -A option signifies that all databases should be backed up.

To restore from a backup:
C:\SIU\mysql\bin>mysql -usiu20 -psiu20 < ..\backup\2010-08-10.sql
5. Back up the eIUM software. The following describes the directories and files you should back up.
These tables give the default installation locations. If you installed eIUM in an alternate
location, change these to match your environment. For UNIX:

UNIX Directories to Back Up

Directory Description
/etc/opt/SIU eIUM software files.
/var/opt/SIU eIUM log files and data files. Binary configuration store files,
named *.db and *.db.last.
/opt/SIU eIUM software files.
/sbin/init.d/SIU or Start up and shut down scripts.

/etc/init.d/SIU
/etc/rc.config.d/SIU Start up and shut down initialization files.
For Windows, back up the C:\SIU directory, which contains all eIUM software, log files and data
files.
6. Back up all directories containing your input and output data files. Examples of input data files
are CDR files, log files and other usage and session data files. Check the configurations of your
collector encapsulators for input files and directories.
Examples of output files are IDR files, XML files and binary data files. Check the configurations
of your collector datastores for output files and directories.
7. Back up the file system and the operating system software using your standard backup
solution.
8. Start the Configuration Server. Use an siucontrol command like the following:
siucontrol -n ConfigServer -c startProc
9. Start each collector. Check the collectors status in the Launchpad and its log files to make sure
it is running properly and processing the restored data files properly.
Restoring from Offline Backup Files

The following outlines the general steps for an eIUM recovery process when an offline backup
strategy is used:
1. Stop all collectors and eIUM processes. Use a command like one of the following:
On Windows: net stop SIU_AdminAgentServer
On HP-UX: /sbin/init.d/SIU stop
On Linux or Solaris: /etc/init.d/SIU stop
2. Restore all eIUM files using your backup solution.
3. Start eIUM on the host with the Configuration Server.
On Windows: net start SIU_AdminAgentServer
On HP-UX: /sbin/init.d/SIU start
On Linux or Solaris: /etc/init.d/SIU start
4. Start any other collectors configured to start manually, if any, on all remaining eIUM hosts.

5. Check to make sure all collectors and other processes that start automatically are running
properly. Check status in the Launchpad, examine log files and output data.
Troubleshooting Recovery
If there are errors after restarting eIUM, then the restored version of the Configuration Store may
be corrupted. In this case, use the ASCII form of the Configuration Store, which you created using the
saveconfig command, to start the Configuration Server using the command: configserver -f
<configuration file name>.
If the Configuration Server starts when manually loading the Configuration Server using the ASCII
configuration file do the following:\
1. Use the loadconfig command to reload the configuration from the ASCII configuration file. For
example, use a command like the following:
loadconfig -f UsageBackup07062004.config
When loading configurations with the Launchpad or the loadconfig command, make sure you
load valid configurations as the configurations are simply copied into the configuration server.
2. Stop the Configuration Server. Use a command like the following:
siucontrol -n ConfigServer -c stopProc
3. Start eIUM.
On Windows: net start SIU_AdminAgentServer
On HP-UX: /sbin/init.d/SIU start
On Linux or Solaris: /etc/init.d/SIU start
Commands for Backing Up eIUM

This section describes the siubackup and siurestore commands for backing up and restoring an
eIUM deployment. You can perform both full and incremental online backups while collectors and
other processes are running.
For complete information on eIUM commands, see the eIUM Command Reference.
siubackup Command
The siubackup command saves all data associated with a collector. The collector must be running
when you use siubackup. After running this command, save the resulting files using your routine
system backup procedures. Use the siurestore command to restore a collector from backup files.
This command saves the following:
l Collector configuration.
l Meta data for the collector. That is, the history table and the recovery table.
l Usage data in the collectors datastore.
This command does not save the collectors log file.

Syntax
siubackup -n <collector name> [ -full] [ -incremental] [ -dir
<directory name>] [ -maxfilelimit <files number>] [ -usage] [ -l
<loglevel>] [ -version] [ -propertyFile <file>] [ -host <host>] [ -
iorURL <URL of IOR file>] [ -binRoot <directory>] [ -cfgRoot
<directory>] [ -varRoot <directory>] [ -login <user>] [ -pw
<password>]
Some common options are highlighted in the following table. See the eIUM Command Reference for a
full listing of siubackups options.
siubackup Command Options

Option Description
-n <collector name> Specifies the name of the collector to back up.
-full (Default) Specifies a full backup operation.

Creates a backup file named
(<collectorname>_FULL_<timestamp>_
<number>.jar), containing the configuration,
data files, and database entries needed to
restore the data later. The utility also stores
the backup history information needed for
incremental backups in the BackupHistory.xml
file. When you execute a full backup again, the
existing history file is moved to a file with the
time stamp in its name.
-incremental Specifies an incremental backup operation.

This operation reads the backup history
(BackupHistory.xml) to determine the
datasets to be backed up and creates an
incremental backup file named
(<collectorname>_<timestamp>_
<number>.jar). If the specified directory does
not exist or does not contain the history file,
this operation performs a full backup.
-dir <directory name> Specifies the directory in which to create and

store the backup files. The default directory is
<VARROOT>/Backups/<collector name>,
where <VARROOT> is typically C:\SIU\var\ on
Windows and /var/opt/SIU on UNIX systems.
Examples
The following example performs a full backup of the collector named SWITCH01 and places the
backup file named SWITCH01_FULL_060620041725_1.jar in the directory /var/opt/backup/usage:
siubackup -full -n SWITCH01 -backupDir /var/opt/backup/usage

The following example performs an incremental backup of the collector named Correlator03 and
places the backup file named Correlator03_060620041725_1.jar in the directory
/var/opt/backup/usage:
siubackup -incremental -n SWITCH01 -backupDir /var/opt/backup/usage
siurestore Command
This section describes the siurestore command for restoring a collector from backup files. The
collector to be restored must be stopped when running siurestore. However, the admin agent and
the configuration server must be running to use this command.
As an added precaution, perform an offline backup, if possible, particularly if there is data in the
collectors to be restored, and if the intent of the restore is to roll back to a given point in time.
To restore one or more collectors, shut down the collectors and clean them up using the Launchpad
or the siucleanup command. Then run siurestore using the backup file for each collector.
After restoring each collector, start each restored collector and make sure it is running correctly by
checking status in the Launchpad, and the collectors log file and output data.
Syntax
siurestore -f <file name> [ -noConfig] [ -l <loglevel>] [ -version] [
-propertyFile <file>] [ -host <host>] [ -iorURL <URL of IOR file>] [ -
binRoot <directory>] [ -cfgRoot <directory>] [ -varRoot <directory>] [
-usage] [ -login <user>] [ -pw <password>]
Some common options are highlighted in the following table. See the eIUM Command Reference for a
full listing of siurestores options.
siurestore Command Options

Option Description
-f <backup File> Specifies the complete path to the file containing

backup information. If there are multiple files in the
directory, select the latest backup file. The utility
determines the last full backup using the backup
history and restores the collector data.
-noConfig Specifies that the collectors configuration should not

be restored. Use this option when your backup
procedure already restores the entire contents of the
Configuration Store.
Examples
The following example stops, cleans up, restores and restarts a collector using the backup file
Correlator03_060620041725_1.jar. The name of the collector is Correlator03.
siucontrol -n Correlator03 -c stopProc

siucleanup -n Correlator03
siurestore -f /tmp/usage/Correlator03/Correlator03_060620041725_1.jar
siucontrol -n Correlator03 -c startProc

Chapter 11
eIUM Logging
The following topics describe eIUM logging and how you can use logs and configure logging for your
deployment.
Overview of eIUM Logging 172
Basic Logging 173
Advanced Logging 173
Basic Logging Configuration 180
Precedence of Settings 181
Setting the Log Level from the Launchpad 181
Setting the Log Level from the Properties Node 181
Setting the Log Level from the Command Line 181
Controlling Log File Rollover and Aging 182
Advanced Logging Configuration 184
Configuring Server and Process Logging 184
Configuring Logging for a Package or Class 184
Using Linked Configurations 188
Setting Up Centralized Logging 188
Logging System Components 189
Logging Control Flow 190
Logging SDK Javadocs 190
Configuring Centralized Logging Using Syslog 190
Setting Up Centralized Logging with LogConsolidator 195
Configuring Centralized Logging Using OpenView Operations 200
Overview of eIUM Logging

The eIUM logging system can provide the information you need to maintain and troubleshoot your
eIUM deployment. Use the logging system find and fix configuration problems, network problems,
data processing problems, or the occasional software defect or operator error. This section
provides an overview of the logging system and describes some basic procedures for working with
eIUM logging.

Chapter 11: eIUM Logging
eIUM maintains a detailed record of activities by generating operational and audit log messages and
storing them in log files. An eIUM deployment typically consists of several collectors and servers,
such as the configuration server, admin agent, and report server. Your deployment may also include
optional servers such as the report server, session server, and schedule server. Each server can
generate operational messages about activities. Some processes, such as collectors, can also
generate audit messages to monitor data processing. For more information on auditing, see the
The logging system supports a distributed deployment in which processes run on multiple hosts.
Figure 10-1 shows the logging system in a distributed deployment with two hosts. The logging
system allows each process to write messages to its own log file on local storage.
Basic Logging
Basic use of the eIUM logging system involves:
l Setting log levels: You can set the log levels for different servers and processes. eIUM processes
start with logging enabled at the default level of 4=Informative.
n For a definition of the log levels available, see "Log Levels" (on page 178).
n For instructions on setting log levels through the Launchpad, see "Setting the Log Level from
the Launchpad" (on page 181).
l Viewing log messages: You can view log files using any text editor or the Launchpad. For
instructions on viewing log files with the Launchpad, see "Viewing Log Files in the Launchpad" (on
page 180) for more information.
NOTE: You can use other interfaces, such as the command-line or the properties file to set log
levels. However, for basic logging, using the Launchpad is the most straight-forward way to
adjust log levels.
Advanced Logging
Although setting log levels and viewing logs through the Launchpad are usually sufficient for
monitoring individual eIUM servers from day to day, eIUM also provides fine-grained control of
logging across the deployment. Taking advantage of these additional capabilities may involve
several advanced tasks, including:

l Configuring advanced logging: The eIUM logging system supports a Logging configuration node in
the configuration tree of the Launchpad, through which you can configure logging for a single
process, configure differentiated logging for packages or classes invoked by that process, or and
optionally, to share the logging configuration with other processes. For instructions on
configuring advanced logging through the Logging configuration node, see "Advanced Logging
Configuration" (on page 184).
l Setting up centralized logging: To manage large numbers of log files generated by many
different collectors and servers, you can set up centralized logging to consolidate log messages
and view them in a single, central log file. Options for setting up centralized logging include using
the UNIX syslog daemon, using HP OpenView Operations (OVO), or configuring the eIUM
LogConsolidator. For instructions on consolidating log files, see "Setting Up Centralized Logging"
(on page 188).
Basic Log File Names and Locations

Basic log files include those for collectors, the admin agent, and the configuration server. You can
find most log files in or under C:\SIU\var\log on Windows and /var/opt/SIU/log on UNIX. The table
below shows the names of the log files and startup files. The startup files contain output from when
a process starts. If a process does not start, check the startup file. The log files contain information
produced by the process itself. If a process is behaving incorrectly, check the log file.
Basic Log Files

Process Log File Name Startup File Name
Collector <collector-name>.log, for example Startup information is in the admin

VoiceColl01.log agent log file.
Admin Agent <host-name>.log, for example AdminAgentServer.out

host01.log
Configuration ConfigServer.log ConfigServer.out

server
Log Message Format

The logging system creates log messages in the following format.
eIUM Log Message Format

Field Description
Date mm/dd/yyyy
Time hh:mm:ss.ms
Time xxT
Zone
Thread Thread generating the message, such as main or Thread-4.
Message (pp.ccc.nn), where pp is the numeric code of the package, ccc is the numeric code
ID of the class, and nn is the numeric code of this message.
Log The severity of the message.

Field Description
Level
Message The text of the message.

Text
The following example shows a log message that is Informative in severity level:
03/20/2003 09:37:19.500 PST main (02.010.09) INFORMATIVE: Server
starting in non-secure mode
Additional Log File Types

Your eIUM deployment generates a number of log file types in addition to basic log files. The
additional log file types include:
l Launchpad log files

l Collector log files
l Configuration server log files
l Host log files
l Windows Service Log Files
l MySQL log files
l Command utility related log files
l Web application log files (Operations Console, RDM)
Launchpad Log Files
The Launchpad creates log files in C:\SIU\var\log or /var/opt/SIU/log named Launchpad_<time-

stamp> where <time-stamp> is the date and time the file is created.
You can specify whether or not to save Launchpad log files by choosing Options and Preferences and
setting or clearing the Delete Launchpad log file on exit checkbox.
Changing whether or not to save the Launchpad log file takes effect the next time you start the
Launchpad. The current setting is used when the Launchpad closes. If you change the setting to save
the log file on exit, but you want to save a copy of the current Launchpad log file, you must manually
make a copy of the log file before exiting the Launchpad.
Collector Log Files
Collector log files contain a record of the collector activity, including when a collector starts, when it
flushes records to the datastore, and details of any errors encountered.
Collector log files are typically located in C:\SIU\var\log on Windows and /var/opt/SIU/log on UNIX:
l Primary log files are named <collector name>.log

l Rollover log files are named <collector name>.logOLD

If a primary log file reaches the maximum size, it rolls over to a new file that is renamed to the
rollover log file name, and a new primary log file is created. For example, if the log file for a collector
named voice_collector reaches the maximum size, the primary log file voice_collector.log rolls over
and is renamed voice_collector.logOLD, and then a new voice_collector.log file is created. For more
information on configuring log file rollover and aging, see "Controlling Log File Rollover and Aging"
(on page 182).
Logging output is controlled by the logging level (by default, 4=INFORMATIVE). Logged messages with
a severity below the logging level are not written to the log file. For example, if a collector generates
a DEBUG level log message, the DEBUG message is not written to the log file if the logging level is
set to WARNING.
Setting the LOGDEBUG property or using the -d command line option specifies that the collector use
stderr for logging messages instead of a log file.
NOTE: If a collector throws and logs a Java exception, the messages begin with the problem
followed by a stack trace. That first message is the actual problem encountered, while the stack
trace can give clues about what the collector was trying to do when it encountered the problem.
Read the stack trace from the bottom, where the first class is invoked, to the top, where the
most recent class is invoked, which is the class with the error.
Configuration Server Log Files
The configuration server uses the same logging mechanism as the eIUM collectors and supports the
same properties. To change the logging level of the configuration server, select the node of the
configuration server, and choose Set Log Level to specify a new logging level. Alternatively, use the
siucontrol utility to change the logging level of the configuration server, for example, enter the
following command to set the log level to 5:
siucontrol -n ConfigServer -c setLogLevel 5
The configuration server uses a primary log file called C:\SIU\var\log\ConfigServer.log on Windows
and /var/opt/SIU/log/ConfigServer.log on UNIX, for the host on which the configuration server runs.
The rollover log file name is ConfigServer.logOLD.
Host Log Files
Each host admin agent writes log messages to C:\SIU\var\log\<hostname>.log or

/var/opt/SIU/log/<hostname>.log. The host admin agent controls all eIUM processes on the host and
records status of managing these processes.
Windows Service Log Files
On Windows platforms, the host admin agent and the MySQL database run as Windows Services and
log additional messages about start-up and shutdown. You can use the Event Viewer application to
view messages related to service start-up and shutdown. The service names are SIU_
AdminAgentServer and SIU_MySQL.
UNIX Daemon Log Files
On UNIX platforms, when the HP-UX system starts or shuts down, it executes the /sbin/init.d/SIU
script and logs the output to the /etc/rc.log file on HP-UX and /dev/msglog on Solaris. The script
/sbin/init.d/SIU starts the host admin agent daemon and the MySQL database server daemon.

MySQL Log Files
MySQL log files you can reference include the following:
l MySQL server logLog messages concerning server operation are logged to this file, such as
server start-up, shutdown, and any error messages. This log file is located in
C:\SIU\mysql\data\$HOST_ID.err (Windows), or /var/opt/SIU/mysql/data/%HOST_ID%.err (UNIX).
l General query logThe server writes information to this log when clients connect or disconnect,
and it logs each SQL statement received from clients. To activate this logging, execute the
following SQL command:
SET GLOBAL general_log = 'ON';
To disable it:
SET GLOBAL general_log = 'OFF';
To view the log file location:

SELECT @@global.general_log_file;
general_log_file is a MySQL server variable that points to the general MySQL log location. This file
is typically in C:\SIU\mysql\data\%HOST_ID%.log (Windows), or /var/opt/SIU/mysql/data/my.log
(UNIX).
l my.ini/my.cnf configuration fileThis stores configuration parameters for the MySQL server.
The full list of configuration options can be found at
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html.
This file is typically found in C:\SIU\mysql\my.ini (Windows), or /opt/SIU/mysql/my.cnf (UNIX).
Executing SQL Statements to Enable Logging
To execute SQL statements to enable logging, you can use the mysql.sh command-line tool
described in "Managing the MySQL Database" (on page 95). Using mysql.sh, you can first connect to
MySQL using the following command:
%BINROOT%/sbin/mysql.sh connect usiu20 psiu20
After being connected, SQL statements can be executed to enable logging.
Command Log Files
Log files related to eIUM's command line interface and console are found in %VARROOT%/log. For
example, the log file for the repositorymanager command (repositorymanager.log) is located in this
directory. See "Using eIUMCommands" (on page 62) or the eIUMCommand Reference for more
information on eIUMcommands.
Web Application Log Files
Both the RDM log file (rdm.log) and Operations Console log files (OperationsConsole.log,
OperationsConsole.audit.log) can be found in C:\SIU\var\webappserver\logs on Windows, or
/var/opt/SIU/webappserver/logs on UNIX.

For RDM, there are four types of logs that you can look at for additional Information about
operations and errors in RDM.
1. rdm.logContains logs such as errors, warnings, and information on operations.

2. rdm.audit.logProvides information about RDM URLs and resources accessed by the user.
3. RDMDB.audit.logContains all the audit log messages for database operations done through
RDM. For more information about auditing, see "Audit Logging" (on page 53).
4. localhost.date.logContains logs made by code outside RDM, or errors not handled by RDM.
Log Levels
Each log message has an associated log level that reflects the importance and urgency of the
message. eIUM defines nine log levels listed in descending order of severity in the table below.
Log levels are cumulative. That is, each level includes all the levels numerically below it. For example,
if you set the log level to 2 = Warning, only 0 = Critical, 1 = Error and 2 = Warning messages are
generated. All levels greater than 2 = Warning are suppressed and not published to the log file.
Setting the LOGLEVEL property or using the siucontrol -loglevel command line option controls the
initial collector logging level. Additionally, you can change the collector logging level while the
collector is running by using the Launchpad to choose Actions and Set Log Level or the siucontrol
command. The default logging level for collectors is 4=INFORMATIVE.
You can selectively raise the debug level on individual components or Java classes to target your
debugging and minimize extraneous logging messages, as described in "Setting the Log Level in a
Secondary Property File" (on page 185).
eIUM Log Levels

Level
Number Level Name Description
0 CRITICAL Message explaining a fatal error just before a component goes down, for
example, messages about being unable to connect to an eIUM
component.
1 ACCOUNTING Message noting a normal occurrence, such as a request to age NMEs or

request for collector shut down. These few messages are useful for
tracing even the logging level severity is greater than INFORMATIVE level.
2 ERROR Message about a situation where the component cannot operate

properly or carry out a request. These error situations could eventually be
fatal but the component will continue to run.
Examples are corrupt input files or corrupt configuration store, cannot

connect to a component even after retry, invalid user input values,
unexpected errors encountered in requests such as to query usage data
or age NMEs, cannot save a file or data, files not found and no default file
name available, or internal errors.
3 WARNING Message about an unexpected event that might lead to further problems.

Level
Number Level Name Description
Examples are messages about connections lost but that will be retried,
parameters not specified and default values used instead, skipping
invalid input log records, packets dropped, files not found, and warnings
about eIUM license expiration.
4 INFORMATIVE Messages about normal events such as commands received, messages

about successful connections made, and results of requests for
statistics. These messages are useful for tracing, as are ACCOUNTING
level messages, but are much more frequent.
5 DEBUG Least detailed and frequent debug messages. Debug messages are
useful only for developers.
6 DEBUG2 Medium detail and frequency debug messages.
7 DEBUG3 Very detailed and frequent debug messages.
8 DEBUG4 Most detailed and frequent debug messages.
Warning About Using Debug Log Levels
Using any of the Debug log levels can significantly reduce collector and server performance. Debug
log messages produce a large number of detailed log messages in a short amount of time The
internal nature of many Debug messages can make them difficult to understand. Only use the
Debug levels temporarily when debugging a collector or server.
Audit Log Levels
In addition to the server logger, eIUM uses an audit logger to track important events during data
processing. The eIUM audit system generates log messages and stores them either in the audit log
files or in the server log files along with the standard operational log messages. Because the audit
logger not a general purpose logger, it supports only a subset of the general server log levels, as
listed below. For more information about the audit system, see the eIUM Foundation Guide.
eIUM Audit Log Levels

Level Level
1 ERROR Indicates that the process encountered a fatal error.
2 WARNING Indicates that the process encountered an unexpected event that might
lead to an error later.
3 INFO Indicates a normal event.
0 OFF No audit messages are written to the log file.

Viewing Log Files in the Launchpad

Log files are text files, so you can view them with any text editor, or you can use the capabilities of
the Launchpad to view log files. The Launchpad has a log viewer pane that displays the log file of a
process. The viewer displays a live view, updating itself as the process writes messages to the log
file. By default, the log viewer pane is displayed below the deployment pane in the main window.
To View Log Files in the Launchpad
With the Launchpad running, select the node of the component for which you want to view logs.
Then refer to the following table for what to do next.
IF you want to
view logs... THEN...
in the log viewer Choose Actions and View Log File. The messages contained in the log file are
pane of the shown in the lower log viewer pane of the main window.
Launchpad
in a separate Choose Actions and Open Log Viewer. The log viewer displays as much of the
window through logging file as possible, continually updating the display with messages as
the Log Viewer the component writes them to the file.
tool
If required, click Pause to stop the live screen updates. You can also do a
text search of the log file contents or wrap the text in the Log Viewer tool.
using the siudiag Refer to the eIUM Command Reference for a description of using this
command command.
Basic Logging Configuration

You can configure each process and the corresponding log file with a specific level of detail and file
rolling and aging policies. A distributed logging system is scalable and reliable. When a process
writes to its own log file on local storage, logging overhead is minimal and reliability is high.
The logging system supports both static and dynamic configuration control. Static control allows you
to specify a configuration and then re-launch the process with the new settings. Dynamic control
allows you to update the configuration for a running process.
All eIUM processes start with logging enabled. The default log level is 4=INFORMATIVE. See "Log
Levels" (on page 178) for a description of the log levels available. The eIUM logging system provides
the following interfaces, which you can use to change the log level to increase or decrease the
granularity of log messages.
l Launchpad
l Command Line
l Process Properties Node
l Configuration Tree
l Inherited Property File
The following sections show you how to configure the log level from each interface.

Precedence of Settings
If any of the logging settings conflict across these different interfaces, the settings apply in the
above, numbered order of precedence. Namely, configuration set using the command line or the
Launchpad takes precedence over the remaining interfaces and configuration set through the
process property file takes precedence over that set using the configuration tree or inherited
property files.
Setting the Log Level from the Launchpad

HP eIUM logs a variety of events for each component. You can change the amount and type of
logging HP eIUM does as follows:
1. With the Launchpad running, select the node of the eIUM component for which you want to set
the log level.
2. Choose Actions and Set Log Level, or right-click and choose Set Log Level.
3. Choose a log level. For a description of each log level, see "Log Levels" (on page 178).
4. Click OK. eIUM writes an accounting message to the log file of the component recording that
the log level is changed.
Setting the Log Level from the Properties Node

eIUM uses a configuration node called Properties to hold the same information in the configuration
tree. To set the startup log level in the Properties node of the configuration tree instead of an
external process property file, use the Launchpad as follows:
1. Start the Launchpad.

2. In the left pane, select a process (collector or server).
3. Under Actions (or right-click), select Properties.
4. In the dialog box that opens, double-click PROCESSARGS.
5. In the dialog box that opens, change the attribute value -l <loglevel>.
6. Click OK, Apply, and OK to apply the changes. The new log level takes affect when the process
restarts.
NOTE: The log level set from the command-line or the Launchpad overrides the log level set in the
process property file or the Properties configuration node.
Setting the Log Level from the Command Line

You can use the siucontrol command to change a components log level. See the eIUM Command
Reference for a description of all eIUM commands.
To change the log level of a running process, execute the following command:
siucontrol -n <collector-name> -c setloglevel <log-level>
You must specify an integer value from 0 to 8 as the <log-level> as described in "Log Levels" (on
page 178).
You can also start a collector at a specific log level by executing the following command:
siucontrol -n <collector-name> -loglevel <log-level> -c startProc

Controlling Log File Rollover and Aging

This section describes the default log file rollover and aging configuration for eIUM, as well as how
you can configure collectors to perform time-based log file rollover and aging.
The eIUM logging system supports simple log file rollover and again. Simple log file rollover involves
archiving the old log file and starting with a new one. You can configure processes to roll over their
log files based on the size of the current log file. When a log file, say netflow_collector.log,
reaches its maximum size, it is renamed netflow_collector.logOLD. Subsequent log
messages are written to the now-empty primary log file netflow_collector.log. If an old file
already exists, it is overwritten. The logging system maintains at most one current and one previous
log file for each process at any given time.
NOTE: To configure time-based rollover, you must disable automatic rollover and use an external
script to perform this operation. For instructions on configuring collectors to create time-based
log files based on simple file roll policies, such as date and time based policies, see "Reading and
Processing Log Files with a Collector" (on page 183).
Changing the Default LOGLINELIMIT

Setting the LOGLINELIMIT property controls the size that primary log files are allowed to reach
before being rolled over. Setting this to a value of 0 (zero) prevents the log files from being
automatically rolled over, no matter how large they get. With the LOGLINELIMIT set to zero, you must
use the administrative request rollLogFile from the siucontrol utility (rollLogFile) to cause the
primary log file to rollover. This can be useful when the log file rollover needs to be controlled
externally, such as by a nightly backup script.
How to Change the LOGLINELIMIT

To change the
LOGLINELIMIT... Take these steps...
for all the Edit the following line in SIU.ini file of your eIUM installation directory, where
processes in your the default value is 50,000 lines maximum allowed in the primary log file:
eIUM deployment
LOGLINELIMIT = 50000
for an individual Determine whether a .properties file containing the LOGLINELIMIT setting is
process, through already created by looking in the /var/<Collector Name> directory of your
the process eIUM installation, where Collector Name is the name of the collector or
.properties file server:
l If this .properties file is present, edit the LOGLINELIMIT property to

specify a different value, for example, 25,000 lines instead of the default
value of 50,000.
l If this .properties file is not present, create a new .properties file
containing the LOGLINELIMIT setting, with your desired value.
Then set the PROCESSARGS property in the Properties configuration node of
the server to specify the use of the .properties file by using the -
propertyFile option.

To change the
LOGLINELIMIT... Take these steps...
for an individual With the Launchpad running, select the node of the collector or server for
process through which you want to change the LOGLINELIMIT.
the Launchpad
1. Right-click on the node, and choose Properties.
2. Right-click on the Properties node, and choose Add Attribute.
3. Enter LOGLINELIMIT for the new attribute name.
4. For the attribute value, specify the maximum number of lines that you
want the primary log file to contain before rolling over, for example,
25000.
5. Click Apply and OK.
Reading and Processing Log Files with a Collector
The collector log file contains various eIUM system messages about errors, warnings, informational
notes, and other operational results and audit details, depending on the logging configuration. By
default, the LogFileHandler component of a collector writes these messages to the collector log file,
rolling over messages to a new log file once the number of lines exceeds the LOGLINELIMIT. You can
use a higher level collector to read these log files, however, this may be tedious due to the rolling
nature of the files. Therefore, you may prefer that your collectors generate log files with time and
date-based file names. In this case, you can configure the RollingLogFileHandler component.
When this file reaches the log limit based on the file size or number of lines or timestamp, it
renames the log file with a logOLD name (based on the configured LogFileRollPolicy) and continues
logging messages from the beginning of the current log file. If abc.log was the current file, then the
history of files created would look like this:
abc.log (current log file)

abc.log.20070312-113011 (previous log file)
abc.log.20070312-112945 (older log file)
abc.log.20070312-112824 (oldest log file)
In this mode, the downstream collectors which reads the log file using a RenameFilePolicy cannot
read the files in time, accurately and completely.
The LogFileHandler generates each new log file with a new name, rather than reusing the original
file and renaming it when it is full. It creates the log files as follows:
abc.log.20070312-113104 (current log file)

abc.log.20070312-113011 (previous log file)
abc.log.20070312-112945 (older log file)
abc.log.20070312-112824 (oldest log file)
LogFileHandler facilitates simple file roll policies such as SequenceNumberFileRollPolicy or

DateFilePolicy in higher level collectors to read the log files.
The RollingLogFileHandler changes the name of the current log file whenever a roll is triggered
instead of renaming them. When the log file is full, the RollingLogFileHandler opens a new file with a
new name, as specified by the log roll policy, and starts populating it with log messages. The

RollingLogFileHandler creates each log file with a unique name, and the name is retained after the
file is full and closed. Once this component creates a log file, it does not rename the file. For more
information on the RollingLogFileHandler component, refer to the eIUM Component Reference.
Advanced Logging Configuration

If you want to provide more fine-grained control of logging for your eIUM deployment, you can use
the Launchpad to perform advanced logging configuration through the configuration tree, and you
can also configure log file rollover and aging. Advanced logging configuration options include:
l Configuring server logging. You can configure server logging through the eIUM configuration tree
in the Launchpad. Performing advanced logging for a single process, such as a collector, requires
creating a Logging configuration node. For instructions on configuring logging for a single
process, including setting the Loggers and HandlerNames configuration attributes, see
"Configuring Server and Process Logging" (on page 184).
l Configuring logging for packages and classes. The eIUM logging system supports differentiated,
granular logging for functional areas of the system, namely classes and packages. For example,
you can configure differentiated logging if you want eIUM processes to log at level
4=INFORMATIVE, and you want the encapsulator package to perform more detailed logging, such
as DEBUG level logging. For information on configuring logging for packages and classes, see
"Configuring Logging for a Package or Class" (on page 184).
l Sharing with Linked Configurations. With linked configurations, you can define a logging
configuration once and reuse it across several processes. For instructions on sharing logging
configuration, see "Using Linked Configurations" (on page 188).
Configuring Server and Process Logging

1. Ensure that the Logging configuration node is created. To create a new Logging configuration
node, add the following lines to the eIUM configuration tree under the server, collector, or
process for which you want to configure logging.
[/deployment/Host/Collector/Logging/]
On creation of the Logging configuration node, the default log level of 4=INFORMATIVE is set.
This is equivalent to -l 1 with ProcessArgs.
2. To change the log level for the collector, specify the level in the Loggers attribute as
Loggers=com.hp,<log level>. For example:
Loggers=com.hp,CRITICAL
3. Set the Loggers configuration attribute. For a description this attribute, see "Loggers
Configuration Attribute" (on page 186).
4. Set the HandlerName attribute. For a description this attribute, see "HandlerNames
Configuration Attribute" (on page 186).
Configuring Logging for a Package or Class

Each class in eIUM has a Logger object, and this Logger object is identified by the fully-qualified
name of the class using it. When a new Logger object is registered with the LogManageran

existing logger with whose name the new loggers name startsis identified (as close a match as
possible) as its parent. Similarly, a child, if any, is identified for the new Logger object.
Each Logger object has a useParentHandlers condition. When set to true, whenever the Logger is
asked to log a message (apart from asking the handler object under it to publish the message), it
also publishes the message to its parents handler, its parents parents handlers, and so on. By
default, useParentHandlers is set to true.
In a typical scenario, none of the logger objects, apart from the one having the name com.hp has a
Handler object. The handler object under the com.hp Logger object is the one logging messages at
%VARROOT%/log/collector.log.
To configure logging for a package or class, you can add another Logger attribute under the parent
Logger, setting the value to the package name of the encapsulator component. An example
configuration node follows:
Loggers=com.hp,INFO
Loggers=com.hp.siu.collector.encapsulator,DEBUG
Furthermore, you can change the log level for one or more individual components or Java classes.
For example, if you suspect that a particular encapsulator has configuration problems, you can raise
the log level for just the encapsulator and all its subcomponents. This avoids the potential problem
of generating large numbers of unrelated log messages. A process can store its run-time properties
in a property file, which can be read whenever the process starts. Each process uses the SIU.ini
property file by default.
The default SIU.ini property file sets the log level to 4=INFORMATIVE. This is the default for the host
and is used by all processes except where it is overridden. You can modify the LOGLEVEL value in
SIU.ini to change the default log level for all eIUM processes on the host.
NOTE:Be careful when modifying the SIU.ini file because your changes could render eIUM
inoperable. You should not modify the lines indicated at the top of the file.
Setting the Log Level in a Secondary Property File

You can also create a secondary property file and set the log level in the property file. To set the
startup log level in a property file, add the following line to a text file:
PROCESSARGS = -l <loglevel>
Specify this property file in the -propertyFile option of any eIUM command. For more information on
setting the log level in a property file, see "Start-Up Properties" (on page 230) or the eIUM Command
Reference.
/Logging Configuration Node

The /Logging configuration node can be specified just under the root configuration node (the
collectors root config node, that is, the node specifying the collector name). Once this configuration
node is specified, the entire configuration node is passed to the SvrLogManager component,
irrespective of the ClassName attribute specified under this node. The SvrLogManager looks for the
following configuration attributes under its configuration node:

l Loggers
l HandlerName
Also see the eIUM Component Reference for more information on SvrLogManager.
Loggers Configuration Attribute

You can use the Loggers configuration attribute to create a new Logger for a package or class,
specify a log level for the package or class, and also specify whether the Logger should publish log
messages to the parent Logger. Loggers is a multi-valued, multi-column attribute with the following
syntax:
Loggers=LoggerName,Level,useParentHandlers
l LoggerName: Gets the name of the logger that logged the event.
l Level: This is an optional value that you can set to override the value that may have been set
previously, for instance, passed as a run time parameter through the command line. The value of
level specifies the log level for this logger and all the children of this logger, as defined by the
Logger name.
l useParentHandlers: Another optional value. When set to false, messages sent to this Logger are
not propagated to the handler object of the parents in the Logger hierarchy. If this value is set to
true for any children of the Logger, all messages of the children are propagated to handler
objects of the parents. For example, you may want to set useParentHandlers to false if you want
to redirect all messages sent to a particular Logger to a Handler other than the default Handler.
The default value for this component is true.
HandlerNames Configuration Attribute

The HandlerNames configuration attribute is also a multi-valued attribute with the following format:
HandlerNames=ConfigNodeName
If the ClassName attribute of the specified configuration node is not set, the HandlerName
configuration attribute uses the LogClassLoader instead of the ConfigNodeName. When the
LogClassLoader is loaded, the configuration node can have the following attributes:
l HandlerClass - A mandatory component of type java.util.logging.Handler

The following, remaining attributes are optional:
l FilterClass - A component of type java.util.logging.Filter

l FormatterClass - A component of type java.util.logging.Formatter
l LogLevel - Specifies the log level
l LogFileRollPolicyClass - A component of com.hp.siu.utils.LogFileRollPolicy
l LoggerNames - A multi-valued component listing all Loggers
Once the HandlerClass is loaded and configured, the following steps occur:
1. The FilterClass, if specified, is loaded, configured, and set for the handler. When a message is
ready to be logged, it passes through the filter, which confirms that the message can be
logged. The Handler then publishes the message.
2. The FormatterClass, if specified, is loaded, configured, and set for the Handler.

3. The LogFileRollPolicyClass is used only if the FilterClass is of type LogFileHandler.

4. The LogLevel specified is set on the handler.
5. The Handler is set on each Logger specified. If none are specified, the
6. Handler is set on the logger associated with com.hp.
Example Configurations with Loggers and HandlerNames

The following configuration example shows how a package and a class within that package can have
different log levels. The log level of the datastore package is DEBUG4, while the log level of
com.hp.siu.datastore.JDBCMetaStore specifies that DEBUG logging for this class is disabled.
[/deployment/ASAWCZYN/Demo/Logging]
Loggers=com.hp.siu.collector.datastore,DEBUG4
Loggers=com.hp.siu.collector.datastore.JDBCMetaStore,DEBUG,false
Once you define a Logger for a package, which in this example is the datastore package, by default,
all classes under datastore have the same log level. If you want different classes under a hierarchy
to use different log levels, you need to define a separate logger for each class, for example:
Loggers=com.hp.siu.collector.datastore.JDBCMetaStore,DEBUG
Loggers=com.hp.siu.collector.datastore.JDBCFileDataStore,DEBUG2
Loggers=com.hp.siu.collector.datastore.MuxDataStore,DEBUG4
A more complex example configuration using Loggers and HandlerNames follows.
[/deployment/testhostid/demo/Logging]
HandlerNames=TestHandlerNode
Loggers=com.hp.siu.collector.datastore,DEBUG4
Loggers=com.hp.siu.collector.aggregator.HashMatchRule,DEBUG4,false
[/deployment/testhostid/demo/Logging/TestHandlerNode]
FormatterClass=com.hp.siu.logging.SimpleLogFormatter
HandlerClass=com.hp.siu.utils.LogFileHandler
LoggerNames=com.hp.siu.collector.aggregator.HashMatchRule
LogLevel=8
In this example configuration:
l Loggers=com.hp.siu.collector.datastore,DEBUG4 specifies that the Logger with

name com.hp.siu.collector.datastore and all logger objects below it in the Logger hierarchy
should be of the logging level DEBUG4. This configures logging for the package datastore. This is
similar for the Logger object named com.hp.siu.collector.aggregator.HashMatchRule
l useParentHandlers is set to false for this Logger. This means that the messages to be logged by
this Logger are not sent to the default handler associated with the root Logger, com.hp.
l The Handlers configuration attribute and associated configuration node specify that a
com.hp.siu.utils.LogFileHandler handler object using
com.hp.siu.logging.SimpleLogFormatter is associated with the Logger of name
com.hp.siu.collector.aggregator.HashMatchRule.

l The LogFileHandler, by default, logs all messages into the error stream, namely, the collector_
stderr file under the %VARROOT%/collector directory. When the demo collector runs with the
following configuration, all log messages from the HashMatchRule should be stored under the
demo_stderr file and must not appear in the demo.log file.
Using Linked Configurations

To share logging configuration with other processes, use linked configurations by defining a
configuration once and reusing it across processes. For example, to reuse the logging configuration
defined in Collector in a different collector, for example MyCollector, add the Link attribute, setting
the value to the path of the Collector logging configuration as follows.
[/deployment/Host/MyCollector/Logging]
Link=/deployment/Host/DemoCollector/Logging
In addition, you can partially override the linked configuration by specifying attribute values locally.
For example, to override the log level of MyCollector while retaining other configuration attributes
of DemoCollector, specify the Loggers attribute value as follows:
Link=/deployment/Host/DemoCollector/Logging
Loggers=com.hp.siu.collector.encapsultor,DEBUG4
This is equivalent to specifying the following logging configuration:
ClassName=com.hp.siu.serverutils.SvrLogManager
Loggers=com.hp.siu.collector.datstore,DEBUG
As this example shows, you can use linked configurations to improve the manageability of complex
configurations.
Setting Up Centralized Logging

As your eIUM deployment grows to include dozens or even hundreds of collectors on several hosts,
viewing and analyzing individual log files can become a tedious task. To help you monitor process
activities in a large eIUM deployment, you can set up centralized logging to gather log messages into
a single, central log file. The following table introduces the three options available to you for setting
up centralized logging.
Centralized Logging Options

Option Description
UNIX Syslog For eIUM deployments on the HP-UX platform, you can use the UNIX syslog
Daemon daemon to set up centralized logging. This allows eIUM to send log messages
from each eIUM process to a local syslog daemon, which then writes the log
messages in time sequence to the syslog log file. For instructions on setting up
centralized logging using the UNIX syslog daemon, see "Configuring Centralized
Logging Using Syslog" (on page 190).
LogConsolidator For eIUM deployments on any of the certified platforms, you can use the eIUM
LogConsolidator to set up centralized logging using a third-party provider, such
as JBoss. Using LogConsolidator allows you to centralize eIUM log messages
from multiple collectors to a single log file. For instructions on setting up

Option Description
centralized logging using LogConsolidator, see "Setting Up Centralized Logging

with LogConsolidator" (on page 195).
HP OpenView You can use the built-in eIUM logging mechanism to centralize logging if you are
Operations managing your eIUM deployment with OVO to send log messages to the OVO
(OVO) message browser. For instructions on setting up centralized logging with HP
OVO, see "Configuring Centralized Logging Using OpenView Operations" (on page
200).
Logging System Components

Each eIUM server initializes logging at startup. The server logger instantiates a legacy log handler,
which uses the legacy log formatter to write log messages to the server log. If auditing is enabled,
the server also creates an audit logger.
The eIUM logging framework allows you to stack additional handler-formatters. Each handler in the
stack processes messages at its log level and passes the log messages down the chain. The eIUM
logging system provides two handlers that you can stack to set up centralized logging, UDPHandler
and OVOHandler.
To centralize log messages, you need to configure a handler and a formatter. Optionally, you can
also configure a filter to send the log messages to the central log and a file roll policy to manage the
central log file. The eIUM logging system provides a handler-formatter combination for use with
syslog and a handler for use with OVO, as follows:
l For use with Syslog, the UDPHandler and SyslogFormatter send log messages to the syslog
daemon, which writes all messages to the central log file.
l For use with OVO, the OVOHandler sends log messages in the form of events to the OVO Message
Browser.
NOTE: Although the OVOHandler consumes more system resources than the UDPHandler and
SyslogFormatter, you may find this option preferable if you are managing your deployment with
OVO.
The eIUM logging system is built on an implementation of the JSR (Java Specification Request) 47
Logging API Specification and includes the following key elements:
l LoggerThe main component to which applications make logging calls. eIUM uses one Logger
object for each class to log messages for a each eIUM process.
l LogRecordUsed to pass logging requests between the logging framework and individual log
handlers.
l HandlerObject that takes log messages from a Logger object and imports the log messages.
For example, a Handler may write logs to a console or file, or it may send them to a network
logging service or the log file of an operating system.
l LevelDefines a set of standard logging levels that you can set to control the level of detail in
log messages. eIUM extends JDK log levels with its own log levels. You can configure processes to
output logging for some levels while ignoring output for others.

l FilterProvides fine-grained control over what gets logged beyond the control provided by log
levels. The eIUM logging API supports a general-purpose filter that you can use to attach
arbitrary filters that control logging output.
l FormatterSupports the formatting of LogRecord objects. The JDK package includes two
formatters, including SimpleFormatter, which formats log messages in plain text, and
XMLFormatter, which formats logs in XML. In addition, eIUM provides the SyslogFormatter.
For more information on using the JDK package to provide specific levels of detail in log messages,
see "Logging SDK Javadocs" (on page 190) or the JSR 47 Logging API Specification.
Logging Control Flow

The following figure shows the flow of control for logging components.
As shown in the figure, an eIUM process makes logging calls on a Logger, which allocates LogRecord
objects and passes them to a Handler. Both the Logger and the Handler use logging levels, and
optionally, filters to determine whether they want to receive a particular LogRecord. A Handler may
use a Formatter to localize and format the LogRecord before writing the log message to an external
destination.
Logging SDK Javadocs

For information on Java logging not providing in this guide, refer to the information on the Java
Logging API at http://www.oracle.com/technetwork/java/index.html. You may also want to refer to
the eIUM SDK training course for more information on the logging API.
Configuring Centralized Logging Using Syslog

Syslog is a powerful and easily configurable system resource, supported on most versions of UNIX
and Linux. Designed to be a general system logging facility, syslog offers not only local logging to
files, but also remote logging over the network using standard protocols. The eIUM host producing
the logs you want to centralize must include a syslog daemon.
NOTE: The eIUM logging system has been tested with syslog on the HP-UX 11i platform. Although
eIUM should operate properly with syslog on other platforms, they have not been tested and are
not certified on this version of eIUM.
The following figure provides a high-level view of centralized logging with Syslog.

As shown in the figure, the eIUM logging system sends log messages from servers and collectors to
the syslog daemon, which in turn consolidates the logs to a single file. The syslog daemon uses the
UDPHandler and SyslogFormatter to convert eIUM messages into the syslog format. Based on the
eIUM log level, you can control which messages are sent to the syslog daemon and at what syslog
level. For a definition of each Syslog level, see "Syslog Levels Corresponding to eIUM Log Levels" (on
page 195).
The standard HP-UX implementation of the syslog daemon receives messages over UDP. UDP
packets are connectionless datagrams that may be discarded on the network before reaching their
destination. Therefore, you should configure eIUM processes to send messages to the syslog
daemon on the local host only, rather than on a remote host so that packets are not lost in transit
across the network.
Configuring centralized logging using syslog involves the following tasks:.
l Invoking a Handler
l Configuring the Handler as a UDPHandler
l Configuring the SyslogFormatter
l Configuring the FileRollPolicy
Syslog Message Format

In syslog, user messages are typically created through either the syslog(3c) interface or the
logger(1) command. These messages are written to /dev/log, from which they are then read by the
syslogd daemon, which directs them to configured output locations.
A syslog message is an ASCII string that consists of a message priority, a timestamp, and the
message string. Priority is encoded as an ASCII string enclosed by the angle brackets < and > at the
beginning of the string. Message priority is the ASCII integer encoding of an 8-bit quantity. This
quantity is a combination of a 3-bit field (bits 0 through 2) used for log level and a 5-bit field (bits 3

through 7) used for the facility. Thus message priority level can have 8 possible values, and message
facility up to 32 possible values.
Fore more details, refer to the The BSD syslog Protocol, IETF RFC 3164, August 2001, at
http://www.ietf.org/rfc/rfc3164.txt.
SYSLOG Components
The syslog system consists of the following components:
l Message Format Specificationsyslog messages are encoded as ASCII strings. The syslog
message format is defined in the include file /usr/include/syslog.h.
l A set of calls for creating those messagesMessages are created through one of the
standard interfaces to syslog. The library call syslog(3c) is a C-code interface for creating
message strings. The logger(1) command creates syslog messages from the command line or
within a shell script. eIUM uses these interfaces to generate log messages.
l A set of locations from which messages can be readEvery syslog message must be directed
to one of many communication channels, such as /dev/log, /dev/klog, and UDP port 514. eIUM
sends log messages at UDP port 514 by default.
l A daemon that reads from these locationsThe syslogd daemon is a user-space process. It
waits for messages on specific communication paths and directs the message to specific output
locations. A message that is logged (to a file, a logged-on user, or the console) is also formatted
and tagged with the system name. The syslogd daemon may also do some filtering of messages
to, for example, prevent repeated messages from flooding the system.
l A set of locations to which messages can be directedYou can direct messages to one or
more locations, including sockets, files, the system console, and logged-on users. You must
specify the location of the log file as /var/opt/SIU/log/syslog.log.
l Rules for how messages are directedYou can specify configuration rules that determine how
messages are logged and the locations to which they are logged in the /etc/syslog.conf file.
Step 1: Invoking a Handler

If you have already configured logging for a server or process as described "Configuring Server and
Process Logging" (on page 184), configuring a named handler involves specifying the HandlerNames
attribute value:
[/deployment/Host/DemoCollector/Logging/]
Loggers=com.hp,INFO
HandlerNames=MyCentralLogHandler
NOTE: You can reproduce this line to invoke multiple handlers.
Step 2: Configuring the Handler as a UDPHandler

Each named handler must have its own configuration node. The configuration node has only one
required attribute, HandlerClass, which indicates its function. Because MyCentralLogHandler was
intended to be a UDPHandler, specify its HandlerClass as follows:

[/deployment/Host/DemoCollector/Logging/MyCentralLogHandler]
HandlerClass=com.hp.siu.serverutils.logging.UDPHandler
Because the eIUM logging system uses the UDPHandler in the context of centralized logging, all
other configuration attributes have default values set for this purpose. You may, however, change
any of these attributes:
DestinationHostName=localhost
DestinationPort=514
LocalPort=<random available>
LogLevel=INFO
LoggerNames=com.hp
NOTE: You can configure the destination hostname to be other than the localhost, but this
configurationin which the syslog daemon is on a remote hosthas not been certified with this
release of eIUM. Also, you can specify a localport to which the UDPHandler binds in order to send
messages to syslog if you need to use a fixed port number.
Step 3: Configuring the SyslogFormatter

Because the UDPHandler uses the SyslogFormatter in the context of centralized logging, the
configuration attributes of the SyslogFormatter have default values set for this purpose. You may,
however, change any of these attributes:
FormatterClass=com.hp.siu.serverutils.logging.SyslogFormatter
SyslogFacility=USER
NOTE: SyslogFacility must match the syslog facility defined in the syslog daemon configuration.
Step 4: Configuring the File Roll Policy

In a centralized deployment (using syslog daemon to consolidate log files), you can take advantage
of supported file rollover policies to roll over the central log file. Because the syslog daemon does
not have a mechanism to roll over log files, system administrators usually write a cron script to
perform this task. If you decide not to use the cron facility, you can use the UDPHandler to roll over
the syslog file at specified intervals. When the eIUM process logs a message, UDPHandler rolls the
syslog file if the specified conditions are met.
Optionally, you can enable the UDPHandler to manage the syslog log file by rolling over the file at
specific intervals and aging the previous log file. The SyslogFormatter supports this function using
SyslogTimeIntervalLogFileRollPolicy. To use this file roll policy, specify the following required
attributes:
LogFile=/var/opt/SIU/log/syslog.log
LogFileRollPolicyClass=SyslogTimeIntervalLogFileRollPolicy
RollIntervalClass=DaysInterval
RollInterval=7d
NOTE: The path to the log file must be /var/opt/SIU/log/ because the host admin agent may not
have access to files outside the eIUM directory hierarchy.
In addition, you can edit the following optional attribute values:
SyslogPIDFile=/var/run/syslog.pid
SyslogdHUPCommand=/usr/bin/kill -HUP

Example Configuration with Syslog

The following example illustrates the centralized logging configuration for a deployment:
[/deployment/Host/DemoCollector/Logging/]
HandlerNames=MyCentralLogHandler
[/deployment/Host/DemoCollector/Logging/MyCentralLogHandler]
HandlerClass=com.hp.siu.serverutils.logging.UDPHandler
LoggerNames=com.hp
FormatterClass=com.hp.siu.serverutils.logging.SyslogFormatter
SyslogFacility=USER
LogFile=/var/opt/SIU/log/syslog.log
LogFileRollPolicyClass=SyslogTimeIntervalLogFileRollPolicy
RollIntervalClass=DaysInterval
RollInterval=1d
To view the central log file created by syslog, specify the syslog file location and launch the central
log viewer in the Launchpad as described below.
Specify the Syslog File Location
The central log file on a host contains log messages consolidated from processes that have been
configured with the UDPHandler and the SyslogFormatter. You can have more than one central log
file on a host. To specify the location of the central log:

2. In the left pane, select a host.
3. Choose Actions and Properties, or right click on the host node and choose Properties.
4. In the dialog box that opens, double-click SyslogFileLocation.
5. If the parameter is not defined, click Add Attribute, and type SyslogFileLocation.
6. In the dialog box that opens, specify the attribute value.
7. Click OK to close the dialog boxes.
Launch Central Log Viewer
Viewing the central log file is similar to viewing a log file for an eIUM process. The central log view is
disabled if a UDPHandler and SyslogFormatter have not been configured on the host. To view the
central log file in the main window:

2. Select the host for which you want to view the central log file.
3. Choose Actions and View Central Log, or right-click the host node and choose View Central Log.

Alternatively, you can view the central log file in a separate window. The Central Log Viewer provides
a search function that you can use to wrap the text of the log message and pause the screen
refresh of the log viewer. To open the Central Log Viewer:

2. Select the host for which you want to view the central log file.
3. Choose Actions and Open Central Log Viewer, or right-click on the host node and choose Open
Central Log Viewer.
NOTE: If you have more than one central log file configured on the host, the Launchpad prompts
you to select the log file you want to view.
Syslog Levels Corresponding to eIUM Log Levels

The standard syslog() library routine defines log message priority as the logical priority or the level
and facility. The level signifies the urgency of the message and the facility signifies the subsystem
generating the message. While formatting eIUM log messages for syslogd, the SylogFormatter
encodes all eIUM messages to the USER facility. The eIUM log levels are mapped to standard syslog()
levels as follows:
eIUM Log Level Mapping to Syslog Levels

eIUM Log Level CODE SYSLOG level
- 0 LOG_EMERG
- 1 LOG_ALERT
CRITICAL 2 LOG_CRIT
ERROR 3 LOG_ERR
WARNING 4 LOG_WARNING
ACCOUNTING 5 LOG_NOTICE
INFO 6 LOG_INFO
DEBUG, DEBUG, DEBUG2, DEBUG3, DEBUG4 7 LOG_DEBUG
Setting Up Centralized Logging with LogConsolidator

LogConsolidator is a stand-alone eIUM server that you can use on any platform certified for eIUM
deployment. To use LogConsolidator, obtain a third-party Java Messaging Service (JMS) Provider of
your choice, for example JBoss. If you are migrating to eIUM 8.0, copy the JBoss configuration files to
an external JBoss application before running it. LogConsolidator receives log messages and
consolidates them into a single file.
You can download JBoss 3.2.1 and later versions compatible with eIUM from
http://www.jboss.org/jbossas/downloads/.
NOTE: Until version 4.5 Feature Pack 6, the JBoss server was bundled with eIUM as the default
JMS provider for the LogConsolidator. However, as of eIUM 5.0, no default JMS Provider is
supplied. Use the JMS provider of your choice.

This section describes the components involved in consolidated logging and also describes
configuring LogConsolidator using a third party provider, including JBoss.
LogConsolidator is an eIUM process that you deploy to consolidate log messages from multiple
collectors into a single log file. The LogConsolidator and collectors communicate over JMS. The
collectors, the LogConsolidator, and the JMS provider each play a part in consolidating logs.
l Collector: You can configure an eIUM collector for centralized logging by selecting the
appropriate handler in the logging section of the collector configuration. A configured collector
opens a JMS Topic (Topic/IUMLogging) for publishing messages, encapsulating all messages that
can be logged in a JMS message and posted on this topic.
l LogConsolidator: LogConsolidator is a server that subscribes to a JMS topic called IUMlogging.
LogConsolidator listens to messages on this topic and logs them into a single, consolidated log
file.
l JMS Provider: Any third party provider, such as JBoss. The provider opens a topic on which
collectors can post messages and from which the LogConsolidator can read them.
LogConsolidator is preconfigured to look for topic/IUMLogging.
l Naming Service: A JMS Provider generally includes a naming service. eIUM processes, namely
Collector and LogConsolidator, use this service to look up the registered topic (topic/IUMLogging).
This topic is a JMS object on which publishers and subscribers can post and read messages.
The figure below illustrates the interaction between these components:
Subsequent sections illustrate with examples how to configure each component to enable
consolidated logging with eIUM LogConsolidator.
Step 1: Configuring Collectors

Add a logging node to the collector configuration as in the sample configuration below:
[/deployment/<host node>/<collector name>/Logging]

ClassName=SVRLogManager
HandlerNames=TestHandler
[/deployment/<host node>/<collector name>/Logging /TestHandler]

ClassName=com.hp.siu.serverutils.LogClassLoader

FormatterClass=com.hp.siu.utils.LegacyLogFormatter
HandlerClass=com.hp.siu.serverutils.logging.JMSHandler
LoggerNames=com.hp
LogLevel=INFO
Password=guest
Topic=topic/IUMLogging
UserName=guest
JNDI-
Prop-
erties=java.naming.factory.initial,org.jnp.interfaces.NamingContextFactory
JNDIProperties=java.naming.factory.url.pkgs,org.jnp.interfaces
JNDIProperties=java.naming.provider.url,jnp://localhost:1099
Step 2: Configuring the LogConsolidator

Create a Log Consolidator collector using the LogConsolidator template provided in the Launchpad.
LogConsolidator is designed to subscribe to the IUMLogging topic as a message listener. For more
information on LogConsolidator, see the section LogConsolidator in the eIUM Component Reference.
This section describes where the consolidated log file is placed, as designated by the Outputfile
attribute. If this attribute is not set, the LogConsolidator places log files in the default location of
/varRoot/log/ConsolidatedLog.log.
To create a Log Consolidator, from the Launchpad, choose File, New, and Collector. Then from the
list of temples, choose LogConsolidator, and click Next. Specify the Host and Collector Name, and
click Create.
Any JMS provider can be used for LogConsolidator. LogConsolidator needs a Naming Service and
Messaging Service from the provider. Naming Service looks up the topic while the Messaging Service
reads and writes messages.
Step 3: Configuring the JMS Provider

You can configure the JMS Provider as described in the following three steps. For information on
configuring the JMS provider not provided in this section, refer to the user documentation provided
with your JMS provider.
A. Activating Naming Service: By default the Naming Service is active and uses port 1099. However,
if the Naming Service is not found to be active, edit the jboss-service.xml
(<jbosshome>/server/default/conf/) file, uncomment the service configuration, if commented, and
record the port used.
Sample configuration of Naming Service follows:

<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming">

<attribute name="Port">1099</attribute>
</mbean>
In the sample configuration above, JBoss 3.2.1 is the JMS provider.
B. Creating the Topic: Include the following configuration to the jbossmq-destinations-service.xml

file, located at <jbosshome>/server/default/deploy/jms.

<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=IUMLogging">
<dependsoptional-attribute-
name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<depends optional-attribute-
name="SecurityManager">jboss.mq:service=SecurityManager</depends>
<attribute name="SecurityConf">
<security>
<role name="publisher" read="true" write="true" create="false"/>
<role name="guest" read="true" write="true" create="false"/>
<role name="durpublisher" read="true" write="true" create="true"/>
<role name="subscriber" read="true" write="true" create="true"/>
</security>
</attribute>
</mbean>
C. Adding Users: Add users to the JBoss user list with iumlog as both the user name and password
and assign the roles of publisher, subscriber and durpublisher.
The method of adding users depends on the version of JBoss used.
If you are using JBoss 3.2.1, you can add users by adding a jboss-mq state file to
<jbosshome>/server/default/conf/. The content of the file appears as follows:
<?xml version="1.0" encoding="UTF-8"?>

<StateManager>
<Users>
<User>
<Name>iumlog</Name>
<Password>iumlog</Password>
<Id>DurableSubscriberExample</Id>
</User>
........other users............
</Users>
<Roles>
........other roles.............
<Role name="subscriber">
<UserName>iumlog</UserName>
</Role>
<Role name="publisher">
</Role>
<Role name="durpublisher">
</Role>
</Roles>
<DurableSubscriptions>
<DurableSubscription>
<ClientID>DurableSubscriberExample</ClientID>
<Name>Log Consolidator</Name>
<TopicName>IUMLogging</TopicName>
</DurableSubscription>

</DurableSubscriptions>
</StateManager>
With JBoss version 4.0, add users by editing the file hsqldb-jdbc-state-service.xml located under
<jbosshome>/server/default/deploy/jms. Add the highlighted portion in the example to this file.
<?xml version="1.0" encoding="UTF-8"?>


<server>
..............................
..............................

<mbean code="org.jboss.mq.sm.jdbc.JDBCStateManager"
name="jboss.mq:service=StateManager">
<depends optional-attribute-
name="ConnectionManager">jboss.jca:service=
DataSourceBinding,name=DefaultDS</depends>
<attribute name="SqlProperties">
...................................
...................................
POPULATE.TABLES.02 = INSERT INTO JMS_USERS (USERID, PASSWD) VALUES
('j2ee', 'j2ee')
...................................
...................................
POPULATE.TABLES.15 = INSERT INTO JMS_USERS (USERID, PASSWD) VALUES
('iumlog', 'iumlog')
POPULATE.TABLES.16 = INSERT INTO JMS_ROLES (ROLEID, USERID) VALUES
('guest', 'iumlog')
('publisher', 'iumlog')
('durpublisher', 'iumlog')
('subscriber', 'iumlog')
</attribute>
</mbean>
</server>
Step 4: Modifying eIUM Configuration

Edit the eIUM configuration to include the following attributes in JNDI properties, under both the
LogConsolidator and Collector.
l JNDIProperties= java.naming.factory.initial, <initial factory to be used by the client>

Set the fully qualified class name of the Initial Context Factory for the JNDI Service Provider. This
initial factory will create the InitialContext object for communication with the JMS Provider. The
class is typically part of the JMS Provider.
If you are using JBoss:

JNDIProperties= java.naming.factory.initial,
org.jnp.interfaces.NamingContextFactory
l JNDIProperties=java.naming.factory.url.pkgs, <org.jboss.naming:org.jnp.interfaces>
The value of the property should be a colon-separated list of package prefixes for the class
name of the factory class that will create a URL context factory.
For JBoss:
JNDIProperties= java.naming.factory.url.pkgs,
org.jboss.naming:org.jnp.interfaces
l JNDIProperties= java.naming.provider.url, <URL of the provider>

The value of the property should be a URL pointing to the JNDI provider to look up the JMS Topic
object.
For JBoss Server:
JNDIProperties = Java.naming.provider.url, jnp://15.2.4.56:1099
Where IP address is the IP address of the host on which earlier configured Naming Service is
running and the port number is where the JNDI service is bound to.
Client Libraries
Every JMS Provider has client libraries (jboss-client-all.jar for JBoss) that provide a means of
communication to the JMS Provider. These libraries must be visible to the LogConsolidator process
and the Collector process. To make them visible, copy the client jar files to a convenient location and
add the jar file location to the eIUM class path using the Launchpad. To add the jar file location,
select the host machine in the Launchpad and select Actions -> Host Default Properties. Right click
ClassPath and select Add Value, then add the jar file location.
Configuring Centralized Logging Using OpenView Operations

You can use the built-in eIUM logging mechanism to centralize logging if you are managing your
eIUM deployment with HP OpenView Operations (OVO). With an OVO agent running on the local host,
eIUM can send log messages to the OVO message browser for the operator to view.
NOTE: eIUM provides OVO template files that provide corrective actions in response to specific
events. For instructions on uploading these templates and configuring OVO to use them, see the
eIUM can send log messages to any version of OVO, including previous versions of OpenView
VantagePoint Operations and OpenView IT/Operations. If you set up centralized logging using OVO,
the process logger uses the OVO log handler. The OVOHandler creates a custom OVO log formatter
to send log messages to the OVO message browser. You can control which messages eIUM sends to
the OVO message browser based on the eIUM log level and at what severity level the messages are
displayed in the message browser.
Before Configuring Centralized Logging Using OVO

Before you configure centralized logging using OVO, ensure that:

l OVO is installed and used for managing your network.

l An OpenView agent is running on the eIUM host for which you want to configure centralized
logging.
l Each collector in your eIUM deployment that you want to send log messages to OVO is configured
to create log messages of the required log level. For example, if you want a collector to send log
messages of the WARNING level to OVO, ensure that the log level for the collector is set to
WARNING.
l You have considered the potential performance impact. OVOHandler uses the opcmsg command
to send each message. Because eIUM processes run in a JVM, an opcmsg command can be
executed only after forking a new process, which can have a significant performance impact.
l You are aware of the OVO templates. eIUM provides OVO templates for HP-UX that enable OVO to
monitor and manage eIUM processes.
Sending Non-CRITICAL Messages to OVO
To prevent eIUM collectors from sending a storm of log messages to OVO, each of which must be
acknowledged by the OVO operator, only 20 non-CRITICAL messages are sent to OVO in any 5-minute
period. CRITICAL messages are exempt from this restriction and no limit applies to the number of
CRITICAL messages that OVO can receive. If messages cannot be sent to OVO for any duration, a
special message indicating the number of messages dropped is sent to OVO after logging resumes.
Making eIUM Log Files Available to OVO
The siulogmerger utility combines eIUM log files into a centralized file of the format required by
OVO. This utility continually monitors eIUM log files, adding new log messages to the centralized file
as they are created. The OVO templates provided with eIUM instruct OVO to read the centralized log
file and display the messages into the OVO Message Browser.
To start siulogmerger and create the central log file, use the following command:
/opt/SIU/bin/SIUJava com.hp.siu.tools.siulogmerger -o /var/opt/SIU/log/IUMMonitor
Add this command to a local boot script so that each time the system or the eIUM components start,
this command is run.
NOTE: When adding to a boot script, it is recommended that you use the nohup command to start
the script by preceding the above command with nohup. For more information on this
command, see the nohup main page on UNIX.
Mapping eIUM Log Levels to OVO Severity Levels

To map eIUM log messages to OVO severity levels:

2. Choose Tools and OV Operations Logging to display the following dialog box.

3. Select the check box to send eIUM log messages to OVO. This setting applies to all hosts that
OVO is managing in the eIUM deployment. If an eIUM host is not running an OVO agent, you
cannot monitor the eIUM components on that host using OVO.
4. Map each eIUM log level to the corresponding OVO severity. These mappings apply uniformly to
all collectors in the eIUM deployment. You should not send INFORMATIVE messages to OVO.
5. Click OK. Your changes are saved to the configuration server. From now on, each collector that
starts sends log messages of the specified levels to OVO. Collectors that are already running
are not affected by this change. You must restart them for the changes to take effect.
6. Restart each collector in your eIUM deployment to which you want to apply these changes.
Notifying OpenView Operations of eIUM Process Status Changes

The eIUM admin agent monitors the run-time status of processes. The admin agent executes a
script that uses the opcmsg command to notify OVO when the status of a collector changes. The
iumadm_chk.sh script and the OVO templates supplied with eIUM monitor the admin agent.
NOTE: eIUM provides templates for OVO v.7 and VPO v.6 on HP-UX and Oracle Solaris.
Configure the admin agent on each host to enable notification as follows:
1. Copy the appropriate version of the process.pl Perl script to the directory where local system
tools are located.
/opt/SIU/OV/hpux.bin/process.pl (HP-UX)
/opt/SIU/OV/solaris.bin/process.pl (Solaris)

This script requires Perl to be present on the system. Make sure that the first line of the script
refers to the location of Perl on this system.
2. Run the Launchpad.
3. Right-click the host to be configured and, from the pop-up menu, select Properties. The
Launchpad displays the parameters used whenever this hosts admin agent starts.
4. Right-click the Properties node and, from the pop-up menu, select Add Attribute. The
Launchpad displays the Add Attribute dialog box.
5. In the edit box, type in the property NOTIFYCOMMAND and click OK. The Add Attribute dialog box
requests a value for the attribute.
6. Type in the complete path name of the process.pl script. Specify the location where you
installed it; DO NOT run it directly from /opt/SIU/OV.
7. Click OK.
eIUM Log Levels and OVO Severity Levels
You can enable eIUM processes to send log messages to the OVO agent running on that host using
the OVOHandler. The operator can then view these messages as events in the OVO Message
Browser. Because OVO has its own definition of severity levels, eIUM log levels must be mapped to
OVO severity levels. This correspondence can be changed, but eIUM recommends the following
(default) mapping:
eIUM Log Levels and OVO Severity Levels

eIUM Log Level OVO Severity
CRITICAL critical
ERROR major
WARNING warning
ACCOUNTING minor
INFO, DEBUG, DEBUG, DEBUG2, DEBUG3, DEBUG4 none

NOTE: Log messages at level 4=INFORMATIVE and higher should be withheld from the OVO
message browser because the volume of messages at these levels would drown out the relatively
rare but more important messages at other log levels.


Chapter 12
Maintaining and Troubleshooting eIUM

The following are topics on tips, techniques and strategies you can use to monitor your eIUM
deployment and to identify and solve problems you may encounter. For example:
l "Troubleshooting" (on page 207) describes ways to examine your eIUM deployment to determine
if it is running properly.
l "Solving Specific Problems" (on page 218) describes specific problems you may encounter and
how to resolve them.
l "Security Issues" (on page 220) describes several security-related troubleshooting scenarios.
Troubleshooting 207
Check for Known Problems 207
How to Connect to a Remote eIUM Host 207
Check Your eIUM Installation 207
Determine Your eIUM Instance Name 207
Check Collector Statistics 208
Test Collectors with Sample Data 208
Query the Collectors Data 208
Check the IOR URL and the IOR 208
Ensure eIUM Components are Running 209
Perform Diagnostics 211
Check Log Files 212
Check that the Configuration is Valid 212
Check Initialization Files 213
Check the JVM Options 214
Troubleshooting Windows Services 215
Troubleshooting UNIX Daemons 216
Solving Specific Problems 218
Collectors Run Out of Disk Space 218
Performance Problems 218
eIUM License Expired or About to Expire 218
Cannot Communicate with Configuration Server 218
SQL Exception: Column Count vs. Value Mismatch 219

Chapter 12: Maintaining and Troubleshooting eIUM
MySQL Activation Errors 219
Security Issues 220
Invalid Command Syntax or Command Usage 220
Improper Command Sequence 220
Required Files or Resources Missing 221
Overriding the Existing Configuration 221
LDAP Login and Lookup Common Issues 222
LDAP Directory Layout (external-dir.properties) Common Issues 223
Kerberos Time Synchronization 224
Troubleshooting
The following sections describe ways you can examine your eIUM deployment to determine if it is
running properly.
Check for Known Problems

Check the eIUM Release Notes for your particular release for any known problems and workarounds
in the product.
How to Connect to a Remote eIUM Host

For an unsecured host, you can run the Launchpad and view a host in your eIUM deployment from a
remote eIUM host by entering the following command.
launchpad -iorurl http://<Host or IP address>:8158
This uses the IOR URL to contact the eIUM configuration server on the remote host. For a secured
host, this can only be performed from hosts that have had eIUMsecurity properly installed and that
have been added to the secured deployment. See "Check the IOR URL and the IOR" (on page 208) for
more information. Also see the eIUM Installation Guide for details on the IOR URL.
Check Your eIUM Installation

There are several requirements you must fulfill when you install eIUM. See the eIUM Installation
Guide to make sure you have installed HP eIUM correctly.
If you have installed any eIUM patches, examine the host log file to make sure the patch information
appears there.
Determine Your eIUM Instance Name

When you install eIUM on a host, you choose an instance name which determines where eIUM is
installed. The default instance name is SIU and is used in this document when referring to files and
directories in your deployment. Use your instance name whenever viewing log files or using eIUM
commands.

Check Collector Statistics

For a running collector, a good way to check its health is to display the collector statistics in the
Launchpad. In the Launchpad, select the collector and select the Actions -> Statistics menu item.
This displays a statistics pane at the bottom of the Launchpad window. It displays the current
number of NMEs in the collector, the number of NMEs in the previous cycle and the number of NMEs
since the collector started running. Examine these values and verify that they are reasonable. Check
when the last flush occurred to see if it is reasonable.
Test Collectors with Sample Data

One way to test a collector or a set of collectors is to send known sample data into the collector and
make sure it is processed correctly and sent to the next collector. You can test an entire collector
chain in this way.
Query the Collectors Data

Another way to determine if a collector is running is to query its data. In the Launchpad, select the
collector then select Actions -> Query Data. Or, you can use the siuquery command. See the
eIUMCommand Reference for additional details.
Check the IOR URL and the IOR

When the configuration server is started, it places IOR information (a CORBA address used by clients
to locate the configuration server) into the file specified with the IORFILE property or the -iorFile
command line option. This IOR file must be accessible to all eIUM components (collectors, tools, and
the Launchpad) using the value of the IORURL property or the -iorURL command line option. The
easiest way to test that the IOR URL is valid is by using a web browser as follows.
1. Open the SIU.ini file in <VARROOT>, typically C:\SIU\SIU.ini on Windows and /var/opt/SIU on UNIX.
2. Find the line beginning with IORURL. For example, the following is a possible IORURL:
IORURL=file:/C:/SIU/var/ConfigServer.ior
3. Copy the value of the IORURL to a web browser address line and view the URL destination. The
result should be a string beginning with IOR: and followed by several lines of numbers. This is
the IOR. If you do not get this result, see the eIUM Installation Guide for details on configuring
the IOR URL.
To test the IOR itself, try running the Launchpad from a command line using the IORURL. That is, run
the launchpad command with the -iorurl option and provide the IORURL from the SIU.ini file.
For example, if the IORURL were file:/C:/SIU/var/ConfigServer.ior, the following command runs the
Launchpad and displays the deployment:
launchpad -iorurl file:/C:/SIU/var/ConfigServer.ior
If the Launchpad does not display your deployment properly, the configuration servers IOR could be
invalid. You can regenerate the IOR as follows.
1. Run the Launchpad.

2. Rename the file <VARROOT>/var/ConfigServer.ior, for example to ConfigServerX.ior.
3. In the Launchpad, right-click the ConfigServer and select Restart Config Server. This generates
a new IOR in the file ConfigServer.ior.

Ensure eIUM Components are Running

This section describes how to check each eIUM process to make sure it is running.
Check the Status of eIUM Processes

The icons displayed beside each process in the Launchpad tell you the process status. See "Status
Icons" (on page 22) for what each icon means.
You can use the HP eIUM Launchpad to examine the current status of each eIUM process as follows:
1. Run the eIUM Launchpad and log in if security is installed.

2. Select the View -> View Operational Status menu item if it is not checked. If it is checked, click
on the Status tab at the bottom of the Launchpad screen. This displays the status of all eIUM
processes.
3. Position your mouse pointer over any icon in the Launchpad screen to display more details
about the status of the process.
Alternatively you can use siucontrol -showStatus or siudiag -showStatus to check the status of
processes. See the eIUM Command Reference for complete details on all eIUM commands.
Check the Launchpad

The Launchpad should be able to start, connect to the configuration server using the IORURL, and
show the status and configuration of all collectors. The Launchpad requires the configuration server
in order to retrieve collector configurations. It also requires the administrative interface of all
configured collectors to determine their status. The most frequent problems in running the
Launchpad are that the IORURL is incorrect or the configuration server is not running. See "Check
the IOR URL and the IOR" (on page 208) and "Check the Configuration Server" (on page 209) for more
information.
Check the Collectors

Collectors run as a process under the control of the admin agent on eIUM hosts. Only one instance of
each collector (within the entire deployment) should be running at a time.
To test the collector administrative interface, use the Launchpad or siucontrol command to perform
an administrative task, such as getting statistics. An active collector should show a growing NME
count.
To test the collector data retrieval interface, use the siuquery command to extract some of the
collected data.
If the collector appears to be running but the interfaces do not appear to be operating, the collector
IOR information in the configuration server may be incorrect.
Check the Configuration Server

The configuration server is required to allow all eIUM components to retrieve their configurations.
One instance of the configuration server (for the entire deployment) must be running at all times.
The configuration server runs under the control of the host admin agent.
To test that the configuration server administrative interface is operational, use the Launchpad or
siucontrol command to perform an administrative task, such as getting statistics.

To test the configuration server configuration retrieval interface, use the loadconfig utility to
extract some portion of the configuration.
Check the Admin Agent Server

The host admin agent is a Windows service or UNIX daemon that runs on each eIUM host, controls all
eIUM processes on the host, and facilitates communication among eIUM hosts. Make sure this
process is running. The process identifier, or PID number, is contained in a file under
<VARROOT>/<host>/pid.txt. Get the PID number from this file and verify that the process is running.
On Windows, make sure the service named <eIUM instance name>_AdminAgentServer is running. On
UNIX, make sure the daemon of the same name is running.
View the admin agents log file in <VARROOT>/log/<host>.log and look for any error messages.
See also "Troubleshooting Windows Services" (on page 215) and "Troubleshooting UNIX Daemons"
(on page 216) for specifics on checking the host admin agent.
Check the MySQL Database

The MySQL database must be running on each eIUM host before starting any collectors. Collectors
require the database in order to store NMEs or recovery and aging information.
Test that the MySQL database process is running on the host by looking for the mysqld process. On
Windows use the Task Manager. On UNIX platforms, use the ps -ef command.
See the HP eIUM Component Reference for more information on the collector datastore.
On Windows, MySQL runs as a separate service and its status can be checked using the Windows
Services tool. MySQL can also be started, stopped, and restarted in the Services interface. On UNIX,
the MySQL start/stop script (%BINROOT%/sbin/mysql.sh) can be used to check MySQL server status.
For example:
$>./mysql.sh status
MySQL is running [SUCCESS]
Check the Process Identifiers

Each eIUM server writes its process id (pid) in the log banner at the start of its log file, as well as in
the file <VARROOT>/<server>/pid.txt. VARROOT is typically C:\SIU\var on Windows systems and
/var/opt/SIU on UNIX systems.
For example, each eIUM host runs a process called the admin agent. The admin agent manages
other eIUM processes on the host and communicates with other eIUM hosts. The pid for the admin
agent process is in the file VARROOT/<host id>/pid.txt. For example, if eIUM is installed at C:\SIU on a
host named IUMhost01, the admin agents pid would be in the file C:\SIU\var\IUMhost01\pid.txt.
The pid for a collector named Radius12 on a UNIX installation at /opt/SIU would be in the file
/var/opt/SIU/Radius12/pid.txt.
You can use the pid number to get system status about the eIUM server process. For example, you
can use the UNIX ps command to check the status of a server process. On Windows systems you can
use the Task Manager to view the status of a server process.

Perform Diagnostics
HP eIUM can perform several different diagnostics that can inform you of potential problems with
your deployment. Use the eIUM Launchpad to view diagnostics for the entire deployment, any
particular host, collector, or the configuration server as follows:

2. In the Deployment pane, select the deployment object, a host, a collector, or the config server.
3. Select the process that you want to diagnose.
4. Choose Actions and Diagnostics.
5. Use the check boxes to specify the type of diagnostic you want to run, such as Status or Start-
Up Parameters.
6. Click Execute to display the diagnostics. eIUM displays the results of the diagnostic tests.
7. Click Save to save the results of the diagnostics to a file.
You can also use the siudiag command to run diagnostics on a host. See the eIUM Command
Reference for more information on eIUM commands.
Deployment Diagnostics
You can request the following diagnostics for your entire deployment:
Deployment Diagnostics
Diagnostic Description
Configuration server Displays information about your configuration server.
Number of hosts Displays the number of hosts in your deployment.
License Information Displays the text of your HP eIUM license.
Host Diagnostics
You can request the following diagnostics for any host in your deployment:
Host Diagnostics
Diagnostics Description
eIUM Displays the version number of eIUM, configuration files and other configuration
Installation information.
System Displays information about the host system environment, such as the type of
Environment system the host is (for example, Windows or HP-UX), and the time zone.
Admin Agent Displays whether or not the host admin agent is running and a list of processes
controlled by the host admin agent.
Collector Diagnostics
You can request any of the following diagnostics for a collector:

Collector Diagnostics
Startup Parameters Displays the parameters used when the collector started
running.
Configuration Displays information about the collector from the configuration

server.
NME Schema Displays all the types of fields an NME can contain.
Status Displays whether the collector is running or not.
Statistics Displays performance statistics for the collector, such as how

many NMEs have been processed.
Database Check connection, Contacts the collectors data store and displays the results.
query time range.
Diagnose History Table Checks the collectors history table and reports the results.
Read Recovery Table Displays the name of the collectors recovery table.
Configuration Server Diagnostics

You can request any of the following diagnostics for the configuration server:
Configuration Server Diagnostics

Startup Parameters Displays the parameters used when the configuration server started
running.
Status Displays whether the configuration server is running or not.
Validate license Checks your eIUM license to make sure it is valid.
Check CORBA Performs a check of the CORBA communications layer and reports
communication the results.
Check Log Files

Whenever a collector, host admin agent, configuration server or any other eIUM process runs
incorrectly or does not run, check its log file for error or warning messages. See "eIUM Logging" (on
page 172) for the different types of log files associated with eIUM processes and servers, how you
can view them, and how you can change the amount of information written to log files.
Check that the Configuration is Valid

If the problem appears to be a configuration error in a collector, you may view the collector
configuration in the eIUM Launchpad. In the Launchpad, select the collector, select the Configure
tab, and then select Edit Collector Configuration. You can check attribute values for each
component of the collector and make corrections.

You can also use the saveconfig command to examine the configuration. Ensure that the NME
schema and the collector configurations exist in the configuration server.
If necessary, use the loadconfig command to reload the eIUM product templates or a saved backup
configuration. Use caution when loading configurations because existing configurations can be
overwritten.
NOTE: Use caution when running multiple instances of the Launchpad. Only one program at a time
should be changing the eIUM configuration, as the configuration server has no mechanism to
prevent multiple programs from saving the configuration. Only one person at a time should be
using the Launchpad or the loadconfig command since these can change the eIUM configuration.
Check Initialization Files

Every eIUM server has an initialization file that specifies how the server process starts. You can view
these files to verify that they are starting with the proper initialization parameters. These files are
typically named <process>.ini. For example, the product initialization file is SIU.ini. The Java
command initialization file is SIUJava.ini. During installation, the initialization file is siu_install.ini.
During activation, the initialization file is activateIUM.ini.
NOTE: Do not modify these initialization file because your changes will get overwritten when you
set or modify the corresponding property, for example during activation or in the Launchpad.
Check the SIU.ini File

During product installation the SIU.ini property file is created in <BINROOT>, typically C:\SIU on
Windows and /etc/opt/SIU on UNIX. This file controls the behavior of all eIUM components on the
system.
NOTE: Be careful when modifying the SIU.ini file because your changes could render eIUM
inoperable. You should not modify the lines indicated at the top of the file.
You may find it useful to copy the SIU.ini file, modify your copy, and run eIUM commands with your
file using the -propertyFile command line option. See the eIUM Command Reference for details on
commands and this option.
This file can be customized to control behavior of all eIUM components on the system, such as the
default logging level. Additionally, other property files can be created and used when running eIUM
components by specifying the -propertyFile command line option. This causes the component to use
any properties defined in the file rather than those defined in the default property file. Options
specified on the command line have precedence over properties defined in property files.
Check that this file has valid property values and is readable by all eIUM components. The most
critical property in the file is the IORURL, which all collector components use when making requests
to the configuration server. See "Check the IOR URL and the IOR" (on page 208). Other important
values are the BINROOT, VARROOT, and CFGROOT properties, which should never be changed once
the product has been installed. See also "Product Root Directories" (on page 230).
Check the SIUJava.ini File

The file SIUJava.ini contains parameters used whenever the java command is invoked, which is
whenever an eIUM collector, configuration server, or other eIUM process is started, or whenever an
eIUM command is run. You only control these Java start-up parameters from the Launchpad using

Edit Start-up Properties. You can view but do not modify these parameters in the file typically at
C:\SIU\SIUJava.ini on Windows and /etc/opt/SIU/SIUJava.ini on UNIX.
CAUTION: Do not modify the SIUJava.ini file because your changes will get overwritten.
Check the MySQL Configuration File and Log Files

The MySQL database has a configuration file, my.cnf, typically in <VARROOT>/mysql/my.cnf on UNIX,
or its Windows counterpart, my.ini, in <BINROOT>\mysql\my.ini. MySQL logs information in
<HOSTNAME>.err files, typically under <VARROOT>/mysql/data/<HOSTNAME>.err.
Check the JVM Options

If you are using the Java Virtual Machine (JVM) version 1.3 or later, and a collector or other process
will not run, it may be that the command to run the JVM is problematic. You can use the following
command to examine the default command line for possible problems with the command itself:
SIUJava -echo my.class
You can also use the-echo option on other eIUM commands, for example:
launchpad -echo
These commands display the Java command used when starting processes from the command line.
The output should look something like the following on Windows:
$ ./siujava -echo my.class

Process args:
java path: C:\j2sdk1.4.1_03\bin\java.exe

jvm shared library path: C:\j2sdk1.4.1_03\jre\bin\server\jvm.dll
class name: my.class
Java options:
-Xbootclasspath/p:C:\SIU/lib/jacorb.jar -Xms8m -Xmx120m
-Djava.class.path=C:\SIU/lib/patches;C:\SIU\lib\patches\IUM45FP04.jar;
C:\SIU\lib\commons-cli-
1.0.jar;C:\SIU\lib\JainSipApi1.1.jar;C:\SIU\lib\nist-sip-
1.2.jar;C:\SIU/-
lib/siuloader.jar;C:\SIU/lib/siuutils.jar;C:\SIU/lib/siucolls.jar;
C:\SIU/lib/-
siuaudit.jar;C:\SIU/lib/siucfg.jar;C:\SIU/lib/siugui.jar;C:\SIU/lib/
siu-
tools.jar;C:\SIU/lib/siuagent.jar;C:\SIU/lib/siudiag.jar;C:\SIU/lib/
siu-
ses-
sion.jar;C:\SIU/lib/siusecurity.jar;C:\SIU/lib/mysqlDriver.jar;C:\SIU/lib/
Federation.jar;C:\SIU/lib/jce.jar;C:\SIU/lib/commons-net-
1.0.0.jar;C:\SIU/lib/
jakarta-oro-2.0.6.jar;C:\SIU/lib/jakarta-regexp-
1.1.jar;C:\SIU/lib/dnsjava.jar;
C:\SIU/lib/jndi.jar;C:\SIU/lib/ldap.jar;C:\SIU/lib/ldapbp.jar;C:\SIU/li-
b/
providerutil.jar;C:\SIU/lib/OracleDriver.zip;C:\SIU/lib/xerces.jar;
C:\SIU/lib/jdom.jar;C:\SIU/lib/castor.jar;C:\SIU/lib/netgraph.jar;

C:\SIU/lib/jRegistryKey.jar;C:\SIU/lib/AdventNetSnmp.jar;C:\SIU/lib/
JimiProClasses.zip;C:\SIU/lib/ipdr.jar;C:\SIU/lib/msbase.jar;
C:\SIU/lib/mssqlserver.jar;C:\SIU/lib/msutil.jar;C:\SIU/jboss-3.2.1
/client/jbossall-client.jar;C:\SIU/jboss-3.2.1/client/jnp-client.jar;
C:\SIU/jboss-3.2.1/client/jboss-common-client.jar;C:\SIU/jboss-3.2.1/
client/jboss-system-client.jar;C:\SIU/jboss-3.2.1/client/jbossmq-
client.jar;
C:\SIU/jboss-3.2.1/client/concurrent.jar;C:\SIU/jboss-
3.2.1/client/log4j.jar;
C:\SIU/jboss-3.2.1/server/deploy/jboss-net.sar/jboss-net.jar;
C:\SIU/jboss-3.2.1/lib/jboss-jmx.jar;C:\SIU/jboss-3.2.1/lib/jboss-
system.jar;
C:\SIU/jboss-
3.2.1/client/jnet.jar;C:\SIU/lib/3rdparty/FieldsConcat.java_1.0.jar;
C:\SIU/lib/3rdparty/WriterExample.java_1.0.jar;C:\SIU/lib/3rdparty;.
-DSystemRoot=C:\WINDOWS -DSIUINI=C:\SIU\SIU.ini -DSIUHOME=
C:\SIU -Dcom.hp.pid=3772 -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORB
The actual Java command used by the admin agent may be somewhat different.
Troubleshooting Windows Services

CAUTION: This topic is for experienced Windows administrators only. Use caution when viewing
the Windows registry.
When you install eIUM on Windows, the admin agent and MySQL database are registered as Windows
services so they run continuously in the background. Provided information includes what can be
useful in diagnosing and handling problems related to eIUM components running as Windows
services.
Verifying that a Windows Service is Running

The eIUM host admin agent and the MySQL database run as Windows services on each eIUM host
system. If you suspect that either the host admin agent or the MySQL database is not running, do
the following:
l Open the Services window from the Control Panel, Administrative Tools. You should see the
services SIU_AdminAgentServer and SIU_MySQL in the Services window, with the status
Started. The MySQL service name is typically of the form <SIU_INSTANCE_NAME>_MySQL, for
example, SIU_MySQL. The process name is mysqld.exe.
l If either service is registered but not running, try starting it manually.
l Next, open the Event Viewer from the Control Panel, Administrative tools. This displays the
Windows event log. Click on Application. You should messages for SIU_AdminAgentServer and
SIU_MySQL. If you double-click one of the messages, you should see that the service was
registered or started successfully.
l Run the Windows task manager and verify that the JVM process (java or jre) is running and
also that mysqld.exe is running. There should be one instance of a JVM for each eIUM component
running on that host.

Viewing Windows Event Logs

The service control application logs all its messages to the Event Viewer's application log files. To
view these messages, run the Event Viewer from the Control Panel, Administrative Tools. This shows
events with a red icon if there was an error or failure starting the service.
Windows provides a service called the EventLog that can be used to log administrative messages.
This EventLog service is started whenever you boot Windows. The EventLog service logs messages
into three areas: Application, System and Security.
SIUNTService (called by the siusvc_*.bat scripts) logs information (blue icons), Warning (Yellow icons)
and Critical (red icons) messages into the Event Viewer's event log. These messages can be used for
debugging the service and to understand what went wrong, when there is a problem with the
service. SIUNTService logs its messages into the Application area of the Event Viewer's event logs.
Specific OS related failures are also logged into the System area of the Event viewer's event logs.
To check for errors in the event viewer log files:
l Click on Start -> Programs -> Administrative Tools -> Event Viewer. This opens the Event Viewer
main window.
l To look at the application log messages, click on Log -> Application.
l To look at the system log messages, click on Log -> System
See the Event Viewer screen above for an example of the Windows Event Viewer window. When you
double click on any of the messages in the event log, it displays information about the messages.
Troubleshooting UNIX Daemons

The admin agent runs as a daemon on each eIUM UNIX host and controls all the collectors on that
host. The MySQL database also runs as a daemon on each UNIX host. These daemons are typically
started when you install eIUM and whenever you reboot so you do not need to run them manually.
However, you can try the following (discussed in subsequent topics) when problems occur with UNIX
daemons.
Checking Runtime Parameters

Some UNIX runtime parameters are stored in the file /etc/rc.config.d/SIU. All of the eIUM utilities
and components use the settings of the variables in this file. These variables are described in the
table below:
Runtime Parameters
Environment
Variables Description
SIU_ADMINAGENT_ A value of 1 (one) automatically starts the host admin agent when the
START system is started.
SIU_MYSQL_START A value of 1 (one) automatically starts the MySQL database server when the
system is started.

Starting and Stopping the UNIX Daemons

The admin agent runs as a daemon on each UNIX host and controls all the collectors on that host.
The MySQL database also runs as a daemon on each host. These daemons are typically started when
you install eIUM and whenever you reboot so you do not need to run them manually. However, the
following command runs these daemons if they are not already running:
l HP-UX: /sbin/init.d/SIU start

l Linux: /etc/init.d/SIU start
l Solaris: /etc/init.d/SIU start
When the host admin agent starts running, it starts all the processes it controls that are configured
to start. That is, it starts the configuration server, if present, and it starts all collectors and other
eIUM servers that are configured to be started.
l HP-UX: /sbin/init.d/SIU stop

l Linux: /etc/init.d/SIU stop
l Solaris: /etc/init.d/SIU stop
Starting and Stopping Daemons Individually
The commands described above start and stop all eIUM daemons on UNIX. The following commands
start and stop these daemons individually (use /etc/init.d/SIU on Solaris).
UNIX Daemon Start/Stop Commands

OS Commands
HP-UX commands: l /sbin/init.d/SIU start_agent Starts the admin agent

daemon.
l /sbin/init.d/SIU stop_agent Stops the admin agent
daemon.
l /sbin/init.d/SIU start_dbs Starts the MySQL database
daemon.
l /sbin/init.d/SIU stop_dbs Stops the MySQL database
daemon.
Linux commands: l /etc/init.d/SIU start_agent Starts the admin agent

daemon.
l /etc/init.d/SIU stop_agent Stops the admin agent daemon.
l /etc/init.d/SIU start_dbs Starts the MySQL database
daemon.
l /etc/init.d/SIU stop_dbs Stops the MySQL database
daemon.
Solaris l /etc/init.d/SIU start_agent Starts the admin agent

daemon.

OS Commands
l /etc/init.d/SIU stop_agent Stops the admin agent daemon.

l /etc/init.d/SIU start_dbs Starts the MySQL database
daemon.
l /etc/init.d/SIU stop_dbs Stops the MySQL database
daemon.
Solving Specific Problems

The following topics describe some specific problems you may encounter and how to resolve them.
Collectors Run Out of Disk Space

If collectors run out of disk space on an eIUM host, you can reduce the number of messages being
logged or change the aging of the log files or of the datastore tables. See "Check Log Files" (on page
212) for ways to save disk space with log files. See the description of the particular datastore you
are using in the eIUM Component Reference for ways to save disk space with the datastore.
Performance Problems
If usage data collection is too slow, see "Tuning for Performance" (on page 226).
eIUM License Expired or About to Expire

If the Launchpad will not run or if any eIUM processes stop or will not start, check to make sure your
license file has not expired.
When you purchased eIUM, you received a license file that is required for the eIUM software to run.
Without a valid license file, eIUM processes will not run. You specify the location of the license file
when you install eIUM. The location of your license file is also specified in the SIU.ini file, typically
located at C:\SIU on Windows and in /opt/SIU on UNIX.
Your eIUM license file will expire at the time specified in the license file. eIUM periodically checks
your license and writes several warning messages to your host log file well before the license
expires to give you plenty of time to renew your license. See the eIUM Installation Guide for how to
obtain and install a new eIUM license.
If your eIUM license expires, all eIUM processes and servers will eventually shut down. You will need
to obtain a new eIUM license from HP and reinstall it. See the eIUM Installation Guide for instructions
on obtaining and installing an eIUM license file.
Cannot Communicate with Configuration Server

If you get a message indicating you cannot communicate with the configuration server, for example
when starting the Launchpad, the cause may be that your eIUM license has expired or the
configuration server IOR has become invalid.
l eIUM license expired - See "eIUM License Expired or About to Expire" (on page 218).
l Configuration Server IOR invalid - You can easily regenerate a new config server IOR file simply by
renaming the old IOR file and restarting the configuration server. The configuration server IOR
file is typically in C:\SIU\var\configserver\ConfigerServer.ior or in

/opt/var/SIU/configserver/configserver.ior. Rename this file and restart the configuration server

as described in "Check the IOR URL and the IOR" (on page 208).
SQL Exception: Column Count vs. Value Mismatch

An exception such as the following can mean that the attributes configured for the collector do not
match the attributes which have been configured in the datastore, typically from a prior run.
09/21/2010 15:03:24.333 MSD main (JDBCTransaction) DEBUG:
SQLException:
java.sql.SQLException: Column count doesn't match value count at row 1
at com.mysql.jdbc.SQLError.createSQLException(Unknown Source)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(Unknown Source)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(Unknown Source)

09/21/2010 15:03:24.333 MSD main (07.003.20) CRITICAL: Flush failed:
java.lang.RuntimeException: Got an exception flushing NMEs:
com.hp.siu.collector.rules.RuleException: Error in processing the
StoreRule / with NME: SrcIP=15.0.0.19, DstIP=17.0.0.3,
NumBytes64=16700, StartTime=09/21/2010 15:04:38 MSD,
EndTime=09/21/2010 15:14:31 MSD
at com.hp.siu.collector.aggregator.FlushProcessor.processLeaf
(FlushProcessor.java:212)
at
com.hp.siu.collector.aggregator.MatchRule.processTree(MatchRule.java:482)
at
com.hp.siu.collector.aggregator.MatchRule.processTree(MatchRule.java:473)
This exception can occur when a collectors aggregation scheme has been changed to add or
remove attributes without creating a new scheme. At flush time, the attributes no longer match up
with the datastore and the exception is thrown.
To correct the problem, configure the collector to use a new scheme and restart it. Alternatively,
you can use the siucleanup command to remove the tables and their associated data from the
datastore.
MySQL Activation Errors

If you are prevented from activating eIUM and the MySQL product extension, you may encounter
MySQL server log errors such as the following:
00929 04:31:45 mysqld_safe Starting mysqld daemon with databases from
/var/opt/SIU/mysql/data
00929 4:31:45 [Warning] '--skip-locking' is deprecated and will be
removed in future release. Please use '--skip-external-locking'
instead.
00929 4:31:45 [Note] Plugin 'FEDERATED' is disabled.
opt/SIU/mysql/bin/mysqld: Table 'plugin' is read only
00929 4:31:45 [ERROR] Can't open the mysql.plugin table. Please run
mysql_upgrde to create it.
G/opt/SIU/mysql/bin/mysqld: Can't create/write to file
'/var/opt/SIU/mysql/tmp/ib{00242' (Errcode: 13)
00929 4:31:45 InnoDB: Error: unable to create temporary file; errno:

13
00929 4:31:45 [ERROR] Plugin 'InnoDB' init function returned error.
00929 4:31:45 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE
failed.
00929 4:31:45 [ERROR] Unknown/unsupported table type: InnoDB
00929 4:31:45 [ERROR] Aborting
Such an error is due to permissions problems with user bin on UNIX, which must have read and
execution permissions for the /opt and /var/opt directories. See "Additional Log File Types" (on page
175) for more information on MySQL logs.
Security Issues
The following topics discuss security-related troubleshooting tips. For more information on installing
eIUM security, see the eIUM Installation Guide. For more information on the commands discussed in
this section, see the eIUM Command Reference.
Invalid Command Syntax or Command Usage

Using eIUM you may often use the eIUM security command line tools to interact with the eIUM
security system (secserveractivate, ldifgen, secactivate). One of the most common errors related to
using these tools involves invalid command syntax. Consequently, all three commands respond
similarly under such conditions.
An invalid command or command option was specified using -<option name syntax. In this case,
error messages of the following form are displayed:
C:\sbin\siu\SIU\bin>ldifgen -xyz
Command execution resulted in error: Unrecognized option: -xyz
See the log file for details.
The eIUM security tools save their log files under %VARROOT%/log. For example:
C:\sbin\siu\SIU\var\log\LDIFGenerator.log for ldifgen command

C:\sbin\siu\SIU\var\log\SecurityActivator.log for secactivate command
C:\sbin\siu\SIU\var\log\SecurityServerActivator.log for
secserveractivate command
The log file will typically have a detailed exception log which can be useful for giving clues to what
went wrong, and for troubleshooting by the eIUM support team.
Improper Command Sequence

Certain commands are dependent on the execution of another command for it to succeed. In this
case, an appropriate error is reported depending on the exact situation. Some common command
sequence problems are described below.
ldifgen was incorrectly executed before secserveractivate. For example:
C:\sbin\siu\SIU\bin>ldifgen gen -host testhostid

-type active-directory
Command execution resulted in error : Could not find required
properties file [C:\sbin\siu\SIU\var\securityserver\conf\external-
dir.properties].
You may not be running the tool on a security server machine.

In this case, because the secserveractivate command was not executed, a property file the ldifgen
command requires was not generated. As a result, the tool assumes you are not running ldifgen on a
security server hosting node.
secactivate login was executed without executing init. eIUM security command line tools can handle
command options specified in any order. The commands are automatically ordered in the correct
sequence for execution. However, if a command option that is required to be executed prior to
another command option that was omitted on the command line, the tool can not process it. In this
case, the executed command option will fail with an error message. For the secactivate login
command to succeed, secactivate init must be executed before it.
secactivate login user thomson password secret
In this example, init will still succeed, even though init is specified after login. The tool does
automatically reorder the commands for execution. However:
secactivate login user thomson password secret
will fail if the init command was not executed beforehand. This is true because login is dependent on
files that are created by init.
C:\sbin\siu\SIU\bin>secactivate login -user edwards

-password secret
Command execution resulted in error : C:\sbin\siu\SIU\var/security-
login.config (No such file or directory)
Required Files or Resources Missing

Some of the commands require certain files to be present for their operation. If the files are not
found, an error is displayed in the console. For example:
C:\sbin\siu\SIU\bin>secactivate login -user edwards

-password secret
Command execution resulted in error : C:\sbin\siu\SIU\var/security-
login.config (No such file or directory)
In the above scenario, secactivate could not find the %VARROOT%/security-login.config file. Another
error follows:
C:\sbin\siu\SIU\bin>secserveractivate init -force -user edwards -
password secret -loginldapserver ldap://localhost:389
-lookupldapserver ldap://localhost:389 -layout
C:\sbin\siu\SIU\var\securityserver\conf\my-external-dir.properties
Command execution resulted in error : No directory layout properties
file specified.
Use -layout option to specify a layout file.
In this case, the specified custom directory layout file did not exist.
Overriding the Existing Configuration

You may need to specify the -force option to forcefully overwrite existing configuration files. For
example:

C:\sbin\siu\SIU\bin>secactivate init
[java.security.auth.login.config configuration] file :
[C:\sbin\siu\SIU\var/security-login.config] already exists and it was
not updated.
In the above command scenario, the configuration files were not overwritten since the -force option
was not used.
LDAP Login and Lookup Common Issues

The %VARROOT%/securityserver/conf/external-login.config file contains the LDAP login and lookup
configuration information, in the form of login module configuration entries. This file is a crucial
part of the integration between the eIUM security server and the LDAP server that contains eIUM
security data. This file is configured during the security server activation process.
You might encounter several different error messages reported by the security server when there
are problems with the login module configuration information. Troubleshooting this can be more
challenging, since the actual error messages are most often generated by the LDAP server itself and
can be difficult to understand. The error message and the amount of details given can vary
depending on the LDAP server implementation used.
Some of the common scenarios with Microsoft Active Directory as the LDAP server used are:
l Invalid credentials given for the login user.

l Invalid credentials of the user account used to look up the LDAP directory.
The symptoms described below are common to both the situations. The user account used to access
the LDAP directory is specified using the secserveractivate command -user and -password options,
along with the -lookupldapserver option (for security server activation). If the user account specified
does not have access rights to look up information in the directory tree, the security server login
operation fails. For example, you can get a failure message as follows:
C:\sbin\siu\SIU\bin>secactivate login -user thomson -password secret

Command execution resulted in error: HTTP/1.1 401 Unauthorized
The : HTTP/1.1 401 Unauthorized is a generic message that is shown whenever a login
operation with the eIUM security server fails. To learn the specifics of the error, open the
%VARROOT%/log/SecurityActivator.log file and find the cause exception message. For example:
06/26/2008 13:07:23.528 IST main (ConsoleApplication) ERROR: Command
execution resulted in error .javax.security.auth.login.LoginException:
HTTP/1.1 401 Unauthorized at
com.hp.usage.security.login.RemoteLoginException.newLoginException
(Unknown Source)

Caused by: com.hp.usage.security.login.RemoteLoginException:
javax.naming.AuthenticationException:
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 52e, vece
at
com.hp.usage.security.directory.DirectoryLoginModule.authenticate(Unknown
Source)
at com.hp.usage.security.login.BasicLoginModule.authenticate(Unknown

Source)
at com.hp.usage.security.login.BasicLoginModule.login(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
The 52e code corresponds to invalid user credentials. To solve this error, execute secserveractivate
again with appropriate user account lookup. The user information is stored in the
%VARROOT%/securityserver/conf/external-login.config file.
LDAP Directory Layout (external-dir.properties) Common Issues

The %VARROOT%/securityserver/conf/external-dir.properties file contains your LDAP security
directory layout in the form of a set of property value pairs. This file is a crucial part of the
integration between the eIUM security server and the LDAP server that contains eIUM security data.
You might encounter several different error messages reported by the security server when there
are problems with the data contained in the file. This leads to a mismatch between what the
security server thinks is the layout and what is actually present in your LDAP server. Troubleshooting
this can be more challenging, since the actual error messages are most often generated by the
LDAP server itself and can be difficult to understand. The error message and the amount of details
given can vary depending on the LDAP server implementation used.
There are a few typical mistakes involved with the directory layout properties file, using Microsoft
Active Directory as the example LDAP server. This mainly concerns incorrect values for the
properties in external-dir.properties file, and results in symptoms that are similar wherein a user
does not exist situation. This occurs because the LDAP server cannot find existing information with
incorrect layout property values. Two example scenarios involved:
l Incorrect value for the com.hp.usage.security.directory.config.root_context property.

l Symptoms exhibiting the same characteristics as that of giving a non-existent user identity.
For example:
C:\sbin\siu\SIU\bin>secactivate login -user thomson -password secret

The : HTTP/1.1 401 Unauthorized is a generic message that is displayed whenever a login
operation with the eIUM security server fails. To learn the specifics of the error, open the
%VARROOT%/log/SecurityActivator.log and find the cause exception message:
AcceptSecurityContext error, data 525, vece
From the Active Directory error codes, 525 user not found is already known. The behavior
explained above will repeat if you specify an incorrect context_pattern property value as well. For
example, the property value could incorrectly be specified to be:
com.hp.usage.security.directory.config.user_dn_pattern =
CN={User},CN=MyUsers,{RootContext}
Meanwhile (according to the current directory organization), the correct value should be:
com.hp.usage.security.directory.config.user_dn_pattern =
CN={User},CN=Users,{RootContext}

This will result in the same symptom:
C:\sbin\siu\SIU\bin>secactivate login -user edwards -password secret

Again, the : HTTP/1.1 401 Unauthorized is a generic message that is shown whenever a
login operation with the eIUM security server fails. To learn the specifics of the error, open the
%VARROOT%/log/SecurityActivator.log and find the cause exception message.
AcceptSecurityContext error, data 525, vece
From the Active Directory error codes, 525 user not found is already known. In summary, the 525
error code can be a common symptom caused by any of the property errors. To solve this type of
problem, examine each of the property values in the external-dir.properties file against the actual
directory layout.
Kerberos Time Synchronization

When using Kerberos authentication, time synchronization on servers in the deployment is crucial
for the proper functioning of eIUM security. Since the security of Kerberos authentication is in part
(pre-authentication) based upon the timestamps of tickets, it is critical to have machine times set
correctly on servers exchanging data via Kerberos.
A short lifetime for tickets is used to prevent attackers from performing successful brute force
attacks or replay attacks. Since clock synchronization is vitally important in the security of the
Kerberos protocol, if times are not synchronized, Kerberos will report authentication errors. Clients
attempting to authenticate from a server with an inaccurate time setting will be rejected by the KDC
in authentication attempts, due to the time difference with the KDCs time. Consequently, you
should synchronize time on all the hosts with an NTP time server, so that servers using Kerberos
have their time automatically synchronized.


Chapter 13
Tuning for Performance

This aspect of the Administration documentation provides suggestions for improving the
performance of your eIUM deployment.
Examining Performance Statistics 226
JVM Maximum Heap Size 226
Heap Size Considerations 227
Changing Maximum Heap Size for eIUM Collectors 227
Optimizing ManagementServer Performance 227
eIUM Host Heap Memory Requirement 228
Adjusting MySQLs Memory Requirement 228
Verifying and Changing OS Heap Memory on Windows 229
Verifying and Changing OS Heap Memory on HP-UX 229
Examining Performance Statistics

You can use the HP eIUM Launchpad to examine performance statistics of the configuration server
and any collectors as follows:

2. Double click on Deployment in the deployment pane to display the hosts.
3. Double click on a host to display its collectors or configuration server
4. Select a collector or the configuration server.
5. Select the Monitor tab.
6. Click on the View Statistics button. The Launchpad displays the statistics window.
NOTE: You can also use the Operations Console to monitor statistics for a process. For more
information, see the Operations Console User's Guide.
JVM Maximum Heap Size

The following procedure shows how to change the Java Virtual Machine maximum heap size by
setting the -Xmx option on the java command invocation. This parameter specifies the maximum
amount of memory each JVM process (all threads in aggregate) is allowed to take. Other command
line changes can be made following this same procedure. Note that these changes will effect all
eIUM Java applications.

Chapter 13: Tuning for Performance
Besides changing the JVM maximum heap size described here, there is an HP-UX imposed limit on
the amount of memory a process is allowed to take. The parameter is maxdsiz and it can be
changed using SAM. See "eIUM Host Heap Memory Requirement" (on page 228) for details.
Heap Size Considerations

Since the manufacturer (Java) default heap size of 64 MB is not large enough to run a collector, the
default maximum heap size value in eIUM is set by default in SIUJava.ini to 120 MB. You may
encounter a problem where the default is not large enough to run a collector. That is, the collector
keeps running out of memory. This problem would be more likely to occur in collectors with a high
input data rate and a long flush cycle, where many NMEs are stored in the in-memory tree during a
long flush cycle.
To solve this problem, first decide what the new maximum heap size should be. The default
maximum heap size for a JVM is 120 MB, so you probably want at least twice this amount if your
collector needs more. Heap memory is usually part of virtual memory and can go up to the size of
the hard disk, but the value should not be larger than the amount of physical memory on the host.
To prevent paging, it is recommended that you set the heap size to approximately 70% the physical
memory size.
Consider that the number and size of aggregated NMEs is the major component to the unknown
heap size for the Java Virtual Machine. Thus, the necessary heap size is based on:
l The size of an NME (the number and types of attributes stored in the NME);
l The maximum number of aggregated NMEs before a flush;
l The concurrent flush policy (implies you need room for up to twice the maximum number of
aggregated NMEs);
l The TrafficTime set in the correlator (used to generate the query time range). This value controls
when and how the correlator flushes, which controls the number of aggregated NMEs retains
before a flush.
Changing Maximum Heap Size for eIUM Collectors

The location of the JVM (Java Virtual Machine) and other Java parameters are set in the file
SIUJava.ini. You can view and modify these parameters, if needed, using the Launchpad. You can
change these parameters for all eIUM processes on the host with Edit Host Defaults. Or you can
override the default parameters for individual eIUM processes with Edit Startup Configuration.
CAUTION: Do not modify the SIUJava.ini file directly as your changes will be overwritten.
To change Java start-up settings for all eIUM processes on a host, change host defaults as
described in "Changing Default Host Properties" (on page 96) and modify the JVMOPTS property.
Stop and restart all collectors and servers you want to use the new host defaults.
To change Java start-up settings for individual eIUM collectors or other eIUM processes, override the
host defaults as described in "Overriding Default Host Properties" (on page 99) and modify the
JVMOPTS property. Setting JVMOPTS to %DEFAULTS% means to use the host default values. Stop
and restart the collector that overrides the host default properties.
Optimizing ManagementServer Performance

On RedHat Linux, to avoid out of memory exceptions, the host where the central management
server is running should have increased limits for open files and maximum user processes. These

values should be set to 65536 for open files, and 16384 for maximum user processes. With the
default memory value, the central management server is able to handle about 100 configured
session servers or other eIUM servers. If you have more eIUM servers, increase the JVM heap size.
Every eIUM server requires about 3-5 MB additional heap space. The maximum heap size for the JVM
is defined using the -Xmx option (see also "JVM Maximum Heap Size" (on page 226)). To change this
value, start the Deployment Editor in the eIUM LaunchPad, select the Properties for the
ManagementServer, and change the number of MB defined in the -Xmx option.
NOTE: You can also use the "ulimit" shell command to view or modify current limits values. In
addition, the /etc/security/limits.conf file can be used to set limits for a particular user.
eIUM Host Heap Memory Requirement

Host heap memory requirements in eIUM are influenced by two factors: the collector process, and
the MySQL database process, each of which have their own heap allotment. As also discussed in
"Heap Size Considerations" (on page 227), the collectors heap size is defined in the
%BINROOT%/SIUjava.ini file (C:\SIU on Windows and /opt/SIU on UNIX) JVMOPTS setting.
Meanwhile, MySQLs heap size is defined in my.ini (C:\SIU\mysql\my.ini for Windows) or my.cnf
(/var/opt/SIU/mysql/my.ini for UNIX). The larger of these two heap sizes determinates the
requirement for the operating system.
NOTE: The JVM settings for SIUJava.ini can differ if you are using the JRockit JVM. For more
information on JRockit parameters and migration from the Oracle JDK to JRockit, see:
http://download.oracle.com/docs/cd/E13150_01/jrockit_
jvm/jrockit/geninfo/diagnos/migrate.htm.
Adjusting MySQLs Memory Requirement

Depending on the performance needs of each collector, the MySQL database may not need as much
memory as specified in the default configuration. To change the amount of memory allocated by
the MySQL server when the collector starts, you can change the innodb_buffer_poolsize value
(default is 47 MB) in the my.ini (Windows) or my.cnf (UNIX) file. To do this:
1. Stop the MySQL service (from the Windows Services panel or run /sbin/init.d/SIU stop). This will
stop the host admin agent and collectors as well.
2. Open the my.ini file (in C:\SIU\mysql\my.ini for Windows, /var/opt/SIU/mysql/my.ini for UNIX
platforms) for editing.
3. Find the line starting with innodb_buffer_poolsize in the my.ini file. It should look something like
this:
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes
and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set
this
# parameter up to 80% of the machine physical memory size. Do not
set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system. Note that on 32bit systems
you
# might be limited to 2-3.5G of user level memory per process, so

do not
# set it too high.
innodb_buffer_pool_size=47M
4. Change the innodb_buffer_poolsize to the new value, save changes, and close the file.
5. Restart the MySQL service (and collectors) from the Windows Services panel or run
/sbin/init.d/SIU start. MySQL will reread the my.ini file and use the new values.
Verifying and Changing OS Heap Memory on Windows

For Windows, which allows processes to take as much memory as they need, no special
configuration is necessary.
Verifying and Changing OS Heap Memory on HP-UX

Use the HP-UX System Administration Manager (SAM) to verify, and if necessary, change, the
maxdsiz parameter on each collector host. Go to SAMs area Kernel Configuration ->
Configurable Parameters.
The maxdsiz configurable parameter must be at least the collector heap size (512 MB by default).

Chapter 14
Directories and Files

The subsequent topics briefly describe the main directories and files of your eIUM installation.
Product Root Directories 230
Start-Up Properties 230
Property Precedence 231
Product Root Directories

The eIUM product has three root directories where various other product directories and files are
stored. These directories are determined by where you install eIUM and on which operating system.
They are sometimes referred to using the notation <Name> or %Name%. The values for these root
directories are defined in the eIUM properties file SIU.ini, and can be used in some configuration
attributes that specify directory paths, for example the DirectoryName attribute of the
PatternDirectoryPolicy component. See the eIUM Component Reference for details.
l <BINROOT> or %BINROOT% This is the main root directory for the product, typically C:\SIU on
Windows and /opt/SIU on UNIX. This directory is determined by you when you install eIUM.
l <CFGROOT> or %CFGROOT% This is the root directory for the product configuration files. For
example, it contains the SIU.ini property file. This is typically C:\SIU on Windows and /etc/opt/SIU
on UNIX.
l <VARROOT> or %VARROOT% This is the root directory for dynamic files that are expected to
change or grow as eIUM operates. This is typically C:\SIU\var on Windows and /var/opt/SIU on
UNIX. For example, most log files are stored in <VARROOT>/log, or C:\SIU\var\log on Windows or
/var/opt/SIU/log on UNIX.
Start-Up Properties
Whenever any eIUM process starts, it uses start-up properties defined either in the configuration
server under the /Properties configuration node or in the file SIU.ini located in the <BINROOT>
directory of each of your eIUM hosts.
When you use the Launchpad or the siucontrol command to start a process, the Launchpad and the
siucontrol command use the start-up properties stored in the configuration server. When you use
any other eIUM command to start a process, the command uses the start-up properties in the file
SIU.ini.
You can change some properties globally by editing the file SIU.ini. eIUM commands have a
command-line option, -propertyFile, to override this default and let you specify your own separate
SIU.ini file. This can be useful for troubleshooting. Finally, you can also override some properties with
command line options such as -iorURL. See the eIUM Command Reference for complete details on all
eIUM commands and options. See the SIU.ini file for the complete list of properties and a description
of each property.

Chapter 14: Directories and Files
NOTE: Be careful when changing any start-up properties as incorrect values can make your eIUM
deployment inoperable.
Property Precedence
Here is the precedence of start-up properties for each eIUM component, starting with the lowest
precedence properties:
1. eIUM default values defined in siuutils.jar (these cannot be modified by the user; they are the
lowest precedence).
2. Values found in the local files SIU.ini. A separate copy of this file resides on each eIUM host.
3. Values found in the file specified with -propertyFile command line option.
4. Specific values specified with command line arguments (highest precedence). For example, the
value specified with the -IORURL command line option would take precedence over the value
specified in the -propertyFile file or the local SIU.ini file.
Higher precedence values override lower precedence values.

Chapter 15
Operations Console Administrative Functions

The subsequent topics describe:
l Localization instructions for the Operations Console

l Enabling/Disabling History Collection in the Operation Console
l Generating License Audit Reports
Operations Console Localization 232
Policy File Configuration 232
Operations Console Attribute-Value Mappings 233
Switching Languages for your Locale 247
Management Server Statistics 247
License Audit Reports 248
Generating the Activity File in the Operations Console 248
Operations Console Localization

The Operations Console allows the display of other languages beyond the default English-US setup.
This will allow eIUM users to view the Operations Console with static screen labels, buttons, dialog
confirmations, and other interface elements displayed in the local language. Process names, such as
collectors, charging managers, and so on that are determined by the eIUM configuration, or
dynamically-generated text such as logging and event messages, are not translated however. The
translation instructions provided in this document are intended for HP field personnel to implement
localization for the eIUM user.
Policy File Configuration

Localization in the Operations Console is achieved by applying a properties file to the eIUM
installation in %VARROOT%/webapplications/webapps/operationsconsole/WEB-INF/classes/i18n.
The Operations Console takes the locale of the browser, and matches it against property files found
in this directory. The file is prefaced by the localization initials (for example, en_US for English, USA
character set), and is available in terms of the following file naming format in the /i18n directory:
ATTR_en_US.properties.
This file contains an attribute-value mapping of all translation keys and strings used to translate
Operations Console screen labels into the local language. The ATTR_zh_CN.properties example file
(included in the same /i18n directory) contains the list of all currently existing keys. The ATTR_en_
US.properties only contains a subset, because the default eIUM language is English (when no
matching locale property file is found). However, the example ATTR_zh_CN.properties file serves as
a model for all the keys that need to be translated in order for the Operations Console to be set up
for the local language (described in "Operations Console Attribute-Value Mappings" (on page 233)).

Chapter 15: Operations Console Administrative Functions
The following guidelines should be adhered to when creating the properties file for another
language:
l All properties files must begin with ATTR and end with .properties. The naming rule format for
the properties file is:
ATRR_ + default language setting + _ + system's region + .properties
For example, ATTR_en_US.properties, ATTR_zh_CN.properties.
l In general, non-Latin character alphabetical strings should be converted to the Unicode string by
using the native2ascii command. For example:
$>native2ascii -encoding gb2312 ATTR_zh_CN.properties.i18n ATTR_zh_
CN.properties
l Users should be allowed to configure parameters in the properties file. For example, given the
following configuration:
message.employee.update.success=Successful update of Employee {0}
This configuration carries one parameter({0}) Likewise, extending this, the following
configuration:
.employee.update.success=Successful update of Employee {0} {1}
carries two parameters ({0}, {1}).

The Operations Console online help directory structure is also prepared for integrating localized
Operations Console online help files. These file should be placed in
%VARROOT%/webapplications/webapps/operationsconsole/help/<i18n>, where <i18n> refers to the
localization initials, which can be replaced with the local language setting + _ + the systems region
(whether en_US, the default included help files, zh_CN, and so on). Note the online-help.xml file
coding format, where the default English version is <?xml version=1.0 encoding=ISO-8859-1 ?>,
and the Chinese <?xml version=1.0 encoding=gb2312 ?>.
Operations Console Attribute-Value Mappings

This section describes these attribute-value keys, according to the different sections within the
Operations Console.
Product Names
Attribute Value
i18n.product.name HP Internet Usage Manager
i18n.project.name Operations Console
eIUM Product Information

Attribute Value
i18n.hp.ium.opsui.title HP Internet Usage Manager Operations Control Panel

Date/Time Format
Attribute Value
i18n.Date.format MMM/dd/yyyy
i18n.Time.format HH:mm:ss
Group and Process Management Navigation Sidebar

Attribute Value
i18n.process.management Process Management
i18n.group.management Group Management
i18n.dashboard.view Dashboard View
i18n.deployment.events Deployment Events (appears in the Deployment Events area

once the Show Events option is enabled)
i18n.crashed.processes Crashed Processes (see Hot List tab)
i18n.crashed.nonprocesses.description There are currently no crashed processes in the

deployment.
i18n.crashed.processes.description The list of recently crashed processes and links to process

details for each are listed below.
i18n.alarmed.processes Alarmed Processes (see Hot List tab)
i18n.alarmed.nonprocesses.description There are currently no processes in an alarmed state.
i18n.alarmed.processes.description The list of processes in alarmed state and links to process

details for each are listed below.
Process Button Text

Attribute Value
i18n.deployment.events Deployment Events
i18n.crashed.processes Crashed Processes
i18n.alarmed.processes Alarmed Processes
i18n.process.lists Process Lists
i18n.start.selected Start Selected
i18n.stop.selected Stop Selected
i18n.cleanup.selected Clean Up Selected
i18n.start Start
i18n.stop Stop

Attribute Value
i18n.cleanup Clean Up
i18n.setloglevel Set Log Level
Process Detail
Attribute Value
i18n.process.infomation Process Information
i18n.process.statistics Statistics
i18n.process.events Process Events
i18n.process.operations Process Operations
i18n.process.controls Process Controls
i18n.process.loglevel Process Log Level
i18n.process.purge.stat.history Purge Statistics History
i18n.process.logfile Log File
i18n.process.logviewer.setting Log Viewer Settings
i18n.process.history History
i18n.process.timerange.setting Time Range Settings
i18n.process.properties Properties
Dashboard View, Data Flow Map

Attribute Value
i18n.data.flow.map Data Flow Map (corresponds both for the Dashboard and for the
corresponding tab when viewing a group)
i18n.events Events (for global, group, and process-level)
Tree Menu
Attribute Value
i18n.bygroup By Group
i18n.byhost By Host
i18n.all All
i18n.process.type Process Type

Dashboard View Tab Labels

Attribute Value
i18n.group.overview Group Overview
i18n.all.processes All Processes
i18n.hot.list Hot List
Process View Tab Labels

Attribute Value
i18n.general General
i18n.operations Operations
i18n.logfile Log File
i18n.history History
i18n.properties Properties
Group Menu Tab Labels

Attribute Value
i18n.processes Processes
i18n.group.events Group Events
List Table Navigation

Attribute Value
i18n.page Page
i18n.of of
i18n.row.per.page Rows/Page
i18n.next.page Next >>
i18n.back.page << Back
i18n.unkown.server.type Unknown Server Type
i18n.time.unknown Time Unknown
Process Information
Attribute Value
i18n.all.processes All Processes

Group Management
Attribute Value
i18n.edit.group Edit Group
i18n.create.group Create Group
i18n.remove.group Remove Group
i18n.view.group View Group
i18n.group.tools Corresponds to Group Management -> Tools
Group Table List Navigation

Attribute Value
i18n.group.list Group List
i18n.group.next Next >>
i18n.group.cancel Cancel
i18n.group.previous << Previous
i18n.group.create Create
i18n.group.remove Remove
View Group
Attribute Value
i18n.view.group.UngroupProcesses Processes that are not in any group
Create Group
Attribute Value
i18n.create.group.properties Select Properties
Edit Group
Attribute Value
i18n.edit.group.select Select Edit Group Lists
i18n.edit.group.edit Edit Properties
i18n.edit.group.modify Add or Remove Processes
Remove Group
Attribute Value
i18n.remvoe.group.description Group Description
i18n.remvoe.group.process.count Process Count

Group Status Table

Attribute Value
i18n.group.name Group Name
i18n.group.state Group State
i18n.group.total Total
i18n.group.description Description
i18n.group.running Running
i18n.group.stopped Stopped
i18n.group.crashed Crashed
i18n.group.alarmed Alarmed
Table of Processes Not in Group

Attribute Value
i18n.process.select Select
i18n.process.name Name
i18n.process.state State
i18n.process.host Host
i18n.process.type Type
i18n.process.start.time Time Started
i18n.process.start.date Date Started
i18n.process.warn Warn
i18n.process.err Err
i18n.process.crit Crit
General Tab Statistics Text

Attribute Value
i18n.process.activity Process Activity
i18n.free.memory Free Memory
i18n.total.memory Total Memory
i18n.data.unavailable Data is unavailable
i18n.nodata.symbol --

Attribute Value
i18n.cant.get.data Unable to retrieve data from deployment
i18n.cant.get.startime Start time is unavailable
i18n.last.startime Last Start Time
i18n.process.memory Memory Usage (free/used/total)
i18n.memory.graph Memory Heap Graph (Free/Used)
i18n.last.log.entry Last Log Entry
Process Attribute Display Tables

Attribute Value
i18n.parameter Parameter
i18n.meter Meter
i18n.message Message
i18n.date Date
i18n.level Level
i18n.msgid Msg ID
i18n.thread Thread
i18n.value Value
Charging Manager Process Attributes

Attribute Value
i18n.CmQt.StatTbl.Rq.Revd TotalRequestsReceived
i18n.CmQt.StatTbl.Rp.Sent TotalResponsesSent
i18n.CmQt.StatTbl.Rq.Sent TotalRequestsSent
i18n.CmQt.StatTbl.Rp.Revd TotalResponsesReceived
i18n.CmQt.RowCon.InBd.Traf Inbound Requests
i18n.CmQt.RowCon.OutBd.Traf Outbound Requests
i18n.CmQt.Row.Incom.Rq InRequests Received
i18n.CmQt.Row.Incom.Rp InResponses Received
i18n.CmQt.Row.OutGo.Rq OutRequests Sent
i18n.CmQt.Row.OutGo.Rp OutResponses Sent

FCS/FDS General Tab Process Attributes

Attribute Value
i18n.fcsqt.stat.col.info Collection Count
i18n.fcsqt.row.col.cnt Total Collection Count
i18n.fcsqt.query.interval Query Interval
i18n.fcsqt.polling.type Polling Type
Main Navigation Bar

Attribute Value
i18n.head.mainpage.dash Dash
i18n.head.mainpage.admin Admin
i18n.head.exit Exit
i18n.head.help Help
i18n.head.back Back
i18n.head.forward Forward
Status States
Attribute Value
i18n.start Starting...
i18n.stop Stopping...
i18n.cleanup Cleaning...
i18n.running Running:
i18n.stopped Stopped:
i18n.crashed Crashed:
i18n.alarmed Alarmed:
i18n.unknown Unknown:
i18n.total Total:
i18n.running Running
i18n.stopped Stopped
i18n.crashed Crashed
i18n.alarmed Alarmed
i18n.unknown Unknown

Collector Configuration Table

Attribute Value
i18n.collector.data.source Data Source
i18n.collector.scheme Scheme
i18n.collector.target Target
i18n.collector.format Format
FCS Table Field Names

Attribute Value
i18n.fcs.job.name Job Name
i18n.fcs.source.type Source Type
i18n.fcs.last.file.name Last File Name
i18n.fcs.last.file.time Last File Time
FDS Table Field Names

Attribute Value
i18n.fds.src.name Source Name
i18n.fds.destination.collector Destination Collector
i18n.fds.file.collected Files Collected
i18n.fds.time Time
i18n.fds.queue.count Queue Count
i18n.fds.distribute.count Distribution Count
i18n.fds.total.distribute.count Total Distribution Count
Collector General Tab Data Flow Statistics

Attribute Value
i18n.collector.dataflow.statistics Data flow Statistics
i18n.collector.lastflush.nmesin Last Flush: NMEs In
i18n.collector.lastflush.nmesout Last Flush: NMEs Out
i18n.collector.nme.dataflow NME Data Flow
i18n.collector.current.nme.aggregated Current NMEs Aggregated
i18n.collector.current.nme.processed Current NMEs Processed
i18n.collector.bad.record Bad Records
i18n.collector.nmeCnt.Since.startup NME Count Since Startup

Collector General Tab Statistics and Process Information

Attribute Value
i18n.collector.activity Collector Activity
i18n.collector.dependency.map Dependency Map
i18n.collector.inputs.tbl Inputs
i18n.collector.outputs.tbl Outputs
i18n.collector.aggregation.tbl Aggregation Details
FCS General Tab Statistics, File Collection Activity

Attribute Value
i18n.fcs.collection.jobs Collection
Jobs
i18n.fcs.collection.activity File
Collection
Activity
i18n.fcs.collection.count File
Collection
Count
i18n.fcs.collection.detail File
Collection
Details
FDS General Tab, Statistics and Process Information

Attribute Value
i18n.fds.map.src.destination Sources
Destination
Mapping
i18n.fds.activity File Distribution

Activity
i18n.fds.detail File Distribution

Details
Charging Manager General Tab, Connector, Statistics and

Process Information
Attribute Value
i18n.cm.connectors Connectors
i18n.cm.session.store Session Stores

Attribute Value
i18n.cm.rule.chain Rule Chains
i18n.cm.session.store.cnt Session Stores Count:
i18n.cm.rule.chain.cnt Rule Chains Count:
i18n.cm.connectors.activity Connector Activity
i18n.cm.session.store.activity Session Store Activity
i18n.cm.rule.chain.activity Rule Chains Activity
i18n.cm.connector.type Connector Type:
i18n.cm.connector.traffic Connector Traffic
i18n.cm.connector.threshold.value Threshold Values
i18n.cm.connector.inbound.traffic Inbound Traffic
i18n.cm.connector.outbound.traffic Outbound Traffic
eIUM ServiceModel Descriptions

Attribute Value
i18n.iumservicemodel.creatingdeploymentmodels Creating Deployment Models ...
i18n.cm.session.store Session Stores
General Tab Statistics Last Update

String
Attribute Value
i18n.subpanel.lastupdate Last Update:
Pre-Login Launch Messages

Attribute Value
i18n.preloginpanel.connecting Connecting...
i18n.preloginpanel.waiting Please Wait...
i18n.preloginpanel.connecting.message Connecting to the deployment
i18n.preloginpanel.failed.connecting.message Failed to connect to the deployment
i18n.preloginpanel.broken.connecting.message Broken connection to the deployment
i18n.preloginpanel.certification.expired Security Credentials have expired.
i18n.preloginpanel.connection.timeout Connection Time-out

Attribute Value
i18n.preloginpanel.unable.connection Unable to connect
i18n.preloginpanel.lost.connection Lost connection
i18n.preloginpanel.reading.deployment Reading Deployment Information..
i18n.preloginpanel.succeedtoconnect.deployment Connection to Deployment was successful.
i18n.preloginpanel.choose.an.action Choose an Action ...>
i18n.preloginpanel.cancel Cancel
i18n.preloginpanel.checkconfiguration Check the configuration
i18n.preloginpanel.lost.jmx.connection Lost JMX Connection to the deployment's

Management Server
i18n.preloginpanel.failed.connection.management Connection to the deployment's management

server has failed. Make sure the management
server process is running, and try again.
i18n.preloginpanel.review.credentials Please login again to renew your credentials.
Text Descriptions
Attribute Value
i18n.serverlist.title.description List of processes and controls in the deployment
i18n.group.title.description A list of all groups in the deployment. To view group details,

click on the group name below.
i18n.group.title.non.group No groups are available.
i18n.group.title.ungrouped.processes A list of processes that are not assigned to any group.
i18n.allprocesses.title.description Operations that are performed on selected processes in the

table below
i18n.allprocesses.list List of processes:
i18n.dataflowmap.title.description Below is a map of the entire deployment. All processes in

deployment are shown in relation to their dependencies
i18n.dataflowmap.note Note: This is a non-interactive screen. It does not indicate

process state, or represent process activity.
i18n.dataflowmap.refresh Refresh the deployment map to pick up any configuration

changes:
Process Detail Sub-panel Title Descriptions

Attribute Value
i18n.eventpanel.title.description This panel will show a table of recent server events. Any

Attribute Value
significant events such as critical log messages, server

crashes, and log errors and warnings are posted here.
i18n.operationpanel.title.description Controls for the available operations for this process.group

details, click on the group name below.
i18n.operationpanel.setting.loglevel Change the log level of the process. DEBUG should not be
used in a production environment, as it will significantly
affect process performance
i18n.operationpanel.purge.oldstatistics Select this option if you want to purge all statistical history
data after the process restarts
i18n.logviewpanel.lastupdate Last Update:
i18n.logviewpanel.availablerange Available Range:
i18n.logviewpanel.search Search:
i18n.logviewpanel.go Go
i18n.logviewpanel.clear Clear
i18n.historysplitpanel.title.description Select the process attributes to graph and graph options

from the list below
i18n.propertypanel.title.description All properties of this process that are available from the
deployment are listed below. Check on the Show
Descriptions box to get a description of each property.
i18n.propertypanel.show.description Show Descriptions
i18n.propertypanel.refresh.table Refresh Table
Group Management Text Descriptions

Attribute Description
i18n.groupadmin.title.description Manage process groups in the deployment. Process groups

allow you to categorize eIUM processes into logical sets. This is
particularly useful in large deployments
i18n.groupadmin.grouplist Select the group you wish to modify or delete from the table
below
i18n.editgroup.title.description Modify an existing process group in the deployment.
i18n.editgroup.select_option1 Select the group you wish to modify or delete from the table
below.
i18n.editgroup.select_option2 Edit the type and description of the group, and then click Next
to continue. Click Cancel to return to the Group List view

Attribute Description
i18n.editgroup.select_option3 Select the processes to include in the group from the list below
i18n.editgroup.select_option4 Select Process Lists
i18n.editgroup.select_option5 Currently Selected Processes
i18n.removegroups.title.description Manage process groups in the deployment. Remove an existing

process group in the deployment
i18n.removegroups.grouplist Select the group(s) you want to delete and click Remove.
i18n.creategroup.title.description Create a new process group in the deployment.
i18n.creategroup.select.option1 Enter the type and description of the new group, and then click
Next to continue. Click Cancel to return to the Group List view.
Admin Agent General Tab Host Machine

Information
Attribute Value
i18n.machine.info Machine Info
i18n.machine.iumversion eIUM Version:
i18n.machine.name Machine Name:
i18n.machine.ipaddress IP Address:
i18n.machine.ostype OS Type:
i18n.machine.osversion OS Version:
i18n.machine.cputype CPU Type:
i18n.machine.libraries libraries
i18n.machine.patches Patches
i18n.machine.libsAndpatchs Libs and Patches
Secure Mode Login and Error Page On Login Failure

Attribute Value
i18n.user User Name:
i18n.password Password:
i18n.login Login
i18n.message.loginfailed Authentication failed.

Try again.

Switching Languages for your Locale

After creating a new properties file for the chosen locale, according to the characteristics described
in "Policy File Configuration" (on page 232), place the file under
%VARROOT%/webapplications/webapps/operationsconsole/WEB-INF/classes/i18n. To start using
the new properties file, you must stop and restart the Web Application Server for the changes to
take effect.
Management Server Statistics

The management server collects history statistics in eIUM. By default, these statistics are collected
on all processes, and are stored to disk in the form of an internal management server database
(using JavaDB). This aspect of the management server and Operations Console allow an
administrator to disable this collection performed by the management server.
NOTE: By default, the management server does not configure the HistoryService for long-term
history collection. Once it is configured (which must be done manually), then the management
service will start collecting statistics in the database by default. The Options Pane -> Tools ->
Management Options control panel in the Operations Console will only display if the
HistoryService is configured in the ManagementService (see below).
The license audit feature in eIUM (discussed in the next section) requires the management server to
collect statistics over a longer time range, to support license auditing. The management servers
internal statistics collection supports the collection of data over a few hours or up to one year. Using
an efficient persistency mechanism, and by aggregating data over intervals, the management
server can store several months worth of statistical data that will be available for clients (such as
the Operations Console) to display. Accordingly, a setting in the Operations Console allows an
administrator to control the collection activity in the management server, once the corresponding
HistoryService component has been configured. See the eIUM Component Reference for more
information on the ManagementService and HistoryService components.

Enabling this option activates history statistics collection in the Management server, while
deselecting it will disable collection. For more information on the Operations Console, see the
Operations Console online help or the Operations Console User Guide.
NOTE: This option will also only appear in the Operations Console interface if eIUM security is
disabled, or if the user viewing the Operations Console has the Administrator ReportAdmin role
applied. See "Setting up Users" (on page 111) and "Roles and Privileges Access" (on page 26) for
more information on managing user roles.
License Audit Reports

Since the management server in an eIUM deployment has the ability to gather statistics information
from processes such as a charging manager, collector, and file service components, process activity
can also be stored. With the appropriate configuration of the HistoryService, this process activity
information can be collected and then exported to a deployment activity file via the Operations
Console interface. Once you generate the activity log file, you can use the ActivityLogGen command
to create reports based on the information contained in this file obtained from the customer
environment. The reports can be used to compare the deployment activity with the customer
license agreements for the deployment.
Generating the Activity File in the Operations Console

When the ManagementServices HistoryService has been configured, the Tools -> License Audit
option will be available for selection under the Options Pane in the Operations Console. The figure
below shows the Operations Console with the license auditing feature enabled.
To generate the license audit activity log file, click Generate License Audit Report. The results of the
activity file generation are printed below.

As shown in the above figure, the Mediation24.ManagementServer.1244671817986.jar file is

placed in %VARROOT%, which is /var/opt/SIU on UNIX, or C:\SIU\var on Windows. The activity file
generated from the management server that has the following format:
<hostName>.ManagementServer.<dateTimeStamp>.jar
This is a JAR-formatted file that contains ActivityLogGen.jar, derby.jar (Apache Derby, an ApacheDB
sub-project, which is an open-source relational database implemented entirely in Java), and a
collection of JAR files responsible for generating log files that can be tracked on the performance
logic (slf4j-api-1.5.6.jar, slf4j-log4j12-1.5.6.jar, log4j-1.2.15.jar).
Each file contains the contents of a database table, which are actually exported tables from the
JavaDB database (Derby). The HP representative can use the ActivityLogGen.jar executable to
generate reports based on the data in the file. By default, AcitivityLogGen.jar will generate a report
based on the entire set of processes in the activity log file. The activity log file is read in by
ActivityLogGen and then constructs a JavaDB database instance inside the running process. It takes
the content of the files to populate tables in the database, and effectively replicates the database
used in the management server. Once the database is replicated, you can also run SQL queries on
the tables to generate deployment activity reports.
NOTE: The data collected via the Operations Console Generate License Audit Report feature
(described above) will be used by HP auditors to generate reports.

HP eIUM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HP eIUM

Uploaded by

Copyright:

Available Formats

HP eIUM

For the HP-UX, Redhat, Solaris, and Windows operating systems

Document Release Date: September 2012

Software Release Date: E926

The information contained herein is subject to change without notice.

Restricted Rights Legend

UNIX is a registered trademark of The Open Group.

Linux is a registered trademark of Linus Torvalds in the United States.

Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.

Page 2 of 250 HP eIUM (8.0)

l Document Edition, which changes each time the document is updated.

Contact your HP representative for additional support details.

First Edition Version 2.0 May 1999, HP SIU

Second Edition Version 2.01 August 1999

Third Edition Version 2.02 November 1999

Fourth Edition Version 3.0 September 2000, HP SIU

Fifth Edition Version 3.1 August 2001, HP IUM

Sixth Edition Version 4.5 Feature Pack 4 May 26, 2006

Seventh Edition Version 4.5 Feature Pack 5 & November 9, 2006

Eighth Edition Version 5.0 December 21, 2006

Ninth Edition Version 5.0 Feature Pack 1 July 16, 2007

Tenth Edition Version 5.0 Feature Pack 2 October 12, 2007

Eleventh Edition Version 5.0 Feature Pack 3 April 22, 2008

Twelfth Edition Version 6.0 November 6, 2008

Thirteenth Edition Version 6.0 Feature Pack 1 June 22, 2009

Fourteenth Edition Version 6.0 Feature Pack 2 May 20, 2010

Page 3 of 250 HP eIUM (8.0)

Edition Version Release Date

Fifteenth Edition Version 7.0 October 9, 2010

Sixteenth Edition Version 7.0 Feature Pack 1 November 30, 2011

Seventeenth Version 8.0 September 26, 2012

Page 4 of 250 HP eIUM (8.0)

HP eIUM documentation set

HP eIUM Provides eIUM concepts and design guidelines, including:

HP eIUM Provides installation-related topics, including:

HP eIUM Provides configuration and administrative guidelines, such as:

Page 5 of 250 HP eIUM (8.0)

Document title Description

l Correcting CDRs with the CDR Editor

HP eIUM Provides eIUM available component information, indexed by category and

HP eIUM Provides eIUM available commands, all possible arguments/options, and

Real-Time Provides contextual help in HP SNAP Studio.

Page 6 of 250 HP eIUM (8.0)

The Launchpad Interface 20

The Launchpad Menu 22

The Operations Console 25

Starting the Operations Console 26

Roles and Privileges Access 26

Using the Reference Data Manager 28

Starting the Reference Data Manager 29

Reference Data Table Definition Example 36

RDM Database Selection 38

Refresh Cache View 39

Working with Tables 42

Table Edit View: Search, Add, Edit, and Delete 42

Bulk Search and Replace 47

Bulk Search and Delete 50

Page 7 of 250 HP eIUM (8.0)

User Types in RDM 56

Default Security Configuration 56

Access Control for Multiple Categories 58

Using the eIUMCommand Console 63

Running the Console 63

Command Autocomplete and Suggestion 64