System Administration Manual

MasterClaw
System Administration
Administrator Manual
This document is intended for MasterClaw versions: 7.0.2

Document number : 09980158
Release date : 2017-01-26
Disclaimer The information in this document may be subject to change or updates
without specific notice. Anritsu cannot be held responsible for any errors or
omissions that may be found and this document does not represent a
commitment on the part of Anritsu.
Revision history
Document/
Release date Revision remarks
Order no.
2012-02-10 09980121 Initial version intended for MasterClaw 6.3.1
2012-03-14 09980122 Corrections in Chapters 3, 5, and 7.
2012-11-28 09980123 Version updated to MC-6.4. Major changes:
Ch. 3: further details on User Administration and more applications
introduced.
Ch. 4: more details on QMON
Ch. 5: capabilites updated; qlogs sec. improved; details on interfaces
and port numbers added.
Ch. 6: Sec-linux Tool added.
2013-02-14 09980124 Version updated to MC-6.4.1. Major changes:
Add-ons in Sec. 5.5 (qmcpi-sec)
Small updates in Ch. 6 "Sec-linux tool"
"Backup procedure" added at Sec. 8.2.
2013-06-28 09980125 Ch. 4 updated; more applications related to postgreSQL
administration added in sections 3.3.1 and 3.5; more capabilities and
their usage at tables 5.1 and 5.3; OSGI console added in table 5.30;
table 5.34 updated.
2014-01-10 09980131 Overall update for MC-7.0.0
2014-03-10 09980132 Dismissed eoCompass items removed throughout whole document.
2014-06-12 09980141 Overall update to MC-7.0.1:
- Vertica user administration, sec. 2.7
- new capabilities, table 4.1
- privacy control, sec. 4.5.4
- port numbers on MC servers updated, sec. 4.6.1
- Vertica port numbers, sec. 4.6.8
- Chapter 5 Sec-linux tool updated
2014-08-08 09980142 Capabilities corrected at sec. 4.4
Universe resources corrected at table 4.25
NDAF-DWH Server, NDAF components now integrated in MC
backup (table 7.1).
2014-12-19 09980151 Overall update to MC-7.0.2:
- Updates at Tables 4.30, 4.44, 7.1.
- qmcpi-sec figures updated at sec. 4.5.3
2015-02-16 09980152 Date/time format examples for securityadmin auditreport corrected
at sec. 3.3.2.
Chapter 5 "Sec-linux" tool: improvements at sec. 5.8, 5.9, 5.10,
5.12.5
2015-04-17 09980153 "URL" and "Domain" capabilities added at Tables 4.1 and 4.3.
Port numbers added at Table 4.30.
SSL Certificate description improved, sec. 6.1.2.
2015-06-12 09980154 Cosmetic adjustments.
2015-08-14 09980155 Wrong items removed from table 4.3
2017-01-26 09980158 Cosmetic adjustments at tables 4.29 and 4.30.
II System Administration — Administrator Manual

Release date: 2017-01-26
Document/
Release date Revision remarks
Order no.
2016-05-30 09980157 Usim_ctxkey_srv added at sec. 4.6.10. Port numbers corrected for
qsmnp, table 4.30
2017-01-26 09980158 Note added on eolivec capability, tables 4.2 and 4.3.
Copyright ©2017 Anritsu. All Rights Reserved. ISO 9001:2000 certified.
System Administration — Administrator Manual III

Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 1
1.1 Scope and Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 2

1.1.1 Topics Within the Scope of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 2
1.1.2 Topics Outside the Scope of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 2
1.2 References and Applicable Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 3
1.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 4
2 System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 1
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 2
2.1.1 Environment Variables and the q7env Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 2
2.1.2 q7adm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 2
2.2 User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 7
2.3 Linux User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 8

2.3.1 Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 8
2.4 Oracle User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 15

2.4.1 Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 15
2.5 PostgreSQL User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 27
2.6 Rainstor User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 30
2.7 Vertica User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 31
2.8 User Administration of Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 33

2.8.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 33
2.8.2 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 34
2.8.3 BO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 35
2.8.4 Self Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 35
2.8.5 SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 35
2.8.6 Timeserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 36
2.8.7 SAS Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 36
2.8.8 Onboard Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 36
3 Self Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 1
3.1 MasterClaw Software Components Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 2

3.1.1 Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 5
3.1.2 Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 5
3.1.3 Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 7
3.1.4 Optimization (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 10
3.1.5 Viewing Status of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 11
3.1.6 Sharing QMON Status Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 12
3.1.7 QMON TCP Port Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 13
3.1.8 QBASE Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 14
3.1.9 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 14
IV System Administration — Administrator Manual

3.1.10 Further Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 15
3.2 Hardware Server Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 16

3.2.1 Integrated Lights-Outs (ILO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 16
3.3 Session Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 18

3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 18
3.3.2 Basic Operations of Security Administrative Command Line . . . . . . . . . . . . . . . . . . . . . . . 3 – 20
3.3.3 Overview of Activity Logging Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 22
3.3.4 Description of Activity Logging Entry Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 22
3.3.5 Operation of Session Management via Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 23
4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 1
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 2
4.2 Clients and Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 4
4.3 Portal User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 5

4.3.1 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 5
4.4 MasterClaw Capability Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 7

4.4.1 Defined Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 7
4.4.2 Use of Capabilities per Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 10
4.5 The Security Capability Configuration Plug-in (QMCPI-SEC). . . . . . . . . . . . . . . . . . . . . . . 4 – 18

4.5.1 QMCPI-SEC Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 18
4.5.2 QMCPI-SEC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 18
4.5.3 QMCPI-SEC Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 19
4.5.4 Privacy Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 42
4.6 Interfaces and External Firewalls /VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 43

4.6.1 Port Numbers on all MasterClaw Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 43
4.6.2 Port Numbers Used by MC Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 46
4.6.3 Port Numbers Used by NDAF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 52
4.6.4 Port Numbers Used by Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 55
4.6.5 Port Numbers Used by PostgreSQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 56
4.6.6 Port Numbers Used by BO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 57
4.6.7 Port Numbers Used by Rainstor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 57
4.6.8 Port Numbers Used by Vertica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 59
4.6.9 Port Numbers on MasterClaw Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 60
4.6.10 Port Numbers on MasterClaw Info Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 63
4.6.11 Port Numbers on HP ProLiant Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 65
4.6.12 Configuring CORBA Port Numbers in MasterClaw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 66
4.7 Further Information on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 69

4.7.1 AGG_IN_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 69
4.7.2 AGG_OUT_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 69
4.7.3 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 69
4.7.4 EOLIVE_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 70
4.7.5 HTTP/HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 70
4.7.6 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
4.7.7 KSIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
4.7.8 Link IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
4.7.9 MEAS_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
System Administration — Administrator Manual V

4.7.10 MICS_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
4.7.11 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 71
4.7.12 SIM_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 72
4.7.13 Sftp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 72
4.7.14 Ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 72
4.7.15 TMSI_IMSI_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 72
4.7.16 UMTS_TMSI_IMSI_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 73
4.7.17 X_IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 73
4.8 Internal Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 74
4.9 Protection of Subscriber Confidential Data Sent Over Networks . . . . . . . . . . . . . . . . . . . . 4 – 75
4.10 Protection of User Confidential Data Sent over Networks . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 76
4.11 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 77
4.12 Disk Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 78
4.13 SUDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 79
4.13.1 Disable sudo on Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 79
4.13.2 Disable sudo on Probe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 80
4.14 Sec-Linux Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 81
5 Sec-linux Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 1
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2

5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
5.1.2 Platform or Packages Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
5.1.3 Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
5.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 5
5.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 6
5.4 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 7
5.5 Configuring Security Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 8
5.6 Enabling/Disabling Plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 10
5.7 Configuring Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 12
5.8 Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 13
5.9 Pre Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 14
5.10 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 15
5.11 Post Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 16
5.12 Plugins Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 17

5.12.1 Add Sticky Bit On World Writable Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 17
5.12.2 Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 17
VI System Administration — Administrator Manual

5.12.3 Block Direct Root Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 18
5.12.4 Block System Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 18
5.12.5 Block USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 18
5.12.6 Block User Failed Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 19
5.12.7 Crontab Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 20
5.12.8 Crontab Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 21
5.12.9 Disable Ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 21
5.12.10 Disable User Mounted FS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 21
5.12.11 Dos Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 21
5.12.12 Enable Accepting Remote Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 22
5.12.13 Enable Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 22
5.12.14 Enabling Idle Connection Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 25
5.12.15 Enable Boot Loader Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 25
5.12.16 Enable Idle Session Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 26
5.12.17 Enable Notifications Failed Logins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 26
5.12.18 Enable Remote Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 27
5.12.19 Enable Session Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 27
5.12.20 Enforcing Secure Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 28
5.12.21 Enforce Single Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 29
5.12.22 File Creation Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 30
5.12.23 Kernel Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 30
5.12.24 Locate Unowned Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 30
5.12.25 Log File Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 31
5.12.26 Login Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 31
5.12.27 Nodev on Used Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 34
5.12.28 Remove World Writable Permission on Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 34
5.12.29 Remove Setuid Setgid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 34
5.12.30 Remove Unneeded Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 35
5.12.31 Restrict Root Login to Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 38
5.12.32 Sftp only mclawxdr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 38
5.12.33 System Configuration File Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 38
5.12.34 TCP IP Hardening. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 38
5.12.35 TCP IP Disable Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 39
5.12.36 TCP Wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 39
5.12.37 Update Services Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 41
5.12.38 Enable Selinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 42
6 System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 1
6.1 Certificate Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 2

6.1.1 Signing of Java Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 2
6.1.2 SSL Certificate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 2
6.2 Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 4
6.3 Protocol Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 6

6.3.1 Adding New Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 6
6.3.2 Updating Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 6
6.3.3 Uninstalling Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 6
6.4 Timezone Updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 7

6.4.1 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 7
6.4.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 7
6.4.3 Systemwide Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 8
System Administration — Administrator Manual VII

7 Back-up and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 1
7.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 2
7.2 Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 3

7.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 3
7.2.2 Supported Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 4
7.2.3 Supported Host Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 12
7.2.4 Remote Backup Host Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 12
7.2.5 Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 13
7.2.6 Central Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 18
7.2.7 Oracle DWH Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 23
7.2.8 Vertica DWH Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 31
7.2.9 Mediation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 32
7.2.10 eoLive Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 36
7.2.11 eoFinder Browse Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 36
8 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 – 1
8.1 Environment and Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 – 2

8.1.1 Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 – 2
8.1.2 Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 – 3
9 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 – 1
List of Figures
Fig. 3.1 Application killed with data saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 19
Fig. 3.2 Application killed with no data saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 19
Fig. 4.1 MasterClaw security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 3
Fig. 4.2 QMCPI-SEC root node – list view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 20
Fig. 4.3 QMCPI-SEC users node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 21
Fig. 4.4 QMCPI-SEC users entity node – attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 22
Fig. 4.5 QMCPI-SEC user groups node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 25
Fig. 4.6 QCMPI-SEC user groups entity node – attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 26
Fig. 4.7 QCMPI-SEC capabilities node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 27
Fig. 4.8 QMCPI-SEC capabilities entity node – attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 28
Fig. 4.9 QCMPI-SEC centres node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 29
Fig. 4.10 QCMPI-SEC centres entity node – attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 30
Fig. 4.11 QCMPI-SEC signalling linkset node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 31
Fig. 4.12 QCMPI-SEC signalling linkset entity node – attributes . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 32
Fig. 4.13 QCMPI-SEC security policies node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 33
Fig. 4.14 QCMPI-SEC security policies entity node – account lockout . . . . . . . . . . . . . . . . . . . . 4 – 34
Fig. 4.15 QCMPI-SEC security policies entity node – password . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 35
Fig. 4.16 QCMPI-SEC Resources node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 36
Fig. 4.17 QCMPI-SEC Resources entity node - attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 37
Fig. 4.18 QCMPI-SEC DBOs node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 40
Fig. 4.19 QCMPI-SEC DBOs entity node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 41
Fig. 4.20 Example of a network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 70
VIII System Administration — Administrator Manual

List of Tables
Table 2.1 q7adm, general options ................................................................................................... 2 – 3
Table 2.2 DWH users .................................................................................................................... 2 – 21
Table 2.3 Oracle accounts and relevant MasterClaw services...................................................... 2 – 24
Table 2.4 Portal users.................................................................................................................... 2 – 34
Table 3.1 Probe service limits........................................................................................................ 3 – 18
Table 3.2 Overview of activity logging entry .................................................................................. 3 – 22
Table 4.1 Common capabilities ....................................................................................................... 4 – 7
Table 4.2 Application specific capabilities ....................................................................................... 4 – 9
Table 4.3 Capability Usage............................................................................................................ 4 – 11
Table 4.4 QCMPI-SEC root node default list view......................................................................... 4 – 21
Table 4.5 QCMPI-SEC root node menu actions............................................................................ 4 – 21
Table 4.6 QCMPI-SEC users node views...................................................................................... 4 – 22
Table 4.7 QCMPI-SEC users node menu actions ......................................................................... 4 – 22
Table 4.8 QCMPI-SEC users entity node views ............................................................................ 4 – 23
Table 4.9 QCMPI-SEC users entity node menu actions................................................................ 4 – 25
Table 4.10 QCMPI-SEC user groups node views ........................................................................... 4 – 25
Table 4.11 QCMPI-SEC user groups node menu actions ............................................................... 4 – 25
Table 4.12 QCMPI-SEC user groups entity node views.................................................................. 4 – 26
Table 4.13 QCMPI-SEC user groups entity node menu actions ..................................................... 4 – 27
Table 4.14 QCMPI-SEC capabilities node views............................................................................. 4 – 27
Table 4.15 QCMPI-SEC capabilities entity node views ................................................................... 4 – 28
Table 4.16 QCMPI-SEC centres node views................................................................................... 4 – 29
Table 4.17 QCMPI-SEC centres entity node views ......................................................................... 4 – 30
Table 4.18 QCMPI-SEC signalling linkset node views .................................................................... 4 – 31
Table 4.19 QCMPI-SEC signalling linkset entity node views........................................................... 4 – 32
Table 4.20 QCMPI-SEC security policies node views ..................................................................... 4 – 33
Table 4.21 QCMPI-SEC security policy node menu actions ........................................................... 4 – 33
Table 4.22 QCMPI-SEC security policies entity node views ........................................................... 4 – 35
Table 4.23 QCMPI-SEC Resources node views ............................................................................. 4 – 37
Table 4.24 QCMPI-SEC Resources entity node views.................................................................... 4 – 37
Table 4.25 Universe resources........................................................................................................ 4 – 38
Table 4.26 QCMPI-SEC DBOs node views..................................................................................... 4 – 40
Table 4.27 QCMPI-SEC DBOs entity node views ........................................................................... 4 – 41
Table 4.28 Port numbers on MasterClaw servers ........................................................................... 4 – 44
Table 4.29 Detailed interfaces and port numbers on MasterClaw servers ...................................... 4 – 44
Table 4.30 Interfaces and port numbers used by MC applications.................................................. 4 – 46
Table 4.31 NDAF port numbers....................................................................................................... 4 – 53
Table 4.32 Detailed NDAF interfaces and port numbers ................................................................. 4 – 53
Table 4.33 Detailed Oracle interfaces and port numbers ................................................................ 4 – 55
Table 4.34 Detailed PostgreSQL Interfaces and port numbers ....................................................... 4 – 56
Table 4.35 Detailed BO Interfaces and port numbers ..................................................................... 4 – 57
Table 4.36 Detailed Rainstor Interfaces and port numbers ............................................................. 4 – 57
Table 4.37 Detailed Vertica Interfaces and port numbers ............................................................... 4 – 59
Table 4.38 Port numbers on MasterClaw probes ............................................................................ 4 – 60
Table 4.39 Detailed probe interfaces and port numbers.................................................................. 4 – 61
Table 4.40 Multiple instances port numbers .................................................................................... 4 – 62
Table 4.41 Port numbers on MasterClaw info servers..................................................................... 4 – 63
Table 4.42 Detailed Info servers interfaces and port numbers ........................................................ 4 – 64
Table 4.43 Multiple instances port numbers .................................................................................... 4 – 65
Table 4.44 Port numbers on HP ProLiant servers ........................................................................... 4 – 65
Table 4.45 Java servers .................................................................................................................. 4 – 68
Table 6.1 TZUpdater options ........................................................................................................... 6 – 7
Table 7.1 Application support details............................................................................................... 7 – 5
System Administration — Administrator Manual IX

Table 8.1 MC environment variables ............................................................................................... 8 – 2
Table 8.2 Terms used in the directory structure............................................................................... 8 – 3
Table 8.3 Files and directories in ${QUEST7_ROOT} ..................................................................... 8 – 4
Table 8.4 Contents of tar.................................................................................................................. 8 – 7
Table 9.1 Acronyms ......................................................................................................................... 9 – 1
X System Administration — Administrator Manual

1
Introduction
This document contains an overall description of how to manage the MC

Systems in order to help the system manager.
System Administration — Administrator Manual 1– 1

Introduction
1.1 Scope and Purpose
1.1.1 Topics Within the Scope of This Document

Routine maintenance Guidelines and procedures for routine maintenance of MasterClaw.
System configuration Guidelines and procedures for MasterClaw system administration.
1.1.2 Topics Outside the Scope of This Document

System planning This document does not contain guidelines or information needed for
planning a new MasterClaw system or major changes in an existing
MasterClaw system.
Please contact your local Anritsu representative or the Anritsu Customer
Support Department for further information.
Installing a new While Chapter 2. System Administration describes commands and utilities
software release for installing a new software, and Chapter 8. Appendix describes the directory
structure and the required configuration files, you may not find this document
relevant for installation of a new software release.
Instead, for information on installation of the current software release, please
refer to the MasterClaw installation and configuration guides.
1– 2 System Administration — Administrator Manual

1.2 References and Applicable
Documents
The following reference documentation can be found at Anritsu official
documentation main page:
● MC System Installation and Configuration Manual
● Common Data Warehouse and MC Insight Installation & Administration
Manual
● Probe Installation and Configuration Guide
● Common ULP Installation Manual
● eoLive Installation and Configuration Manual
● eoFinder Browse Server Installation and Administration Manual
● Self Monitoring Installation and Configuration Manual
● MC Backup Installation Manual
● Portal Installation and Configuration Manual
● Security Installation and Configuration Manual
Further documentation can be found at other Anritsu internal repositories:

● Security Features document (for details on availability and access to this
documents, please contact Anritsu).

Introduction
1.3 Typographical Conventions

Introduction Typographical conventions are used throughout this manual to help you find
the information that you are looking for.
Caution: A type of note that advises users that failure to take or avoid a
specified action could result in loss of data or damage of
equipment.
Note: Indicates neutral or positive information that emphasises or

supplements important points of the main text.
Hint: A type of note that helps users apply the techniques and procedures
described in the text.
Procedures A procedure that tells you how to perform a task looks like this:
Step What to do
1. Select and open the object by double-clicking the icon
2. Place the instrument in its carrying case and close it.
Lists In a list that summarises a number of facts, each item is preceded by a • like
this:
● One fact
● Another fact
● Yet another fact
Keyboard keys A KEYBOARD KEY is represented by the name of the key in capitals, like
SHIFT+F3.
Buttons, icons, boxes, All these items are represented by their name or label text, like this; in the
dialogues, etc. Instrument Setup dialogue, click Load.
Links or cross- Links and cross-references are written in italic. Links to Web sites are written
references in blue and underlined.

2

2.1 Introduction
This Chapter describes the commands for general MasterClaw system
administration.
Please refer to the release notes for each package for detailed information
about how to install and configure MasterClaw.
Please refer to Chapter 8. Appendix for more information about environment
variables, directory structure, and configuration files.
2.1.1 Environment Variables and the q7env

Command
The MasterClaw base system contains the command q7env, which can be
used to set up the proper environment for an administrator. To set up the
environment, use the command:
# export QUEST7_ROOT=quest7_root
# . ${QUEST7_ROOT:-/opt/anritsu/mclaw}/bin/q7env
The first command is only needed if MasterClaw is not placed in /opt/anritsu/

mclaw. It is recommended to include the command in the .profile of user
mclaw.
2.1.2 q7adm
The q7adm command is used for all administration of MasterClaw. The
q7adm command can perform the following operations:
● Start all server processes used within MasterClaw
● Stop these server processes
● Load a new package into the current MasterClaw system
● Install a loaded package
● Uninstall a previously installed package
● Unload a previously loaded package
The q7adm command can only be used from the root account.
The q7adm command is called as:
# q7adm [command-options…] SUB-COMMAND [sub-command-
options…] ARGUMENTS
Each of the possible sub-commands and their special options are described
below.

General command The q7adm command has these general options:
options
Option Description
-v Run in verbose mode.
-s Run in silent mode (default)
-D Run q7adm in a special debug mode where all commands are listed
before they are executed and all temporary files are left after the
execution of the command (normally, they are deleted).
-T Trace the execution of shell functions.
-P Sets QBASE_PACKAGE_PATH to <path>
<path>
Table 2.1 q7adm, general options
help To see a short description of all available q7adm commands, use the
command:
% q7adm help
The q7adm help command displays the following help message:

Usage: q7adm [-DT] [-sv] [-P <qbase-package-path>]
<command> <command-options> <command-arguments>...
q7adm is used to administer a MasterClaw installation and performs a
number of operations as specified by the command.
The default command is help.
To get additional information about a specific command, including a
description of all command options and arguments, use the command:
% q7adm <command> -H
Options:
-D Run in debug mode
-T Trace the execution of shell functions
-v Run in verbose mode
-s Run in silent mode
-P <path> Sets QBASE_PACKAGE_PATH to <path>.
Usage: q7adm cron <type>

Run a cron job periodically.
Usage: q7adm dump [-f]

Dump selected information about installed packages.
Usage: q7adm help

Show help about all available commands.
Usage: q7adm install [-u] <package-id>...

Install selected packages.

Usage: q7adm list [-lv] [<package-prefix>]

List installed (or loaded) packages.
Usage: q7adm load [-iuf] <package-file>...

Load the specified packages into the installation.
Usage: q7adm recalclinks

Recalculate the symbolic links in .../bin, .../shlib, .../shlib64 and .../jar.
Usage: q7adm start [-f] [<package-name>...]

Start selected packages.
Usage: q7adm stop [-f] [<package-name>...]

Stop selected packages.
Usage: q7adm uninstall [-u] <package-name>

Uninstall the specified packages.
Usage: q7adm unload <package-id>...

Unload the specified load but not installed packages.
Usage: q7adm update-package [<package-id>...]

Update the package.def of the specified packages.
Usage: q7adm verify [<package-name>...]

Verify the installed of the specified packages.
start and stop To start all installed services use the command:
% q7adm start
To start services of a specific set of packages, use the command:
% q7adm start package…
When no packages are specified (the first example), the qbase, qns and
TOPO packages are started before any other packages. The rest of the
packages are handled in alphabetical order.
The packages are stopped in the reverse sequence.
Note: The support for start and stop is implemented in the individual
packages; please refer to the release notes for the different packages
for further information.

load To load a new package or a new version of a package into MasterClaw, use
the command:
% q7adm load package-file
where package-file is the name of the file to load.
For example:
% q7adm load /usr/tmp/qstc-1.1.2.tar.Z
When the package has been loaded, install it with the install sub-command
(see below). More than one version of a package can be loaded at any one
time.
install To install a previously loaded package, use the command:

% q7adm install [-u] package
where package is the full name of the package (e.g., qstc-1.1.2).
Option Description
-u Update a currently installed package.
For example:
% q7adm install qstc-1.1.2
uninstall To uninstall a previously installed package, use the command:

% q7adm uninstall package
where package is the base part of the package (e.g., qstc).
For example:
% q7adm uninstall qstc
unload To unload a previously loaded package, use the command:

% q7adm unload package
where package is the full name of the package (e.g., qstc-1.1.2).
For example:
% q7adm unload qstc-1.1.2
list To list loaded and installed packages, use the command:

% q7adm list
The q7adm list command produces output similar to the following:
apmlinux-2.1.2 (installed as 'apmlinux')
cdb-1.0.7 (installed as 'cdb')
cdb-if-2.0.2 (installed as 'cdb-if')
cdb-model-1.1.8.5 (installed as 'cdb-model') - CDB
Core Data Model
corrdef-0.6.9 (installed as 'corrdef') - Correlation
Definition Package

.
qxts-if-2.1.0 (installed as 'qxts-if')
sdlt-4.0.8.3 (installed as 'sdlt')
temip-register-3.0.3 (installed as 'temip-register')

2.2 User Administration
This section contains guidelines and procedures for user administration.
● Users are defined with a username, a group, a password, and a home
directory.
● The security level of the system depends on how well educated the users
are with respect to password protection and frequent changes of the
password.
Some more words on Remember that the password is the weak link in the security chain in any Unix
passwords system.
● Never have your password written on a piece of paper or hidden under
the keyboard, in a drawer or anywhere near the keyboard – passwords
are meant to be remembered!
● Choose a password that is easily remembered but hard to guess.
MasterClaw user administration consists of the following parts:

● Linux User Administration
● Oracle User Administration
● PostgreSQL User Administration
● Rainstor User Administration
● Vertica User Administration
● Other applications’ User Administration
Details for each item are provided in the next sections.

2.3 Linux User Administration

Linux user administration is partly Linux security administration, and partly
user administration.
2.3.1 Linux
The following Linux accounts are present in a MasterClaw system and they
should not be blocked since they are used to administer and run the
applications:
● root
● mclaw
● qpm (only on probes and info servers)
● ipsec-listen (optional)
● oracle
● rainstor
● vertica
Optional user mclawxdr is also present for letting third part download
TDRs. This user can be blocked.
All other users can be disabled (or removed) by using the sec-linux tool. See
Chapter 5. Sec-linux Tool for details.
Changing password The password can be changed on a host using standard linux command:
> passwd
It is also possible to change the password on several hosts from the Central
Server and the mclaw account at the same time, using the change
password tool (changepass, provided that the listed hosts have the same
password. If needed, the tool can update probe configuration files for qpm
and ipsec-listen accounts (see more info further down in this section).
Changing expiring The expiring date can be modified with the standard linux command chage:
date To show the current setting for a user:
> chage -l <user name>
To set the expire date for a user

> chage <user name> -E <expire date>
where the date is in the YYYY-MM-DD format
To reset the expiring time:

> chage <user name> -E -1
Setting time based Add the following line to /etc/pam.d/login:

access restriction login account required pam_time.so

(Note that if sec-linux tool is used, the line can be added to its pam login
file in the DEFAULT configuration directory.)
Then edit /etc/security/time.conf by adding:
login ; * ; <user list> ; !Al0000-2400
Where user list follows the syntax: <user name>[|<>]

For more info see the man paged for pam_time and time.conf
Force password It is possible to force the password change with the standard linux command
change chage:
> chage <user name> -d 0
Key generation for ssh For NDAF it is mandatory to create keys for ssh authentication by executing
the following command, that uses RSA by default:
> ssh-keygen
If you need to change the algorithm using rsa1, rsa or dsa, execute:
> ssh-keygen -t <rsa1|rsa|dsa>
The minimal key length shall be:
Cyphering Length
Algorithm
RSA1 2048
RSA 2048
DSA 1024
The key shall be installed together with the host fingerprint.
Personal accounts On Linux host, the personal account (which is by default not needed) can be
created using the following commands executed as root:
# useradd <account name>
# passwd <account name>
The following command can be used to become root (or mclaw) and to
perform the administrative task that requires the given account:
> su -
or
> su - mclaw
This command may require a password.
root The root account is the Linux administrator.

Default passwords are:
On server: elmi..
On probe: nettest
It is possible to change the password or to disable the root login.

The root account is used to install:

● Platform
● Platform packages (e.g. SRV)
● Supported third party product
E.g. Oracle, BO, MC Self Monitoring
● MC Backup
● Security enforcements (sec-linux)
Seldom, the root account may also be needed to perform some other
administrative tasks:
● System probe software installation/upgrade(uses sudo rpm)
● Probe ntp configuration (uses sudo ntp_copy.sh)
● Ipsec deployment (uses sudo ipsec-config)
● MC Selfmon agent deployment (uses sudo rpm)
● MC Selfmon services start/stop/administration
● MC backup installation/administration
For more info, see also Section 4.13 SUDO.
MCSelf Monitoring
MC Self Monitoring is started and stopped using the linux command
service on:
● nagios (only on selfmon machine)
● mysqld (only on selfmon machine)
● httpd (only on selfmon machine)
● nrpe (only on monitored machines)
root is also needed to change the nagiosadmin user through the apache
htpasswd command.
Disabling login
It is possible to disable direct root login from outside; in this case, the
administrator shall log on the system using another account, and then
becoming root.
Depending on the security level requested by the customer, you can:
● Use mclaw account also as login account
● Use personal accounts as login account
To disable the root account, you should use the sec-linux tool by choosing
the plugin that implements the Customer requirement, to:
● Permit root login only from console
● Completely disable root login.
Login from mclaw

The following command can be used to become a root user and perform
the administrative task that requires such account:
> su -
2–10 System Administration — Administrator Manual

(The command asks for the root password)
Login from personal accounts only
A precaution shall be taken not to permit mclaw and other machine
accounts to become root.
As root, create the needed personal accounts, one for each user. Then
modify the system as follows:
1. Assign the wheel group the above personal accounts:
# usermod -G wheel <personal account name>
2. Edit /etc/pam.d/su which should look like:
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid
quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
Note: The home directories are not preserved in case of platform upgrade.
Moreover, the personal accounts could be locked in some cases (e.g.
expired password, too many failed logins…) so the risk exists that the
administrator cannot logon remotely.
mclaw User mclaw is available on all platforms on which the plugins PRO, SRV
and CLU have been installed. This is the main MasterClaw account and it is
used by almost all services.
The default password is: mclaw..
Note: If there are any applications installed on the system which use mclaw
account, they shall be reconfigured with the new password. Examples:
● dwh backend downloading DR from a mediation server
● qxdrs delivering DR to eoFinder Browse
● eoFinderBrowse Server to install tablespaces
As already mentioned, the mclaw account in NDAF shall be configured to

use ssh keys between nodes.
Refer to the relevant application documentation for further information.
mclawxdr The user mclawxdr is available on all platforms on which the plugins PRO
and SRV have been installed.
This account can be used to let third party applications download TDRs from
a host. This ensures that the mclaw password is not communicated to those
that aren’t Master Claw administrator.
Its default passwords are:
On server: mclawxdr..
On probe: mclawxdr..
System Administration — Administrator Manual 2–11

It is also possible to use the sec-linux tool in order to configure such

account, so to avoid ssh connection while allowing sftp connection only.
Configure xdr directory for QXDRS

An active generation can be configured to produce data record in a directory
owned by mclawxdr.
First you create a subdirectory in /var/opt/anritsu/mclawxdr/
Example: xdr.
Then you configure the active generation changing the default dir in the
Directory parameters, see below:
<xDRGeneration name="NGN-Diameter">
<Definition>
<Format ref-name="NGN-Diameter"/>
<OutputInterval value="300"/>
<Output name="NGN-Diameter-1">
<File>
<FileName dateFormat="%Y%m%d%H%M"
postfix="" prefix="NGN_" separator="-" value="1"/>
<Directory value="/var/opt/anritsu/
mclawxdr/xdr"></Directory>
<UseTemporary value="Y"></UseTemporary>
</File>
</Output>
</Definition>
</xDRGeneration>
See Data Record Gateway Installation Guide for further information.
Configure xdr directory for DoIP probes

The voip/ether SIM can be reconfigured in order to use another directory
accessible only to mclawxdr for both output and temporary DRs.
The /var/opt/anritsu/mclawxdr/xdr directory can be created on the probe,
thus providing the following ownership and rights:
drwxrwx--- mclawxdr:mclaw
See li-ether-sim Release Notes for more information on configuration

requirements.
qpm User qpm is available on all platforms on which the plugins PRO has been
installed. This account is reserved for probe software installation.
The default password is: qpm
If this password is changed, then the qpm-server.nin on the Central
Server has to be updated with the new password.
ipsec-listen The ipsec-listen user is available on all platforms on which the ULP
platform has been installed. This account is reserved for ipsec configuration.
The default password is: ipsec..
If this password is changed, then the ipsec.nin on the Central Server has
to be updated accordingly.

Oracle User oracle is available on all platforms on which the Oracle package has
been installed. This account is used by:
● Oracle RDBMS
● DWH ETL during installation and at runtime to manage tablespaces
● Various MasterClaw applications during their installation phase (e.g. to
create the directories hosting the tablespaces).
The default password is: oracle..

If the password is changed, then the configuration for the following
applications has to be updated as well:
● cdb
● qdash
● qalarms
● security
● portal
● qfds
● all DWH backends
postgres User postgres is available on all platforms on which the Postgres package
has been installed. This account is used by:
● PostgreSQL RDBMS
● eoFinderBrowse during the installation phase (e.g. to create
tablespaces).
● eoLive
● cdb
● qdash
● qalarms
● security
● portal
● qfds
The default password is: postgres..

If the password is changed, then the configuration of the following
application has to be updated as well:
● eoFinder Browse Server
● eoLive
● cdb
● qdash
● qalarms
● security
● portal
● qfds
Refer to the applications’ documentation for further info.
Rainstor User mclaw is available on all platforms on which the Rainstor package has

● rainstor DBMS
● eoFinder Browse during installation and at runtime to manage tablespaces
● Various MasterClaw applications during their installation phase (e.g. to
create the directories hosting the tablespaces).
The default password is: mclaw..
If the password is changed, then the configuration for the following
applications has to be updated as well:
● eoFinder Browse Server
● eoFinder Browse Loader
Vertica User dbadmin is available on all platforms on which the Vertica package has
● Vertica RDBMS
● DWH- NDAF ETL during installation and at runtime to manage
tablespaces
The default password is: dbadmin..

If the password is changed, then the configuration for the DWH-NDAF
application has to be updated as well:
apache User apache is available on all platforms on which the MC Self Monitoring
has been installed. This account is used by the Apache web server used to
deliver the MC Self Monitoring web interface.
The account is blocked on MC Self Mon server.
nagios User nagios is available on all platforms on which the MC Self Mon has
been installed. This account is used by the MC Self Mon server.
The account is blocked on MC Self Mon server.

2.4 Oracle User Administration
Oracle user administration is partly Oracle security administration, and partly
user administration:
Users can be classified in:

● Oracle System/Administration users
● Application users
2.4.1 Oracle
Changing password Passwords of oracle accounts can be changed using the following
procedure.
For sys and system accounts:

Logon as oracle and execute the command:
> sqlplus / as sysdba
SQL> ALTER USER sys IDENTIFIED BY newpassword;
or
> sqlplus /as sysdba
SQL> ALTER USER system IDENTIFIED BY newpassword;
For other MasterClaw accounts:

Logon as mclaw and execute the command providing the user the password
when requested:
> sqlplus
SQL> ALTER USER <masterclaw db account> IDENTIFIED BY

newpassword;
If you change the password for an Oracle account that is used by a
MasterClaw service, then it is highly recommended that you stop the service
(or services) before you change the password.
For further information, see Common ULP Installation Manual – Oracle
section.
Listing grants SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"

FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('%&uname%')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

Listing Grants on SET ECHO off

Object REM NAME: TFSOBPRV.SQL
REM USAGE:"@path/tfsobprv"
REM ----------------------------------------------------------
----------------
REM REQUIREMENTS:
REM SELECT ANY TABLE
REM ----------------------------------------------------------
----------------
REM AUTHOR:
REM Geert De Paep
REM ----------------------------------------------------------
----------------
REM PURPOSE:
REM Will report what OBJECT privileges are related to a
certain user
REM (for GRANTOR as well as GRANTEE)
REM ----------------------------------------------------------
-----------------
REM EXAMPLE:
REM Enter user to evaluate: sys
REM
REM Table privileges GIVEN:
REM ======================
REM SELECT ON SYS.ACCESSIBLE_TABLES TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_ARGUMENTS TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_CATALOG TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_CLUSTERS TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_CLUSTER_HASH_E TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_COL_COMMENTS TO PUBLIC
+GRANT OPT
REM SELECT ON SYS.ALL_COL_GRANTS_MAD TO PUBLIC
REM
REM Table privileges RECEIVED:
REM ==========================
REM SELECT ON SYSTEM.DEF$_CALL FROM SYSTEM
+GRANT OPT
REM SELECT ON SYSTEM.DEF$_ERROR FROM SYSTEM
+GRANT OPT
REM SELECT ON SYSTEM.DEF$_DESTINATIO FROM SYSTEM
+GRANT OPT
REM SELECTON SYSTEM.DEF$_CALLDEST FROM SYSTEM
+GRANT OPT
REM SELECT ON SYSTEM.REPCAT$_REPSCHE FROM SYSTEM
+GRANT OPT
REM
REM Column privileges GIVEN:
REM ========================
REM
REM Column privileges RECEIVED:
REM ===========================

REM
REM ----------------------------------------------------------
-----------------
REM DISCLAIMER:
REM This script is provided for educational purposes only. It
is NOT
REM supported by Oracle World Wide Technical Support.
REM The script has been tested and appears to work as intended.
REM You should always run new scripts on a test instance
initially.
REM ----------------------------------------------------------
----------------
REM Main text of script follows:
set head off

set verify off
set feed off
set pause off
col pr format a10
col tn format a22
col tn2 format a30
col gr format a20
accept person char prompt 'Enter user to evaluate: '
ho clear
prompt Table privileges GIVEN:

prompt ======================
select privilege pr,
'ON',
owner||'.'||table_name tn,
'TO',
grantee gr,
decode(grantable,'YES','+GRANT OPT')
from sys.dba_tab_privs
where owner = upper('&person');
prompt
prompt Table privileges RECEIVED:
prompt ==========================
'ON',
owner||'.'||table_name tn,
'FROM',
grantor gr,
from sys.dba_tab_privs
where grantee = upper('&person');
prompt
prompt
prompt Column privileges GIVEN:

prompt ========================
'ON',
owner||'.'||table_name||'('||column_name||')' tn2,
'-->',
grantee gr,
from sys.dba_col_privs
where owner = upper('&person');
prompt
prompt Column privileges RECEIVED:
prompt ===========================
'ON',
owner||'.'||table_name||'('||column_name||')' tn2,
'FROM',
grantor gr,
from sys.dba_col_privs
where grantee = upper('&person');
set head on
set verify on
set feed on
Administration sys
Oracle user sys is available on all platforms on which the Oracle package
has been installed. Its password can be changed.
The default password is: manager
If you change the password, you must also update the configuration of the
Self-Monitoring application.
The password should be updated in:
Oracle_Database_password, section credentials_APP_deploy in auto-
conf.nin file present under /opt/anritsu/selfmon/auto-conf on selfmon server
Refer to Self Monitoring Installation and Configuration Manual for further
information.
system
Oracle user system is available on all platforms on which the Oracle
package has been installed. Its password can be changed.
The default password is: manager
following applications:

● cdb
● qdash
● qalarms
● security
● portal
● qfds
● dwh
Refer to the single applications’ documentation for further information on

configuration.
Applications CDB
Oracle user cdb is available on the Oracle server used by cdb. Its password
can be changed.
The default password is: cdb
cdb application:
Role and Grants

GRANTEE GRANTED_ROLE ADM DEF
------------------------------ ------------------------------ --- ---
CDB CDB_ROLE NO YES
GRANTEE GRANTED_ROLE PRIVILEGE

------------------------------ ------------------------ --------
CDB_ROLE -- CREATE SEQUENCE
CDB_ROLE -- CREATE SESSION
CDB_ROLE -- CREATE TABLE
CDB_ROLE -- CREATE TRIGGER
EXECUTE ON SYS.DBMS_LOB FROM SYS
Refer to the specific application’s documentation for further info.
SecurityS
The oracle user mclawsecurity is available on the Oracle server used
by masterClaw security. Its password can be changed.
The default password is: testtest
security application.
Refer to the specific application’s documentation for further information.
Role and Grants

------------------------------ ------------------------------ --- ---
MCLAWSECURITY RESOURCE NO YES
MCLAWSECURITY CONNECT NO YES

------------------------------ ------------------------------ --------

MCLAWSECURITY RESOURCE CREATE PROCEDURE

MCLAWSECURITY RESOURCE CREATE SEQUENCE
MCLAWSECURITY RESOURCE CREATE CLUSTER
MCLAWSECURITY RESOURCE CREATE TRIGGER
MCLAWSECURITY RESOURCE CREATE TYPE
QDASH
The oracle user qdash is available on the Oracle server used by qdash. Its
password can be changed.
The default password is: qdash
qdash application.
Role and Grants

------------------------------ ------------------------------ --- ---
QDASH QDASH_ROLE NO YES
QDASH_ROLE RESOURCE NO YES
QDASH_ROLE CONNECT NO YES

------------------------------ ------------------------------ --------
QDASH_ROLE -- UNLIMITED TABLESPACE
QDASH_ROLE CONNECT CREATE SESSION
QDASH_ROLE RESOURCE CREATE CLUSTER
QDASH_ROLE RESOURCE CREATE INDEXTYPE
QDASH_ROLE RESOURCE CREATE OPERATOR
QDASH_ROLE RESOURCE CREATE PROCEDURE
QDASH_ROLE RESOURCE CREATE SEQUENCE
QDASH_ROLE RESOURCE CREATE TABLE
QDASH_ROLE RESOURCE CREATE TRIGGER
QDASH_ROLE RESOURCE CREATE TYPE
ALARMS
Oracle user event is available on the Oracle server used by qevent. Its
password can be changed.
The default password is: event
qes application.
Role and Grants

------------------------------ ------------------------------ --- ---
EVENT EVENT_ROLE NO YES
EVENT_ROLE CONNECT NO YES
EVENT_ROLE RESOURCE NO YES

------------------------------ ------------------------------ --------
EVENT_ROLE -- UNLIMITED TABLESPACE
EVENT_ROLE CONNECT CREATE SESSION
EVENT_ROLE RESOURCE CREATE CLUSTER
EVENT_ROLE RESOURCE CREATE INDEXTYPE
EVENT_ROLE RESOURCE CREATE OPERATOR
EVENT_ROLE RESOURCE CREATE PROCEDURE
EVENT_ROLE RESOURCE CREATE SEQUENCE
EVENT_ROLE RESOURCE CREATE TABLE
EVENT_ROLE RESOURCE CREATE TRIGGER
EVENT_ROLE RESOURCE CREATE TYPE
QFDS
Oracle user qfd is available on the Oracle server used by qfds. Its password
can be changed.
The default password is: qfd
qfds application.
Role and Grants

------------------------------ ------------------------------ --- ---
QFD_ROLE CONNECT NO YES
QFD_ROLE RESOURCE NO YES
QFD QFD_ROLE NO YES

------------------------------ ------------------------------ --------
QFD_ROLE -- UNLIMITED TABLESPACE
QFD_ROLE CONNECT CREATE SESSION
QFD_ROLE RESOURCE CREATE CLUSTER
QFD_ROLE RESOURCE CREATE INDEXTYPE
QFD_ROLE RESOURCE CREATE OPERATOR
QFD_ROLE RESOURCE CREATE PROCEDURE
QFD_ROLE RESOURCE CREATE SEQUENCE
QFD_ROLE RESOURCE CREATE TABLE
QFD_ROLE RESOURCE CREATE TRIGGER
QFD_ROLE RESOURCE CREATE TYPE
DWH
The following oracle users and passwords are available on the Oracle
servers used by the DWH:
DWH User Password

qadwh qadwh qadwh
qgbdwh qgbdwh qgbdwh
Table 2.2 DWH users

DWH User Password

qisupdwh qisupdwh qidw
qiucsdwh qiucsdwh qiucsdwh
qlmsdwh qlmsdwh32 qlmsdwh32
qrsdwh qrsdwh qrsdwh
qsmsdwh qsmsdwh qsmsdwh
qtcapdwh qtcapdwh qtcapdwh
grqdwh grqdwh grqdwh
qardwh qardwh qardwh
qdtdwh qdtdwh qdtdwh
qngndwh qngndwh ngndwh
Table 2.2 DWH users
These passwords can be changed. If you change the password, you must
also update the configuration of the given DWH application and BO.
Role and Grants

QADWH only will be reported here as an example, since all DWH users
have the same definition:

------------------------- -------------------------- -------------
QADWH DWH_ADMINISTRATOR_ROLE ALTER TABLESPACE
QADWH DWH_ADMINISTRATOR_ROLE CONNECT
QADWH DWH_ADMINISTRATOR_ROLE CREATEANY DIRECTORY
QADWH DWH_ADMINISTRATOR_ROLE CREATE DATABASE LINK
QADWH DWH_ADMINISTRATOR_ROLE CREATE DIMENSION
QADWH DWH_ADMINISTRATOR_ROLE CREATE MATERIALIZED VIEW
QADWH DWH_ADMINISTRATOR_ROLE CREATE PROCEDURE
QADWH DWH_ADMINISTRATOR_ROLE CREATE SEQUENCE
QADWH DWH_ADMINISTRATOR_ROLE CREATE SESSION
QADWH DWH_ADMINISTRATOR_ROLE CREATE TABLE
QADWH DWH_ADMINISTRATOR_ROLE CREATE TABLESPACE
QADWH DWH_ADMINISTRATOR_ROLE CREATE TRIGGER
QADWH DWH_ADMINISTRATOR_ROLE CREATE VIEW
QADWH DWH_ADMINISTRATOR_ROLE DROP ANY DIRECTION
QADWH DWH_ADMINISTRATOR_ROLE DROP TABLESPACE
QADWH DWH_ADMINISTRATOR_ROLE EXECUTE CATALOG ROLE
QADWH DWH_ADMINISTRATOR_ROLE QUERY REWRITE
QADWH DWH_ADMINISTRATOR_ROLE RESOURCE
QADWH DWH_ADMINISTRATOR_ROLE SELECT ANY DICTIONARY
QADWH DWH_ADMINISTRATOR_ROLE SELECT CATALOG ROLE
QADWH DWH_ADMINISTRATOR_ROLE UNLIMITED TABLESPACE
QADWH -- ALTER SYSTEM
QADWH -- UNLIMITED TABLESPACE
SELECT ON SYS.DBA_FREE_SPACE FROM SYS

SELECT ON SYS.DBA_DATA_FILES FROM SYS
EXECUTE ON SYS.DBMS_PIPE FROM SYS
WRITE ON SYS.QADWH_DIM_BAD FROM SYS

READ ON SYS.QADWH_DIM_BAD FROM SYS
EXECUTE ON SYS.QADWH_DIM_BAD FROM SYS
WRITE ON SYS.QADWH_DIM_DIR FROM SYS
READ ON SYS.QADWH_DIM_DIR FROM SYS
EXECUTE ON SYS.QADWH_DIM_DIR FROM SYS
WRITE ON SYS.QADWH_DIM_LOG FROM SYS
READ ON SYS.QADWH_DIM_LOG FROM SYS
EXECUTE ON SYS.QADWH_DIM_LOG FROM SYS
WRITE ON SYS.QADWH_EXT_BAD FROM SYS
READ ON SYS.QADWH_EXT_BAD FROM SYS

EXECUTE ON SYS.QADWH_EXT_BAD FROM SYS
WRITE ON SYS.QADWH_EXT_DIR FROM SYS
READ ON SYS.QADWH_EXT_DIR FROM SYS
EXECUTE ON SYS.QADWH_EXT_DIR FROM SYS
WRITE ON SYS.QADWH_EXT_LOG FROM SYS
READ ON SYS.QADWH_EXT_LOG FROM SYS
EXECUTE ON SYS.QADWH_EXT_LOG FROM SYS
Refer to the specific DWH’s configuration manuals for further information.

Note that it is possible to:
● Further restrict the grants on a DWH role so that it no longer belongs to:
— DBA
— DELETE_CATALOG_ROLE
— EXP_FULL_DATABASE
— IMP_FULL_DATABASE
— AQ_ADMINISTRATOR_ROLE
— SNMPAGENT
— OEM_MONITOR
— RECOVERY_CATALOG_OWNER
● Restrict grants on public objects.
Refer to Common ULP Installation Manual – Oracle security section.
MC Backup
The MC Backup application creates the user RMAN on the Oracle server
used by cdb (security, qevent, fraud, qdash). Its password cannot be
changed.
The default password is: CAT
Refer to MC Backup Installation Manual for further information.
Role and Grants

CONNECT, RECOVERY_CATALOG_OWNER
SELECT on USER_ROLE_PRIVS
Summary of Oracle Table 2.3 sums up the Oracle user accounts and the MasterClaw service(s)
Accounts that use these accounts; the third column specifies what further actions you
need to take in order for the service(s) to properly connect to Oracle (once
you have modified the password(s) in Oracle).

Oracle MasterClaw Affected

Account Service(s) Configuration file
<dwh name>DWH DWH see Table 2.2.
cdb CDB $QUEST7_ROOT/nin/cdb.nin
Correct the Password entry in the

[Database] section so it specifies the
new password:
[Database]
Username=cdb
Password=cdb
Please note that all cdb accounts

shouldn’t be changed, otherwise a
system malfunction might occur.
event QES, QCHANNEL $QUEST7_ROOT/nin/qes.nin and
$QUEST7_ROOT/nin/qchannel.nin
Correct the passwd entry in the [Oracle]

section so it specifies the new password:
[Oracle]
...
passwd=event
qdash QDASHS $QUEST7_ROOT/nin/qdashs.nin

[DATABASE] section so it specifies the
new password:
[DATABASE]
...
Password=qdashs
qfd Fraud Server $QUEST7_ROOT/nin/qfds.nin
Correct the passwd entry in the

[DBconnection] section so it specifies
the new password:
[DBconnection]
...
user=qfd
password=qfd
Table 2.3 Oracle accounts and relevant MasterClaw services (Sheet 1 of 3)

security SECURITY_V1 $QUEST7_ROOT/nin/finder.nin

[Oracle] section so it specifies the new
password:
[Oracle]
...
Password=testtest.
portal – $QUEST7_ROOT/nin/portal.nin

[Oracle] section so it specifies the new
password:
[Oracle]
...
Password=portal..
rman MC Backup Refer to MC Backup Installation Manual
for further info.
sys MC Self-Mon The password should be updated in:
Oracle_Database_password, section
credentials_APP_deploy
in auto-conf.nin file present under /opt/
anritsu/selfmon/auto-conf on selfmon
server
Refer to Self Monitoring Installation and
Configuration Manual for further
information.
system CDB $QUEST7_ROOT/nin/cdb.nin
Correct the OracleLogin entry in the

[Database] section so it specifies the
system account with its new password,
<system user name>/<system
password>
[Database]
...
OracleLogin=system/manager
QES, QCHANNEL $QUEST7_ROOT/nin/qes.nin and
$QUEST7_ROOT/nin/qchannel.nin
Correct the passwd entry in the [Oracle]

section so it specifies the system
account with its new password, <system
user name>/<system password>
[Oracle]
...
oracle_login=system/manager


system Fraud Server $QUEST7_ROOT/nin/qfds.nin
Correct the Oracle_sys_password entry

in the [DBconnection] section so it
specifies the new password:
[DBconnection]
...
Oracle_sys_user=system
Oracle_sys_password=manager
Security $QUEST7_ROOT/nin/security.nin
Correct the OracleSystemPassword

entry in the [Oracle] section so that it
specifies the new password:
[Oracle]
...
Password=manager

2.5 PostgreSQL User Administration
Postgres user administration is partly Postgres security administration, and
partly user administration:

● PostgreSQL System/Administration users
Password changes and details for eoLive and eoFinderBrowse servers are
described in eoLive Installation and Configuration Manual and eoFinder
Browse Server Installation and Administration Manual respectively.
Changing password Passwords of PostgreSQL accounts can be changed using the following
procedure.
For the system account, i.e. postgres:
Logon as postgres and execute the command:
> psql
ALTER USER postgres WITH PASSWORD '<new password>';
For other MasterClaw accounts:
Logon as mclaw and execute the command providing the user the password
when requested:
> psql –U <masterclawdb account>
ALTER USER <masterclawdb account> WITH PASSWORD '<new
password>';
If you change the password for a PostgreSQL account that is used by a

For further information, see Common ULP Installation Manual – PostgreSQL
section.
Password Expiration Passwords of PostgreSQL accounts don’t expire by default. This behavior
Time can be changed with the following procedure.
● For the system account, i.e. postgres, logon as postgres and execute:
> psql
ALTER ROLE postgres VALID UNTIL '<timestamp’>';
Where timestamp can assume one of the following structures:
-1999-01-08 04:05:06
-1999-01-08 04:05:06 -8:00 (with timezone)
● For other MasterClaw accounts, logon as mclaw and execute the below
command, providing the user with the password when requested:
ALTER USER <masterclawdb account> VALID UNTIL
'<timestamp’>';

This option can be used also when changing the password for both system
and MC application accounts. E.g.:
ALTER USER <masterclawdb account> WITH PASSWORD '<new
password>' VALID UNTIL '<timestamp’>';
Administrator The PostgreSQL administrator user postgres is available on the

PostgreSQL server used by eoLive/eoFinderBrowse. The password can be
changed.
The default password is: postgres..
● eoFinderBrowse server
● eoLive
● cdb
● qdash
● qalarms
● security
● portal
● qfds
Refer to the above mentioned documentation for further information.
Applications eoLive
PostgreSQL user eolive is available on the PostgreSQL server used by
eoLive. The password can be changed.
The default password is: eolive
eoLive application.
eoFinderBrowse
PostgreSQL user eofb_user is available on the PostgreSQL server used
by eoFinderBrowse. The password can be changed.
The default password is: eofb_pass
eoFinderBrowse application.
CDB
PostgreSQLuser cdb is available on the PostgreSQL server used by cdb.
The password can be changed.
The default password is: cdb
cdb application.
Refer to the specific application’s documentation for further info.

SECURITY
PostgreSQL user mclawsecurity is available on the PostgreSQL server
used by security. Its password can be changed.
The default password is: testtest
security application.
Refer to the specific application’s documentation for further information.
QDASH
PostgreSQL user qdash is available on the PostgreSQL server used by
qdash. Its password can be changed.
The default password is: qdash
qdash application.
QALARMS
PostgreSQL user event is available on the PostgreSQL server used by
qevent. Its password can be changed.
The default password is: event
qes application.
QFDS
PostgreSQL user qfd is available on the PostgreSQL server used by qfds.
Its password can be changed.
The default password is: qfd
qfds application.

2.6 Rainstor User Administration

Rainstor user administration is partly Rainstor security administration, and
partly user administration:
● Rainstor System/Administration users
Password changes and details for eoFinderBrowse server is described in

eoFinder Browse Server Installation and Administration Manual.
Changing password Passwords of Rainstor accounts can be changed using the following
procedure.
Logon as mclaw and execute the below command, providing the user with the
password when requested:
> npa_admin -U<admin_username> -P<admin_password>

change_password <username>, <old password>, <new
password>
quit
If you change the password for a Rainstor account that is used by a
Administrator The Rainstor administrator user (admin) is available on the DB used by

eoFinderBrowse server and loader.
The default password is: elmi..
● eoFinderBrowse server
● eoFinderBrowse loader
Refer to the above mentioned documentation for further information.
Applications eoFinderBrowse
Rainstor user eofb_user is available in Rainstor DB.
The default password is: eofb_pass
eoFinderBrowse Server and eoFinder Browse Loader applications.

2.7 Vertica User Administration
Vertica user administration is partly security administration, and partly user
administration:
● System/Administration users
Changing password Passwords of Vertica accounts can be changed using the following
procedure.
Logon as dbadmin and execute the below command, providing the user
with the password when requested:
> vsql -U<admin_username> -w<admin_password>
ALTER USER <admin_username> IDENTIFIED BY

'<admin_password>';
>\q
If you change the password for a Vertica account that is used by a
Note: dbadmin user can change any user's password; non-dbadmin users
can alter only their own passwords.
Administrator The Vertica administrator user (dbadmin) is available on the DB used by

DWH-NDAF.
The default password is: dbadmin..
DWH-NDAF applications.
You must also update /root/tools/Vertica/scripts/
vertica_admin.sh by changing the line as follows:
DBA_PWD="<admin_password>"
Applications For DWH-NDAF, see in table below the Vertica users for the applications
concerned:
DWH User Password

eoipdwh ipdwh ipdwh..
eoiupsdwh iupsdwh iupsdwh..
eoltedwh ltedwh ltedwh..
eosignindwh (aka eogiu_url dwh) giurldwh giurldwh..
eoiucsdwh iucsdwh iucsdwh..
Notes:* Intended as Special Customer Release (for customers who request it)

DWH User Password

eongndwh * ngndwh ngndwh..
Notes:* Intended as Special Customer Release (for customers who request it)
The passwords can be changed.

different DWH-NDAF applications (IP DWH, LTE DWH….) and BO.

2.8 User Administration of Other
Applications
2.8.1 MySQL
The MySQL RDBMS is used by the Master Claw Self Monitoring application
to store Nagios configuration and performance data.
Listing Users To get the list of users, execute:

> mysql -u root
mysql> SELECT User, Host, Password FROM mysql.user;
The output may look like this:

+------+--------------------+----------+
| User | Host | Password |
+------+--------------------+----------+
| root | localhost | |
| root | myhost.example.com | |
| root | 127.0.0.1 | |
| root | ::1 | |
| | localhost | |
| | myhost.example.com | |
+------+--------------------+----------+
where:
● Lines without password indicates that the account does require a
password when logging in from the specified host.
● Lines without user indicates anonymous users.
Changing Password The password of MySQL accounts can be changed using the following
procedure:
For root account:

Logon as root and execute the command:
> mysql -u root
mysql> UPDATE mysql.user SET Password =
PASSWORD('newpwd')
-> WHERE User = 'root';
mysql> FLUSH PRIVILEGES;
If the password has already been set, then the following command can be
used:

> mysql -u root -p

Enter password: (enter root password here)
PASSWORD('newpwd')
-> WHERE User = 'root';
For MasterClaw accounts:

Logon as root and execute the command:
> mysql -u root -p
PASSWORD('newpwd')
-> WHERE User = '<user name>';
Administrator The MySQL administrator user root is available on the MySQL server used
by SelfMon. The password can be changed.
By default, the password is not required when accessing the DB from
localhost or Self Monitoring server. In other circumstances, mysql cannot
be accessed with the root account.
Anonymous Accounts Anonymous accounts can be removed with a command such as:
> mysql -u root -p
mysql> DROP USER ''@'localhost';
mysql> DROP USER ''@'host_name';
Self Monitoring The MySQL user nagios is available on the DB server used by Self
Application Monitoring. Its password cannot be changed.
The default password is: nagios
2.8.2 Portal
The MasterClaw portal is delivered by default with the two system
administrative users listed below, along with their default passwords:
User Password
mclaw mclaw..
root elmi..
Table 2.4 Portal users

2.8.3 BO
Business Objects has its own administration console accessible from a web
browser. BO user is not needed for the normal administration of the system,
and user and passwords cannot be changed – hence, such information are
not in the scope of this document.
BO has also some default internal end user:
● AdminRD
● AdminPS
They can create/delete/update/refresh reports.

BO has also other default internal user:
● Guest (disabled)
● SMAdmin (disabled)
● QaaWSServletPrincipal (who can generate the web service
definition (wsdl))
Should you need further clarification, please contact Anritsu R&D.
2.8.4 Self Monitoring

The Self Monitoring application has by default the nagiosadmin user to
administer Self Monitoring. Its password can be changed.
The default password is: admin
Refer to Self Monitoring Installation and Configuration Manual for further
information.
2.8.5 SNMP
SNMP protocol can be secured by the following actions:
● Changing default community strings
● Disabling the not needed SNMP services
● Adding an access firewall to the MC network perimeter
● Configuring SNMP agent to accept connection for specific hosts
● Using SNMP v3 where available.
Change default community strings: public and private. It is recommended to

use strings that follow the password policies.
The below products require the MC SelfMon configuration to be updated.
● Procurve switches
● Extreme switches
● Hp blades (OAM)

● Timeservers
Please refer to external product documentation for non-MC products (e.g.

switches).
LANTIME M300/GPS If SNMP has been enabled for LANTIME M300/GPS NTP Server, then you
NTP Server should follow the instructions provided in Probe Installation and
Configuration Guide, in order to:
● Change default read and read-write community strings.
● Disable not needed SNMP services.
E.g. by removing read-write community string if the device configuration
will be performed without SNMP
● Add an access firewall to the MC network perimeter.
● Configure SNMP agent to accept connection for specific hosts.
2.8.6 Timeserver
LANTIME M300 GPRS timeserver is an NTP timeserver integrating a GPS
radio clock running a simplified Linux OS.
Disable “console” It is possible to disable the front panel of the timeserver. Its configuration can
always be done using https or ssh.
More instructions are provided in Probe Installation and Configuration
Guide.
root The root account is the Linux administrator.

Default password is: timeserver.
It is possible to change the password by following the instructions from
Probe Installation and Configuration Guide.
2.8.7 SAS Storage

SAS storage has their own administration web interface (http).
The default administrator is: manage
The default password is: !manage
2.8.8 Onboard Administrator

BladeSystem offers a web interface called "HP BladeSystem Onboard
Administrator" (OA). It uses the http protocol.
The default administrator is: Administrator
The default password is written on the tag bound to the OA/iLO card.

3
Self Surveillance

Self Surveillance
3.1 MasterClaw Software

Components Monitoring
MasterClaw has a facility named MasterClaw Software Components
Monitoring –abbreviated QMON in the following– that provides monitoring of
essential services of a MasterClaw system. QMON consists of a front-end
command called qmon and a daemon named qmond. Use the qmon
command to interface to the daemon.
In this part of the MasterClaw documentation, the term ’software component’
is any software that must run continuously in a MasterClaw system. Typically
the monitored components are the MasterClaw services, for instance the
name service (QNSS) and the configuration service (CDB).
It is assumed that QMON has sufficient access privileges to start and stop the
services it monitors. The account used to install QMON becomes the owner
of the QMON package files and data directories and can subsequently
configure and run the QMON daemon. Suppose the (Linux/Unix) superuser
(aka root) installs the QMON package, then the superuser is the only person
allowed to configure and start and stop the QMON daemon. Likewise, if
QMON is installed by an ordinary user, then this particular user is granted full
permission to configure and start and stop QMON.
Note: All users are allowed to view the status of the monitored components.
The QMON daemon periodically tries to contact the monitored software
components. If a component does not respond to inquiries posed by qmond,
the monitored component is assumed to be malfunctioning, and qmond will
attempt to restart it. If for some reason, a component cannot be started, then
QMON eventually gives up and considers the component buggy. The system
administrator can set up QMON to work in DUMMY mode. When in DUMMY
mode, QMON will monitor and check the status of the monitored component,
but it will not attempt to restart them if they become faulty. Use the -d option
to define the run modus of the daemon. It is possible to change the run modus
while the daemon is running. When not running in DUMMY mode, the
daemon is said to work in normal mode.
When the daemon runs in normal mode, it monitors and (re)starts services
automatically in case they stop or become unresponsive. However, the
daemon only tries to start a service five times, and if a service does note start
after five attempts, the service ends up in CANNOT_START or BUGGY
mode. In certain cases, in particular when QMON is applied in a distributed
MasterClaw system, it may happen that five attempts in not enough. Thus for
QMON installations in distributed environments, i.e., when the MasterClaw
services (software) is installed on disparate hosts, the daemon can be
configured to run in tenacious mode. When the daemon is in tenacious mode,
it will (tenaciously) try to (re)start services.
Note: QMON logs each start attempt in the host's system log and in the
MasterClaw alarm/event system (if external logging is enabled), so
QMON may end up generating many events when set to run in
tenacious mode.
QMON monitors and starts services on one machine, but additionally multiple
QMON instances running on disparate host machines can share status
information over the network. This allows the MasterClaw system
administrator to get a quick overview of MasterClaw services spread across

multiple machines. The QMON daemon employs a state machine for every
monitored components. These are the states of the state machine:
● UNSET
● NOT_RUNNING
● RUNNING
● AVAILABLE
● UNRESPONSIVE
● TO_BE_RESTARTED
● RESTARTED
● CANNOT_START
● BUGGY
The states have the following meaning:
UNSET Initial state of each component. It means that QMON has no knowledge of the
component's state.
NOT_RUNNING This state signals that the component has no running process(es) in the Unix
system. This is not necessarily an error; it may be that the component has not
been started yet.
RUNNING This state denotes that the expected Unix processes are running on the
system. However, it does not necessarily mean that all is well, because a
component may be in a state where it does not respond to client requests, or
it may be deadlocked, or something else.
AVAILABLE This state follows state RUNNING, and it implies the same as RUNNING, and
in addition, it adds the constraint that the service must be responsive to client
requests (if applicable). All monitored processes should be in state
AVAILABLE during operation.
UNRESPONSIVE This state is the logical counterpart to AVAILABLE. UNRESPONSIVE means

the component does not behave as expected although it appears to be
running. QMON will restart an unresponsive component.
TO_BE_RESTARTED This state is used to signal that the component was previously in state
UNRESPONSIVE, and that the component is subject to restart.
RESTARTED This is the state that follows from a successful restart. It does not signal that
the component is again AVAILABLE, but merely that the expected set of Unix
processes are running.
CANNOT_START This state indicates that it is not possible to start a component.

CANNOT_START means that administrator intervention is necessary. When
QMON is in normal mode, it will not attempt to start a service in state
CANNOT_START. However, when QMON is in tenacious mode, it will never
put a service in state CANNOT_START but rather try to (re)start the service
again and again.
BUGGY This state indicates that although it seems possible to start a component, the
component never seems to enter state AVAILABLE. This state indicates that
administrator intervention is necessary. When QMON is in normal mode, it
will not attempt to start a BUGGY service; however, when QMON is in

Self Surveillance
tenacious mode, it will never put a service in the BUGGY state but rather try
to (re)start the service again and again.
Assuming the QMON daemon runs on well-configured systems, the state
machine for each monitored component will undergo the following state
transitions:
UNSET --> RUNNING --> AVAILABLE
All component checks and actions to start an stop are time delimited to avoid
hanging the QMON daemon. QMON increases the amount of time that a
component is allowed to:
● start and stop
● to respond to the availability checks
When a component does not respond in time, i.e., when the permitted
duration expires, QMON increases the permissible duration, but only up to a
pre-defined upper limit of five minutes. QMON increases the timeout to
account for unpredictable factors such as machine load and system
dependent start/stop time.
If QMON cannot (re)start a component within the maximum permitted start
time, then the component is considered BUGGY.
The QMON daemon is disconnected from the components it monitors; the
daemon uses action scripts to interface with the monitored components. An
action script is usually a shell script, but it can be anything that can execute
on the host machine, e.g., an action script can be written in C or Python. An
action script must provide the following four actions:
● start start the component
● stop stop the component
● check check quickly that the component is running
● rcheck check rigidly that the component is running and responding
There are two check actions, check and rcheck;

● check should be quick and light on CPU and system resources, for
instance a ps command to check a certain process is running
● rcheck should check thoroughly that the component does in fact work as
expected, for example, if the component can be reached through its
CORBA reference in the MasterClaw name service.
QMON provides some ready-to-use action scripts for the core MasterClaw
services, but you can copy and modify the scripts if you want to. You can also
write your own action script from scratch if you want to periodically execute
some check, for instance to monitor available disk resources. Some
MasterClaw components come with their own action scripts. You can use the
qmon list -l command to get a list of the monitored components and the
actions used.

3.1.1 Synopsis
The qmon command is used in different contexts, see below:
$QUEST7_ROOT/bin/qmon{ start | stop | status ] }
$QUEST7_ROOT/bin/qmon config [ -c cycle time ]
[ -r rigid cycles ]
[ -v verbose level ]
[ -d debug mode flag ]
[ -p port number ]
[ -x max timeout ]
[ -k check timeout ]
[ -s start timeout ]
[ -e external logging flag ]
[ -t tenacious mode flag ]
$QUEST7_ROOT/bin/qmon{ add | rm } [ -h ]
{ -a | component... | host ... }
$QUEST7_ROOT/bin/qmon list[ -l ]
$QUEST7_ROOT/bin/qmon{ restart | ping }
Use the first synopsis to start, stop or obtain status of the monitoring daemon.
Not all users are allowed to start or stop the daemon, but all users are allowed
to view status information.
Use the second synopsis to configure the QMON daemon. Refer to
Section 3.1.2 Options for information on timing parameters.
Use the third synopsis to add to and remove from the set of monitored
services, respectively. You can specify the list to add or delete, or use the
-a option to denote all components currently known by QMON.
Use the fourth synopsis to view the list of monitored processes.
Use the fifth synopsis to display all the components installed on the specific
machine that can be monitored with qmon.
Use the sixth synopsis to reset or wake up the QMON daemon. The
subcommand restart is semantically the same as stop followed by
start. The subcommand ping wakes up the daemon as if a new cycle had
just begun.
It is permitted to configure QMON daemon both when it is stopped or running.
Any changes will take affect when the QMON daemon is started or when
commencing its next cycle.
3.1.2 Options
-d A logical flag; 0 means FALSE, 1 means TRUE, that determines whether the
daemon runs in normal or dummy mode. In normal mode (FLAG equal to
zero), QMON will try to restart faulty components, but in dummy mode (FLAG
equal to 1) automatic restart does not take place. The default value is 0
(FALSE).

Self Surveillance
-a This option denotes ‘all’, used with the subcommands add and rm.
-c Number of seconds between iterations of the QMON daemon. A small delay

provides more current status information but puts a higher load on the host
machine. The default value is 30 seconds.
-r Number of cycles between rigid checks of the monitored components. Keep

in mind that a rigid check is more resource intensive than is a standard check.
The lower the value, the more accurate state information, but the more load
on the machine. Note that setting the value to 1 effectively removes the
distinction between a standard check and a rigid check; this is not
recommended. The default value is 10.
-v Set verbosity level by specifying an integer value, 0 (zero) or 1 (one). A value

of zero disables all logging, while one provides detailed view of the QMON
daemon. The verbosity range may be extended in future versions, and it is
recommended to only specify zero or one. The default value is 0 (zero).
-p Specify the TCP port number used for communicating per-host QMON status
information between multiple QMON daemon instances where each QMON
instance runs on its own host machine. This port defaults to port number
5899, but can be changed in case this number collides with other services.
Note that -p has a dual purpose: (1) it specifies the TCP port used by the
daemon to provide status information to other QMON instances, you set this
port with the config -p <port> sub-command; (2) it specifies the TCP port
used by the daemon to retrieve status information from another QMON
instance, you set this port with the sub-command add -h -p <port>. Be
aware that you must be the superuser (aka. root) to listen to a port number
below 1024. The default value for both purposes is 5899, and it is
recommended that you do not set the port number unless it is necessary.
-x The maximum timeout in seconds when invoking an action script. This value
should be larger than or equal to both the check timeout (see -k option) and
the start and stop timeout (see -s option). The default value is 300 seconds.
-k The default timeout in seconds when invoking an action script's check or

rcheck method. This value should be lower or equal to the maximum timeout
(see -x option). The default value is 30 seconds. This option defines the
aggressiveness of QMON. A low value enables QMON to detect quickly
whether a service is not responding, but it also opens up the possibility that
the service is merely not given sufficient time to respond, in particular if the
host machine is heavily loaded. A high value enhances correctness, but
results in a higher re-start time for an unresponsive service.
-s The default timeout in seconds when invoking an action script's start or stop
method. The default value is 120 seconds.
-l Provides more details for the list and find commands. The additional
information for local components is the full path of the action script, while the
additional information for remote QMON instances is the TCP port number
used to connect to the remote QMON daemon to get status information.
-e Specify either 0 (zero) or 1 (one) as value. Specify 0 to disable and 1 to enable

external logging. QMON logs daemon start, service start, and service stop
when external logging is enabled. External logging is done via the so-called
QSA_EVENT_IF, and the events can be seen with either TeMIP or the

MasterClaw QALARM application. Note that external logging is a
supplement, disabling external logging does not disable QMON logging
altogether.
-t Specify either 0 (zero) or 1 (one) as value. Specify 0 to disable and 1 to enable

tenacious mode. When QMON runs in tenacious mode, then the daemon will
try to (re)start services again and again. Tenacious mode is only relevant
when QMON is not in DUMMY mode.
3.1.3 Operands
Referring to the third synopsis in Section 3.1.1 Synopsis, the operands are
either the locally monitored components or the names (or IP addresses of the
remote host) to add or delete, respectively. For instance the following will add
the name service (qnss), the statistics service (qsts), and the statistics
loader (qstldr) to the set of monitored components:
qmon add qnss qsts qstldr
Action scripts QMON uses component-specific action scripts to determine the status of
software components. These scripts are named qmon-<sub component
name>.
The sub component name could be:
● qbase Package name. E.g. cdb
● name of a sub component included in a multicomponent package. E.g.
qes included in the qalarms package.
Each MC server should have one qmon script.
QMON is supplied with a variety of action scripts templates; the scripts are
stored in $QUEST7_ROOT/installed/qmon/lib/sbin. You can list the available
action scripts:
# ls $QUEST7_ROOT/installed/qmon/lib/sbin/qmon-*
/opt/anritsu/mclaw/installed/qmon/lib/sbin/qmon-cdb
/opt/anritsu/mclaw/installed/qmon/lib/sbin/qmon-qnss
/opt/anritsu/mclaw/installed/qmon/lib/sbin/qmon-qpecs
/opt/anritsu/mclaw/installed/qmon/lib/sbin/qmon-qps
/opt/anritsu/mclaw/installed/qmon/lib/sbin/qmon-temip-
register
You can customize an action script by copying it to a pre-defined directory,
while some MasterClaw components come with ready-to-use action scripts.
QMON searches for action scripts in a number of directories in the following
sequence:
1. $QUEST7_ROOT/qmon/data/qmon/<hostname>/sbin/
2. $QUEST7_ROOT/installed/<component>/rc.d/
3. $QUEST7_ROOT/installed/qmon/lib/sbin/

Self Surveillance
The script in 1 is customized, the one in 2 is supplied by the application

programmer of the component, while 3 is the QMON supplied. QMON uses
one of the action scripts above at any one time.
For a service named cdb running on host modi, QMON searches for the
following set of action scripts:
1.$QUEST7_ROOT/qmon/data/qmon/modi/sbin/qmon-cdb
2.$QUEST7_ROOT/installed/cdb/rc.d/qmon-cdb
3.$QUEST7_ROOT/installed/qmon/lib/sbin/qmon-cdb
Regardless of location, an action script must be executable for the user

running QMON, and if not, the action script is silently disregarded, even when
the script is readable.
You can write your own action script if you want to monitor a component that
is not already included; the easiest is to copy an existing script to the
(customisable) sbin directory (see 1. above). You must follow the naming
convention that QMON expects, i.e., you must include the ‘qmon-’ prefix in
the action script file name. When QMON invokes an action script, QMON
supplies the action as the first argument to the script ($1). Your script must
implement four actions:
● start
● stop
● check
● rcheck
The start and stop actions should start and stop the component, respectively.
The check action should execute quickly and consume only little CPU
resources, because check is the most frequently invoked action. The most
rigid check should lie with the rcheck action, which should guarantee that the
monitored component is up and running and, if applicable, responding to
’client’ requests. It is legal for the check and rcheck actions to be identical. All
four actions must be synchronous, i.e., they return when the action is
complete.
An action script informs the QMON monitor whether an action succeeded by
its return value. A action script’s return value must obey the simple rule:
● Return value is zero (0) if the action succeeded, or
● Return value is non-zero if the action failed
Note: If you write your own action script or modify an existing one, it is
important that you adhere to the rule.
If you do not, the QMON daemon will make wrong decisions and
possibly impede your software component. For instance if your start
action’s exit code is non-zero, the QMON daemon will kill any
processes started by your action script and will try to invoke the start
action again or give up after a number of attempts. Thus, if the start
action was in fact successful, but failed to return zero, the daemon will
kill your processes.
Here is shown an excerpt of the qmon-tns action script:

NOTICE=daemon.notice

CMD=$1
export QUEST7_ROOT=${QUEST7_ROOT:-/opt/anritsu/mclaw}
case $CMD in
start)
/sbin/init.d/tns_server start
status=$?
if (( status == 0 )) then
logger -p $NOTICE -t `basename $0` "tns_server

started"
fi
exit $status
;;
stop)
/sbin/init.d/tns_server stop
status=$?
logger -p $NOTICE -t `basename $0` "tns_server

stopped"
exit $status
;;
check|rcheck)
# Okay if process /usr/sbin/tns_server is owned by

root
ps -u root -o cmd | grep -q ^/usr/sbin/tns_server 2>/

dev/null
;;
*)

Self Surveillance
echo "usage: $0 start|stop|check|rcheck"
;;
esac
You should check that your action script works by invoking it manually.
Remember to try all four actions, and check that the return value is correct.
When it is working, tell QMON about it with the command:
qmon add component
Your component will be monitored starting from the next periodic check.
3.1.4 Optimization (Optional)

A typical action script's check method executes a pipeline that includes the
ps(1) and grep(1) commands. The purpose of the ps command is to get
a list of processes while the grep command finds the process(es) behind the
service. The execution of the ps command can be resource and time
consuming, in particular on RedHat Linux 7.2. When QMON wakes up and
begins to check service availability, QMON executes a ps command and
stores the output in a file (the process list file); then QMON invokes the action
scripts check and rcheck methods and supplies the name of the file
containing the ps output as the second argument (to the action script).
QMON does not supply this filename when invoking an action script's start
or stop methods.
The process list file has the following structure:
PID CMD
1 init
2 [keventd]
3 [ksoftirqd_CPU0]
4 [ksoftirqd_CPU1]
...
19063 /usr/mq01/installed/qxts/lib/qxts -c /usr/mq01/

data/qxts/corr.def
19064 /usr/mq01/installed/qxts/lib/qxts -c /usr/mq01/

data/qxts/corr.def
...
9472 ./qmond /usr/mq01
Each line contains the process identifier (PID) followed by a space character
and then follows the service invocation command line. The action scripts that

are supplied with QMON avoid executing the ps command but do the grep
directly on the process list file, as follows:
...
QBASE_NAME=qes
PLF=$2
...
function do_check
{
if (( ${#PLF} > 0 )) then
grep -E -- "-[D]quest7.cid=${QUEST7_ROOT}-
${QBASE_NAME} " \
$PLF >/dev/null
else
ps auxww | grep -- \
"-[D]quest7.root=${QUEST7_ROOT}
.*QEventService" \
2>&1 >/dev/null
fi
}
Note: The older action scripts remain compatible with this version of QMON,
but when writing action scripts on RedHat Linux 7.2, you are
encouraged to write action scripts that work directly on the process list
file.
3.1.5 Viewing Status of Components

You can type qmon status to get an overview of the monitored components:
# qmon status
qmond is running.
You can also use Netscape (or another HTML capable browser) to study a
periodically updated status view by typing the command:
netscape file:$QUEST7_ROOT/data/qmon/$HOSTNAME/
index.html
TIP If you are running a Web server on your system, you can set up your
web server so that it becomes possible to browse the status of the monitored
services from machines on your network. Set up your server so that it allows
HTTP access to the directory $QUEST7_ROOT/data/qmon/$HOSTNAME.

Self Surveillance
3.1.6 Sharing QMON Status Information

If you have a MasterClaw system consisting of more than one host machine,
you can run an instance of QMON on each host and configure the individual
QMON instances to share the status information. More precisely a QMON
daemon provides:
● An interface through which other QMON instances can retrieve status
information from the first daemon;
● The QMON daemon can query one or more remote hosts for the status
information pertaining to the remote host(s).
The information sharing is best compared with an automated execution of the

qmon status command on each of the hosts, collected and made available on
the machine on which you type the qmon status command. This relieves you
from doing remote logins to get information on service availability.
The present version of QMON only allows you to monitor status information
across multiple hosts; you cannot start and stop or configure QMON
instances from one host machine. It is necessary to log on to individual
machines to configure and start each of the QMON instances. The following
example shows a simple configuration. Suppose you are running the
MasterClaw name service (QNSS) on host modi and the configuration
database service (CDB) on host skade, and suppose you want to be able to
monitor the status of both services from both machines, then one way of
doing it is to execute the following steps.
1. Log in to host modi and configure QMON to monitor QNSS on the local
host and to obtain status information from host skade. The following
example assumes the two machines know one another's host names, but
you can also use the IP address if you want to.
qmon add qnss
qmon add -h skade
qmon start
2. Log in to host skade and configure QMON to monitor CDB on the local
host and to obtain status information from host modi.
qmon add cdb
qmon add -h modi
qmon start
3. You can now view the status information on either of the machines, in this
case from skade.
qmon status
qmond is running.
COMPONENT STATE
-------------------- --------------------
cdb Available
modi:
qnss Available
4. Suppose you are logged in to skade and the QMON daemon on modi
cannot be reached, then QMON silently ignores the unreachable host
and displays (only) information that is current, in this case information for
the local host (skade).

qmon status
qmond is running.
COMPONENT STATE
-------------------- --------------------
cdb Available
Whenever the QMON instance on skade can reach the QMON instance on
modi, then the status information is included in the status report, but if (say)
the QMON daemon on modi cannot reach the QMON daemon on skade, the
QMON daemon on modi silently excludes the status information from skade.
5. To configure QMON on skade and to not obtain status information from
modi, use the remove subcommand.
qmon list
cdb
host: modi 5899
qmon rm -h modi
qmon list
cdb
3.1.7 QMON TCP Port Number

The QMON daemon uses TCP port number 5899 by default to listen for
status requests from other (remote) QMON daemons but you can assign a
different port number if the default port number collides with other processes.
1. To use a different (server) port, use the -p option to configure command:
qmon config -p 9999
2. You must restart QMON for the change to take effect:
qmon stop
qmon start
Note: You cannot use qmon restart for the port change to take effect.
You must use the -p option with the add sub-command, if the remote
QMON daemon has been configured to listen to a port number
different from the default port number.
3. To configure QMON to retrieve status information from host modi on
(client) port number 23456, use the add sub-command with the -p
option.
qmon add -h -p 23456 modi

Self Surveillance
4. To change the port number, you must first remove the entry, then add it
again with the new port number.
qmon rm -h modi
qmon add -h -p 65432 modi
3.1.8 QBASE Integration

QMON and QBASE are not fully integrated. For information on QMON usage
in a clustered MasterClaw installation, refer to the next section. For standard
(non-clustered) installations, the following guidelines may be a help.
It is advisable to add the set of services to the set of components monitored
by QMON, and then let QMON start the components. This approach provides
an easy way to both start and monitor the components. However, since
QMON will restart a component, if it becomes unavailable, it is not possible
to use the QBASE q7adm to stop the component. If it is necessary to stop
components, or to stop the MasterClaw system altogether, then basically
there are three ways:
● Stop QMON first and then use the standard QBASE commands or user
provided scripts to stop the components in question. When it becomes
time to start the MasterClaw system again, then it is enough to start the
QMON daemon.
● Leave the QMON daemon running and remove the component(s) in
question from the list of surveyed components, using the QMON remove
(rm) subcommand (see Section 3.1.1 Synopsis on page 3-5). Upon
completion, add the component(s) again using the QMON add
subcommand.
● Put QMON in DUMMY mode and leave it running; once the system is up
and running again, you can put QMON back into full mode.
It is recommended that you stop QMON during maintenance, and restart

QMON when going into production.
3.1.9 Files
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.cfg
This file determines the current configuration of QMON, i.e., what processes
to monitor and the timing specifics.
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.state
ASCII file that lists the states of monitored services. The format used is
straightforward:
proc1 proc1-state
proc2 proc2-state
This file is only updated when at least one service changes state.
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.state.html

This file contains the same information as qmond.state but in HTML format,
suitable for displaying in Netscape. The HTML file is set up to automatically
refresh depending on the cycle time; in this way you can use your browser as
a simple graphical user interface to QMON.
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.stderr
This file contains whatever the QMON daemon and its spawned action scripts
print on standard error.
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.stdout
This file contains whatever the QMON daemon and its spawned action scripts
print on standard output. This is the file to examine when the verbosity level
is above zero.
/var/log/messages
The QMON daemon logs when it stops and start a monitored component.
(You must be root to read this file). Note that you can use the grep
command (as root) to find all log entries pertaining to QMON.
grep qmon /var/log/messages
$QUEST7_ROOT/data/qmon/$HOSTNAME/qmond.ps-list
This file contains the process identifiers (PIDs) and command line invocations
of the processes on the host machine. QMON builds this file when it wakes
up to check service availability.
$QUEST7_ROOT/data/qmon/$HOSTNAME/event.log
This file contains QMON log entries: which services were up and down, and
which were started, re-started, or stopped. The reason for having this file is
that non-root users cannot read the system log on Linux.
3.1.10 Further Information

For most up-to-date information refer to the QMON manual, which you can
read by issuing the command:
qmon man
Ensure that the version of QMON is consistent with the MasterClaw system.
Only one instance of the QMON daemon can run at any one time (using the
same QUEST7_ROOT).
Only the superuser and the person that installed QMON is permitted to start
and stop the QMON daemon.
If QMON cannot (re)start a component within the maximum permitted start
time, then the component is considered BUGGY, even if it is not.

Self Surveillance
3.2 Hardware Server Surveillance

Surveillance of the Hardware Servers can be performed with HP Integrated
Lights-Outs.
3.2.1 Integrated Lights-Outs (ILO)

ILO stands for Integrated Lights-Out version 2, 3 and 4. ILO is provided via a
separate adapter with a designated network interface. ILO must be
configured during server installation so that it is possible to connect to the ILO
adapter. It is possible to access ILO through a browser or via telnet or SSH,
depending how it is set up.
ILO provides the following functionality:
● Overview/Summary information, including:
— Server name
— Serial number
— System ROM version information
— Overall system health (OK, not OK)
— Server power (OK, not OK), and the ability to turn the power on/off,
— ILO firmware version
— ILO IP address
— and more
Turn server power on and off (by pushing a button in the Status Summary /
Overview/ page on the bottom bar).
● Overview of server health. ILO summarizes the condition of the
monitored subsystems including overall status and redundancy (ability to
handle a failure). The subsystems may include fans, temperature
sensors, power supplies, and Voltage Regulator Modules (VRMs).
— Fans. ILO shows the state of the replaceable fans within the server
chassis. This data includes the area that is cooled by each fan and
the current fan speeds.
— Temperatures. ILO shows the conditions monitored at temperature
sensors at various locations in the server chassis. The temperature
is monitored to maintain the location temperature below the caution
threshold.
If the temperature exceeds the caution threshold, the fan speed is
increased to maximum.
If the temperature exceeds the critical temperature, a graceful server
shutdown is attempted.
If the temperature exceeds the fatal threshold, the server is
immediately turned off to prevent permanent damage.
— Power. ILO shows the present power reading. This value shows the
most recent power reading from the server and at what time the
reading was taken.
— VRMs. ILO shows the state of the VRMs. VRMs are required for each

processor in the system. They adjust the power to suit the needs of
the processor supported. A VRM can be replaced if it fails. A failed
VRM prevents the processor from being supported.
— Power Supplies. ILO shows the state of the power supplies:
OK indicates that the power supply is installed and operational
Unpowered indicates that the power supply is installed, but not
operational.
Not present indicates that the power supply is not installed. Power is
not redundant in this condition.
Failed indicates that the power supply should be replaced.
— Processors (CPUs). ILO shows which processor modules are in the
chassis:
CPU clock frequency.
Execution Technology: number of cores and threads (per core).
Memory Technology: do the CPUs support 64-bit addressing.
CPU Cache Information: Amount of CPU cache.
— Memory. ILO shows the server memory configuration:
The available DIMM slots.
The specification for installed memory modules, such as their size
and speed.
— Network Interface Cards (NICs). ILO shows the number of built-in
NICs, not any add-in network adapters. ILO also displays the MAC
address of each (built-in) NIC.
● ILO Log. The log provides information such as

— When was system power last removed/restored.
— Cautions such as unavailable network (for the ILO adapter).
— Who logged into ILO and when.
● Integrated Management Log. This log provides management log entries,

such as:
— When was system power last removed/restored.
— Hardware failures, such as a faulty power supply.
ILO's functionality can be extended by purchasing an extended license. This

provides a remote console service, which grants access to the system
console remotely.
For further description of ILO, please refer to HP documentation.

Self Surveillance
3.3 Session Audit
3.3.1 Introduction
The Session Audit application is an administrative tool which enables
administrators to browse, monitor and terminate application sessions. Large
complex systems such as MasterClaw shall be protected by improper use of
the system resources that may block important work and prevent other users
from performing critical tasks. from a user perspective, the most critical
resources in a MasterClaw system is fast access to probe data: every probe
allows a limited number of sessions to browse its internal data storage, e.g.,
the eoFinder Inspect application needs a single Event-Log browser in every
probe monitored by the user, while the eoFinder Trace application needs two
or more CSDR-log browsers in every probe included in a trace.
The probes will reject browse requests, if the concurrent number of browsers
exceeds the maximum number of allowed sessions (see Table 3.1). The
MasterClaw application will detect the shortage of browser resources and
either queue the request or inform the user to try later.
Service user Max Number of

Probe Service
Application Sessions
Main services Probe monitor 1
Surveillance services Alarm server 1
PA services (aka Event-log Protocol Analysis/ 64
browsing) eoFinder inspect
CSDR services (aka CSDR-log qxts/eoFinder, 64
browsing) qxdrs
ICSDR services (aka ICSDR-log qxts/eoFinder, 32
browsing) qxdrs
Update CSDR services infoservers 32
Statistical control services Traffic observer/ 10
eoLive
Statistical data services Traffic observer/ 10
eoLive
Table 3.1 Probe service limits
With the Audit web application, an administrator can get an overview of the
number of active application sessions. It is also possible to determine the
number of resources every session has reserved, and finally it is possible to
“kill” application session if the administrator has to free resources to be used
by others.
Limitation: The Session Audit application is not able to precisely correlate an
application session with specific browser instances in the Probes. The
Session Audit is only able to indicate the number of browsers indirectly by
presenting the number of Signalling Links or Linksets monitored by the
Session Manager. The rule is that if the resource count is high, it is very

probable that the Session Audit occupies many browser sessions in the
probes.
The application user will receive a message (as in Fig. 3.1) when a task or
complete session has been terminated (‘killed’) by the administrator.
Fig. 3.1 Application killed with data saving
When the user receives this message and clicks Save File or Close
Application, then the application terminates and the resources are
released: at this moment only, they can be used by others. This means that
when killing the session or application, some applications will allow the user
to save the data/configuration before the application/session is finally killed.
Until the application or session is killed, the session/application will be visible
in the list of active sessions/applications.
In this situation, the user can only save the work done and try again later.
In other applications, the session is instead killed immediately i.e. the user is
not allowed to save any data (Fig. 3.2):
Fig. 3.2 Application killed with no data saving
The Session Audit application consists of a server component Security with

a command line interface and a Portal component Audit. The Portal
component uses the Security component to perform the same tasks which
can be performed on the command line interface. The use of these two
components is described in the following sections.

Self Surveillance
3.3.2 Basic Operations of Security Administrative

Command Line
Starting the security The Security is started by the command:
# q7adm start security
Start up verification When the Security is started, a CORBA server is started.

It is possible to check the status of the server process by issuing the
command:
# securityadm status
If active, the server responds with:
Security Server is: RUNNING
Log files are available at the path $QUEST7_ROOT/log/security.

Logs are rotated at each startup.
Listing application It is possible to list the current application sessions by issuing the command:
sessions
# securityadm auditreport [exportToCsv=<CSV file
name>] [from <date> <time>] [to <date> <time>]
[component <comp1>,<comp2>...]
The output has the following structure:
<SESSION ID> <APPLICATION> <USER> <HOST> <REMOTE START
TIME> <LOCAL START TIME> <DURATION> <STATE> <# RES>
where:
SESSION ID; the session id related to this application
APPLICATION; the application name
USER; the user name currently running the application
HOST; the host name or the IP address of the host running the
application
REMOTE START TIME; the application start time (local to application
host)
LOCAL START TIME; the application start time (local to the server
running Security)
DURATION; the application running time
STATE; The application status (Alive/Terminating)
# RES; The total number of resources held/used by the session
Querying the server The list of available sessions can be queried based on criteria.
for sessions
To search session by application name issue the command:
# securityadmin auditreport component
<comp1>,<comp2>
where <compN> is the name of the application as listed in the
‘APPLICATION’ field of the session list.

Time Conditions
Time condition allows getting logs only for a specific time interval.
To search sessions in a specific time interval
# securityadm auditreport from <dd/MM/yy> <HH:mm> to
<dd/MM/yy> <HH:mm>
where <dd/mm/yy><hh:mm> is the date and time of the time period.
Filter Conditions
It is possible to specify a particular COMPONENT in order to get only log
records related to them. A filter condition may be used in addition to a time
condition.
Listing logs for a It is possible to list the current Activity Logging content for particular
specific component components by issuing:
# securityadm auditreport component component1,…,
componentN
where component1,…,componentN are the requested components to be
listed.
Example of combined conditions:

Search all the logs from 12 February 2015 08:00 for the components
"eoFinder" and "eoFinder.sdlt" :
securityadm auditreport from 12/02/15 08:00 filter
component=eoFinder,sdlt
Exporting logs on file It is possible to have the resulting logs exported on file rather than being
displayed on screen, by simply adding the option exportToCsv with the
output CSV file. All the above conditions are always valid.
Example: exporting all the logs from 12 February 2015 12:00 in CSV file
# securityadm auditreport exportToCsv=sample.csv from
12/02/15 08:00
Sending commands to It is possible to kill either an entire user session, application sessions or
applications application tasks using the following commands.
To kill a user session, type:
# securityadm kill session <session-token>
To kill an application session, type:

# securityadm kill application <application-token>
To kill an application task, type:

# securityadm kill task <task-token>

Self Surveillance
Stopping the security The security is stopped by the command:

# q7adm stop security
3.3.3 Over view of Activity Logging Entr y
The below table lists the structure of each message entry stored by the
Security audit.
Field name Description

ACTION The type of activity to log. For audit logs this is always
MESSAGE. Other types of activities (e.g.
SESSION_STARTED, SESSION_KILLED) are referred to
session lifecycle activities.
LOGTIME The time (UTC) when this entry has been stored
LOGLEVEL The severity of this entry.
Possible values are: LOW, MEDIUM, HIGH
COMPONENT The identifier used by the application logging the message
SOURCE_HOST The IP address of machine where running the logging
application
USERNAME The MasterClaw user using the logging application
MESSAGE The message logged by the application
Table 3.2 Overview of activity logging entry
Note: Each field except the LOGTIME field is set by the logging application,
thus their content is not generated by the Security server.
3.3.4 Description of Activity Logging Entr y Fields

LOGTIME Shows the time (UTC) related to the creation of this entry in Security Audit. It is
filled by Security itself.
LOGLEVEL Used to differentiate the importance of the logged message. The possible
values are:
● LOW: low importance
● MEDIUM: medium importance
● HIGH: high importance
Logging applications may want to use this field to allow a subsequent filtering
when generating reports. The default is HIGH.
COMPONENT Used as identifier of the logging application.

Logging applications set this field, and they are required to choose a
descriptive identifier and always use the same one.

SOURCE_HOST Used to store the IP address of the machine hosting the logging application.
Logging applications set this field, and they are required to use the right
address.
USERNAME Used to store the MasterClaw user name currently using the logging
application.
Applications set this field, and they are required to use the right user name.
MESSAGE Contains the logged message concerning the logging application activity.
There is not a policy for applications that states what should and should not
be logged. You should expect that an application logs events such as:
● Application start
● Application stop
● Application success
● Application failure
3.3.5 Operation of Session Management via Portal

All Session Management functionalities to browse, query and manage
current and past sessions are available through the MasterClaw Portal.
Please refer to the MasterClaw Portal Operator Manual for a detailed
description of the Session Management and Audit functionalities.

4
Security
Introduction This Chapter highlights what is relevant from a security point of view, and
describes the actions needed to enforce the security at Customer site.

Security
4.1 Introduction
Security plays a crucial role in the MasterClaw system, being MC integrated
with the Operators’ different networks, such as LAN/WAN network, office LAN
network and external networks (Internet etc.). Therefore, user authentication
and access to subscriber confidential data collected by the MC system has to
be controlled. Logging of user access is also important as well as encryption
of the data that is transported over the different networks.
As shown in Fig. 4.1, an MC system is composed of three layers:
● Presentation and reporting layer
It is related to clients on workstation:
— HTML Browser
— Java clients
● Data processing and business logic layer

It is composed of:
— MC Servers and applications
— Third party products fed by MC mediation server or by MC DB
● Data acquisition layer

It is composed of:
— Probes
— Third party data provider
For further details on MC security features and requirements for the

aforementioned components, please refer to the Security Features
document.

Fig. 4.1 MasterClaw security environment

Security
4.2 Clients and Workstations

Different types of windows workstations are supported.
The workstations could be connected to the office network or via an external
network (Internet). The connection could be via a VPN. For VPN and firewall
configuration, see Section 4.6 Interfaces and External Firewalls /VPNs on
page 4-43.
Clients need only to access servers (arrow A in Fig. 4.1 MasterClaw security
environment on page 4-3 ) and servers only need to access probes (arrow B
in Fig. 4.1 MasterClaw security environment on page 4-3 . Access from the
clients to the servers is handled via the MC Portal and a single sign-on server.
The single sign-on will take care of the user authentication via password
validation.
Servers Access to subscriber data and third party applications as Oracle DB on the
servers are handled via the Linux security. Different levels of security could
be selected on the servers.
Probes Accesses to probes are controlled via password protection, see Section 4.4
MasterClaw Capability Security on page 4-7.
The MC system contains a security module. The functionality of this module
is based on capabilities. Users are added to groups and each group are
granted capabilities. The Capability Security (see Section 4.4 MasterClaw
Capability Security on page 4-7) deals primarily with portal end users access
rights to:
● Applications
● Capabilities (subsets of application functionality)
● Sub-sections of the monitored network
Configuration of users, groups and capabilities are handled via a security

client, and described in Section 4.5 The Security Capability Configuration
Plug-in (QMCPI-SEC) on page 4-18.
Logging of the user activity is handled by a logging system, and is described
in Section 3.3.3 Overview of Activity Logging Entry and Section 3.3.4
Description of Activity Logging Entry Fields.
How to protect the subscriber confidential data sent over the different
networks are described in Chapter 5. Sec-linux Tool.
How to protect a user confidential data sent over networks are described in
section Section 4.10 Protection of User Confidential Data Sent over Networks
on page 4-76.
Caution: The customer is responsible for the total security of the MC

system. The level of security has to be planned together with
Anritsu during installation.
Note: Procedures and commands in this Chapter are not designed for C2
security level except if explicitly stated.

4.3 Portal User Authentication
Users of MasterClaw must be authenticated before they can use the system.
"MasterClaw user accounts are created with the security administration
application "qmcpi-sec" described later in this Chapter.
Users can be roughly grouped into two categories: system administrators and
normal users. A system administrator is a user which belongs to the user
group "System Administrators". System administrators have all capabilities
(see Section 4.5 The Security Capability Configuration Plug-in (QMCPI-SEC)
except those controlling access to MasterClaw Insight reports whose names
start with BO.
A user authenticates by logging in. This can be done in two ways:
● Through the MasterClaw portal, the user enters a user name and a
password which are checked against the existing user accounts. When
there is a match, and the user account has not been locked or disabled,
the user's web browser receives a token which is checked each time the
user navigates the portal.
Alternatively, on Kerberos-enabled systems, the log in will be
automatically performed upon landing on the MasterClaw Portal, using
the Workstations’ credentials.
● Through administrators who need to manage server applications or
troubleshoot log in on the appropriate server. In this case, the user logs
in to the server to use MasterClaw applications, and his/her UNIX
account must correspond to a MasterClaw user account. Authentication
is only done by the operating system and not by MasterClaw.
A user must also authenticate when changing passwords.

Default users used by Anritsu are the following:
● AdminRD
● AdminPS
● Guest
● SMAdmin
4.3.1 Security Policies

Login and password changes are governed by two policies:
● Account lockout policy
● Password policy
Account lockout This policy is used to prevent someone breaking into an account by quickly
policy trying different passwords. When such an attempt is detected, the account is
locked for a limited amount of time as defined in the policy.
Password policy This policy is used to enforce the use of strong passwords and control how
often a password must be changed. It defines the number or uppercase,

Security
lowercase, digits and punctuation characters that a password must contain,

as well as the minimum password length.
Note: The password policy is only enforced for normal users. It does not
apply to system administrators as this would risk blocking an
administrator from logging in.
For a detailed description of each policy, see Section 4.5.3 QMCPI-SEC

Nodes.

4.4 MasterClaw Capability Security
The section serves two purposes:
● It lists all known capabilities and provides a brief textual application of
each, together with the default description to be stored in the security
database
● It provides an overview of the processes that check for capabilities and
states, which capabilities are used by each of the processes
4.4.1 Defined Capabilities

The capabilities are divided into two groups:
● Common
● Application-specific
The division into groups serves only to increase the readability of this
document.
Table 4.1 and Table 4.2 consist of two columns:
● Capability Name specifies the capability
● Description provides the short textual description that must be used
when creating the capability in the security system.
Common capabilities are listed in Table 4.1:
Capability Name Description

AccessTopology Right to access network topology or probe information in applications.
ViewSecurity The right to read security settings in the security database.
ChangeSecurity The right to modify security settings in the security database.
ViewGDS The right to read the system-wide data store.
ChangeGDS The right to modify the system-wide data store.
ViewTopology The right to read topology information in the configuration database.
ChangeTopology The right to modify topology information in the configuration database.
ViewConfiguration The right to read configuration data in the configuration database.
ChangeConfiguration The right to modify configuration data in the configuration database.
Server (deprecated) The right to use a server program (no longer needed).
ViewPDUs The right to view low-level protocol data units (PDUs) in applications.
ViewCompleteNumber The right to view complete phone number(s) in applications. See Note 1
for parameters in use.
SpecifyCompleteNumber The right to specify complete phone number(s) in a report or query. See
Note 2 for parameters in use.
ViewSMSContent The right to view captured SMS/MMS content.
ViewUSSDContent The right to view captured USSD content.
Table 4.1 Common capabilities (Sheet 1 of 2)

Security

ViewEndpointDetails The right to view endpoint details such as IP addresses and phone
numbers.
ViewCredentials The right to view user credentials such as user name and password.
ViewURLContent The right to view captured URL content.
ViewDomainContent The right to view captured Domain names.
SaveRawPDU The right to save PDUs in binary formats (for instance QPA and
CAP/DMP formats).
ViewRawData The right to view PDUs in raw Hex and ASCII formats.
BO_Customer_Report_Developer Right to: create/modify/delete reports and folders in “User Defined Folder”
and “My Favorites” folder, open any report, schedule reports.
BO_Customer_Report_Viewer Right to: open any report, modify any report by saving it only in “My
Favorites”, schedule reports.
BO_PS_Report_Developer Right to: create/modify/delete reports and folders in “Customized Folder,
“User Defined Folder” and “My Favorites” folders, open any report,
schedule reports.
ViewGlobalCSDRSetup Right to view CSDR setup setting.
ChangeGlobalCSDRSetup Right to change the global CSDR setup.
ViewLocalCSDRSetup Right to view local CSDR setup.
ChangeLocalCSDRSetup Right to view or change the local CSDR setup.
ViewMap Right to read Map configuration.
ChangeMap Right to modify Map configuration.
ViewDevice Right to read Device configuration.
ChangeDevice Right to modify Device configuration.
ViewEnterprise Right to read Enterprise configuration.
ChangeEnterprise Right to modify Enterprise configuration.
ViewEoLiveResource Right to view a resource (folder or DataView) in eoLive.
ChangeEoLiveResource Right to modify a resource (folder or DataView) in eoLive.
ViewOperator Right to read Operator configuration.
ChangeOperator Right to modify Operator configuration.
Note 1: Parameter 1 = The amount of Notes:
trailing digits that will be masked, if the parameters are set using the Security Administration tool.
user lacks the ViewCompleteNumber
capability.
Note 2: Parameter 1 = The amount of
leading digits that will be accepted, if
the user lacks the
SpecifyCompleteNumber capability.
Table 4.1 Common capabilities (Sheet 2 of 2)

Application-specific capabilities are listed in Table 4.2:

AdminCallTrace Right to act as a MasterClaw eoFinder Trace Administrator.
AdminBrowse Right to act as a MasterClaw eoFinder Browse Administrator.
AdminRdac Right to act as a MasterClaw eoFinder Capture Administrator.
AdminSelfmon Right to act as a MasterClaw Self Monitoring Administrator.
ChangeDBO Right to configure dashboards
ViewDBO Right to view dashboards
ViewEvents The right to view events in the alarm repository.
ChangeEvents The right to view or change events in the alarm repository.
ChangeEventTemplate Right to edit QEVENT objects in cdb.
ChangePrivacy Right to assign privacy capabilities to groups
CommitGuiUse (deprecated) Right to use eoPath Commit GUI.
CommitGuiModifyQoSProfiles Right to configure service profiles in eoPath Commit GUI.
(deprecated)
EnableExpertCallTrace Right to act as an MasterClaw eoFinder Trace expert user.
configtool The right to start the ConfigTool application.
findercci Right to start the eoFinder CCI application
findercciAdmin right to act as a eoFinder CCI Administrator
finderoff Right to start the eoFinder off-line application.
finder Right to start the eoFinder application.
probescan Right to use probe scanner application.
qalarm The right to start the QAlarm application.
qct The right to use the Trace functionality in eoFinder application.
qptliv-dwhalarm-cfg The right to access the DWH Alarms' Configuration Console via MC Portal
qmcpi-gds The right to use the general data store management plug-in.
qmcpi-qlms The right to start the QLMS QMC plug-in.
qmcpi-qrs (deprecated) The right to start the Roaming Management configuration plug-in.
qmcpi-qsa The right to use the surveillance management plug-in.
qmcpi-sec The right to use the security management plug-in.
qpa The right to use the Inspect functionality in eoFinder application.
qpecc (deprecated) The right to start the protocol event collector.
qpm The right to use probe manager application.
qpmscans The right to use probe autoconfiguration.
qptls_admin The right to manage the MasterClaw Portal.
qptls_config Right to configure the MasterClaw Portal. A user with this capability is able
to access the Configuration tab panel in order to configure alarms,
dashboards, and other tools. A Configurator sees and accesses
troubleshooting applications, Insight and Reports on the basis of the
security (Insight related) capabilities as controlled by the MasterClaw
security Administrator.
qptls_user The right to access the MasterClaw Portal as user.
qrtfsc-csb The right to use the Real Time Fraud Sentry.
qmcpi-dwh-kpi Right to configure DWH alarms.
qmcpi-qfc The right to use the fraud configuration management plug-in.
Table 4.2 Application specific capabilities (Sheet 1 of 2)

Security

qsecs (deprecated) The right to start and stop the QSECS (security) service.
rdac Right to use the Capture functionality in eoFinder application.
browse Right to use the Browse functionality in eoFinder application.
eolivec Right to use the eoLive application. It is also needed to see eoLive
instances in eoFinder application.
eolivec_power_user Right to use the eoLive application as a powered user
eolivec_admin Right to use the eoLive application as an administrator
Selfmon Right to use the Self Monitoring application as a user.
ViewMCLS Right to view MCLS data.
ViewEventTemplate Right to read/change QEvent
ModifyMCLS Right to modify MCLS data.
qtrg (deprecated) The right to start the Trigger application.
Table 4.2 Application specific capabilities (Sheet 2 of 2)
4.4.2 Use of Capabilities per Application

The following table states the current capabilities in MasterClaw used by
portal end users. Refer to this table when setting up the security system of a
MasterClaw system.

Application
Program Capability Comment
name
Configuration configtool configtool The right to start the Config Tool.
Editor qptls_config The capability to access the Configuration tab
panel
ViewGlobalCSDRSetup Capabilities to read/change global CSDR setup

ChangeGlobalCSDRSetup
ViewLocalCSDRSetup Capabilities to read/change local CSDR setup

ChangeLocalCSDRSetup
Capabilities to read/change Map
ViewMap
ChangeMap
Capabilities to read/change Device
ViewDevice
ChangeDevice
Capabilities to read/change Enterprise
ViewEnterprise
ChangeEnterprise
Capabilities to read/change Operator
ViewOperator
ChangeOperator
ViewEventTempla
te Capabilities to read/change QEvent
ChangeEventTemplate
ViewMCLS
ModifyMCLS The right to view/modify MC Lookup Service
data.
eoFinder Off- finderoff finderoff finderoff is an off-line tool that does not check for
line any capabilities; however, the finderoff capability
is required to access the application via MC
Portal.
Alarm Manager qalarm qalarm It requires the qalarm capability to run QALARM.
It requires the ViewEvents capability to view
ViewEvents alarms (and run QALARM).
It requires the ChangeEvents capability to
ChangeEvents change the status of events.
Table 4.3 Capability Usage (Sheet 1 of 7)

Security
Application
name
eoFinder finder, ViewTopology ViewTopology is required in order to view the
findercl topology. Access to ViewTopology is
mandatory for starting Call Trace.
AccessTopology (option) Gives access to specific topology parts.
ViewCompleteNumber ViewCompleteNumber gives the right to view

phone numbers unmasked.
SpecifyCompleteNumber SpecifyCompleteNumber gives the right to
set up a call trace for a specific A- or B-number.
ViewPDUs ViewPDUs gives the right to view the low-level
SaveRawPDU signalling information as recorded by the
ViewRawData measurement probes. (Note that access to a
PDU may reveal A- or B-numbers.)
ViewGDS Access to ViewGDS grants the user permission
to load Call Trace files from and to the General
Data Store (GDS).
ChangeGDS Access to ChangeGDS grants the user

permission to load and save Call Trace files from
and to the GDS and to delete files from the GDS.
finder finder is checked at start-up; eofinder will not

run if the user does not have access to finder.
eolivec eoFinder user also needs the eolivec capability

to be able to see eoLive instances in eoFinder
application.
eoFinder ViewTopology ViewTopology and ViewConfiguration are
Capture Client SaveRawPDU required in order to view the MasterClaw
topology and central configuration.
rdac
All these capabilities are mandatory.
ViewConfiguration

Application
name
eoFinder qct eoFinder provides the following user profiles:
Trace Client AdminCallTrace Trace Administrator
EnableExpertCallTrace He/she owns at least the following capabilities
qct, AdminCallTrace, ViewTopology,
ViewConfiguration ViewConfiguration
ViewEndpointDetails He/she has access to the administration
ViewCredentials functionalities in Trace: configuration of global
ViewSMSContent layouts, configuration of services, usage of both
ViewUSSDContent the expert and customer care interface to launch
traces.
ViewURLContent
Trace Expert user
ViewDomainContent He/she owns at least the following capabilities
qct, EnableExpertCallTrace,
ViewTopology, ViewConfiguration
He/she has access to the expert functionalities in
Trace: configuration of local layouts, usage of
both the expert and customer care interface to
launch traces.
Customer Care Trace user
He/she owns at least the following capabilities
qct, ViewTopology, ViewConfiguration
He/she has access to the basic functionalities in
Trace: usage of customer care interface to
launch traces.
All the other capabilities are optional and might
be assigned to any user profile thus allowing/
revoking access to the related views and data.
The Customer Care Trace interface is optional in
MC and requires a specific package (enable-
qctcci) to be installed to enable it.
In case enable-qctcci is not installed only
Trace Administrator and Trace Expert users are
enabled to launch Trace.
ViewSMSContents, ViewCredentials,
ViewUSSDContent,ViewEndpointDetails
,ViewURLContent, ViewDomainContent
respectively grant permission to View SMS,
Credentials, USSD, EndPoint, URL, Domain
content in Trace results.
eoFinder browse Browse user
Browse Client ViewConfiguration He/she owns at least the following capabilities:
ViewEndpointDetails browse
ViewCredentials
ViewTopology
ViewSMSContent
ViewUSSDContent ViewConfiguration
ViewURLContent He/she has access to browse functionalities.
ViewDomainContent
eoFinder qpa Inspect user
Inspect Client ViewConfiguration He/she owns at least the following capabilities:
ViewEndpointDetails qpa
ViewCredentials
ViewSMSContent ViewTopology
ViewUSSDContent ViewConfiguration
ViewURLContent He/she has access to inspect functionalities.
ViewDomainContent

Security
Application
name
eoLive eolive eoLive provides the following user profiles:
client eolivec eoLive User
He/she owns the eolivec capability: can create
personal Dataviews. Can copy charts to personal
Dataviews via “drag-and-drop” from public
Dataviews. Does not have rights to manually
create/edit charts.
eolivec_power_user eoLive Power User
He/she owns the eolivec_power_user
capability: can create, edit, rename, and delete
public Dataviews; can create, edit, rename,
delete, and publish personal Dataviews. Can
create, edit and delete charts in Dataviews for
which he/she has edit access.
eolivec_admin eoLive Administrator
He/she owns the eolivec_admin capability:
can create, edit, delete, publish, and rename
data views in all workspace; can perform
export and import operations.
ViewEndpointDetails
ViewCredentials
ViewSMSContent
ViewUSSDContent
ViewTopology
AccessTopology
ViewCompleteNumber
SpecifyCompleteNumber
ViewEoLiveResource
ChangeEoLiveResource
Realtime Fraud qrtfsc-csb qrtfsc-csb qrtfsc-csb is checked during start-up.
Sentry The capability is created during package
installation.
Alarm qptliv- qptliv-dwhalarm-cfg The right to access the DWH Alarms’
Configuration dwhalarm- Configuration Console via MC Portal.
Tool cfg
General Data qmcpi-gds qptls_admin qptls_admin : the capability to be the
Store administrator of the Portal.
Configuration qmcpi-gds qmcpi-gds and ViewGDS are checked at start-
Tool ViewGDS, up time.
ChangeGDS ChangeGDS is only required when moving/
creating and deleting entries.

Application
name
Link and qmcpi-qlms qmcpi-qlms The QMCPI-QLMS creates the qmcpi-qlms
Message capability during package installation.
Configuration qptls_config qptls_config:the capability to access the
Tool Configuration tab panel
In order to create, delete, and modify
subscriptions, the MasterClaw user must have
access to the following capabilities:
ViewTopology qmcpi-qlms
ViewConfiguration ViewTopology
ChangeConfiguration ChangeConfiguration
To operate in read-only mode, the following
capabilities are required:
qmcpi-qlms
ViewTopology
ViewConfiguration
Fraud qmcpi-qfc qmcpi-qfc qmcpi-qfc is checked during start-up.
Configuration qptls_config qptls_config:the capability to access the
Tool Configuration tab panel
ViewConfiguration ViewConfiguration grants the user the right
to view the fraud configuration.
ChangeConfiguration The user is allowed to change (and view) fraud
configuration if they have the
ChangeConfiguration capability.
Roaming KPI qmcpi-qrs qmcpi-qrs (deprecated) The qmcpi-qrs capability is required to start the
roaming configuration program.
qptls_config qptls_config: the capability to access the
Configuration tab panel
QMCPI qmcpi-sec qmcpi-sec qmcpi-sec is checked during start-up.
qptls_admin qptls_admin : the capability to be the
administrator of the Portal.
ViewSecurity
ChangeSecurity
ChangePrivacy
ViewConfiguration
ChangeConfiguration

Security
Application
name
qpm qpm QPM itself: The user must has access to QPM to
use the qpm
ACTIVATE: This command requires
ChangeConfiguration ChangeConfiguration for each centre
ViewConfiguration affected.
DELETE: This command requires
ChangeConfiguration and ChangeGDS for
each centre affected.
ViewTopology LIST: This command requires

ChangeTopology ViewConfiguration (or
ChangeConfiguration) for each centre affected.
GENERATE: This command requires
ChangeConfiguration and ChangeGDS for
each centre affected. The qpmgen itself
incorporates these checks too (plus qpmgen).
VALIDATE: This command requires
ViewConfiguration
(or ChangeConfiguration) and ViewGDS
(or ChangeGDS) for each centre affected.
DOWNLOAD: This command requires
ChangeConfiguration and ViewGDS (or
ChangeGDS) for each centre affected.
qpmgen ViewTopology See above.
ChangeTopology
ViewConfiguration
ChangeConfiguration

Application
name
Portal portal The QPTLS installs and uses the following
capabilities:
qptls_admin qptls_admin : the capability to be the
administrator of the Portal. “Root” is the name of
the Administrator by default: he has access to the
Portal and to all the application installed, except
Insight. “Root” Administrator owns the capability
to use the Security Administration Tool and
consequently create new users and user groups.
A user with this capability has administrative
rights in the Portal. He is the only user who is
able to access the Administration tab panel.
qptls_config qptls_config:the capability to access the
Configuration tab panel in order to configure
alarms, dashboards, and other tools. A
Configurator sees and accesses troubleshooting
applications, Insight and Reports on the basis of
the security (Insight related) capabilities as
controlled by the MasterClaw security
Administrator.
qptls_user qptls_user: the capability to use the Portal
and customize the My MasterClaw page
A MasterClaw user needs to be granted at least
the qptls_user capability before trying to
connect the Portal. With this type of access, the
user will only be able to edit its own (’My’) Portal
page with dashboard and applications. Users
belonging to ’System Administrators’ are granted
access to the Portal.
Starting with QPTL-2.0.5, qptls checks
individual capabilities when displaying and
configuring MC Java Clients for ’My MasterClaw’
pane. Consider this when configuring Portal
users.
qmcpi-dwh-kpi qmcpi-dwh-kpi: The right to access the DWH

DBO and KPI configuration pages and tabs.
MasterClaw Mcls ViewMCLS The right to view/modify MCLS data.
Lookup Service ModifyMCLS
Protocol Event qpecc qpecc qpecc is checked during start-up.
Collector ViewPDUs Both ViewPDUs and ViewCompleteNumber
(deprecated) ViewCompleteNumber are required because qpecc retrieves and
stores low-level probe data.
Application qtrg qtrg (not in use) There exists a capability qtrg to control access
Trigger to QTRG, but this capability is not yet in use,
(deprecated) hence it is the file access rights of QTRG that
determines who can start QTRG.
ViewGDS However, QTRG employs ViewGDS and
ChangeGDS ChangeGDS to control access to the General
Data Store (GDS). Access to ViewGDS grants
the right to read from the GDS; access to
ChangeGDS grants additional right to write, both
overwrite and create a new one, in the GDS.

Security
4.5 The Security Capability

Configuration Plug-in (QMCPI-SEC)
4.5.1 QMCPI-SEC Applications

QMCPI-SEC application is used to configure the security system of
MasterClaw.
Note: In order to enable the security system in MasterClaw, the QBASE
package ’enable-security’ must be installed first. Security is an
optional feature in MasterClaw.
Functionality QMCPI-SEC supports the following functionality:

● Accessing and changing information about users of MasterClaw
● Accessing and changing user groups
● Accessing and changing security capabilities
● Accessing and changing security capabilities of linksets per centre or
user group
For List of Security Capabilities see: Section 4.4 MasterClaw Capability

Security on page 4-7.
4.5.2 QMCPI-SEC Features

Navigation The security related information of the MasterClaw information model is
mapped to a navigational structure that makes it easy to display a relevant
subset of entities. You can e.g. display user groups related to:
● Attributes
● Capabilities
● Centres
● Users
● Signalling linksets
● Resources
● DBOs
Conversely, you can display all Capabilities in effect for a specific user, for
example.
Notification of QMCPI-SEC tracks configuration changes made by other clients, thus

changes and conflicts providing access to the most recent configuration data.
Privacy control Privacy control is the feature where control of capabilities that govern access
to privacy-related information is handled by a set of users that is separate
from the normal system administrators group, often users that are member of

this group are employees of the MasterClaw customer, while system
administrators may be Anritsu staff.
See Section 4.5.4 Privacy Control for a more detailed description of this
feature and its impact on QMCPI-SEC.
Tree structure The structure of a completely unfolded tree hierarchy of QMCPI-SEC is:
● QMCPI-SEC (root)
● Users
● User entity
● User Groups
● User Group entity
● Capabilities
● Capability entity
● Centres
● Centres entity
● Signalling linksets
● Signalling linksets entity
● Security policies
● Security policies entity
● Resources
● Resources entity
● DBOs
● DBOs entity
Node operations Together with simple editing of object attributes, some operations may be
performed on tree nodes. The set of these operations is different for each
node type. Each node type provides the same operations independent of
node position in hierarchy. However, some of the operations may be disabled
in specific cases. The reason for disablement is insufficient context for
successful operation flow in those specific cases.
4.5.3 QMCPI-SEC Nodes

Root node As system administrator you will initially be presented with the default views
as shown in Fig. 4.2. These views are further explained in Table 4.4. Right-
click on the node to view the menu actions.

Security
Fig. 4.2 QMCPI-SEC root node – list view

Rows Displayed Description
Users List and create new users
User groups Attach users to user groups and grant or revoke
UserGroup resource access.
Capabilities Grant or revoke capabilities for the user
Centres Grant or revoke user group access to the defined centres
Signalling linksets Grant or revoke user group access to the individual
signalling linksets
Security policies Specify password and account lockout policies for all
users
Resources List and describe resources
DBOs List and describe the database objects.
Table 4.4 QCMPI-SEC root node default list view
Actions for QMCPI-SEC root node in the pop-up menu and in the toolbar.
Action Name Description

List view Lists the nodes as shown in Fig. 4.2
Attribute view N.A.
Table 4.5 QCMPI-SEC root node menu actions
Users node
Fig. 4.3 QMCPI-SEC users node

Security
Displayed Description
Name System name of user
Enabled Shows if the user is enabled (Yes/No)
Locked Shows if the user has been locked (Yes/No)
Bad password count The number of times a wrong password has been entered
Expires The date and time the user login will expire and has to be
renewed, otherwise Never
Password expired Shows if the password has already expired (Yes/No)
Change password Shows if the password has been set to be changed the
next time the user logs in (Yes/No)
Password expires The date and time the password will expire and has to be
renewed, otherwise Never
Table 4.6 QCMPI-SEC users node views
Actions for QMCPI-SEC root node in the pop-up menu and in the toolbar.

Create User Create a new user and add this user to the list.
Table 4.7 QCMPI-SEC users node menu actions
Users entity node
Fig. 4.4 QMCPI-SEC users entity node – attributes

Name Displayed Description
User Name System name of user
Attributes
Description User details, e.g. full name
Password User’s system password
Confirm Password Repeat of password for confirmation
Capabilities Capability List of all user capabilities
Usergroup Shows the user group(s) associated with
each Capability
UserGroups Member of Choose the user groups you want the user
to be a member of
Not member of
Table 4.8 QCMPI-SEC users entity node views (Sheet 1 of 2)

Security
Name Displayed Description

Extended Enabled Choose whether the user is to be enabled or
user disabled (Yes/No)
attributes
Last enabled Shows the date and time the user was last
enabled
Enabled by Shows the system name of the person who
last enabled the user
Last disabled Shows the date and time the user was last
disabled, otherwise shows Never
Disabled by Shows the system name of the person who
last disabled the user
Expires Type the date (and time if relevant) when the
user login should expire, otherwise choose
Never
Expired Shows if the user login has already expired
(Yes/No)
Locked Choose whether the user is to be locked or
unlocked (Yes/No)
Last locked Shows the date and time the user was last
locked, otherwise shows Never
Locked by Shows the system name of the person who
last locked the user
Last unlocked Shows the date and time the user was last
unlocked, otherwise shows Never
Unlocked by Shows the system name of the person who
last unlocked the user
Password expires Type or edit the date and time the password
expires, otherwise choose Never
Password expired Shows if the user password has already
expired (Yes/No)
Change password Choose if the user should change their
password at next login (Yes/No)
Last log In Shows the date and time the user last
logged in, otherwise shows Never
Last log out Shows the date and time the user last
logged out, otherwise shows Never
First bad password Shows the date and time the first time the
user used a wrong login password,
otherwise shows Never
Last bad password Shows the date and time the last time the
user used a wrong login password,
otherwise shows Never
Password set Shows the date and time the user had their
password set
Password set by Shows the system name of the person who
last set the user’s password
Login count Shows the number of times the user has
logged in
Bad password count Shows the number of times the user has
tried to log in with a wrong password
Table 4.8 QCMPI-SEC users entity node views (Sheet 2 of 2)

Create User Like Create a user like the selected user. The new user
becomes member of the same set of groups as the
selected user.
Delete User Delete the selected user (after clicking Delete).
Table 4.9 QCMPI-SEC users entity node menu actions
User groups node
Fig. 4.5 QMCPI-SEC user groups node
Column name Description

Name Shows the names of all the user groups.
Description Gives an optional description of the user groups
Scope The scope that capabilities of this group must have when
privacy control is enabled.
Table 4.10 QCMPI-SEC user groups node views

Create user group Create a new user group.
Table 4.11 QCMPI-SEC user groups node menu actions

Security
User groups entity

node
Fig. 4.6 QCMPI-SEC user groups entity node – attributes
Name Rows Displayed Description

User group attributes Name View or edit the user group
name
Description Optional description of the user
group
Scope The scope that capabilities of
this group must have when
privacy control is enabled.
User group capabilities Granted Grant or revoke the individual
capabilities for the group.
Revoked
User group centres Access granted Grant or revoke access for the
group to the individual centres.
Access revoked
User group users Contains Assign the users to the user
group.
Does not contain
User group signalling Access granted Grant or revoke access for the
linksets group to the individual linksets.
Access revoked
User group resources Access granted Grant or revoke access for the
group to the resources created.
Access revoked
Table 4.12 QCMPI-SEC user groups entity node views

User group DBOs Access granted Grant or revoke access for the
group to the DBOs created.
Access revoked
Table 4.12 QCMPI-SEC user groups entity node views

Delete user group Delete the selected user group (after clicking Delete)
Table 4.13 QCMPI-SEC user groups entity node menu actions
Capabilities node
Fig. 4.7 QCMPI-SEC capabilities node

Name Shows the name of the capability
Description View or edit the capability description
Parameter 1
Parameter 2 These are system parameters created during installation
Parameter 3
Scope The administrative scope of the capability (read only)
Table 4.14 QCMPI-SEC capabilities node views

Security
Capabilities entity
node
Fig. 4.8 QMCPI-SEC capabilities entity node – attributes

Capabilities attributes Name Shows the name of the
capability
Description View or edit a description of the
capability
Parameter 1 These are system parameters
created during installation
Parameter 2
Parameter 3
Scope The administrative scope of the
capability (read only)
Capabilities user Granted for Choose the user groups to be
groups granted or revoked the selected
Revoked from
capability.
Table 4.15 QCMPI-SEC capabilities entity node views

Centres node
Fig. 4.9 QCMPI-SEC centres node

Name View or edit the centre name
Main Centre Choose if this is the main centre (Yes/No)
Location View or edit the location of the centre
Table 4.16 QCMPI-SEC centres node views

Security
Centres entity node
Fig. 4.10 QCMPI-SEC centres entity node – attributes

Centre attributes Name See Table 4.16
Main Centre
Location
User groups Access granted Choose the user groups to be
granted or revoked access to the
Access revoked
selected centre.
Table 4.17 QCMPI-SEC centres entity node views

Signalling linksets
node
Fig. 4.11 QCMPI-SEC signalling linkset node

Name The linkset name
Description View or edit the description of the linkset
Administrative state Shows if the linkset is LOCKED or UNLOCKED
Protocol package The protocol package containing the linkset
Signalling point A The signalling link start point
Signalling point Z The signalling link end point
Table 4.18 QCMPI-SEC signalling linkset node views

Security
Signalling linksets
entity node
Fig. 4.12 QCMPI-SEC signalling linkset entity node – attributes

Signalling linkset Name
attributes
Description
Administrative state
See Table 4.18
Protocol package
Signalling point A
Signalling point Z
Signalling linkset Access granted Choose the user groups to be
UserGroups granted or revoked access to the
Access revoked
linkset.
Table 4.19 QCMPI-SEC signalling linkset entity node views

Security policies node
Fig. 4.13 QCMPI-SEC security policies node
Login and password changes are governed by two policies, as in table here
below.
Name Description
Account lockout policy Set up parameters for locking out an account. This policy
is used to prevent someone breaking into an account by
quickly trying different passwords. When such an attempt
is detected the account is locked for a limited amount of
time as defined in the policy.
Password policy Set up parameters for creating and using passwords. This
policy is used to enforce the use of strong passwords and
control how often a password must be changed. It defines
the number or uppercase, lowercase, digits and
punctuation characters that a password must contain as
well as the minimum password length.
Note: the password policy is only enforced for normal
users. It does not apply to system administrators as this
would risk blocking an administrator from logging in.
Table 4.20 QCMPI-SEC security policies node views
Action name Description

Set category for Opens a dialogue where you can choose the account
lockout policy lockout policy category (low/medium/high)
Table 4.21 QCMPI-SEC security policy node menu actions

Security
Action name Description

Set category for Opens a dialogue where you can choose the password
password policy policy category (low/medium/high)
Table 4.21 QCMPI-SEC security policy node menu actions
Security policies entity

node
Fig. 4.14 QCMPI-SEC security policies entity node – account lockout

Fig. 4.15 QCMPI-SEC security policies entity node – password
Entity name Field name Description

Account Category Choose the lockout policy category (low/medium/
lockout high) with pre-defined parameters, or choose
policy custom to define your own parameters.
Duration The number of minutes (starting from a lockout)
after which a new set of login attempts can be
made. After this duration the lockout (and
‘Observation window’ if relevant) will be reset. If 0
then a lockout will need to be reset by a system
administrator.
Threshold The maximum amount of login attempts before
account lockout (0 = infinity)
Observation The number of minutes (starting from the first login
window attempt) after which a new set of login attempts can
be made if the user has not been locked out. If the
user has been locked out, then the ‘Duration’ rules
apply. If 0 then the observation window is disabled.
Table 4.22 QCMPI-SEC security policies entity node views (Sheet 1 of 2)

Security
Entity name Field name Description

Password Category Choose the password policy category (low/
policy medium/high) with pre-defined parameters, or
choose custom to define your own parameters
Password The number of times you need to use a different
history password each time you renew your password
Max password The number of days after which you need to renew
age your password. Note that changing the value of this
parameter only affects user accounts that are
created or whose password is updated, after the
change has been applied.
Min password The number of days that have elapsed before you
age can renew your password
Min password The minimum number of characters in the
length password
Min lower case The minimum number of lower case characters in
chars the password
Min upper The minimum number of upper case characters in
case chars the password
Min digits The minimum number of digits in the password
Min special The minimum number of special characters in the
chars password
Min number The minimum number of different kinds of
categories characters required in the password, e.g. 2
categories could be lower case characters and
digits.
Table 4.22 QCMPI-SEC security policies entity node views (Sheet 2 of 2)
Resources node
Fig. 4.16 QCMPI-SEC Resources node

Id Shows the resource identifier.
Location View or edit the location of the Resource
Type Gives the resource type.
Owner Shows an owner for the resource.
Table 4.23 QCMPI-SEC Resources node views
Resources entity node
Fig. 4.17 QCMPI-SEC Resources entity node - attributes
Rows
Name Description
displayed
Resource Id See Table 4.23
name
Type
Owner
Table 4.24 QCMPI-SEC Resources entity node views
The following table includes the BO_Universe Resources created from the
bo-model. These are needed to assign the grants for Universe usage. For
example, a user belonging to a given group can be assigned the
“BO_Customer_Report_Developer” capability as well as the “eoIP Service
KPI” Resource. Such user will be then intended as a

Security
“BO_Customer_Report_Developer” enabled to operate on the assigned

“eoIP Service KPI” resource.
Resource Program Comment

GSM Access KPI QADWH data Grants the right to view reports and universe of "GSM
warehouse Access KPI DWH". You should also have at least one of
the common capabilities:
BO_Customer_Report_Developer
BO_Customer_Report_Viewer
BO_PS_Report_Developer
GPRS Access KPI QGBDWH Grants the right to view reports and universe of "GPRS
data warehouse Access KPI DWH", You should also have at least one of
UMTS Circuit Access KPI QIUCSDWH Grants the right to view reports and universe of "IuCS
data warehouse Access KPI DWH", You should also have at least one of
Link and Message Statistics QLMS data Grants the right to view reports and universe of "LMS
warehouse DWH", You should also have at least one of the common
capabilities: BO_Customer_Report_Developer
Network Call Performance QNCKPI Grants the right to view reports and universe of "NCKPI
KPI data warehouse DWH", You should also have at least one of the common
Next Generation Network NGN data Grants the right to view reports and universe of "NGN KPI
KPI warehouse DWH", You should also have at least one of the common
Roaming Statistics Roaming Statistics Grants the right to view reports and universe of "Roaming
data warehouse Statistics DWH", You should also have at least one of the
common capabilities:
Active Roamers KPI QARDWH data Grants the right to view reports and universe of “Active
Warehouse Roamers KPI DWH”. You should also have at least one
of the common capabilities:
SMS KPI SMS KPI data Grants the right to view reports and universe of "SMS KPI
Table 4.25 Universe resources (Sheet 1 of 2)

Resource Program Comment
TCAP Service KPI QTCAP data Grants the right to view reports and universe of "TCAP
warehouse KPI DWH", You should also have at least one of the
common capabilities:
Global Roaming Quality GRQ DWH Grants the right to view reports and universe of "GRQ
DWH”.
eoLTE KPI eoLTE data Grants the right to view reports and universe of "eoLTE
eoGI URL KPI (option eoSign In DWH Grants the right to view reports and universe of "eoSign
available as Special In” DWH.
Customer Release)
eoIP Service KPI eoIP Service DWH Grants the right to view reports and universe of "eoIP
Service” DWH.
eoIUPS KPI eoIUPS DWH Grants the right to view reports and universe of "eoIUPS”
DWH.
eoIUCS KPI eoIUCS DWH Grants the right to view reports and universe of "eoIUCS”
DWH.
eoNGN KPI eoNGN DWH Grants the right to view reports and universe of "eoNGN”
DWH.
Table 4.25 Universe resources (Sheet 2 of 2)

Security
DBOs node
Fig. 4.18 QCMPI-SEC DBOs node

Name Shows the name of the DBO.
DBO Type Gives a DBO type.
Owner Shows an owner for the DBO
Table 4.26 QCMPI-SEC DBOs node views

DBOs entity node
Fig. 4.19 QCMPI-SEC DBOs entity node
Rows
Name Description
displayed
DBO name Name See Table 4.23
DBO Type
Owner
Table 4.27 QCMPI-SEC DBOs entity node views
4.5.4 Privacy Control

Enabling privacy control changes the behaviour in some parts of QMCPI-
SEC. Some actions on some objects, as those described below, no longer
require the ChangeSecurity capability (by default available to all system
administrators) but instead require the ChangePrivacy capability (by default
only available to privacy administrators).
Note: See Security Installation and Configuration Manual for instructions on
how to enable privacy control.
Enabling the first time When first enabled, the «privacy» capabilities such as ViewSMS are removed
from all user groups and a «Privacy Administrators» group is created.
A system administrator has to assign capabilities to the default privacy
administrator, “mclaw_privacy”, in order to let that user access the portal and
qmcpi-sec (when created this user only has all PRIVACY capabilities).

Security
Changes in behaviour When privacy control is enabled, the following changes in qmcpi-sec:
● To be able to add a capability to a group the capability must be in the
same scope as the user group, and the user of qmcpi-sec must have
either ChangeSecurity (for system scoped capabilities) or
ChangePrivacy (for privacy-scoped capabilities).
● To create user groups with SYSTEM scope, a user must have
ChangeSecurity and to create groups with PRIVACY scope
ChangePrivacy is required.
● In order to change the scope of a user group, the user of qmcpi-sec must
have both of the capabilities mentioned above, and the group must not
contain any capabilities. It is forbidden to put capabilities of different
scopes in the same group when privacy control is enabled, and qmcpi-
sec enforces this.
● To be able to add users, centres, linksets, DBOs and other resources to
a user group with a certain scope, the user of qmcpi-sec must have the
appropriate capability, i.e ChangeSecurity for user groups with SYSTEM
scope, and ChangePrivacy for user groups with PRIVACY scope.
● Only members of Privacy Administrators may update the password of the
default privacy administrator “mclaw_privacy”.

4.6 Interfaces and External Firewalls /
VPNs
This Section includes:
● The used port numbers involved in the configuration of VPNs or firewalls
● The network interfaces used inside a MC system, focusing on the action
required to secure them.
Note: Only port numbers on the server side are specified here. Clients
always choose a random port number.
Note: The firewall shall be configured in a way that filters other than IP
addresses and ports are not used. E.g. Firewall should not filter the
content with deep packet inspection.
4.6.1 Port Numbers on all MasterClaw Servers

The following table applies to all servers, such as:
● Central server
● Mediation server
● DWH
● Oracle
● Application
● Probes
● Infoservers
● NDAF servers (master or slave)
● Rainstor
● Vertica
tcp/ Port
Application Protocol Note
udp Number
NTP ntp udp 123
SSH/SFTP SSL tcp 22 Customer service login, SW download, etc.
udp 500 IKEv2 (IPSec control path)
— IPsec* udp 4500 IKEv2 (IPSec control path)
tcp 50 ESP IPSec data path
* Disabled by default
This is a Special Customer Release feature only intended for customers who request it.
Table 4.28 Port numbers on MasterClaw servers

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Name Server Client Data Type Comment
Sensible
udp
SFTP Data Record eoFinder Browse eoDR, Call/ SFTP tcp 22 No Yes Yes Yes
Gateway Server loader Transaction
(qxdrs) parameters
SFTP Data Record Oracle DWH DR, Call/ SFTP tcp 22 No Yes Yes Yes
Gateway Server Transaction
(qxdrs) parameters
SFTP Probe Oracle DWH DR, Call/ SFTP tcp 22 No Yes Yes Yes
Transaction
parameters, Voice
kpi
SFTP Oracle host CDB, QES, remote directory SFTP tcp 22 No No Yes Yes It applies when
QDASH, QLOG, creation Oracle is deployed
Fraud on a separate
server
SFTP eoFinder Browse eoFinder Browse Configuration SFTP tcp 22 No No No Yes
Loader Server
SSH/SFTP Probe / Infoserver Deploy server Download SFTP tcp 22 No Yes Yes Yes
software/
configuration
SSH/SFTP Nrpe agents Selfmon server Server/Service SSH/SFTP tcp 22 No Yes Yes Yes
status
SSH/SFTP Any server/probe/ Central Server Any file transfer SSH/SFTP tcp 22 No No Yes Yes
infoserver/ NDAF needed by MC
server (master & administrators
slave)
SSH/SFTP Central Server External client Any file transfer SSH/SFTP tcp 22 No Yes Yes
needed by MC
administrators
Table 4.29 Detailed interfaces and port numbers on MasterClaw servers (Sheet 1 of 2)
4 – 44 System Administration — Administrator Manual

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
NTP time server, server Servers, probes Time NTP udp 123 No No No No
synchronization
Syslog Central log server Any Linux Host system logs. Syslog udp 514 No Yes No No Optional
Both servers shall
be CentOS/RedHat
5.5/5.8
Rsyslog Central log server Any Linux Host system logs. Rsyslog tcp 514 No Yes No No Optional
Both servers shall
be CentOS/RedHat
6.4
Table 4.29 Detailed interfaces and port numbers on MasterClaw servers (Sheet 2 of 2)
4.6.2 Port Numbers Used by MC Applications
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
AGG_IN_IF Aggregator Server Data Record eoDR, Call/ TCP socket tcp Note 2 No Yes No No Configurable port.
(qxdrs) Gateway Server Transaction
(qxdrs) parameters
Table 4.30 Interfaces and port numbers used by MC applications (Sheet 1 of 7)
System Administration — Administrator Manual 4 – 45

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
AGG_OUT_IF eoLive Server Aggregator Server KPI data TCP socket tcp Note 2 No Yes No No Configurable port.
(qxdrs)
Sensible data in
case of VIP
monitoring.
Alarm Config. IF DWH Portal Alarm HTTP tcp 8123 No Yes No No Data may
configuration comprehend
Customer network
node addresses.
Configurable port.
CDB CDB server Call Trace Server, Configuration, user CORBA tcp 8765 Yes Yes No No VIP, MC and
Data Record data for GDS Operator network
Gateway Server map
(qxdrs), rdas,
eoFinder Mediator,
DWH Server, Port configuration
qxdrs, eoLive setting in cdb.nin
Server, eoLive
Client, eoFinder
Browse Server,
eoFinder Browse
Client, eoFinder
Client, eoCCI, qes,
probe listener.
Selfmon. All other
clients available
from portal

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
EOLIVE_IF eoLive Server eoLive Client KPI data TCP socket tcp 6722 Yes Yes No No Sensible data in
case of VIP
monitoring
Configurable port.
FINDER_BROWSE eoFinder Browse eoFinder Client, eoDR, Call/ CORBA tcp Note 1 Yes Yes No No Configurable port.
_S Server eoCCI Transaction
parameters
FINDER_MM eoFinder Mediator eoFinder Client Configuration CORBA tcp Note 1 Yes No No No Configurable port.
http MC portal Web browser, java Configuration HTTP/HTTPS tcp 8000/8443 Yes Yes Yes Yes Configurable port.
clients files,KPI data
http eoCCI Web browser KPI data HTTP/HTTPS tcp 9090 Yes Yes Yes Yes Configurable port.
http eoCCI Command line KPI data HTTP/HTTPS tcp 9090 Yes No Yes No Configurable port
tools
http Map Server Java and Web Geographic data HTTP/HTTPS tcp 8080/9094 Yes Yes Yes Yes Configurable port.
browsers
https SelfMon Web browser MC Network HTTPS tcp 433 Yes No Yes Yes
configuration/
status
MICS_IF MICS Data Record MSISDN-IMSI pair TCP socket tcp 21987 No Yes No No
Gateway Server
(qxdrs)
MSISDN_IMSI_IF MICS eoFinder Client MSISDN-IMSI pair CORBA tcp Note 1 Yes Yes No No Configurable port.
PROBE_CONF_V1 Deploy server Deploy server Probe CORBA tcp Note 1 No Yes No No Configurable port.
client configuration
OSGI console OSGI OSGI, Probe text tcp 4444 No No No No Configurable port.
ipsecsync configuration

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
SECURITY Security - session Portal, all java Sessions CORBA tcp Note 1 Yes No No No Configurable port.
manager and audit clients
<DWH DWH backend qmcpi-dwh-kpi DBO KPI CORBA tcp Note 1 Yes Yes No No Configurable port.
Name>_DIMPROVI Configuration Sensible data in
DER case of VIP
monitoring
QCHANNEL Qchannel mqam - TeMIP Alarms CORBA tcp Note 1 No Yes No No Configurable port.
Access Module,
QSNMP
QCPMS QCPMS Fraud Server CDR, Call/ CORBA tcp Note 1 No No No Configurable port.
Transaction
parameters
QCS Qchannel qes, qalarm, Alams CORBA tcp Note 1 No Yes No No Configurable port.
qsnmp
QDASHS DWH dashboard server KPI data CORBA tcp Note 1 No Yes No No Sensible data in
case of VIP
monitoring
QES Qes - Event All DWH Alarms CORBA tcp Note 1 Yes Yes No No Sensible data in
Service Server Backends, eoLive case of Fraud
Server, many Java MSISDN
clients, Fraud,
probe listener.
Configurable port.
QES_QCH_IF Qes - Event qchannel Alarms CORBA tcp Note 1 No Yes No No
Service Server

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
QFDS_CPM Fraud Server Qrtfb-csb CDR, Call/ CORBA tcp Note 1 No Yes No No
Transaction
parameters
QMON_IF qmond qmond qbase application Text Tcp 5899 No No No No Configurable port.
status
QNS qnss Naming Almost all CORBA IOR CORBA tcp Note 1 Yes No No No Port configurable
Server application: java during installation
client, eoCCI, of QNSS
DWH, servers with
the exception of
probes
QPAS Protocol Analysis eoFinder Client PDU CORBA tcp Note 1 Yes Yes No No Configurable port.
Server II
QPS Protocol Server II eoFinder Client PDU, Protocol CORBA tcp Note 1 Yes Yes No No Configurable port.
help, Protocol spec
QSA_EVENT_IF Qes - Event Almost all Alarms CORBA tcp Note 1 Yes Yes No No Configurable port.
Service Server application Uses the
sending alarms application name
(e.g. probe ’MasterClaw-am’.
listener)
QXTS Call Trace Server eoFinder Client Trail Call/ CORBA tcp Note 1 No Yes No No Configurable port.
(qxts) Transaction
parameters
QXDRS ADM Data Record Command line Server/Service CORBA tcp Note 1 No No No No Configurable port.
Gateway (qxdrs) administration status/
client administration

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
QXDRS AGG Data Record Data Record KPI data TCP socket tcp 12701, Yes Yes No No Configurable port.
Gateway (qxdrs) Gateway (qxdrs) 12702,
12703,1270
4,12705,127
06,12707,12
708,12709,1
2710,12711,
12712,1271
3,12714,127
15,12716,12
717,12718,1
2719,12720,
12721,1272
2,12724,127
25
QXDRS EOLIVE eoLive server Data Record KPI data TCP socket tcp 44101,4410 Yes Yes No No Configurable port.
Gateway (qxdrs) 2,44103,441
04,44106,44
119,44107,4
4122,44117,
44109,44110
,44116,4411
7,44121,441
25,44118,44
120
RDAS Raw Data Analysis eoFinder Client Server/Service CORBA tcp Note 1 Yes Yes No No Configurable port.
Server (rdas) status/
administration /
data: Pcap files
Selfmon Nrpe agents Selfmon server Server/Service SSH/SFTP tcp 22 No Yes Yes Yes Configurable port.
status
Selfmon Nrpe agents Selfmon server Server/Service TCP socket tcp 5666 Yes Yes No No Configurable port.
status

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
SMPP Short Message Selfmon server Alarms SMPP tcp 2755 Yes Yes No Yes Configurable port.
Service Center
SNMPtrap Third party SNMP qsmnp Alarms SNMP udp 162 No Yes No No Qsnmp send
manager forward alarms to
3rd party
SNMPtrap qsmnp Third party SNMP Alarms SNMP udp 11162 No Yes No No Microtel send
manager alarms to qsnmp
SNMP qsmnp Third party SNMP Alarms SNMP udp 1161 No Yes No No
manager
key-server MICS eoFinder Client MSISDN-IMSI pair CORBA tcp Note 1 Yes Yes No No
rmiport Qes - Event QALARMS Statstics data for Java RMI tcp 2501 No No No Configurable port
Service Server selfmon interface in NIN file
rmiport Qchannel QALARMS Statstics data for Java RMI tcp 2502 No No No Configurable port
selfmon interface in NIN file
rmiport QSNMP Trap QALARMS Statstics data for Java RMI tcp 2503 No No No Configurable port
service selfmon interface in NIN file
rmiport_agent QSNMP Agent QALARMS Statstics data for Java RMI tcp 2504 No No No Configurable port
Service selfmon interface in NIN file
MCLS CORBA Binary/ tcp Corba No Yes No No

protocolbuffer defined
mclsadmtool TcpServer.P
qxdrs ort = 0
CIS Cisadm Binary tcp TcpServer.P No Yes No No
qxts ort = 65432

Security
Note 1 – Random port number

Note 2 – Default value is missing –changes after server configuration.
4.6.3 Port Numbers Used by NDAF

The port numbers listed below are the default ones.
Service Port
NameNode 8004, 8020, 50070, others
SecondaryNameNode 50090, others
JobTracker 8006, 8021, 50030, others
DataNode 50010, 50020, 50075, others
TaskTracker 50060, others
Notes: others” refers to ports

randomly chosen at runtime
Table 4.31 NDAF port numbers

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
HDFSMaster NDAF master NDAF enabled Filesystem IPC: tcp 8020 Yes Yes No No
application metadata ClientProtocol
(eoFinder Browse operations.
Loader etc)
HDFSSlaveData NDAF slave NDAF enabled DFS data transfer Custom Hadoop tcp 5001 Yes Yes No No
application Xceiver: 0
(eoFinder Browse DataNode and
Loader etc) DFSClient
HDFSSlaveMeta NDAF slave NDAF enabled Block metadata IPC: tcp 5002 Yes Yes No No
application operations and InterDatanodePro 0
(eoFinder Browse recovery tocol,
Loader etc) ClientDatanodePr
JobTracker NDAF enabled Job submission, IPC: 8021 Yes
NDAF master application task tracker JobSubmissionPr tcp Yes No No
(eoFinder Browse heartbeats. otocol,
TaskTracker NDAF slave NDAF enabled Communicating IPC: tcp Unkn Yes Yes No No
application with child jobs TaskUmbilicalProt own,
(eoFinder Browse ocol rand
WebUI NDAF master Web browser WebUI (HDFS) HTTP tcp 5007 Yes Yes No No
WebUI NDAF slave Web browser WebUI (HDFS) HTTP Tcp 5007 Yes Yes No No
WebUI NDAF master Web browser WebUI HTTP tcp 5003 Yes Yes No No
(MapReduce) 0
WebUI NDAF slave Web browser WebUI HTTP Tcp 5006 Yes Yes No No
(MapReduce) 0
Table 4.32 Detailed NDAF interfaces and port numbers (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
JMX NDAF master NDAF master Hadoop health JMX tcp 8004 No Yes No No
(Qmon script, data ,
selfmon script) 8006
Table 4.32 Detailed NDAF interfaces and port numbers (Sheet 2 of 2)
4.6.4 Port Numbers Used by Oracle
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
JDBC Oracle CDB Configuration JDBC tcp 1521 Yes No Yes
JDBC Oracle eoPathCommit Call/Transaction JDBC tcp 1521 Yes No Yes

parameters,
Configuration
JDBC Oracle qalarm Alarms JDBC tcp 1521 Yes No Yes
JDBC Oracle security Log messages JDBC tcp 1521 Yes No Yes
JDBC Oracle qdash KPI data JDBC tcp 1521 Yes No Yes
JDBC Oracle qes Alarms JDBC tcp 1521 Yes No Yes
Table 4.33 Detailed Oracle interfaces and port numbers (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
JDBC Oracle Fraud Call/Transaction JDBC tcp 1521 Yes No Yes

parameters
JDBC Oracle DWH KPI data JDBC tcp 1521 Yes No Yes It is used in
presence of ETL
separation.
OCI Oracle BO KPI data OCI tcp 1521 Yes No Yes
Table 4.33 Detailed Oracle interfaces and port numbers (Sheet 2 of 2)
4.6.5 Port Numbers Used by PostgreSQL
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
JDBC PostgreSQL eoFinder Browse eoDR, Call/ JDBC tcp 5432 Yes No Yes
Loader Transaction
parameters
JDBC PostgreSQL eoFinder Browse eoDR, Call/ JDBC tcp 5432 Yes No Yes
Server Transaction
parameters
Table 4.34 Detailed PostgreSQL Interfaces and port numbers (Sheet 1 of 2) (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
JDBC PostgreSQL CDB Configuration JDBC tcp 5432 Yes No Yes
JDBC PostgreSQL qalarm Alarms JDBC tcp 5432 Yes No Yes

JDBC PostgreSQL security Log messages JDBC tcp 5432 Yes No Yes
JDBC PostgreSQL qdash KPI data JDBC tcp 5432 Yes No Yes
JDBC PostgreSQL qes Alarms JDBC tcp 5432 Yes No Yes
Call/Transaction
JDBC PostgreSQL Fraud JDBC tcp 5432 Yes No Yes
parameters
Table 4.34 Detailed PostgreSQL Interfaces and port numbers (Sheet 2 of 2) (Sheet 2 of 2)

Security
4.6.6 Port Numbers Used by BO
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
https BO Client KPI data HTTPS tcp 8443 x Yes Yes Yes Sensible data in
case of VIP
monitoring
ftp BO External server Report result FTP tcp 21 x Yes No Yes Sensible data in
(not MC server) case of VIP
monitoring
Table 4.35 Detailed BO Interfaces and port numbers
4.6.7 Port Numbers Used by Rainstor
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
Rainstor jdbc/odbc CLU node eoFB Server KPI data JDBC/ODBC TCP 3731 Yes No Yes Sensible data in
case of VIP
monitoring
Table 4.36 Detailed Rainstor Interfaces and port numbers (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
Rainstor hsql db CLU node CLU node Instance metadata JDBC TCP 9001 No No Yes
corosync/cman CLU node CLU node reliable TCP socket UDP 5404 No No
(Cluster Manager) communications 5405
layer for high
availability clusters
dlm CLU node CLU node Distributed Lock TCP socket TCP 2106 No No
Manager 4
modclusterd CLU node CLU node provides an TCP socket TCP 1685 No No
abstraction of 1
cluster status
ricci CLU node CLU node propagates TCP socket TCP 1111 No No
updated cluster 1
information
Table 4.36 Detailed Rainstor Interfaces and port numbers (Sheet 2 of 2)

Security
4.6.8 Port Numbers Used by Vertica
through firewall
Authentication
Port Number
Encrypted
tcp/ udp
Sensible
SSHD Vertica CS Installation SSH Tcp 22 Yes No Yes Yes

nodes Vertica data
nodes
JDBC Vertica DWH KPI data JDBC Tcp 5433 Yes Yes No Yes
nodes
Vertica spread Vertica N/A DB data UDP Udp 5433 Yes No No no

monitoring nodes
Vertica nodes Vertica Vertica node Intra cluster TCP Tcp 5434 Yes No No No Intra-cluster
nodes communicati communication
on
Vertica Vertica Vertica node DB data TCP Tcp 5444 Yes No No No Management
Management nodes Console to agent
Console connection
Vertica Vertica Vertica node DB data TCP Tcp 5450 Yes No No No Console server
Management nodes
Console
Spread Vertica Vertica node DB data TCP Tcp 4803 Yes No No No Client
nodes connections
Spread Vertica Vertica node DB data UDP Udp 4803 Yes No No No

nodes
Table 4.37 Detailed Vertica Interfaces and port numbers (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
Encrypted
tcp/ udp
Sensible

nodes

nodes
rsync Vertica Backup DB data TCP Tcp 50000 Yes Yes No No Communication
nodes node between Vertica
nodes and
backup host
Table 4.37 Detailed Vertica Interfaces and port numbers (Sheet 2 of 2)
4.6.9 Port Numbers on MasterClaw Probes
tcp/ Port
udp Number
APM control tcp 11009

config tcp 11001 Only relevant if PPU and SIM reside on different boards
and in different locations, otherwise the connection is
event — 11002
SIM local.
Port number may vary (11010, 11020,...) depending on
the instance number of the probe application
Table 4.38 Port numbers on MasterClaw probes (Sheet 1 of 2)

Security
tcp/ Port
udp Number
MEAS-IF measif tcp 65000 Majority of probes (running QMPA5 application).
Port number may vary (65000, 65020, 65030)
depending on the instance number of the probe
application
X command — tcp 65001 Majority of probes (running QMPA5 application).
Port number may vary (65001, 65021, 65031)
depending on the instance number of the probe
application
Table 4.38 Port numbers on MasterClaw probes (Sheet 2 of 2)
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
LINK IF Physical link Probe SIM PDU, ip packets Yes No no

MEAS_IF Probe Mediation Server CSDR Call/ TCP socket tcp 6500 x Yes No No Configurable port
(qxdrs) Transaction 0
parameters,
protocol counters
MEAS_IF Probe Call Trace Server CSDR Call/ TCP socket tcp 6500 x Yes No No Configurable port
(qxts) Transaction 0
parameters, PDU,
Alarms
MEAS_IF Probe Raw Data Server PDU TCP socket tcp 6500 x Yes No No Configurable port
(rdas) 0
MEAS_IF Probe qxdrs protocol counters TCP socket tcp 6500 x Yes No No Configurable port
0
MEAS_IF Probe Info servers CSDR Call/ TCP socket tcp 6500 x Yes No No Configurable port
Transaction 0
parameters
Table 4.39 Detailed probe interfaces and port numbers (Sheet 1 of 2)

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
SIM_IF Probe QMPA Probe SIM PDU TCP socket tcp 1000 Yes No No Configurable port.
1-
1000
2 Can be considered
for firewall
configuration if the
SIM is not on the
same host as
QMPA.
SIM_RAWDATA_IF Probe SIM Probe QMPA PDU TCP socket tcp 1100 Yes No No Raw data.
5
SIM_INSPECT_IF Probe SIM inspect command SIM status TCP socket tcp 1100 No No No
6
X_IF Probe QMPA x command Probe status text tcp 6500 No No No Configurable port
1
Table 4.39 Detailed probe interfaces and port numbers (Sheet 2 of 2)
Table 4.38 and Table 4.39 list the ports of the first qmpa/SIM instance. Still, probes can be deployed with multiple instances of qmpa/
SIM, with each instance having its own port number.
Therefore, port numbers are assigned by default as follows:
Instance MEASIF x-command SIM-IF

Normal 65000 65001 11001-2,5-6
i2 65020 65021 11201-2,5-6
i3 65030 65031 11301-2,5-6
i23 65230 65231 13301-2,5-6

Table 4.40 Multiple instances port numbers

Security
Instance MEASIF x-command SIM-IF
i53 65530 65531 16301-2,5-6

4.6.10 Port Numbers on MasterClaw Info Servers
tcp/ Port
udp Number
tcp 11003
KEY-SERVER KSIF configurable via NIN file
udp 11004
USIM_CTXKEY_SRV KSIF tcp 11003 configurable via NIN file
11004
TMSI-IMSI-SERVER request tcp, udp 11006
configurable via NIN file
response tcp, udp 11007
APM control tcp 11009

watchdog tcp 11004 Obsolete, NT-APM only (HSL probe). Internal only
(between PPU and LCCPU)
MSISDN-IMSI- CORBA tcp Note 1 Used by finder. Configurable.
SERVER
Notes:
1. Random port number
Table 4.41 Port numbers on MasterClaw info servers

Security
through firewall
Authentication
Port Number
tcp/
Encrypted
Sensible
udp
TMSI_IMSI_IF IMSI TMSI Probe QMPA MSISDN, IMSI, TCP socket tcp 11006- x Yes No No
Infoserver TMSI, TMSI, 11007
Location, HO
parameters,
Procedure type
UMTS_TMSI_IMSI_IF IMSI TMSI Probe QMPA MSISDN, IMSI, (P- TCP socket tcp 11006- x Yes No No
Infoserver )TMSI, TMSI, 11007
Location
parameters,
Procedure type
Central IMSI-IMEI IMSI TMSI IMSI, IMEI(SV), TCP socket tcp x Yes No No
Infoserver/Key MSISDN
server
Central IMSI-IMEI eoFinder IMSI, IMEI(SV), CORBA tcp Note 1 x Yes No No
MSISDN
KSIF Key Infoserver Probe QMPA Ciphering TCP socket tcp 10003- x Yes No No
parameters 10004
KSIF Usim_ctxkey_srv Probe SIM Ciphering TCP socket tcp 10003 x Yes No No
parameters
MSISDN_IMSI_IF MSISDN IMSI Info eoFinder Client MSISDN-IMSI pair CORBA tcp Note 1 x Yes No No Configurable port.
server
X_IF / TI_IF Info servers x/ti command Status text tcp No No No
Table 4.42 Detailed Info servers interfaces and port numbers
Table 4.41 and Table 4.42 list the port related to the first infoserver instance. Still, infoservers can be deployed with multiple instances,
with each instance having its own port number.
Therefore, port numbers are assigned by default as follows:

Key_server and
Instance x/ti-command Tmsi_imsi_srv
usim_ctxkey_srv
Normal 65001 11003-4 11006-7
i2 65021 11203-4 11206-7
i3 65031 11303-4 11306-7
i23 65231 13303-4 13306-7
i53 65531 16303-4 16306-7
4.6.11 Port Numbers on HP ProLiant Servers
tcp/ Port
udp Number
OS HTTP tcp 2301 HP System Management:
web agent; web server
Administrative purposes (RAID controller
configuration SW)
HTTPS tcp 2381 HP System Management:
web agent; web server
Administrative purposes (RAID
controller configuration SW).
SSH tcp 22 Applies to iLO4, iLO3, iLO2
Customizable
HTTP tcp 80 Applies to iLO4, iLO3, iLO2
Customizable
HTTPS tcp 443 Applies to iLO4, iLO3, iLO2
Customizable
iLO Remote tcp 17990 Applies to iLO4, iLO3, iLO2
Console Port Customizable
Virtual tcp 17988 Applies to iLO4, iLO3, iLO2
Media Customizable
SNMP 161 Applies to iLO4
Customizable
SNMP Trap 162 Applies to iLO4
Customizable
IPMI/DCMI 623 Applies to iLO4
Table 4.44 Port numbers on HP ProLiant servers

Security
tcp/ Port
udp Number
SSH tcp 22 Establishes a connection to the remote Linux
HTTP tcp 80 Updates transfer

HTTPS tcp 443 A secure data port used to transfer information
HP SUM FTP tcp 21 FTP ports to perform switch updates

62286 Internal communications
X11 tcp/udp 6000 - X-server (remote execution of the HP SUM GUI)
6005
VNC tcp 5900 - VNC (remote execution of the HP SUM GUI)
5906
Table 4.44 Port numbers on HP ProLiant servers
4.6.12 Configuring CORBA Port Numbers in

MasterClaw
Checking Port To see which CORBA port numbers are actually used by the MasterClaw
Numbers in servers, issue the command qnsdump -o. The result contains both
MasterClaw MasterClaw service name, host name/address and port number.
Modifying Port When a user accesses MasterClaw through the Portal, applications run on
Numbers in the user’s workstation while the MasterClaw services run on remote servers.
MasterClaw The applications access the (remote) services over the network.
For example, MasterClaw clients establish CORBA connections with
MasterClaw servers like eoFinder Trace Server, Protocol Server.
To set up the communication between servers and the client, different port
numbers are assigned to different services.
MasterClaw services can use fixed or dynamic port numbers.
By default, port numbers are assigned dynamically by the CORBA
subsystem. Connection problems may be experienced when client and
servers are separated by a firewall, which allow only certain ports for
communications.
To ensure communication in such a scenario, it is possible to set the port
numbers to fixed values.
Find below how to set a fixed port number for the different MasterClaw
services. The process is slightly different for services written in C++ and for
those written in Java.
C++ servers For MasterClaw C++ servers, the port numbers configuration is made by
modifying the application nin file (or the global.nin file), located under
$QUEST7_ROOT/nin folder.
The example below shows how to configure port number 7777 (or any other
port number not in use in the system by other applications) for QXTS server:

# qxts.nin file
[qxts]
addr=0.0.0.0:7777
Port number 7777 for QXTS server can also be configured by applying the
same change at the end of the global.nin file, as follows:
# global.nin file
...
[presentation]
Version=6.4
[qxts]
addr=0.0.0.0:7777
[qps2]
addr=0.0.0.0:7778
...
C++ servers are listed below:
● QXTS
● RDAS
● QPS2 (included in protocol-servers)
● QFDS
● MICS
● MCLS
Java servers For MasterClaw Java server the ORB listening TCP port number
configuration is made by configuring the CORBA Java “system property”
called ooc.iiop.port.
For applications that do not invoke ORB.initORB, or to override the default

parameters, you can make an entry in $QUEST7_ROOT/nin/java.nin for the
application/server in question.
The example below shows how to configure port number 7779 (or any other
port number not in use in the system by other applications):
[server]
JAVA_VERSION=1.7.0
JAVA_OPTIONS=<options...> -Dcom.sun.CORBA.ORBServerPort=7779 -
Dcom.sun.CORBA.POA.ORBPersistentServerPort=7779
Java servers are listed below:

Security
Application Port number

CDB 8765, configuration in cdb.nin
QALARMS *
eoFinder Browse Server *
eoFinder Mediator *
eoLive Server *
QNSS 9876, Configurable during installation of
QNSS
Security *
Map Server *
Notes:port number configurable
Table 4.45 Java servers

4.7 Further Information on Interfaces
Here you can find more details for some of the interfaces described in the
above sections.
4.7.1 AGG_IN_IF
This interface is used by the DR Gateway Server to feed a DR Gateway
Server acting as an aggregator with eoDR which contains call/transaction
details.
This interface is not secure so it is needed to protect it by means of ipsec
channel/firewall.
4.7.2 AGG_OUT_IF
This interface is used by the DR Gateway Server to feed a eoLive server
with aggregated eoDR.
channel/firewall.
4.7.3 CORBA
This protocol is mostly used by:
● Java clients to communicate with servers.
● Servers to communicate with other servers (e.g. with CDB)
● Scripts to communicate with other servers (e.g. with CDB) usually during
packages installation in order to feed CDB or to administer a server.
The scripts are executed on the server where they are installed.
This protocol can be secured by creating an IPsec channel between them. It

is also recommended that clients run in a protected environment, e.g. virtual
host, terminal server on which only one user can log at a time or on which
the user has not the capability to capture IP traffic. The client can connect
using virtual desktop, remote desktop or other like ICA client.

Security
Fig. 4.20 Example of a network
This ensures that the user logged on the virtual host can only see its
unencrypted CORBA traffic and cannot see CORBA traffic related to other
users.
Alternatively, the virtual hosts can be configured to accept multiple users at
the same time, but then none of them shall have the capabilities to capture
traffic from the IP interfaces.
4.7.4 EOLIVE_IF
This interface is used by eoLive Client to get KPI from eoLive Server.
channel/firewall.
4.7.5 HTTP/HTTPS
This protocol is used by the web browser to connect to the MC Portal.
It is used also by java application to download their configuration file
(encrypted).
HTTP only is to configure alarm on DWH. This interface is not secure so it is
needed to protect it by means of ipsec channel/firewall.

4.7.6 JDBC
This protocol is used by applications to connect to Oracle and PostgreSQL
to store Configuration, DR detail, aggregated KPI.
channel/firewall.
4.7.7 KSIF
This interface is used by key server to get cyphering parameters used in the
Telecom network.
channel/firewall.
4.7.8 Link IF
This is the interface used by the probes to get Customer traffic. It is based
on several technologies and usually it is not encrypted (exception are GB
links). This means for example that from a probe an administrator can
capture traffic from Ethernet links.
4.7.9 MEAS_IF
This protocol is used by MC servers to connect to MC probe and download
CSDR, pdus or counters.
This protocol is not secure so it must be protected by means of ipsec
channel.
4.7.10 MICS_IF
This interface is used by the DR Gateway Server to feed MICS with
MSISDN-IMSI pairs.
channel/firewall.
4.7.11 NTP
This protocol is used to synchronize the clocks of servers and probes.

Security
4.7.12 SIM_IF
This interface is used by MC probes (QMPA) to connect to the SIMs
(Signalling Input Mediators) that collect raw traffic (signaling pdus, e.g. SIP,
or voice rtp packets).
channel/firewall.
4.7.13 Sftp
This protocol is used by:
● MC administrator to transfer files on the MC system (for example to
upgrade the system).
● MC applications to create the Oracle directory hosting the tablaspaces.
● DWH or by third party applications to download DR from MC mediation
servers or DOIP probes.
● Probe configuration software to download snapshot on probe/info
servers/key servers
● MC Self Mon for NRPE agent deployment
See section Section 4.7.14 Ssh for security mechanism.
4.7.14 Ssh
This protocol is used by:
● MC administrator to log on the MC system.
● Probe configuration software to configure probe/info servers/key servers
● MC Self Mon NRPE agent interrogation
The ssh parameters provided by default by sec-linux are:

Ciphers: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc
Authentication: PasswordAuthentication
4.7.15 TMSI_IMSI_IF
This interface is used by IMSI-TMSI infoserver and probes to retrieve
MSISDN, IMSI, TMSI, TMSI, Location, HO parameters, Procedure type
used to fill CSDR with IMSI and/or MSISDN.
channel/firewall.

4.7.16 X_IF
This is an administrative interface used to get mainly probe (QMPA)
statistics (e.g. # of collected CSDR, # of discarded CSDR) or configuration
info (e.g. installed protocols).
This interface is not secure so it must be protected by means of ipsec
channel/firewall.

Security
4.8 Internal Firewalls

A firewall can be activated on a linux server by deploying IPsec. It ensures
that incoming and outgoing network traffic is related to those connections
configured in CDB only.
Note: IPsec is a Special Customer Release feature only intended for
customers who requested it.

4.9 Protection of Subscriber
Confidential Data Sent Over
Networks
Data that flows in non secure networks could be protected in several ways:
● For Data warehouse and eofinder Browse, files from the XDR generator
gateway server to the DB can be sent via secure ftp (sftp)
● For the data warehouse and eofinder Browse, files from the DoIP to the
DB can be sent via secure ftp (sftp)
● Using VPN connections for non encrypted connection such as:
— probes and central server
— probes and mediation server
— mediation server and aggregators
● Using routers with HW encryption

Security
4.10 Protection of User Confidential

Data Sent over Networks
The user confidential data (passwords) sent over networks is protected via
Secure HTTP (HTTPS) in the MC Portal.

4.11 IPSec
If needed, it is possible to configure ipsec to use sha1 instead of the default
md5. Change the AH_PROTO=sha1 in ipsec.nin setting.
For more information, refer to Common ULP Installation Manual.
Note: IPSec is a Special Customer Release feature only intended for
customers who request it.

Security
4.12 Disk Encryption

The ULP provides the option to enable disk encryption. If implemented, it
ensure that the disk content is not accessible to others without authorization.
Please be aware that serious system performance penalty may occur when
you enable the disk encryption.
For more info, refer to Common ULP Installation Manual.

4.13 SUDO
Sudo is a linux utility that allows Unix administrators to provide specific users
with the right to execute programs that usually only root can run (e.g. rpm).
Sudo is required on the MC system to install (or upgrade):
● specific probe software/configuration
● ipsec-listen
● nagios daemons
By default, MC platforms will have sudo enabled on both servers and

probes. It is up to the MC administrator to disable sudo as soon as the above
software has been installed. Sudo can be re-enabled later only when a new
version has to be installed.
Sudo configuration file, /etc/sudoers, shall be edited by root using the

command:
# visudo
Probe Software/ The installation/upgrade of the following software packages require sudo to
Configuration be enabled on probes:
● qlinux-base
● qlinux-kernel-pfring
● apmlinux
● li-ether-sim
● li-hdlu-sim
● li-voip-sim
● li-usim
● li-usim-ip
NTP (re-)configuration requires also sudo to be enabled.
4.13.1 Disable sudo on Servers

To disable sudo, just log on the server and comment the following line in /
etc/sudoers file on probe:
ipsec-listen ALL=NOPASSWD:/etc/sysconfig/network-
scripts/ipsec-config
mclaw ALL=NOPASSWD:/bin/rpm
like:
#ipsec-listen ALL=NOPASSWD:/etc/sysconfig/network-
#mclaw ALL=NOPASSWD:/bin/rpm
Note that:
● To reconfigure ipsec, you need to uncomment the ipsec-listen line in

Security
sudo before deploying ipsec.

● To install MasterClaw Self Monitoring package, you need to uncomment
the mclaw line in sudo before starting the installation.
4.13.2 Disable sudo on Probe

To disable sudo, just log on the probe and comment the following line in /
etc/sudoers file on probe:
ipsec-listen ALL=NOPASSWD:/etc/sysconfig/network-
mclaw ALL=NOPASSWD:/bin/rpm, /sbin/shutdown, /
nettest/appl/bin/ntp_copy.sh
like:
# ipsec-listen ALL=NOPASSWD:/etc/sysconfig/network-
# mclaw ALL=NOPASSWD:/bin/rpm, /sbin/shutdown, /
nettest/appl/bin/ntp_copy.sh
Note: To install some packages and to reconfigure ipsec, it is required to

enable sudo before activating the snapshot or deploying ipsec.

4.14 Sec-Linux Tool
The Sec-Linux Tool is a platform package that can be used for Linux
enforcement.
This tool is described in detail in next Chapter 5. Sec-linux Tool.

5
Sec-linux Tool

Sec-linux Tool
5.1 Introduction
This Chapter describes how to install a security enforcement on a MC
platform.
This is done via the Sec-Linux tool, a platform package used for Linux
enforcement.
The root account is required for installing the tool and for applying the
security enforcements.
5.1.1 Overview
The Security tool is composed of several security enforcements (plugins).
Each plugin performs a specific security enhancement –to enforce ssh
connection, for instance. Plugins may require additional configuration. For
example, the plugin that stops unneeded services could be configured to
add a service that is normally stopped, but that may be needed by a third
party application.
The structure of the package is:
+-- bck
|
+-- bin
| +-- sec.sh
| +-- log_idle_users.sh/
|
+-- config
| +-- PRO
| +-- SRV
| +-- DEFAULT
| +-- CLU
| +-- 10.105.2.233
|
+-- lib
| +-- Actions
| +-- DefaultConfigFiles--DEFAULT
| +-- ScriptPlugin
| +-- Util
|
+-- log

where
- bck
Contains backup version of configuration files.
- bin
It contains the main program, sec.sh, and a shell that if needed will
be installed in the root crontab for logging idle connections.
config
It contains various configuration files. It is structured in subdirectories each
one containing a set of configuration files to differentiate the rules per server
type.
A configuration file is searched starting from the most specific directories in
the following order:
- IP address, address of the host
- PRO, if the probe plugin is installed on the host
- SRV, if the server plugin is installed on the host
If the file has not been found then the lesser specific is used, i.e. DEFAULT.
Some configuration files may be specialized for the underlying OS version.

The following strings may be part of the filename to specify the OS:
- centos6_4 for CentOS 6.4 only
- redhat6_4 for RedHat 6.4 only
- centosrh6_4 for both CentOS 6.4 and RedHat 6.4
In some cases it could be required to configure the files present in the

relevant directory before running the tool. This depends on the security
enforcement.
Among the configuration files you can find the sec.nin file used to select
the security level and, if more selectivity is required, to identify which
security enforcement has to be applied.
- lib
It contains private files used by the tool.
log
It contains log files. They will be cleaned if their size exceeds the maximum
size permitted.
5.1.2 Platform or Packages Updates

When the platform or a platform package (e.g. oracle) is updated, it is
necessary to apply the changes one more time, since the whole OS could
have been reinstalled or relevant files modified.

Sec-linux Tool
5.1.3 Warning
Some security issues may require a manual intervention from the
administrator to fix them. This could be the case where shell initialization
scripts build umask using variables instead of plain commands, like umask
022.
It is assumed that the system setting of the server is not altered from a
security point of view.

5.2 Setup
The stepwise procedure to setup the security enforcements is:
1. Install/Upgrade the SEC package
See Section 5.3 Installation and Section 5.4 Upgrade.
2. Choose the security level
See Section 5.5 Configuring Security Level.
3. Verify if all plugins belonging to the enabled security levels are needed
(optional)
See Section 5.6 Enabling/Disabling Plugins and Section 5.12 Plugins
Description
4. Perform the specific configuration that might be required by the chosen
plugins.
See Section 5.12 Plugins Description.
5. Run the tool and verify the output
See Section 5.10 Execution
6. Check whether the Linux system is fixed
See Section 5.11 Post Check
Note that if the ULP platform is upgraded, then the tool has to be reinstalled.
The files already configured will be preserved.

Sec-linux Tool
5.3 Installation
The package is installed using the platform patch manager, and it should be
the last package installed on a server (e.g. after Oracle, BO or probe
platform plugin).
If a platform plugin patch is installed afterwards, it might be necessary to
apply some of the security plugins again.
Note: The installation does not activate the security enforcements; the
administrator has to choose the security level.
To install the package, perform the following steps:
1. Copy the patch file to a directory not located into the /opt/anritsu/sec
directory.
2. Verify the checksum of the downloaded patch file:
# md5sum –c SEC_x.y.z.pkg.md5sum
SEC_x.y.z.pkg: OK
If the message does not return OK, you have to download the file again, and
repeat the above steps.
3. Install the patch using the command:
# platformPatchManager applyPatch <path>/

SEC_x.y.z.pkg
If some of the configuration files have been manually edited or changed in
the release, a warning message may appear (see example below). It is
recommended to check the differences. If they are only related to a
customization, then the modified version can be kept; otherwise, it is
recommended to rename the new file (same name of the original, with a
version suffix) and merge the manual changes applied in the previous
version.
Here is an example of warning message:
* /opt/anritsu/sec//config//DEFAULT/pam_sshd already
exists. If needed merge with /opt/anritsu/sec//config/
/DEFAULT/pam_sshd.x.y.z
* /opt/anritsu/sec//config//DEFAULT/sec.nin already
exists. If needed merge with /opt/anritsu/sec//config/
/DEFAULT/sec.nin.z.y.z

5.4 Upgrade
For the upgrade, follow the same procedure as installation – see Section 5.3
Installation.

Sec-linux Tool
5.5 Configuring Security Level

The first step is to generate the configuration files through command:
# sec.sh -s
This may be needed if some configurations have been altered and need to be
restored.
The second step is to choose the plugins that will be executed. This is
achieved by editing the sec.nin file.
The default sec.nin is located in /opt/anritsu/sec/config/DEFAULT/
directory.
The sec.nin file structure is composed of two sections:

● [General]
It is used to choose the security level through the SecurityLevel
setting, which may assume the following values (higher level
automatically includes the lower):
— Increase logging
Protect files
Enforce ssh/sftp
— Block unneeded accounts
Protect log files
Protect against various TCP/IP attacks
Protect filesystems
— Enforce login policies
Enforce system boot
Root access only from console
— Root cannot logon
Block users with failed login attempts
● [SecurityLevelX]
Where X could be 1,2,3 or 4.
It is used to refine the security plugins, mainly to disable some
enforcement that may add excessive constraints on the system. For more
information, see Section 5.6 Enabling/Disabling Plugins.
With setting 1, a plugin is enabled, e.g.:
add_sticky_bit_on_world_writable_directories
With setting 0, a plugin is disabled.
Therefore, sec.nin prepares the tool to apply all security enforcements
belonging to level 1 and 2; see example below:
[General]
SecurityLevel=2
[SecurityLevel1]
add_sticky_bit_on_world_writable_directories=1
...
The third step is to configure each plugin, where needed. This is described
in Section 5.12 Plugins Description.

To verify if the expected plugins are selected, use the command:
# sec.sh -l

Sec-linux Tool
5.6 Enabling/Disabling Plugins

Depending on the Customer solution, it could be needed to relax some
enforcement. For example, level 3 not only implies that nobody can login as
root using ssh/sftp, but also that it will be inaccessible from console.
Therefore, it may happen that if all passwords expire or have been locked,
the system becomes inaccessible.
The relevant part of sec.nin appears as follows (one section per security
level):
● SecurityLevel1
● SecurityLevel2
● SecurityLevel3
● SecurityLevel4
...
[SecurityLevel1]
add_sticky_bit_on_world_writable_directories=1
banner=1
crontab_protection=1
crontab_users=1
disable_ipv6=1
disable_user_mount_fs=1
enable_audit=1
enable_idle_session_logging=1
enable_remote_syslog=1
enable_accepting_remote_syslog=0
enforce_secure_connection=1
file_creation_mask=1
locate_unowned_files=1
remove_world_writable_permission_on_files=1
system_configuration_file_protection=1
enable_notification_failed_logins=1
[SecurityLevel2]
block_system_accounts=1
dos_prevention=1
enable_idle_connection_shutdown=1
enable_session_control=1
kernel_tuning=1

log_file_protection=1
no_dev_on_used_filesystems=1
remove_unneeded_accounts=1
tcp_ip_hardening=1
tcp_ip_disable_ping=0
tcp_wrappers=1
update_services_runlevel=1
[SecurityLevel3]
block_usb=1
enable_boot_loader_password=1
enforce_single_mode=1
login_policies=1
remove_setuid_setgid=1
restrict_root_login_to_console=1
enable_ldap_client=0
enable_kerberos_client=0
[SecurityLevel4]
block_direct_root_access=0
block_user_failed_login=1
enable_selinux=0

Sec-linux Tool
5.7 Configuring Plugins

Configure the enabled plugins whenever necessary. See Section 5.12
Plugins Description for information on each plugin configuration.

5.8 Command Summary
The tool has the following syntax:
sec.sh (-c|-e|-l|-s|-h) [-b][-v][-d][--noexec]
Where
-c) check if the current server configuration satis-

fies the security plugin requirements.
-e)execute command. To fix security on system.
-l)list command. To show which security plugin will
be executed marked with [Y] and those that will be
ignored, marked with [n].
-s)set default command. To set configuration files
to default values.
-b)enable backup of configuration files. It is exe-
cuted only with -e.
-v)verbose.
-d)debug mode.
--noexec print commands without executing them. No
changes will be applied to the system.
-h)this help.
Additional information is provided in the next sections.

Sec-linux Tool
5.9 Pre Check

To verify the current security status of the system, execute the command:
# sec.sh -c
It should return the following output:

* Excuting: /opt/anritsu/sec/bin/sec.sh -c
* Checking plugins.
* The following plugins will be checked:
enforce_secure_connection
block_usb
login_policies
* Checking plugin enforce_secure_connection.
* Checking /etc/ssh/sshd_config.
ERROR - AuthorizedKeysFile is missing.
[...]
* Checking user: hpsmh
* Skipped user hpsmh since it is blocked.
ERROR - Plugin login_policies check failed.
* Plugin Result
* enforce_secure_connection [F]
* block_usb [F]
* login_policies [F]
Output should end up with a summary of the check, as follows:

* <plugin name> [F/s]
where:
- [F] indicates that the plugin check failed and the security plugin
chosen is not applied on the system. Execution of plugin (e.g. with sec.sh –
e) fixes the system.
- [s] indicates that the plugin check succeeded, i.e. the system is
already configured to satisfy the plugin requirements.

5.10 Execution
To apply the security enforcements, execute the command:

# sec.sh -e -b
It will change the Linux host configuration and save the original files.
Note that the log is saved in /opt/anritsu/sec/log/<host ip address> and files
are backed up in /opt/anritsu/sec/bck/<host ip address> directory.
It should return the following output:
* Excuting: /opt/anritsu/sec/bin/sec.sh -e
* Executing plugins.
* The following plugins will be executed:
enforce_secure_connection
block_usb
login_policies
* Executing plugin enforce_secure_connection.
* Updating /etc/ssh/sshd_config.
[...]
* Skipped user hpsmh since it is blocked.
* Executing plugin login_policies. Done.
* Plugin Result
* enforce_secure_connection [s]
* block_usb [s]
* login_policies [s]
Output should end up with a summary of the plugins activation:
* <plugin name> [F/s]
where
- [F] indicates that the plugin enforcement cannot be applied
because of some error.
Note the few plugins do not change the system but reports only
where the system doesn’t meet the pluging requirement. The admin-
istrator shall then proceed manually. This is for example the case of
unowned files that shall be removed or assigned manually to some
linux account.
- [s] indicates that the plugin check succeed, i.e. the system has
been configured to satisfy the plugin requirements.

Sec-linux Tool
5.11 Post Check

To verify if the enforcements are in place, execute:
# sec.sh -c

5.12 Plugins Description
In order not to lose the configuration made on the system (e.g. in case of
ULP upgrades) it is recommended to change the plugin in configuration files
in the sec-linux home (/opt/anritsu/sec-linux), and to not change the system
configuration files directly.
For example, if you need to extend the list of hosts required by the tcp
wrapper, it is recommended to:
1. Modify sec-linux configuration file (e.g. /opt/anritsu/sec-linux/config/
DEFAULT/config/sshd.hosts) and not the /etc/sshd.hosts system.
2. Reapply the plugin (reinstalling the package whenever needed in case of
full ULP installation –not for patch installation).
5.12.1 Add Sticky Bit On World Writable Directories

Description The sticky bit is set on world writable directories.
Only the file owner (or superuser) can rename or delete a file in such
directories.
Note that a directory is traversed only if all its parents are world accessible.
5.12.2 Banner
Description Install login banner with advice on confidentiality of informations and on
restricted usage.
This will not disclose the OS type and version.
The permission will be set to “readonly” and the file will be owned by “root”
user/group.
The following files will be replaced:
● /etc/issue
● /etc/issue.net
Prerequisites You should consider the below prerequisite:
Parameter Description
Customer name The name to be used in the login messages
Configuration Replace “Anritsu” with the name of the customer in issue.anritsu

present in ConfigFiles directories.

Sec-linux Tool
5.12.3 Block Direct Root Access

Description Block direct root login on the host.
To gain root access as administrator, you first have to log with a personal
account to become root (su/sudo).
Note that this plugin conflicts with the Restrict Root Login to Console plugin.
If both are enabled, the last in sec.nin will overwrite the settings of the
previous.
Personnel List of people that shall logon the host for
administrating each administration purposes.
host.
Configuration For each administrator, create a personal Linux account enabling su/sudo
when needed.
Risk It may happen that nobody can connect to the system, e.g. because the
password expired (if expiry option is enabled) or have been locked.
5.12.4 Block System Accounts

Description Login to system accounts (i.e. with pid < 500) will be blocked, with the
exception of root, ipsec-listen, mclaw, mclawxdr, qpm, oracle, postgres and
vertica dbadmin accounts.
Risk Third party application that may add a system account with login capabilities
could stop working properly.
5.12.5 Block USB

Description Enforce the boot loader to not load USB.
Risk It will be no longer possible to mount an usb device; this may have an impact
on system maintenance. For example, usb could be needed for patching the
platform, then grub has to be manually updated by removing nousb from the
kernel parameters in /boot/grub/grub.conf.
Open with vi /boot/grub/grub.conf and edit the kernel lines that contain
the option nousb, removing the option. For example:
[…]
title Red Hat Enterprise Linux Server (2.6.32-
358.11.1.el6.x86_64)

root (hd0,0)
kernel /vmlinuz-2.6.32-358.11.1.el6.x86_64 ro root=/
dev/mapper/sys_vg-rootvol panic=30 pci=nommconf
numa=off vga=791 rd_LVM_LV=sys_vg/rootvol
LANG=en_US.UTF-8 apic=bigsmp pci=nommconf rd_NO_LUKS
rd_NO_MD crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us
SYSFONT=latarcyrheb-sun16 rd_NO_DM ide=nodma quiet
numa=off nousb
initrd /initramfs-2.6.32-358.11.1.el6.x86_64.img
Save the file and restart the server to get the new configuration.
5.12.6 Block User Failed Login

Description This plug in denies access in case of too many failed attempts.
By default, a user – other than root– is temporarily locked after 3 failed
attempts for 15 minutes.
Is it possible to verify if an account is locked using the following command:
# pam_tally2
And to reset a blocked account:
# pam_tally2 --user <user name> --reset
In the below example, the mclaw account is locked due too many failed
connection attempts:
# pam_tally2
Login Failures Latest failure From
root 1 08/09/13 18:07:24 172.28.35.141
mclaw 5 08/27/13 11:02:23 10.105.2.183
#pam_tally2 --user mclaw –reset
# pam_tally2 --user mclaw

Login Failures Latest failure From
mclaw 0
See pam_tally2 man page for more info.
Prerequisites Please consider the below parameters for verifying whether the Customer
requires different rules:

Sec-linux Tool
Max failed attempts The account is temporarily locked when this

limit is reached
Lock time
Lock root Root has to be locked too
Configuration It is possible to change:

● The number of failed attempts triggering the account locking
● The lock time
● The lock enabling also for the “root” account.
To do this, you need to modify the following settings on the ”auth

required pam_tally2.so“ line in pam_disable-user. E.g.:
auth required pam_tally2.so deny=3 onerr=fail
unlock_time=900
Where:
— deny – Number of attempts before locking the user (default: 3)
— unlock_time – Waiting time before login is allowed again (default:
900 secs). If the setting is removed, it is required the manual
administrator to unlock the account.
— even_deny_root –This setting can be added to block also root
(default: not present).
— root_unlock_time –Waiting time before allowing root login again
(default: not present). If the setting is not present, it requires the
manual administrator to unlock the account.
More information can be found on the platform in the text /usr/share/

doc/pam-0.99.6.2/txts/README.pam_tally2.
Risk When enabled, this option exposes the system to a denial of service attacks.
i.e. an attacker may try to login as oracle causing the oracle account to be
blocked. The oracle account will not be available even for MC system,
preventing normal operations until the account is restored.
5.12.7 Crontab Protection

Description Access to the following files is allowed to root account only:
— /etc/crontab
— /etc/cron.d
— /etc/cron.daily
— /etc/cron.deny
— /etc/cron.hourly
— /etc/cron.monthly
— /etc/crontab
— /etc/cron.weekly

5.12.8 Crontab Users
Description Restrict cron and at access to: root, mclaw and oracle.
/etc/cron.allow is replaced/created
/etc/cron.deny is removed.
/etc/at.allow is replaced/created
/etc/at.deny is removed.
User running crontab jobs Users other than root/mclaw/oracle that use cron. These additional users
could be needed by an integrated Third party application.
Configuration It other users require crontab (e.g. for third party applications), they can be
added in the cron.allow and at.allow configuration files,in the sec-
linux configuration directory.
5.12.9 Disable Ipv6

Description IPv6 support is disabled.
Requires host reboot.
5.12.10 Disable User Mounted FS

Description Disables user mounted removable file systems.
5.12.11 Dos Prevention

Description Improves the system tolerance to DOS attacks, by:
● increasing Linux auto tuning TCP buffer limits
● tuning or increasing TCP minimum, initial and max buffer size
● hardening the TCP/IP stack against SYN attacks.
Configuration The default values can be changed in sysctl_dos_prevention file.

Settings with their defaults values are:
net.core.rmem_max=8388608
net.core.wmem_max=8388608
net.core.rmem_default=65536

Sec-linux Tool
net.core.wmem_default=65536
net.ipv4.tcp_rmem=8388608 8388608 8388608
net.ipv4.tcp_wmem=8388608 8388608 8388608
net.ipv4.tcp_mem=8388608 8388608 8388608
net.ipv4.tcp_max_syn_backlog=2048
Usually, it is not needed to change them unless it is required to tune some

services, like nfs.
For more information, please refer to tcp man page on Linux.
5.12.12 Enable Accepting Remote Syslog

Description This plugin configures syslog to accept remote message from client syslog.
Risk The log space on the server hosting the central syslog daemon should have
enough space to hold logs also for remote machines. Otherwise, logs risk to
be lost.
5.12.13 Enable Audit

Description Enable linux auditd daemon.
It adds rules for monitoring security-related user activities.
An activity is considered relevant if it modifies one of the following files, or
changes their attributes:
● /var/log/audit/
● /var/log/audit/audit.log
● /var/log/audit/audit_log.1
● /etc/auditd.conf
● /etc/audit.rules
● /etc/libaudit.conf
● /etc/sysconfig/auditd
● /etc/init.d/auditd
● /boot/grub/grub.conf
● /etc/hosts
● /etc/sysconfig/
● /etc/sysctl.conf
● /etc/inittab

● /etc/init.d/
● /etc/modprobe.conf.d/
● /etc/modprobe.conf.local
● /etc/modprobe.conf
● /etc/ld.so.conf
● /etc/group
● /etc/passwd
● /etc/shadow
● /etc/shadow-
● /etc/gshadow
● /etc/gshadow-
● /etc/login.defs
● /etc/shells
● /etc/bashrc
● /etc/profile
● /etc/csh.cshrc
● /etc/csh.login
● /etc/aliases
● /etc/sudoers
● /etc/securetty
● /etc/pam.d/
● /etc/pam.d/system-auth
● /etc/pam.d/system-auth-ac
● /etc/pam.d/login
● /etc/pam.d/sshd
● /etc/security
● /etc/security/limits.conf
● /etc/ssh/moduli
● /etc/ssh/sshd_config
● /etc/ssh/ssh_host_key
● /etc/ssh/ssh_host_dsa_key
● /etc/ssh/ssh_host_rsa_key
● /etc/ntp/keys
● /etc/ntp.conf
● /etc/ntp/
● /etc/at.allow
● /etc/at.deny
● /var/spool/at
● /etc/cron.allow
● /etc/cron.deny
● /etc/cron.d/
● /etc/cron.daily/
● /etc/cron.hourly/
● /etc/cron.monthly/
● /etc/cron.weekly/

Sec-linux Tool
● /etc/crontab
● /var/spool/cron/root
● /etc/anacrontab
● /etc/issue
● /etc/issue.anritsu
● /etc/issue.net
● /etc/motd
● /var/log
● /var/log/faillog
● /var/log/lastlog
● /etc/localtime
● /etc/fstab
An activity is also relevant if it executes one of the following syscalls:

● sethostname
● adjtimex
● settimeofday
● clock_settime
● mount
● umount2
To simplify the search for specific operations, the following keys have been
defined. They can be used to filter audit logs:
Key Description
audit_log Actions on auditd log files

audit_cfg Actions on auditd configuration files
system_cfg Actions on system configuration files
time-change Date time changes events
filesystem Mount/umount related events
Configuration By default, no configuration is needed. However, in case it is required to add

additional rules to audit, they can be added in the audit.rules in the sec-
linux configuration directories.
It is possible to control the log file size and rotation in auditd.conf.
● auditd.conf: num_logs = 4
● audit.rules:
add additional lines like the following to monitor all the audit_log.XXX
files that can be generated if the previous setting, num_logs, has been
changed.
-w /var/log/audit/audit_log.XXX -k audit_log
See Linux auditd.conf man pages.
Risk Adding too many rules may result in a low performance-system due to high
logging.

5.12.14 Enabling Idle Connection Shutdown
Description Enables shutdown of idle connections.
Shell and ssh/sftp will be configured to have a timeout (15 minutes by
default) after which the shell or ssh/sftp connection will be closed.
Prerequisites Please consider the below parameter in order to verify if the Customer
Max idle time Max session inactive time accepted before closing a
login connection.
Configuration It is possible to change the timeout value, as follows:

1. Edit tmout.sh and set TMOUT (expressed in seconds) to the desired
value.
2. Edit autologout.csh and set autologout (expressed in minutes) to
the desired value.
3. Edit sshd_config_idle_connection_shutdown.
ClientAliveCountMax – number of client alive messages.
ClientAliveInterval – wait time before requesting client alive
messages.
The total timeout is given by ClientAliveCountMax x

ClientAliveInterval.
For more information, see Linux sshd_config man page.
5.12.15 Enable Boot Loader Password

Description Protects grub with a password.
The default value is elmi..
Prerequisites
Grub password Password used by the grub boot loader to unlock itself.
Configuration If needed, it is possible to change the default password by editing the

grub_password configuration file:
1. Execute the below command and provide the new password
# grub-md5-crypt
Password:*****
Retype password:*****
$1$ttlSY0$R2fxIifh9oXzVbwg0.Dgz/
Copy the output (in italics above).

Sec-linux Tool
2. Edit grub_password by replacing the old password with the previous

output, i.e. $1$ttlSY0$R2fxIifh9oXzVbwg0.Dgz/
Risk This precaution could not be sufficient since people having physical access
to the host could boot from another source, such as DVD or USB key/disk.
To block such attempts, it is suggested to use passwords also for the BIOS.
5.12.16 Enable Idle Session Logging

Description Enable monitoring of idle sessions.
Users having session whose idle time is greater than a specified threshold
are logged in:
/var/log/secure
The below example shows mclaw user having a session idle time of more
than 2 hours:
Feb 21 23:55:01 saturn IDLESESSION: mclaw from
(localhost.localdomain) idle time: 02:29
Idle timeout Idle sessions are logged if their idle time is longer than
this parameter.
Configuration The max idle time used to trigger the log is 5 minutes. It is possible to
change it by modifying the argument in the root crontab job in the
configuration file idle_session_log_crontab:
*/5 * * * * /opt/anritsu/sec/bin/log_idle_users.sh
5 > /dev/null 2>&1
Note that the crontab time and date fields shall be modified accordingly.
5.12.17 Enable Notifications Failed Logins

Description Enables notification of successful and failed log on:
● ssh
● Console/login

5.12.18 Enable Remote Syslog
Description This plugin configures syslog to send its log to a remote syslog daemon.
rsyslog is for CentOS/RedHat 6.4 while syslog for all the previous OSes.
Note that if a firewall is present then
port 514/udp should be open between the syslogs daemons (CentOS/
RedHat 5.5/5.8).
port 514/tcp should be open between the rsyslogs daemons (CentOS/
RedHat 6.4).
Prerequisites Please be aware of the following:
Central syslog IP The ip address of the server on which a centralized
address syslog daemon is running.
Client syslog IP The ip address of the servers on which syslogd is
addresses sending its logs.
Configuration Locally, edit the configuration file syslog_remote_server by inserting the

IP address of the remote syslog daemon.
On the remote host, configure syslog to accept remote logging:
1. Edit /etc/sysconfig/syslog by adding “-r” to SYSLOGD_OPTIONS. E.g.
SYSLOGD_OPTIONS="-m 0 -r"
2. Restart the service:
# service syslog restart
Alternatively, it is possible to use the “Enable Accepting Remote Syslog”

plugin.
Note that if a firewall is present, then port 514/udp should be open between
the syslogs daemons.
Risk The log space on the server hosting the central syslog daemon should have
enough space to hold logs also for remote machines. Otherwise, logs risk to
be lost.
Moreover, this setting may increase the amount of data transferred over the
network,and affect those services that depend on the available bandwidth
(TDR transfer, CSDR download, PDU collection,…).
5.12.19 Enable Session Control

Description This imposes limits on session numbers globally or per user.
By default, the max number of sessions per user is:
Ipsec-listen – 8
mclaw – 20

Sec-linux Tool
mclawxdr – 8
oracle – 4
qpm – 8
postgres – 4
nagios – 4
apache – 4
mysql – 4
Any other user – 2
Cuncurrent ssh/sft/login session Maximum number of active logins per user.
Configuration By default, limits change is not needed unless requested by the Customer or
in case of third party-additional users having their own limits.
The configuration file is session_limits.conf where:
maxlogins specifies the maximum number of active sessions for each

user.
In the example below, the system accepts 20 login with user mclaw and only
2 for other kind of accounts:
* - maxlogins 2
mclaw - maxlogins 20
See the Linux limits.conf manual page for more info.
Risk If the contraints are too small, the system may stop working properly, e.g. a
DWH cannot download xdr from a mediation server. Therefore, you should
consider the total number of simultaneous connections needed by all DWHs
or eoFinderBrowse loaders connected to the same mediation.
5.12.20 Enforcing Secure Connection

Description ssh will be configured in order to:
● Use securer protocols (ssh protocol v2)
● Use PAM
● Set the max number of attempts(2)/connections setup(4)
● Use securer cipher (aes128-cbc) and MAC (hmac-sha1)
Prerequisites Please consider the below parameters in order to verify if the Customer

MaxAuthTries Specifies the maximum number of authentication
attempts permitted per connection
MaxStartups Specifies the maximum number of concurrent
unauthenticated connections to the sshd daemon
Cipher Ciphers used by sshd
MAC Message authentication code algorithms
Configuration It is possible to change the configuration by modifying sshd_config in the

ConfigFiles directories. If also Enable Kerberos Client is activated, then the
configuration file used is sshd_config_and_kerberos, that doesn’t
disable GSSAPI.
The most relevant settings are:

MaxAuthTries
Specifies the maximum number of authentication attempts permitted per
connection.
MaxStartups
Specifies the maximum number of concurrent unauthenticated connections
to the sshd daemon. Additional connections will be dropped until
authentication succeeds or the LoginGraceTime expires for a connection.
Cipher
Specifies the ciphers allowed for protocol version 2.
MAC
Specifies the available message authentication code algorithms.
See ssd_config Linux man page for details such as a complete cipher list.
See also Section 5.12.6 Block User Failed Login, and Section 5.12.26 Login
Policies for additional settings related to the PAM module.
If you already have authorized keys that you would like to preserve, you can
copy/merge them from <user home dir>/.ssh/authorized_keys in
<user home dir>/.ssh/authorized_keys2 to avoid recreating them.
Risk If not properly configured, the functionality of MC could be affected. This

may happen for example if MaxStartups is too low for systems where there
could be more concurrent connections (e.g. probe).
Ssh/sftp client may need to be upgraded to support new ciphers.
5.12.21 Enforce Single Mode

Description Access in single user mode is allowed to root only.
The system will ask for the root password.

Sec-linux Tool
5.12.22 File Creation Mask

Description Set umask to 027 for all users.
The system shell initialization files will be affected (e.g. /etc/profile) as
well as home initialization files (e.g. ~/.profile).
Some warnings could be reported in presence of umask usage inside shell
comment initiated after a regular command. The plugin expects umask to be
expressed directly with octal form (e.g. umask 077).
Some umask settings could be missing e.g. if it executed in non standard
files (e.g. from a sourced) or executed with variable expansion.
Note: If there are still users with a wrong umask value, user shell initialization
script files might modify it (e.g. by sourcing a non standard file, by
using variable expansion, etc.). To fix the value, the user script files
have to be manually analized.
The login shell is supposed to remain unchanged; however, if the login shell
is changed, the plugin must be re-executed.
Once this plugin has been enabled, it might be necessary to install a
platform package or patch (e.g. Oracle_XXX_PA_YYY.pkg).
In such a case, it will be necessary to manually reset umask before applying
the update, as follows:
# umask 022
# platformPatchManager applyPatch <patch>
5.12.23 Kernel Tuning

Description Kernel Tuning plugin:
● Disables kernel system request debugging functionality kernel.
● Disables reboot thru ctrl+alt+delete
● Enables core with pid.
Risk It will be no longer possible to try to reboot the host, so to close the
processes in a clean manner (e.g. through the so called “REISUB” key
sequence).
This enforcement could be considered relevant if the host is not accessible
(because in such case it is possible to manually turn off the server or unplug
the power) or if the terminal is not accessible (e.g. because the host is
virtualized and only few users have the right to access it thru VMWare).
5.12.24 Locate Unowned Files

Description This plugin locates unowned files. It is up to the administrator to handle
them.

The administrator can:
● Assign these files to an existing user (not root) using the linux chmod
command
● Remove them, provided that no functionality is affected or relevant data
is lost.
5.12.25 Log File Protection

Description Log files in /var/log are protected according to the rules listed below.
● All files belong to root user
● All files belong to root or utmp group
● No files can be read by others with the exception of:
— lastlog
— sa/*
— wtmp
— /var/log/platformPatchManager/*
Note: Some applications may report an error because they are not able to
collect system log information. E.g.
cp: cannot open `/var/log/dmesg' for reading:
Permission denied
Such an error will not affect the normal operation of the application itself and
can be ignored.
Risk Analysis of system malfunctions could not be performed by mclaw

administrator only, since in some cases it is needed to analyze some system
logs accessible by root only.
5.12.26 Login Policies

Description Sets policies for password expiration and complexity for Linux account.
Password expiration is not imposed on the following users:
● root
● ipsec-listen
● mclaw
● mclawxdr
● qpm
● oracle
● postgres
Policies are:
● Password expiration (90 days default, note that other Customers may

Sec-linux Tool
require 365 days for administrators.)

● Account Lockout when not in use.
● Strong password policies.
● HOME Directory assigned.
● Logs the service, terminal, user, remote user and remote host to syslog
● Blocking of root login (optional)
● Blocking of an user after anumber of failed logins (optional)
A password is considered “strong” provided that:

● It is min 8 char long; other customers may require 14 char for
technological and internal accounts. 14 is the default value.
● It allows max 3 retries
● It has max 3 char different from the previous passwd
● It has minimum 1 lowercase, 1 uppercase, 1 digit, 1 other char (#$!...)
● The last 12 passwords are remembered
Forcing password changes every 90 days and remembering the last 12

passwords, prevent them from being reused within 90*12 days = ~36
months (or less if the user changes the password more frequently).
If necessary, modify the arguments to ensure compliance with the customer
organization’s security policy. Note that the password quality requirements
are not enforced when commands are executed with the root account
(however, a warning may be provided).
Prerequisites Please consider the below parameters in order to verify if the Customer
Password expiration
Password expiration warning
period
Password complexity password criteria:
- minimal length
- number of lowercase characters
- number of uppercase characters
- number of digits
- number of special characters (e.g. !#)
Maximum login attempts
Password history A password cannot be reused if already present in the history.
Configuration Password expiration

To change the password expiration time, update PASS_MAX_DAYS in
login.defs (default: 90).
More info in Linux login.defs man page.

Password expiration warning period.
To change the number of warning days before password expiration, update
PASS_WARN_AGE in login.defs (default: 28).

More information can be found in Linux login.defs man page.
Password complexity and Maximum login attempts
The following settings can be used to configure how the password has to be
created.
Open pam_system_auth and edit in the ”password required
pam_cracklib.so“ line:
password requisite pam_cracklib.so retry=3

minlen=14 difok=5 lcredit=1 ucredit=1 dcredit=1
ocredit=1
Where:
— retry –number of failed attempts before giving up a login attempt
(default: 3)
— minlen – Minimum size of passwords (default: 14)
— lcredit – Number of lower case letters (default: 1)
— ucredit – Number of upper case letters (default: 1)
— dcredit – Number of digits (default: 1)
— ocredit – Number of other characters, e.g. #$!. (default: 1)
More information can be found in text /usr/share/doc/pam-0.99.6.2/

txts/README.pam_cracklib.
Password history
The password history can be configured in the pam_unix.so line of
pam_system_auth:
password sufficient pam_unix.so sha512 shadow
nullok try_first_pass use_authtok remember=12
With setting remember=12 and with an expiration time of 90 days, the

password history can be approximated to ~36 months. If the password is
changed more frequently, then this setting has to be increased to have an
history covering the same period.
The history can be disabled by removing the remember setting from the
pam_system_auth file.
More information can be found in text /usr/share/doc/pam-0.99.6.2/
txts/README.pam_unix.
Risk If user passwords on which MasterClaw depends on expires, then

MasterClaw might stop working properly.

Sec-linux Tool
5.12.27 Nodev on Used Filesystems

Description Set nodev on the used filesystems (ext2, ext3 and xfs) to prevent the user
from mounting such a kind of device.
Set nodev on mountable filesystem (e.g. cdrom, floppy) to prevent a user

other than the administrator from mounting them.
Root filesystem, /, will not be affected.
5.12.28 Remove World Writable Permission on Files

Description Remove world writable permission from files accessible by any user. Only
the owner or its group could write it, depending on the permission.
Note: Files world writable under /opt/anritsu/mclaw are left untouched even
having write permissions, since /opt/anritsu/mclaw does not allow
users other than mclaw (or root) to access them.
5.12.29 Remove Setuid Setgid

Description Removes setuid and setgid from executables files with the exception of:
● /bin/ping
● /bin/su
● /usr/bin/at
● /usr/bin/crontab
● /usr/bin/passwd
● /usr/bin/sudo
● /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
● /usr/lib/vmware-tools/sbin32/vmware-hgfsmounter
● /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
● /usr/lib/vmware-tools/sbin64/vmware-hgfsmounter
Files with setuid/ List of files that require setuit or setid.
setgid These files are installed manually on a server, e.g.
because required for third party integration.
Configuration Edit setuid_setgid_programs adding the list of files that shall preserve the
setuid/setgid attribute.

Risk Some commands will no longer work for users other than root. For example,
a user cannot change its login shell, while root can.
5.12.30 Remove Unneeded Accounts

Description Blocks or remove unneeded user accounts.
The administrator shall check the configuration to verify whether all users
expected on the host are listed.
The users configuration file (users.centosrh6_4 in case of CentOS/
RedHat 6.4) contains the following list of users that should be kept.
For server with SRV installed:
B abrt
K adm
B apache
B avahi
K bin
K daemon
K dbadmin
B dbus
B ftp
B games
B gopher
B haldaemon
K halt
K hpsmh
K ipsec-listen
B lp
B mail
K mclaw
K mclawxdr
B mysql
B named
B nagios
B nfsnobody
K nslcd
B nobody
K ntp
B operator

Sec-linux Tool
B oprofile
K oracle
B postfix
K postgres
B qpm
K root
K rpc
K rpcuser
B saslauth
K shutdown
K spread
K sshd
K sync
B tcpdump
B tss
B uucp
B vcsa
For CLU:
K adm
B ais
B apache
B avahi
B avahi-autoipd
K bin
K daemon
B dbus
B distcache
B ftp
B haldaemon
K halt
K ipsec-listen
B luci
K mclaw
K mclawxdr
K nagios
K nfsnobody
K nobody

K ntp
B oper
B operator
B oprofile
B pcap
B qpm
B ricci
K root
K rpc
K rpcuser
K shutdown
B smmsp
K sshd
K sync
B uucp
B vcsa
B xfs
Each line contains a user with a K or B prefix:
K – keep. The user is not modified.
B – block. The user is blocked.
Any user not listed above is removed from the system.

Home directories, cron and at jobs will be removed as well.
List of required users List of users that have to be kept (not
deleted and not blocked).
These are usually required for third party
integration.
Configuration Add in the users configuration file (users.centosrh6_4 in case of

CentOS/RedHat 6.4) the users you want to keep.
Risk Some relevant services might stop working if the list is not correct or user
data is deleted.

Sec-linux Tool
5.12.31 Restrict Root Login to Console

Description Enables root connection only from console.
Note that this plugin conflicts with the Block Direct Root Access plugin. If
both are enabled, the last in sec.nin will overwrite the settings of the
previous.
Risk No remote administration is possible. This may happen for example if a user
account used to login cannot be used e.g. due to password expiration (if
expiry is enabled) or locking after too many failed access attempts.
5.12.32 Sftp only mclawxdr

Description The user mclawxdr is not allowed to login thru ssh; he can only use the sftp
service on the host.
5.12.33 System Configuration File Protection

Description Configuration files in /etc/ should have the right owner/group and
protection to reduce as much as possible the possibility that users other than
root (or daemons) access them to modify/execute/read.
All files generated by the system administrator can only be modified by the
system administrator. Access by other users to files of the system
administrator must be read-only or executive.
There are however some exceptions:
● etc/logrotate.d – It may belong to the “mclaw” group and it may contain
files owned by mclaw. No problem will occur because of this, since the
“mclaw” user is used when logrotate is executed.
● Nagios configuration files are owned by nagios and mclaw:
/etc/httpd/conf.d/nagios.conf
/etc/httpd/conf.d/nagiosgraph.conf
/etc/httpd/conf.d/nagvis.conf
5.12.34 TCP IP Hardening

Description It configures TCP/IP stack to protect the system from various network
attacks, such as:
● SYN attacks
● IP addresses spoofing
● IP Source Routing
● Routers that send out invalid responses to broadcast frames

● Log Spoofed Packets, Source Routed Packets, Redirect Packets
● Disable packet forwarding
● Enable Ignoring Broadcasts Request (not in case of CLU platform)
Configuration By default it is not needed to change the configuration, which is stored in

sysctl_tcp_ip_hardening.
For more information about the net ipv4 settings, refer to:
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
5.12.35 TCP IP Disable Ping

Description It configures TCP/IP stack to disable ping, for instance to ignore the ICMP
Requests.
Note that some MasterClaw applications, as for example Self-Mon, depends
on this functionality; therefore, it can be disabled only when the impact on
MasterClaw has been verified. For the same reason, this plug-in is disabled
by default.
Once disabled, in case of necessity it can be enabled temporarily by root,
with command:
# sysctl -w net.ipv4.icmp_echo_ignore_all=0
When no longer needed, it can be disabled again with:
# sysctl -w net.ipv4.icmp_echo_ignore_all=1
Risk Some MasterClaw applications may stop working properly since they
depends on ping, e.g. to verify if a host can be reached (see in Selfmon if the
ping checks are enabled).
5.12.36 TCP Wrappers

Description It restricts the network access to services thru tcp wrappers.
Only the following services will be enabled:
● ssh/sftp
● snmptrapd
Connection to the enabled services will be controlled by the following files:

● /opt/anritsu/sec-linux/config/DEFAULT/config/sshd.hosts
● /opt/anritsu/sec-linux/config/PRO/config/sshd.hosts
● /opt/anritsu/sec-linux/config/SRV/config/sshd.hosts
● /opt/anritsu/sec-linux/config/<ip address>/config/sshd.hosts (where
needed).
● /opt/anritsu/sec-linux/config /DEFAULT/hosts.allow (also for snmptrapd)
Once you have modified this file, re-enable tcp.wrappers plugin to update
the system configuration file /etc/sshd.hosts.

Sec-linux Tool
Successful ssh attempts are logged in authpriv syslog facility with a priority
of informational.
Failed attempts are logged in authpriv syslog facility with a priority of
notification.
The messages can be found in /var/log/secure by filtering with
FILTERSESS.
If Portmap is running, it will be restarted.
An alternative is the use of firewall, or IPsec solution which includes firewall
settings and does not require manual configuration.
Prerequisites It is required to know the following info:
MC hosts address List and type of all the hosts deployed at a Customer site.
Configuration It is required to edit the security tool sshd.hosts configuration file.

It shall contain the list of servers from which ssh and sftp connection can be
established.
Typically, sshd.hosts should contain IP addresses or names. The use of
names should be avoided if the portmap service is running (this is needed
for NFS).
sshd.hosts on the Central Server can be configured with additional lines
for administrators connecting from outside the MC system.
The most straighforward configuration may contain all the IP addresses of

the MC hosts. It is also possible to use a more precise configuration, where:
● A central server can accept the connection from a limited number of
external hosts
● Probes can accept connection only from Central Server, Mediation
Server or IP Service KPI backend
● A mediation server can accept connection from Central Server or DWH
fed by its DRs.
The address can be provided also in these forms:

- IP address ending with “.” to accept all hosts sharing the initial numeric
groups of an IP address. E.g.
10.105.2.
172.28.35.
- IP address/netmask pair, e.g.
10.105.0.0/255.255.254.0
to accept all host with IP in the range 10.105.0.0 - 10.105.1.255
If needed, it is also possible to update the hosts.allow in the security

configuration directory. It will be copied in /etc/hosts.allow.
For more information on how to configure hosts.allow, see the linux man
page hosts_access in section 5 (e.g. with the command: man 5
hosts_access).

For example, to let snmptrapd accept traps from a specific machine:
sshd: /etc/sshd.hosts: spawn \logger -p authpriv.6 -t
FILTERSESS access authorized from %c to %d : allow
ALL: localhost
ALL: LOCAL 127.0.0.1
snmptrapd: 172.29.01.141:allow
ALL: ALL: spawn \logger -p authpriv.0 -t FILTERSESS
access not authorized from %c to %d: DENY
Risk It won’t be possible to login from an external system if the configuration is

not correct or updated.
This could also implies that some MC component depending on ssh/sftp
may stop working properly. In such a case, the login will be possible from the
console only.
5.12.37 Update Services Runlevel

Description This plugin stops all unneeded services and start the ones required (if down
by default) for running level 3.
The list can be configured by adding additional services that may be needed
for special customer solutions.
require different rules:
List of required Additional services that are required by third party
services applications or intended as a specific Customer solution.
Configuration The default configuration is sufficient.

However, if the Customer solution requires special services, check the
service list in server_services.txt file or in or
server_services.centosrh6_4.txt file. Note that you can find
different versions in the DEFAULT, PRO and SRV configuration sub
directories. PRO is for probes and SRV for servers.
For each service there could be a line with two fields: service name, required
status.
The required status may assume one of the below values:
● on – the service is added and started;
● off – the service is stopped and removed;
● ignore – the service is ignored, i.e. its status is not modified.
All services not present in the list will be stopped.
If you intend to configure and use IP tables firewall, add iptables on to
the list.
If you intend to use the HP PSP service pack, add lm_sensors on to the
list.

Sec-linux Tool
Note that if you need to access CD-ROM or DVD, the rawdevice service
has to be manually started and stopped when it is no longer needed.
In case of MasterClaw server customization for a special customer solution
relying on additional not default services, the server_services.txt file
or server_services.centosrh6_4.txt file have to be updated with it.
Risk If not properly configured, some functionalities may stop working.
5.12.38 Enable Selinux

As of the time of this writing, this plugin is not available.

6
System Maintenance

System Maintenance
6.1 Certificate Maintenance
6.1.1 Signing of Java Applications

The MasterClaw Portal (portal) signs Java applications with a Certificate. A
certificate is issued by a trusted Certificate Authority and guarantees the
software is published by Anritsu.
In MasterClaw, the certificate used for Java Applications is issued by Verisign
and included in the standard Portal installation.
6.1.2 SSL Certificate Management

In order to have the MasterClaw Portal (portal), MC Self-monitoring and
Insight Server running in Secure Mode (over SSL), they need an SSL
Certificate. This certificate must be issued to the organisation that owns the
Portal server. A certified SSL certificate is therefore not part of the
MasterClaw product.
Portal The Portal will use a SSL certificate placed in the keystore used by portal:
$QUEST7_ROOT/installed/portal/lib/key/mckeystore
The Portal will create an uncertified dummy certificate at start if a certificate

is not found at the location. The dummy SSL certificate is valid for one year.
To create a new certificate, follow the instructions given in Portal Installation
and Configuration Manual.
MC Self-Monitoring Selfmon uses the Apache httpd SSL certificate. It is located by default in:
/etc/pki/tls/certs/localhost.crt
That location is defined in /etc/httpd/ conf.d/ssl.conf by the SSLCertificateFile
setting.
The ULP will create an uncertified dummy certificate at installation time. The
dummy SSL certificate is valid for one year.
To create a new self-signed certificate:
1. Execute as root:
# openssl req -new -x509 -nodes -out server.crt -keyout
server.key
2. Edit SSLCertificateFile in /etc/httpd/ conf.d/ssl.conf:
SSLCertificateFile /path/to/this/server.crt
SSLCertificateKeyFile /path/to/this/server.key
3. To add a passphrase to the key use:
# openssl rsa -des3 -in server.key -out server.key.new

# mv server.key.new server.key
To create a CA signed SSL Certificate:

To create a RSA private key for your Apache server (e.g. encrypted with
AES 128 and with PEM format), follow the below procedure.
1. Generate the key file by executing as root the following command:
# openssl genrsa -aes128 -out server.key 1024
The above command will prompt for a passphrase; backup this server.key
file and the pass-phrase.
For any information on the openssl options, refer to the openssl man pages.
2. Create a CRS (Certificate Signing Request) file, for which you will need
to enter:
— Country Name, 2 letters
— State/Province
— Location
— Organization
— Organizational Unit
— Common name (server's fully qualified domain name)
— Email
— Password
Execute command:
# openssl req -new -key server.key -out server.csr
and then submit the information listed above.
3. Submit server.csr to your CA to get the custom certificate for the server:
server.crt.
4. Edit SSLCertificateFile in /etc/httpd/ conf.d/ssl.conf as follows:

SSLCertificateFile /path/to/this/server.crt
SSLCertificateKeyFile /path/to/this/server.key
5. To avoid Apache asking for the pass-phrase, execute the below

commands (which might imply a reduced security, though):
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# chmod 400 server.key
Insight Server BO uses an uncertified dummy certificate. It is not yet possible to change it.

System Maintenance
6.2 Disk Space Availability

You should periodically check that the file systems on MasterClaw server
machines do not run full. Especially check that there is disk space free in the
following directories on a ULP platform: /tmp, /var/log, /var/opt and /opt/
anritsu
Issue the following commands:
df -h /tmp /var/tmp /var/log /var/opt /opt/anritsu
it returns:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sys_vg-tmpvol
2.0G 95M 1.8G 6% /tmp
/dev/mapper/sys_vg-rootvol
7.8G 3.2G 4.3G 43% /
/dev/mapper/sys_vg-logvol
3.9G 238M 3.5G 7% /var/log
/dev/mapper/data_vg-varoptvol
155G 29G 126G 19% /var/opt
/dev/mapper/data_vg-usrvol
9.7G 5.2G 4.0G 57% /opt/anritsu
Note: Depending on the platform installed, the three directories may stem
from the same file system, as shown below:
df -h /tmp/ /var/tmp/ $QUEST7_ROOT/
it returns:
Filesystem Size Used Avail Use% Mounted on
none 30G 5.6G 24G 20% /
none 30G 5.6G 24G 20% /
none 30G 5.6G 24G 20% /
Check the Avail and USE% columns. If you do not have sufficient disk space
available, then you must clean up. You can for instance free disk space by
deleting old log files.
To check the inode usage, perform the command:

df -i
It will return:
Filesystem Inodes IUsed IFree IUse%
Mounted on

/dev/mapper/rootvg-rootvol
4169728 2083368 2086360 50% /
/dev/sda1 26208 40 26168 1% /boot
none 1020265 1 1020264 1% /dev/shm
/dev/mapper/datavg-datavol
4472832 216212 4256620 5% /data
Check the IFree and IUse% columns. If you do not have sufficient inodes
available, then you must clean up. You can for instance free disk space by
deleting old log files. Note that the output may change depending on the host
type.

System Maintenance
6.3 Protocol Maintenance
6.3.1 Adding New Protocols

MasterClaw protocols are delivered as standard MasterClaw packages, and
you use the QBASE command q7adm to install a new protocol. For instance
to load a protocol named: protocol-GPRS_GB-1.6-4.2,
you would use the command:
q7adm install protocol-GPRS_GB-1.6-4.2.tar.Z
It is legal to include a full path to the package, as in:

q7adm install /tmp/protocol-GPRS_GB-1.6-4.2.tar.Z
6.3.2 Updating Protocols

To update a protocol, use the QBASE install command together with the -u
option:
q7adm install -u protocol-italy-unx0@EEE-2.5.tar.Z
It is legal to include a full path to the package, as in:

q7adm install -u /tmp/protocol-italy-unx0@EEE-
2.5.tar.Z
6.3.3 Uninstalling Protocols

To uninstall:
q7adm uninstall
Conditions for To successfully uninstall a protocol, a number of conditions must be fulfilled

uninstall in CDB, such as:
● No SignallingLinkSets can be attached to the ProtocolPackage.
● No SignallingLinkset ProtocolDialogueFormat can refer to any
ProtocolDialogueFormatPerLayer of the Protocol Package. The qprotinst
tool will remove any dangling ProtocolDialogueFormatPerLayer
automatically. Any custom configuration of Formats per Layer will be lost.
If any of these criteria are not adhered to, the tool will issue a number of error
messages on standard output, and nothing will be removed from CDB.

6.4 Timezone Updater
It is recommended to always check for updates and to perform time zone
definition update during the installation, as well as before each daylight
savings switch date.
6.4.1 Installation
Download the TZUpdater tool bundle archive from
http://www.oracle.com/technetwork/java/javase/downloads/tzupdater-
download-513681.html
and unzip it into an appropriate directory.
6.4.2 Usage
The TZUpdater tool modifies the JDK/JRE software instance that is used to
execute the tool. A single image of the JDK/JRE software is modified per
execution. To administer the tool to multiple instances of the JDK/JRE
software, see Section 6.4.3 Systemwide Usage.
You must stop any running instances of the JDK/JRE software to be operated
upon before you run the TZUpdater tool on that installed JDK/JRE software
image.
Run the TZUpdater tool with the following commands:
java -jar tzupdater.jar
options
To update timezone data successfully, you should ensure that you have
sufficient privileges to modify the JDK_HOME /jre/lib or JRE_HOME /lib
directory.
If you do not have sufficient privileges to modify these directories, contact
your system administrator.
If you do not specify any options, the usage message is displayed. To update
the timezone data, specify either the -u or -f option.
Option Description
Print the usage to stdout and exit. Other options are
-h, --help ignored if you specify this option.
Show the tool version number and the tzdata version
-V, --version numbers of the JRE software and the archive embedded in
the JAR file and exit.
Table 6.1 TZUpdater options (Sheet 1 of 2)

System Maintenance
Option Description
Update the time zone data and perform verification tests. You
can run the verification tests separately with the -t option. If
-u, --update you specify the -h, -t, or -V options, the command displays
the usage to stdout and exits.
Force update the tzdata even if the version of the tzdata
archive is older than the JRE software's tzdata version.
-f, --force This option does not require the -u option to perform the
update. This option is not needed under normal operating
conditions.
-v, --verbose Display detailed messages to stdout.
Keep backward compatibility with the JDK version 1.1 three-
-bc, -- letter timezone IDs, "MST," EST,"and "HST." Any timezone
backwardcompa IDs that conflict with the JDK version 1.1 timezone IDs will be
tible removed from the installed timezone data. You must specify
the -bc option with the -u, -f or -t option.
Run verification tests only and exit. If the JRE has timezone
data that does not match the data in the tool, the verification
tests report errors and fail. The -f option is ignored if
-t, --test specified. If you specify the -bc option, any test cases for
timezone IDs that conflict with the JDK version 1.1timezone
IDs will be ignored.
Table 6.1 TZUpdater options (Sheet 2 of 2)
6.4.3 Systemwide Usage

You must stop any running instances of the JDK/JRE software to be
operated upon, before you run the TZupdater tool on that installed JDK/JRE
software image.
Systems can accrete multiple copies of JDK/JRE software images;
therefore, you might need to apply the tool individually to each JDK/JRE
software image.
Find here below how to locate multiple installed copies of the JDK/JRE
software on Unix derivative systems. Microsoft Windows users can use the
desktop search utility.
1. Find locally installed JDK/JRE software instances for Unix derived
systems:
/usr/bin/find
DIRPATH -fstype nfs -prune -o -fstype autofs -prune -
o -name java -print -exec {} -version \;
Where DIRPATH is a directory path to search under for installed instances of
the Java SE platform; for example /usr.
2. Automate updating of locally installed instances:
/usr/bin/find
DIRPATH -fstype nfs -prune -o -fstype autofs -prune -
o -name java -print -exec {} -jar /
ABSOLUTEPATH/tzupdater.jar -u \;

Where DIRPATH is a directory path to search under for installed instances of
the Java SE platform. For example, /usr. ABSOLUTEPATH should be
replaced with the full path name to the directory into which tzupdater.jar
is expanded.
Example of java The java timezone functioning is outlined in a script that:

timezone usage
1. Gets the system timezone:
grep "ZONE" "/etc/sysconfig/clock"
e.g. in case of a Mexico City operator, this should return: ZONE=”America/
Mexico_City”
2. Computes the actual timezone offset and determines whether DST is
applied or not (e.g. 6:00 true)
3. Looks into java-timezones file to see if the system timezone is defined in
it, and if the timezone offset matches (e.g. 6:00 true America/
Mexico_City).
i.e. java timezone would be as America/Mexico_City in this case
4. If the system timezone is not in the list, or if the timezone offset does not
match, it will select the first timezone in the list with the same timezone
offset that was computed in step 2 (in our case, line “6:00 true CST”).
i.e. java timezone would be as CST in this case
To make sure that the timezone has been properly set, the system support
needs to execute the following command again:
grep "ZONE" "/etc/sysconfig/clock"
and then check if the zone name is the same as in the JAVA_TZ
environmental variable.
If so, then zone is set correctly. If not, then a further check is necessary to
determine whether those two zones have the same time offset and the same
DST rules or not.
For more information see:
http://www.oracle.com/technetwork/java/javase/documentation/tzupdater-
readme-136440.html
For Timezone Data Versions in the JRE Software see:

http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html

7
Back-up and Recovery

7.1 General Information

It is essential that you regularly perform back-up of the servers on which you
run the MasterClaw system. A back-up enables you to restore parts of the
system in case of hardware failures or human errors.
MasterClaw runs on so-called servers, which are computers of high quality
that in addition contain redundant hardware components to avoid single point
of failures, e.g., redundant power supplies and multiple network interface
cards, and fault-tolerant disk systems. But fault-tolerant hardware is no
substitute for a back-up in case you lose multiple disks or the building burns
down. You may also find use for your back-up in case a human deletes
essential files that you require to continue running the system.
For detailed information on Oracle back-up and recovery, please refer to
System Installation and Configuration Manual.

7.2 Backup Procedure
The following sections describe the procedure for backup setup and for
restoring it on various types of MC servers.
Conventions Further down in this Section, commands that shall be executed as root are
prefixed with #, e.g.
# mc_backup –e mediation-server-defaults.nin
Commands that shall be executed as mclaw are prefixed with > e.g.
> /opt/anritsu/mc_backup/bin/mc_post_install -v –c
MEDIATION_SERVER
Prerequisites ● Availability of a remote backup host with enough disk space for storing
backup files. Refer to the MC Manual for the disk dimensioning.
● Access as root and oracle to the systems.
● Knowledge and experience in installing and configuring MC applications.
Basic actions required to install applications and enable backup are listed
further down in this document, as example situations. More info as well
as other installation and backup options are described in the specific
application manuals.
Depending on the type of crash, experienced administrator may decide to

skip some of the listed steps, provided that the system is in a consistent and
uncorrupted state. For instance, if some files in the qbase directory have
been deleted, then it is possible to avoid the installation of the platform to
restore qbase environment.
Note that the optional MC Security platform package should be the last to be
(re)installed and/or (re)enabled so after restore.
7.2.1 Limitations
The backup procedure does not support the following applications:

● MC Self Monitoring
The backup procedure does not fully support the following applications:
● eoPath Commit
● eoPath Device
● eoFinder Data Analysis
● MSISDN-IMSI
For more details about what is backed up for every application, please refer
to Table 7.1.
Backup does not support backup of systems other than Linux servers, such
as:
● Probes and Infoservers – They can be restored on a fresh platform by

downloading and activating the last saved snapshot.

● Switches
● Maps tiles
7.2.2 Supported Applications
Table 7.1 illustrates how MC applications/components are integrated in MC

backup. It includes:
Server Type – May be: CS (Central Server), MS (Mediation Server), DS
(DWH Server), empty.
Application – Specifies the MC application or component.
Linux system files/directories – when marked with X, indicates that the
following files/directories are backed up:
/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow
/etc/hosts
/etc/cron.monthly
/etc/cron.deny
/etc/cron.daily
/etc/cron.weekly
/etc/cron.hourly
/etc/crontab
/etc/cron.d/etc
Oracle system configuration – when marked with X, indicates that the
below directories are backed up:
%(orahome)s/network/admin
%(orahome)s/dbs
Oracle/PostgreSQL/Rainstor – when marked with O/P/R, indicates that the
given applications are backed up to Oracle, PostgreSQL or Rainstor
databases respectively:
Oracle DWH data – when marked with X, indicates that the following data
are backed up in a given DWH:
metadata
hourly aggregation
daily aggregation
monthly
Qbase MC Package – when marked with X, indicates that executable,
libraries, package, etc. are backed up for MC qbase packages.
Qbase Nin and configuration files – when marked with X, indicates that
qbase nin and data directories are backed up.
Comments – contains exceptions and general considerations that might
impact back up and restore procedures.

Qbase Nin and configuration files

Oracle/PostgreSQL/Rainstor
Oracle system configuration
Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
MS Mediation Server X X X Backup does not include:
(MS) -%(q7path)s/log
-%(q7path)s/data/xdr
-%(q7path)s/data/qxdrs
-%(q7path)s/data/qxdrs/DB
CS Central Server X O/P Database backup applies to:
(CS) ● cdb
● Security
● QDASHS
● event
● qfd
Backup does not include:

-%(q7path)s/data/mics
-%(q7path)s/data/xdr
%(q7path)s/data/qtobscs/etl
-%(q7path)s/data/rdas/storage
-%(q7path)s/log
DS DWH Server X X X X X Backup does not include:
(DS) -%(q7path)s/data/*/etl
-%(q7path)s/log
Table 7.1 Application support details (Sheet 1 of 8)


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
MS DWH-NDAF Server X X X X The backup of the Vertica data is handled by
Vertica platform and not integrated in MC Backup
due to the large amount of data.
The backup of Vertica data includes:
- FULL DB
- single schema
- metadata
MS NDAF X X The backup does not include data i.e. eoDR buffer
MS NDAF-tool X X
CS/MS MC libraries X
CS/MS java-libs X X
CS/MS sdlt X X
CS options X CDB configuration covered by Central Server
Oracle or PostgreSQL backup.
CS deploy-server X X CDB configuration covered by Central Server
Oracle or PostgreSQLbackup.
CS probe-conf X
CS probe-sims X
CS qlinux-base X
CS qmpa5 X
CS qpmscans X X


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
CS Uninorm X
CS qprotinst X
CS qpss X
CS Dialogue names X X
CS/MS qpas2 X X
CS/MS protocol-servers X X
CS enterprise-model X X CDB configuration covered by Central Server
CS qalarms X X CDB configuration and CDB model extension
covered by Central Server Oracle or PostgreSQL
backup.
CS qalarm X X
CS security X X Audit DB and CDB configuration and CDB model
extension covered by Central Server Oracle or
PostgreSQL backup.
CS qdashs X X CDB configuration and CDB model extension
backup.
CS portal X X CDB configuration and CDB model extension
backup.


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
CS security X X CDB configuration and CDB model extension
backup.
CS documentation X
CS configtool X X CDB configuration covered by Central Server
qmon X X CDB configuration supported by CS, MS and DS
server type backup
CS probescan X X CDB configuration and CDB model extension
backup.
CS CDB and CDB X X CDB DB covered by covered by Central Server
model Oracle or PostgreSQL backup.
CS QNSS X X
CS/MS MSISDN IMSI X X MSISDN-IMSI data base content is not backed up.
Central Server
CS cdb-operator-loader X CDB DB covered by Central Server Oracle or
PostgreSQL backup.
CS cdb-ssa-it X CDB DB covered by Central Server Oracle or
PostgreSQL backup.
MS cis X X


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
CS info-servers X
MS mcls X X
mcls-model X
qdm-cdb-dl X
qdm-device-db X
MS Data Record X X Backup includes correlation rule definition, xDR/
Gateway eoDR format definition, active generation status
CDB configuration and CDB model extension

backup.
Generated TDR, correlation DB (e.g. MSISDN-

IMSI for CDR, and correlation data for IMS DR
generation) are not backed up.
DS DWHs X X X Backup does not include:
- FACT (DR detail), 5 minutes MV

- xDR ingestion buffer (in ${QUEST7_ROOT}/
<DWH>/etl)


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
MC Insight X X X Backup does not include:
-%(q7path)s/log
- BO binaries and configuration files
It includes:
- reports
- scheduled reports
- users
CS eoFinder X X CDB configuration, CDB model extension, and
GDS content are covered by Central Server Oracle
or PostgreSQL backup.
MS eoFinder Browse P/R X X
CS/MS eoFinder Data X X The storage is not backed up (Manual restore is
Analysis Server needed)
CS/MS eoFinder Trace X X
Server
MS eoLive X X CDB configuration and CDB model extension e.g.
for user settings, dataviews covered by Central
Server Oracle or PostgreSQL backup.
DB content and metadata are not backed up.



Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
CS map-server X X CDB configuration and CDB model extension
backup.
MAP tiles are not backed up.

MC Backup X Backup of the following directories in /opt/anritsu/
mc_backup:
- etc
- data/plugins
MC Self Monitoring Backup not integrated.
It can be manually backed up.

DS Link and Message X X X Subscription and dimensions are in CDB whose
Statistics backup is covered by Central Server Oracle or
PostgreSQL backup.
Backup does not include:

- FACT (DR detail), 5 minutes MV.
CS General Data Store X X GDS content and CDB configuration backup is
covered by Central Server Oracle backup.
CS Real-time Fraud X X QFD DB and CDB configuration and CDB model
Sentry extension covered by Central Server Oracle or
PostgreSQL backup.


Qbase MC Packages
Linux system files
Vertica DWH data

Oracle DWH data
Server Type
Application
Comments
DS eoPath Commit X X
DS eoPath Device X X
7.2.3 Supported Host Types
The backup procedure recognizes five types of server:

● Backup host
● Application Server, i.e. BO (not fully supported)
● Central Server
● DWH Server
● Mediation Server
7.2.4 Remote Backup Host Configuration

The following steps must be performed to enable the backup of MC applications on an uncorrupted and fully configured host (e.g. with
ULP, SRV, Qbase system, etc.):

Step 1 – Install Platform
Step 2 – Install MC Backup
Step 3 – Configure service with IP of Remote Backup Repository and Start
Service
Step 1 – Install MC Platform

The following plugins shall be installed on the host:
– ULP
– SRV
Instructions are described in Common Data Warehouse and MC Insight
Installation & Administration Manual and Common ULP Installation Manual.
Step 2 – Install MC Backup

Copy the MC Backup platform package on the server and follow the
installation instructions described in the MC Backup Installation Manual.
The file is supposed to be in the /root directory.

E.g.
# platformPatchManager applyPatch /root/backup-x.y.z.pkg
Step 3 – Configure service with IP of Remote Backup

Repository and Start Service
Edit /opt/anritsu/mc_backup/etc/mc_backup.nin file with the IP
of the remote backup system (section [remote]) then follow the steps
described in MC Backup Installation Manual, e.g.:
# mc_backup generate-rsa
# mc_backup check-remote-connection
# service mc_backup start
7.2.5 Application Server
The following actions must be performed to enable the backup of MC

applications on an uncorrupted and fully configured host (e.g. with ULP, SRV,
BO platform, Qbase system, etc.).
Backup setup Step 1 – Install MC Platform and Applications

Step 2 – Install MC Backup and Start Service
Step 3 – Enable MC Backup MCBACKUP_CONFIG plug-in
Step 4 – Enable MC Backup bo-manager plug-in
More details are provided here below.
Step 1 – Install MC Platform and Applications

Install the following packages on the host:
● ULP

● SRV plugin
● BO platform
● MC qbase applications
Instructions on how to install the above are described in Common ULP

Installation Manual and Linux Installation and Configuration Guide.

1. Copy the MC Backup platform package on the server and proceed with
the installation1. Here it is assumed that the file is in the /root directory.
E.g.
# platformPatchManager applyPatch /root/backup-
x.y.z.pkg
2. Configure /opt/anritsu/mc_backup/etc/mc_backup.nin with:
a. Remote repository parameters (section [remote])
b. Local repository parameters (section [local]).
3. Start the service. For example:
4. Configure Connection with remote host generating and storing RSA keys
(e.g. mc_backupgenerate-rsa) and then checking the connection (e.g.
mc_backupcheck-remote-connection)

1. Enable MC Backup mcbackup-config-defaults.nin (mc_post_install –c
MCBACKUP_CONFIG).
2. If needed, configure /opt/anritsu/mc_backup/lib/
post_install/ plugins/mcbackup-config-defaults.nin
3. Enable the plugin. For example:
# /opt/anritsu/mc_backup/mc_post_install –c
MCBACKUP_CONFIG
Or:
# mc_backup –i /opt/anritsu/mc_backup/lib/
post_install/plugins/ mcbackup-config-defaults.nin
Step 4 – Enable MC Backup bo-manager plugin

1. If needed, configure /opt/anritsu/mclaw/nin/bo-backup.nin
2. Enable the plugin; for example, as mclaw:
> /opt/anritsu/mc_backup/bin/mc_backup –i
/opt/anritsu/mclaw/nin/bo-backup.nin
# mc_backup –e /opt/anritsu/mclaw/nin/bo-backup.nin
Restore on the same To restore a BO Application Server, a non-corrupted functioning host is

BO AS needed, with:
● ULP configured with the same hostname (same IP and hostname)
● SRV
1. As specified in MC Backup Installation Manual

● BO platform
● MC Backup
The following steps must be performed:

Step 2 – Shut down MasterClaw
Step 4 – Find Restore point
Step 5 – Restore MC Backup Configuration backup
Step 6 – Restore MC Backup BO AS plug-in
Step 7 – Restart the host
Step 8 – Restart BO AS
Step 9 – Restart bo-manager
Step 10 - Restore BO Data
The following packages shall be installed and running on the host2:

● ULP, configured with the same hostname (with same IP and hostname,
they are used by Selfmon auto configuration and IPSec)
● SRV
● BO platform
● MC Backup
Note: No service shall be started at this stage (e.g. qmon).

Instructions can be found in the manuals:
Common ULP Installation, Migration and Upgrading Manual

Master Claw Backup Installation Manual
Common DWH and MC Insight Installation and Administration Manual

Optional. MasterClaw shall be down if present and running. If needed,
execute as mclaw:
> q7adm stop

1. Copy the MC Backup platform package on the server and follow the
install instruction described in the MC Backup manual (here it is assumed
that the file is in the /root directory).
E.g.
# platformPatchManager applyPatch /root/backup-
x.y.z.pkg
2. Configure /opt/anritsu/mc_backup/etc/mc_backup.nin with:
— Remote repository parameters (section [remote])
2. According to instructions as in Common ULP Installation Manual and MC Back‐ up Installa-
tion Manual

— Local repository parameters (section [local])
3. Start service. For example:


The restore point shall be chosen in order to ensure that the recovered data
is consistent with the CDB model present in the restored MC environment.
Note that the restore point shall be consistent with the CDB content since
application may have extended the CDB model or updated its content. If not,
application may need to be reinstalled or reconfigured.
The restore point to consider shall have the names BACKUP IDs, like these:
HOSTNAME:mcbackup-config-
defaults:YYYYmmddHHMM:YYYYmmddHHMM HOSTNAME:bo-
server-
defaults:YYYYmmddHHMM:YYYYmmddHHMM
To get the list, type:

# mc_backup --backup-list
Please notice that in the examples provided further down, it is assumed that
the system shall be recovered from 2012-12-23 11:00.

Restore MC Backup Configuration backup. E.g.:
# mc_backup --restore=HOSTNAME:mcbackup-config-
defaults:...:…..
Step 6 – Restore MC Backup BO AS plug-in

Restore MC environment. E.g.:
# mc_backup --restore=HOSTNAME: HOSTNAME:bo-
backup:201212232300
# tar –xvf <backup filename> -C /

Once all the configuration files have been restored, execute the following
command as root:
# reboot
Step 8 – Restart BO Application Server

Now the BO Application Server can be restarted, since all the configuration
files have been restored.
Execute as root.
# /etc/init.d/ SAPBOBJEnterpriseXI40 start

For further details, refer to Common DWH Installation and Administration
Manual - BO Application Server section.
Step 9 – Restart bo-manager

Execute as mclaw:
# q7adm start bo-manager
Step 10 – Restore BO Data

Install the BO basic configuration:
# boadm configure standard
Then restore the bo data, run:
# boadm restore <fullpath-backup>
Where the <fullpath-backup> is the biar file contained in the mc_backup
restored.
Restore on another To restore the backup on another BOAS, you can follow the above
BOAS procedure “Restore on the same BOAS” until step 5, and then continue with
steps 6-9 here below.
Step 1 – Restore MC Backup BO Server plugin

Restore MC environment.
E.g.:
# mc_backup --restore=HOSTNAME: HOSTNAME:bo-
backup:201212232300
# tar –xvf <RESTORED_TAR> -C / var/opt/anritsu/mclaw/

bo_backup/
Step 2 – Check if the BO Application Server is running

Start BOAS if it is not running.
Execute as root.
# /etc/init.d/ SAPBOBJEnterpriseXI40 start

Step 3 – Check if the bo-manager is running

Start bo-manager if it is not running.
Execute as mclaw:
# q7adm start bo-manager
Step 4 – Restore the BO data

If the BO basic configuration is not installed, run:

# boadm configure standard

Then restore the bo data, by running:
# boadm restore <fullpath-backup>
Where the <fullpath-backup> is the biar file contained in the mc_backup
restored.
7.2.6 Central Server

Backup setup Enable MC Backup central-server-defaults.nin plugin, then enable
Oracle backup full (rman-full-backup.nin) or archive (rman-archive-logs.nin),
by following the instructions provided in MC Backup Installation Manual.
The following steps must be performed to enable the backup of MC
applications on an uncorrupted and fully configured host (e.g. with ULP,
SRV, Qbase system, etc.).
Step 3 – Enable MC Backup MCBACKUP_CONFIG plugin
Step 4 – Enable MC Backup central server plugin
Step 5 – Enable Oracle/PostgreSQL Backup

The following plugins shall be installed on host3:
● ULP
● SRV
● Oracle/PostgreSQL

installation instructions described in the MC Backup manual (here it
is assumed that the file is in the /root directory).
E.g.
2. Configure /opt/anritsu/mc_backup/etc/mc_backup.nin with

b. Local repository parameters (section [local])
Refer to MC Backup manual for more information.
3. See Linux Installation and Configuration Guide and Common Data Warehouse and MC
Insight Installation & Administration Manual

3. Start service:
4. Configure Connection with remote host generating and storing RSA
keys (e.g. mc_backup generate-rsa) and then checking the
connection, as for instance:
mc_backup check-remote-connection)

Enable MC Backup mcbackup-config-defaults.nin (mc_post_install –c
MCBACKUP_CONFIG).
If needed, configure /opt/anritsu/mc_backup/lib/post_install/
plugins/mcbackup-config-defaults.nin
enable the plugin, e.g.
# /opt/anritsu/mc_backup/mc_post_install –c MCBACKUP_CONFIG
Or
# mc_backup –i /opt/anritsu/mc_backup/lib/post_install/plugins/
mcbackup-config-defaults.nin
# mc_backup –e mcbackup-config-defaults
Step 4 – Enable MC Backup central server plugin

plugins/central-server-defaults.nin
If the Central Server has PostgreSQL instead of Oracle, before installing the
plugin edit it and comment and uncomment the correct locations attribute, as
in the example below:
; Uncomment this setting if the Central Server has PostgreSQL instead of Oracle
locations = /etc/passwd /etc/shadow /etc/group /etc/gshadow /etc/hosts /etc/cron.monthly /etc/
cron.deny /etc/cron.daily /etc/cron.weekly /etc/cron.hourly /etc/crontab /etc/cron.d %(q7path)s
; Comment this setting and uncomment the above one if the Central Server has PostgreSQL
instead of Oracle
;locations = /etc/passwd /etc/shadow /etc/group /etc/gshadow /etc/hosts /etc/cron.monthly /etc/
cron.deny /etc/cron.daily /etc/cron.weekly /etc/cron.hourly /etc/crontab /etc/cron.d %(q7path)s
%(orahome)s/network/admin %(orahome)s/dbs
Enable the plugin, e.g. as mclaw:

> /opt/anritsu/mc_backup/bin/mc_backup –i /opt/anritsu/
mc_backup/lib/post_install/plugins/central-server-defaults.nin
Or
CENTRAL_SERVER
# mc_backup –e central-server-defaults

Step 5 – Enable Oracle/PostgreSQL Backup

Enable Oracle or PostgreSQL backup by following the procedures described
in MC Backup Installation Manual – “Configuration for Oracle Database” or
“Configuration for PostgreSQL Database” sections.
Basically, it is needed to configure MC Backup with two plugins for:
● Full backup, e.g. weekly, using
— /opt/anritsu/mc_backup/lib/post_install/plugins/rman-
full-backup.nin or
— /opt/anritsu/mc_backup/lib/post_install/plugins/psql-
full-backup.nin
● Incremental backup, every day, using
— /opt/anritsu/mc_backup/lib/post_install/plugins/ rman-
archive-logs.nin or
— /opt/anritsu/mc_backup/lib/post_install/plugins/ psql-
wal-backup.nin
Restore To restore a Central Server, you need a non corrupted functioning host with
● SRV
● Oracle or PostgreSQL, identical version
● Step 1 – Install Platform
● Step 2 – Disable qmon service
● Step 3 – Shut down MasterClaw
● Step 4 – Install MC Backup and Start Service
● Step 5 – Find Restore point
● Step 6 – Restore MC Backup Configuration backup
● Step 7 – Restore MC Backup Central Server plugin
● Step 8 – Restart the host
● Step 9 – Restore Oracle/PostgreSQL data
● Step 10 – Restart MasterClaw
● Step 11 – Enable qmon service
● Step 12 – Enable IPSec

The following plugins shall be installed and running on the host:
● SRV
● Oracle, identical version
Note: No service shall be started at this stage (e.g. Oracle, qmon).
Find more details on Common ULP Installation Manual and MC Backup

Installation Manual.

Step 2 – Disable qmon service
To avoid starting MC system when not ready, block qmon automatic start.
Execute as root:
# service qmon stop
# rm /etc/rc3.d/S99qmon

If running, MasterClaw shall be down. When needed, execute as mclaw:
> q7adm stop

installation procedure described in the MC Backup Installation
Manual.
(Here it is assumed that the file is in the /root directory).
E.g.

3. Start service, e.g.

The restore point shall be chosen in order to ensure that the data recovered
from Oracle/PostgreSQL is consistent with the CDB model present in the
restored MC environment.
The restore point to consider have the names BACKUP IDs like these:
HOSTNAME:central-server-
For Oracle
HOSTNAME:rman-archive-
logs.nin:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:rman-full-backup.nin:YYYYmmddHHMM:YYYYmmddHHMM
For PostgreSQL
HOSTNAME:psql-archive-
logs.nin:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:psql-wal-backup.nin:YYYYmmddHHMM:YYYYmmddHHMM
To get the list


Basically, it is needed to get the last available full backup and the whole
archive backup since then.
In the next section examples, it is however assumed that the system shall be
recovered from 2012-12-23 11:00.

Restore MC Backup Configuration backup.
E.g.:
defaults:...:…..
# tar –xvjf <backup filename> -C /
Step 7 – Restore MC Backup Central Server plugin

E.g.:
# mc_backup --restore=HOSTNAME:central-server-
defaults:...:201212232300
Get all the needed Oracle data out of MC backup, from multiple points
backup IDs.
E.g.:
# mc_backup --restore=HOSTNAME:rman-archive-
logs:...:201301062300
# mc_backup --restore=HOSTNAME:rman-full-
backup:...:201301062300
# tar –xvjf <rman archive log backup filename> -C /
# tar –xvjf <rman full backup filename> -C /
Note that the Oracle restore point shall be consistent with the applications
installed on this host or on any other. If not, it may be required to reinstall or
reconfigure the applications.
Follow the rman restore steps described in the MC Backup Installation
Manual.

Once all the configuration files have been restored, execute the following
command as root:
# reboot
Step 9 – Restore Oracle/PostgreSQL data
For Oracle: As oracle user, restore the data exported from backup4
For PosgreSQL: As root user, restore the data exported from backup5.
4. See MC Backup Installation Manual - Oracle section

Step 10 – Restart MasterClaw
Execute as mclaw:
> q7adm start
Step 11 – Enable qmon service

Enable back qmon automatic start, execute as root:
# cd /etc/rc3.d/
# ln -s ../init.d/qmon S99qmon
# service start qmon
Step 12 – Enable IPSec

If IPSec (or firewall) was enabled before, it has to be redeployed on this host
from Configtool.
7.2.7 Oracle DWH Server
The DWH backup procedure depends on the Oracle deployment, which can
be:
● Standard, i.e. Oracle deployed on the same DWH backend host
● ETL separation, i.e. Oracle alone on another host.
Standard Deployment
Backup setup For DWH backup, follow the instructions in Common Data Warehouse and
MC Insight Installation and Administration Manual.
applications on an uncorrupted and fully configured host (e.g. with ULP,
SRV, Qbase system, etc.).
Step 4 – Enable MC Backup DWH server plugin
Step 5 – Enable DWH Metamodel and Aggregation backup
The following plugins shall be installed on the host 6:

● ULP
● SRV
● Oracle
5. See MC Backup Installation Manual - PostgreSQL section

6. For details on installation, see relevant MC installation manuals.


install instruction described in the MC Backup manual (here it is
assumed that the file is in the /root directory).
E.g.

4. Configure Connection with remote host generating and storing RSA
keys (e.g. mc_backup generate-rsa) and the checking the
connection (e.g. mc_backup check-remote-connection)

MCBACKUP_CONFIG), following the instruction in MC backup manual.
If needed configure /opt/anritsu/mc_backup/lib/post_install/
Enable the plugin, e.g.
# /opt/anritsu/mc_backup/mc_post_install –c
MCBACKUP_CONFIG
Or
# mc_backup –i /opt/anritsu/mc_backup/lib/post_install/
# mc_backup –e mcbackup-config-defaults
Step 4 – Enable MC Backup dwh server plugin

plugins/dwh-server-defaults.nin
Enable the plugin, e.g. as mclaw:
mc_backup/lib/post_install/plugins/dwh-server-defaults.nin
Or
DWH_SERVER
# mc_backup –e dwh-server-defaults

Step 5 – Enable Oracle Backup
1. Configure the DWH by enabling backup for at least one kind of
granularity.
Edit nin files corresponding to DWH backend by inserting the
following lines in [archiver] section:
backup.hour=yes
backup.day=yes
backup.month=yes
backup.directory=/var/opt/bkp
The backup directory must be accessible to mclaw user.
2. Restart the Loader (as mclaw user)

(It is mandatory the first time and when some DWH backup
configuration has been changed.)
> <dwh_name> start Loader
3. Stop DWH
> <dwh_name> shutdown
4. If they are already installed in MC backup (mc_backup -p), then

remove them.
- to get the list of installed plugins:
# mc_backup –p
- to remove them:
# mc_backup –u <dwh_name>_hour.nin
# mc_backup –u <dwh_name>_daily.nin
# mc_backup –u <dwh_name>_monthly.nin
# mc_backup –u <dwh_name>_metamodel.nin
5. Install dwh plugins in mc_backup (hourly, daily and monthly are

optional) as root
# mc_backup –i ${QUEST7_ROOT}/nin/
<dwh_name>_metamodel.nin
<dwh_name>_hour.nin
<dwh_name>_daily.nin
<dwh_name>_montly.nin
6. Restart DWH
> <dwh_name> start all
Restore To restore a DWH server, you need a non-corrupted functioning host with:
● ULP, configured with the same hostname (with same IP and hostname)
● SRV
● DWH framework and backend with identical version


Step 7 – Restore MC Backup DWH server plugin
Step 9 – Set Oracle Timezone
Step 10 – Restore known_hosts file
Step 11 – Restore DWH data
The following plug-ins shall be installed 7and running on the host:

● SRV
Note: No service shall be started at this stage (e.g. Oracle, qmon).
Instructions are described in the manuals:

- “Common ULP Installation, Migration and Upgrading Manual”
- “Common DWH and MC Insight Inst & Admin Manual”

Optional.To avoid starting MC system when not ready, block qmon automatic
start (if present and running).
Execute as root:
# service qmon stop

Optional. MasterClaw shall be down if present and running. If needed
execute as mclaw:
q7adm stop
7. According to procedures described in Common ULP Installation Manual and Common

Data Warehouse and MC Insight Installation & Administration Manual

installation instructions described in the MC Backup manual (here it
is assumed that the file is in the /root directory). E.g.


In order to find the restore points it shall be considered that the data restored
from Oracle (hourly, daily, montly and metamodel) shall be consistent with
the version of the DWH backend, i.e. no major dwh upgrade has been
performed in the meanwhile (with dwh backend major upgrade we refer to
as un upgrade that changed the data model or that enabled/disabled some
options).
The restore point to consider have by default the names BACKUP IDs, as
follows:
HOSTNAME:dwh-server-defaults:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:hour:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:daily:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:montly:YYYYmmddHHMM:YYYYmmddHHMM
HOSTNAME:metamodel:YYYYmmddHHMM:YYYYmmddHHMM
dwh backend Oracle

BACKUP IDs
v1.0.0 |
Backup | |
initialized | |
2011-12-12 23:00 ---------+-------------------------+
1*
| |
| |
| |
2011-12-22 23:00 ---------+-------------------------+
2*
| |
dwh backend major upgrade | |
2011-12-23 11:00 v1.1.0 |
| |

2011-12-22 23:00 ---------+-------------------------+

| |
| |
dwh backend major upgrade | |
2012-12-23 11:00 v1.2.0 |
| |
2012-12-13 23:00 ---------+-------------------------+ 3*
| |
...
2013-01-06 23:00 ---------+-------------------------+
| |
BACKUP IDs:
1* HOSTNAME:dwh-server-defaults:...:201112122300
HOSTNAME:hour:...:201112122300
HOSTNAME:metamodel:...:201112122300
In the above example, if on 2013-01-07 it is needed to restore a DWH data
generated before a major backend upgrade, then it is required to perform
the restore incrementally; one must also consider that DWH data must be
ingested using the same backend version that has generated it.
E.g.
1. restore DWH server and then DWH data until 2011-12-12 23:00 (next
Steps 5 and 6).
2. restore DWH server and then DWH data from 2011-12-12 23:00 to
2012-12-12 23:00 (next Steps 5 and 6).
This imply that there will be a hole in the recovered data. If the exact hour
of backend installation is known then it is possible to recover some
additional hour aggregation data.
3. restore DWH server and then DWH data from 2012-12-13 23:00 to
2013-01-06 23:00.
To get the list

In the examples provided further down in this section, it is however assumed

that the system shall be recovered from 2012-12-23 11:00.

Example:
defaults:...:…..

Restore MC environment with the BO configuration files, e.g.:
# mc_backup --restore=HOSTNAME:dwh-server-
defaults:...:201212232300
Get all the needed DWH data out of MC backup, by restoring data from
multiple backup points, e.g.:
# mc_backup --restore=HOSTNAME:hour:201212232300:...
...
# mc_backup --restore=HOSTNAME:hour:...:201301062300
# mc_backup --restore=HOSTNAME:metamodel:201212232300:...
...
# mc_backup --restore=HOSTNAME:metamodel:...:201301062300

Now the host can be restarted, since all the configuration files have been
restored.
Execute as root.
# reboot

1. On the DWH node, connect to Oracle via sqlplus as follows:
#sqlplus system/manager
2. Select the correct time zone as follows:
SQL> select TZNAME, TZABBREV from v$timezone_names
3. Set the time zone as follows:
SQL> ALTER DATABASE SET TIME_ZONE = <use the TZNAME
selected in the previous query>
4. Restart Oracle.

Connect with ssh to all needed hosts and IPs (including localhost).

1. As mclaw:
> <dwh_name> install
2. As root, import data restored in previous step in DWH. For each

aggregation type and metamodel nin (please refer to “Common
DWH and MC Insight Inst & Admin Manual” for detailed
instructions):
# tar -xvfz <tar.gz file from locations_r parameter of
<dwh_name>_<unique name>.nin> -C /
# mv /var/opt/data/datapump/backup/<dwh name>/<unique name>l/*.dar

<locations_r>
# <dwh_name> restore

Execute as mclaw:
> q7adm start

# cd /etc/rc3.d/

from Configtool.
ETL Separation
Backup setup DWH backend host

For DWH backend host, follow the instructions in section Backup setup on
page 7-23.
Here is an example of stepwise procedure:

Step 2– Installing Oracle client instead of full Oracle.
Step 3– Install MC Backup and Start Service
Step 4– Enable MC Backup MCBACKUP_CONFIG plugin
Step 5– Enable MC Backup DWH server plugin
Step 6– Enable DWH Metamodel and Aggregation backup
Oracle server
For Oracle server, follow the steps 1,2 and 3 described in paragraph Backup
setup on page 7-23. As an example:

Full Oracle installation is required here.
Step 4 – Enable MC Backup DWH server plugin
Restore DWH backend restore

Oracle data do not need to be restored as long as it is not located on a
damaged server; MC environment must be restored instead.
The following steps are to be performed.


Oracle Host Restore
Oracle data must be restored according to the following steps:

Only the dwh-server plugin and excluding the hour/daily/monthly and
metamodel.
Command and procedures needed to successfully perform the above steps

are described at paragraph Restore on page 7-25 in this section.
Both DWH Backend and Oracle Host Restore
Here you must execute the below steps, in the given order:
1. Oracle Host Restore
2. DWH Backend Restore
7.2.8 Vertica DWH Server

Refer to Common ULP Installation Manual - Backup/restore section.
7.2.9 Mediation Server

Backup setup Enable MC Backup mediation-server-defaults.nin plugin8.


applications on a uncorrupted and fully configured host (e.g. with ULP, SRV,
Qbase system, etc.).

Step 4 – Enable MC Backup mediation server plug-in
More details are provided here below.

The following plug-ins shall be installed on the host:
● ULP
● SRV
Instructions on how to install the above are described in Common ULP

Installation Manual and Linux Installation and Configuration Guide.

1. Copy the MC Backup platform package on the server and proceed with
the installation9. Here it is assumed that the file is in the /root directory.
Example:

3. Start service
E.g.
Configure Connection with remote host generating and storing RSA keys
(e.g. mc_backup generate-rsa) and then checking the connection
(e.g. mc_backup check-remote-connection)

MCBACKUP_CONFIG).
If needed configure /opt/anritsu/mc_backup/lib/post_install/


Enable the plugin:
E.g.
# /opt/anritsu/mc_backup/mc_post_install –c MCBACKUP_CONFIG
Or
# mc_backup –i /opt/anritsu/mc_backup/lib/post_install/plugins/
mcbackup-config-defaults.nin
Step 4 – Enable MC Backup mediation server plug-in

plugins/mediation-server-defaults.nin
Enable the plugin:
E.g. as mclaw
mc_backup/lib/post_install/plugins/mediation-server-
defaults.nin
Or
MEDIATION_SERVER
# mc_backup –e mediation-server-defaults.nin
Restore To restore a Mediation Server, a non-corrupted functioning host is needed,

with:
● SRV
● MC Backup

Step 7 – Restore MC Backup Mediation Server plugin


The following plug-ins shall be installed and running on the host 10:
they are used by Self-Mon auto configuration and IPSec)
● SRV
● MC Backup
Note: No service shall be started at this stage (e.g. qmon).

Optional. To avoid starting MC system when not ready, block qmon
automatic start (if present and running).
# service qmon stop

Optional. MasterClaw shall be down it present and running. If needed
execute as mclaw:
> q7adm stop

install instruction described in the MC Backup manual (here it is
assumed that the file is in the /root directory).
E.g.

- Remote repository parameters (section [remote])
- Local repository parameters (section [local])
- Refer to MC Backup manual for more information.
3. Start service
E.g.

The restore point shall be chosen in order to ensure that the data recovered
from Oracle is consistent with the CDB model present in the restored MC
10. According to instructions you can find in Common ULP Installation Manual and MC Back-
up Installation Manual

environment.
Note that the restore point shall be consistent with the CDB content since
application may have extended the CDB model or updated its content. If not
application may need to be reinstalled or reconfigured.
The restore point to consider have the names BACKUP IDs like thise:
HOSTNAME:mediation-server-
To get the list

In the next section examples, it is however assumed that the system shall be
recovered from 2012-12-23 11:00.

Restore MC Backup Configuration backup.
E.g.:
defaults:...:…..
Step 7 – Restore MC Backup Mediation Server plugin

E.g.:
# mc_backup --restore=HOSTNAME: mediation-server-
defaults:...:201212232300

Now the host can be restarted, since all the configuration files have been
restored.
Execute as root.
# reboot

Execute as mclaw:
> q7adm start

# cd /etc/rc3.d/


from Configtool.
7.2.10 eoLive Ser ver

Backup setup Follow the procedure described in Section 7.2.9 Mediation Server to make
sure to backup eoLive configuration (charts, dataviews and other settings).
Periodically, perform the backup procedure described in eoLive Installation
and Configuration Manual, if you want to backup eoLive KPI DB data.
Restore To restore eoLive Server, a non-corrupted functioning host is needed, where

also PostgreSQL package shall be installed.
See Section 7.2.9 Mediation Server.
Then perform the restore procedure as described in eoLive Installation and
Configuration Manual.
7.2.11 eoFinder Browse Server

Rainstor
The below procedure only applies to eoFinder Browse with Rainstor.
Backup setup For every node, follow the procedure described in Section 7.2.9 Mediation
Server then follow the instruction in eoFinder Browse Installation and
Administration Manual, section “Rainstor Backup and Restore”.
Rainstor backup is integrated with mc_backup using eofb-loader plugin: for
further details, please see eoFinder Browse Installation and Administration
Manual.
Restore To restore an eoFinder Browse node, a non-corrupted functioning host refer to

the instructions in Section 7.2.9 Mediation Server, then follow the instruction
in eoFinder Browse Installation and Administration Manual, section “Rainstor
Backup and Restore”.
PostgreSQL
The below procedure only applies to eoFinder Browse with PostgreSQL.
Backup setup For every node, follow the procedure described in Section 7.2.9 Mediation
Server, provided that you install PostgreSQL after SRV in Step 1.
Restore To restore an eoFinder Browse node, a non-corrupted functioning host is

needed and PostgreSQL package shall be installed as well; refer to the
instructions in Section 7.2.9 Mediation Server, with the following exceptions:
— In Step 1, install PostgreSQL after SRV.

— After Step 8, on the node where eoFb server is installed:
1. execute eofb-server start_db
2. For each instance definition file restored into QUEST7_ROOT/data/eofb-
server/output_file, execute:
eofb-server-admin –i <instance_name>
3. If the instance is already installed, the installation fails; execute:
eofb-server-admin –up <instance_name>

8
Appendix
Introduction This Chapter contains descriptions of directory structures, environment

variables, configuration files and similar reference information.

Appendix
8.1 Environment and Directory

Structure
This section describes the environment variables and directory structure of
MasterClaw in a production system, and the general layout of each package.
8.1.1 Environment Variables

Certain environment variables are needed by all MasterClaw packages. You
can use an installed command q7env to set up this environment.
Name Description
QUEST7_ROOT The root of the MasterClaw system. Set up this variable
before calling q7env if MasterClaw is not placed in
/opt/anritsu/mclaw.
PATH Path used by shells to find programs. The directory
${QUEST7_ROOT}/bin is appended if not already
present.
LD_LIBRARY_PATH Path used to search for shared libraries. The directory
${QUEST7_ROOT}/shlib is appended if not already
present.
Table 8.1 MC environment variables
To set up the environment, use the commands:

# export QUEST7_ROOT=/opt/anritsu/mclaw/
# . ${QUEST7_ROOT}/bin/q7env
You need the first command only if MasterClaw is not placed in /opt/anritsu/
mclaw/.
Add the command to the .profile of the root user and all users that should
be able to run MasterClaw applications.
To ensure that new users will automatically source the QUEST7 environment,
enter the following line in the file /usr/skel/.profile:
. ${QUEST7_ROOT}/bin/q7env

8.1.2 Directory Structure
Terminology The following terms are used:
Term Definition
production system The system on which MasterClaw is running at the customer.
Third-party product on which MasterClaw depends is
assumed to be installed.
package A set of files that makes up an integrated functionality of
MasterClaw, e.g., qsa, TOPO, qpa, and qst.
A package can exist (and usually does) in more than one
version.
A package is identified by a name and a version number. Each
package can depend on a set of other packages.
loaded A package is said to be ’loaded’ on a production system if the
files of the package are physically available in the file system
of the production system (e.g., a tar file with the package has
been copied into the local file system). More than one version
of a package can be loaded simultaneously. Each package
version is placed in a separate base directory.
installed A package is said to be ’installed’ on a production system if the
functionality of the package is integrated into the operating
MasterClaw system on that production system. Except for the
qlib packages, only one version of each package can be
installed on a production system simultaneously.
public programs Programs that can be started directly by a user. In MasterClaw
only a few programs can be started directly. Most programs
are started by other programs (e.g., TeMIP).
installation script Script that is executed when a loaded MasterClaw package is
installed into the MasterClaw system.
deinstallation script The reverse of the installation script.
Table 8.2 Terms used in the directory structure
Common root All files used on the package system are placed under a common root
denoted by the environment variable QUEST7_ROOT.
The default value of this variable is /opt/anritsu/mclaw
Symbolic links Whenever possible, symbolic links are used between the installed package
and the loaded package to keep disk usage as low as possible. Symbolic
links within the ${QUEST7_ROOT} directory structure are always relative;
this ensures that the ${QUEST7_ROOT} can be moved without extensive
rework of all links.
All files in the ${QUEST7_ROOT}/packages/<name>-<version>/
{bin,shlib,shlib64, jar}, directories are installed in ${QUEST7_ROOT}/
{bin,shlib, shlib64, jar} as symbolic links when the package is installed (an
attempt to install the same name from more that one package is a fatal error).
Some packages will have files that must be installed outside the
${QUEST7_ROOT} structure. The installation and deinstallation scripts of the
packages take care of this.

Appendix
Overview of directory The following files and directories are found under ${QUEST7_ROOT}:
structure
Directory or file name Status

${QUEST7 ROOT}/packages/ —
${QUEST7_ROOT}/packages/<name>-<version>/ —
${QUEST7_ROOT}/packages/<name>-<version>/bin/ optional
${QUEST7_ROOT}/packages/<name>-<version>/shlib/ optional
${QUEST7_ROOT}/packages/<name>-<version>/nin/ optional
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/ mandatory
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/install mandatory
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/env optional
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/sys.start optional
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/sys.stop optional
${QUEST7_ROOT}/packages/<name>-<version>/lib/ optional
${QUEST7_ROOT}/packages/<name>-<version>/client/ optional
${QUEST7_ROOT}/installed/ —
${QUEST7_ROOT}/installed/<name>/ —
${QUEST7_ROOT}/data/ —
${QUEST7_ROOT}/data/<name>/ optional
${QUEST7_ROOT}/bin/ —
${QUEST7_ROOT}/bin/q7env —
${QUEST7_ROOT}/bin/q7adm —
${QUEST7_ROOT}/shlib/ —
${QUEST7_ROOT}/jar —
${QUEST7_ROOT}/nin/ —
Table 8.3 Files and directories in ${QUEST7_ROOT}
${QUEST7_ROOT}/packages/
This directory contains a subdirectory for each loaded MasterClaw package.
Each subdirectory is of the form <name>-<version>, e.g., qsa-1.1,
qpac-1.3, and qlib-3.1. More than one version of a package can be present.
All files under this directory are read-only except at the time when the files are
loaded into the production system. This is required for easy sharing of the
files between different MasterClaw production systems, either on the same
machine or on different machines (through use of NFS).
${QUEST7_ROOT}/packages/<name>-<version>/
Directory with a package. In general, each package will have the structure
described below.
${QUEST7_ROOT}/packages/<name>-<version>/bin/
All public programs of the package.
’Private programs’ are normally put in the lib directory (see below).

${QUEST7_ROOT}/packages/<name>-<version>/shlib/
All shared libraries provided by the package.
All shared libraries should contain a version number as part of the name.
${QUEST7_ROOT}/packages/<name>-<version>/nin/
All NIN-files used by this package.
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/
A number of shell scripts that are executed by the MasterClaw administration
command (see below) during different phases of the life cycle of a
MasterClaw system.
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/install
Script executed to install the package. The script will do the following:
Install files that should not be located in:
${QUEST7_ROOT}/packages/<name>-<version>/bin or
${QUEST7_ROOT}/packages/<name>-<version>/shlib.
Examples are:
● Configuration files (so-called .NIN files) that must be edited by the
administrator. A description of the needed changes is included in the
release notes.
● TeMIP files, such as .def and .ms files.
Run the setup-links script to setup all the links needed for the new package.
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/env
Korn script sourced to setup environment variables specific to this package.
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/sys.start
Script executed when q7adm start is executed.
${QUEST7_ROOT}/packages/<name>-<version>/rc.d/sys.stop
Script executed when q7adm stop is executed.
${QUEST7_ROOT}/packages/<name>-<version>/lib/
All other libraries and miscellaneous files in the package.
There is no common structure below this directory.
${QUEST7_ROOT}/packages/<name>-<version>/client/
Application description used by MasterClaw Portal.
${QUEST7_ROOT}/installed/
This directory contains a symbolic link for each installed package.

Appendix
${QUEST7_ROOT}/installed/<name>/
Symbolic link to ../packages/<name>-<version>. This link can be used by an
installed package to access private files in the package.
The link is also used by the MasterClaw administration command to access
files in all installed packages.
${QUEST7_ROOT}/data/
This directory contains an optional subdirectory for each installed package.
${QUEST7_ROOT}/data/<name>/
This directory can be used by an installed package for private data files that
can change during the operation of the MasterClaw system. The structure of
the files and directories under this directory is private to the package. The
installation procedure of a newer version of a package takes account of any
data files found here and converts them as needed.
Any NIN-files of the package that can be changed by the user are placed in
the ${QUEST7_ROOT}/nin/ directory described below.
Data that must be shared across several systems of MasterClaw (or even
across centres), will not be located in the file system, but rather in the general
data store.
${QUEST7_ROOT}/bin/
This directory contains the public programs of MasterClaw. Most programs
found here are symbolic links to the appropriate packages (e.g., on the form
../installed/<name>/bin/...).
${QUEST7_ROOT}/bin/q7env
Shell script that can be sourced to set up all relevant environment variables
for a Korn shell script.
${QUEST7_ROOT}/bin/q7adm
Command that is used for all management of a MasterClaw installation.
${QUEST7_ROOT}/shlib/
This directory contains all shared libraries of the installed packages. Most
files found here are symbolic links to the appropriate packages (e.g., of the
form ../installed/<name>/shlib/lib...).
${QUEST7_ROOT}/nin/
This directory contains all NIN-files that can be modified by the user.
MasterClaw All administration of MasterClaw in a production is handled by the command

administration q7adm. This command is part of the base package and is located in
command ${QUEST7_ROOT}/bin.For the syntax and usage of this command, see
Section 2.1.2 q7adm on page 2-2.

Package layout Each package is delivered as a compressed tar (.tar.Z and/or .tar.gz) file with
summary the following files and directories:
Directory or file name Status

packages/<name>-<version>/ mandatory
packages/<name>-<version>/bin/ optional
packages/<name>-<version>/shlib/ optional
packages/<name>-<version>/lib/ optional
packages/<name>-<version>/nin/ optional
packages/<name>-<version>/rc.d/ mandatory
packages/<name>-<version>/rc.d/install mandatory
packages/<name>-<version>/rc.d/env optional
packages/<name>-<version>/rc.d/sys.start optional
packages/<name>-<version>/rc.d/sys.stop optional
Table 8.4 Contents of tar

9
Acronyms
Acronym Explanation
AAMM Anonymous Access Mobility Management
AAPDP Anonymous Access Packet Data Protocol
ACELP Algebraic Codebook Excited Linear Predictor
ADR A-interface Data Record
AGCH Access Grant Channel
APM Application Program Manager
APN Access Point Name
ARFCN Absolute Radio Frequency Channel Number
AS Application Server
ASR Answer to Seizure Ratio
ATM Asynchronous Transfer Mode
AUC Authentication Centre
BCC Base Station Colour Code
BCCH Broadcast Control Channel
BCF Base Control Function
BCH Broadcast Channels
BCS Block Check Sequence
BGCF Breakout Gateway Control Function
BHCA Busy Hour Call Attempt is the average number of calls the user
tries to initiate in one hour
BI Business Intelligence
BLCPU Business Logic CPU
Table 9.1 Acronyms (Sheet 1 of 10)

Acronyms
Acronym Explanation
BO Business Objects
BS Billing System
BSC Base Station Controller
BSIC Base Station Identify Code
BSS Base Station Sub-System
BSSAP BSS Application Part
BSSGP BSS GPRS Protocol
BSSMAP BSS Management Application Part, Layer 3 Protocol for
communication between MSC and BSC
BTS Base Transceiver Station
BVCI BSSGP Virtual Circuit Identifier
CA Certificate Authority
CAMEL Customised Applications for Mobile Network Enhanced Logic
CAP CAMEL Application Part
CAS Channel Associated Signalling
CBCH Cell Broadcast Channel
CC Country Code
Call Control
CCH Common Channels
CDB Configuration Database
CDBS Configuration Database Server
CDR Call Data Record
Call Detail Record
CGI Cell Global Identity
CI Cell Identity
CIC Circuit Identity Code
CIS Central IMEI Server
CKSN Cipher Key Sequence Number
CLI Command Line Interface
CM Connection Management
CMM Combined Mobility Management
CMS Control Management System
CN Core Network
CPCI Compact PCI - a dedicated physical implementation of the PCI bus.
CRC Cyclic Redundancy Check
CRS Certificate Signing Request
CS Circuit Switched / Central Server
CSC Central Surveillance Centre
CSCF Call Session Control Function
CSDR Call Sequence Data Record
CSP Communication Service Provider
CTX Context
DC Derived Counters

Acronym Explanation
DCH Dedicated Channels
DCPL Derived Counter Position Header Length
DHCP Dynamic Host Protocol Configuration Protocol. Dynamic
assignment of IP addresses etc.
DL Downlink
DLCI Data Link Connection Identifier
DM Device Monitoring
DoIP Data over IP
DPC Destination Point Code
DR Data Record
DRX Discontinuous Reception
DTAP Direct Transfer Application Part
DTD Document Type Definition
DTID Destination Transaction ID
DTM Dual Transfer Mode
DWH Data WareHouse
DWHFW Data Warehouse Framework
EDGE Enhanced Data rates for GSM Evolution
EFR Enhanced Full Rate
EIR Equipment Identity Register (white, black and grey lists)
ENUM Telephone Number Mapping Function
ESF Extended Super Frame
ESN Electronic Serial Number
ET Extraction and Transformation
ETL Extraction Transformation and Loading
ETSI European Telecommunications Standards Institute
EUL End User Layer metadata for discoverer end users
FACCH Fast Associated Control Channel
FAT Factory Acceptance Test
FCA First Customer Availability
FCB Frequency Correction Burst
FCCH Frequency Correction Channel
FCS Frame Check Sequence
FDD Frequency Division Duplexing
FEC Forward Error Correction
FOPC First Originating Point Code
FTP File Transfer Protocol
GB - TDR GB Transaction Data Record
GBFLU GPRS Gb Frame Link Unit
GDS General Data Store
GE Gigabit Ethernet
GERAN GSM/EDGE Radio Access Network

Acronyms
Acronym Explanation
GGSN Gateway GPRS Support Node
GMM GPRS Mobility Management
GMSC Gateway Mobile Switching Centre
GMSK Gaussian Minimum Shift Keying
GPRS General Packet Radio Service
GPS Global Positioning System
GR Group
GRR GPRS Radio Resource
GSDC Generic Setup Dialogue Component
GSM Global System for Mobile Communications
GSMSCF GSM Service Control Function
GT Global Title
GTP GPRS Tunnelling Protocol
GTTP GPRS Transparent Transport Protocol
GUI Graphical User Interface
HCS Header Check Sequence
HL Header Length
HLR Home Location Register
HPLMN Home Public Land Mobile Network
HSS Home Subscriber Server
HSSL High Speed Signalling Links
HTTP HyperText Transfer Protocol
HTTPS Secure Hyper Text Transfer Protocol
HW Hardware
I-CSCF Interrogating-CSCF
IAM Initial Address Message (TUP, ISUP)
ICP Inter Connect Partner
IETF Internet Engineering Task Force
IMEI International Mobile Equipment Identity
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IR Incremental Redundancy
ISDN Integrated Services Digital Network
ISUP ISDN User Part
IWF Inter-Working Function
JNLP Java Network Launch Protocol
KC Cipher Key
KPI Key Performance Indicator
KQI Key Quality Indicator
LA Location Area
LAC Location Area Code

Acronym Explanation
LAI Location Area Identity
LAN Local Area Network
LAPD Link Access Protocol-D Channel (Layer 2 Protocol for
communication between BTS and BSC)
LAPDm LAPD Mobile
LAU Location Update
LCCPU Link Concentration CPU
LDPC Last Destination Point Code
LED Light Emitting Diode
LLC Logical Link Control
LMS Link and Message
Location Updating, MAP operation
LU
Link Unit
LUR Location Update Request
Media Access Control
MAC
Medium Access Control
MAP Mobile Application Part
MC MasterClaw
MCC Mobile Country Code
MCD Mass Call Detection
ME Mobile Equipment
MEGACO Media Gateway Controller
MGCF Media Gateway Control Function
MGCP Media Gateway Control Protocol
MGW Media Gateway
MIB Management Information Base
MICS MSISDN IMSI Central Server
MIN Mobile Identification Number
MM Mobility Management
MMI Man-Machine Interface
MMS Multimedia Messaging Service
MNC Mobile Network Code
MNO Mobile Network Operator
MO Mobile Originated
MOS Mean Opinion Score
MPA Multi-channel Protocol Analyser
MPU Multi Processor Unit
MRF Multimedia Resource Function
MS Mobile Station
MSC Mobile Switching Centre
MSIN Mobile Subscriber Identification Number
MSISDN Mobile Subscriber ISDN
MSRN Mobile Station Roaming Number

Acronyms
Acronym Explanation
MT Mobile Terminated
MTBF Mean Time Between Failures
MTP Message Transfer Part
MTP2 Message Transfer Part Level 2 (Signalling Link Level) Peer-to-
peer signalling (MSU, LSSU, FISU)
MTP3 Message Transfer Part Level 3 (Signalling Network Level), routing
of messages from an OPC to a DPC by a routing label in
Connectionless mode
MV Materialised View
N/A Not Applicable
NAT Network Address Translation
NCC Network Colour Code
NCH Notification Channel
NDC National Destination Code
NE Network Element
NER Network Efficiency Ratio
NGN Next Generation Network
NISC Network Item Selection Component
NL Number Length
NMSI National Mobile Subscriber Identity
NPDU Network Protocol Data Unit
NS Network Service
NSS Network Subsystem
NSAPI Network Service Address Point Identity
NT-APM Application Program Manager for Windows NT
NTP Network Time Protocol
O10gAS Oracle 10g Application Server
OA Onboard Administrator
OBSCR Traffic Observer Statistical Counter Record (File format)
O&M Operation and Maintenance
OMA Open Mobile Alliance
OMC Operational Management Centre
OPC Originating Point Code
OSS Operation Support Systems
OTID Originating Transaction ID
P-CSCF Proxy-CSFC
PACCH Packet Associated Control Channel
PAGCH Packet Access Grant Channel
PBCCH Packet Broadcast Control Channel
PC Personal Computer or Server
PCAP Packet Capture
PCCCH Packet Common Control Channel
PCH Paging Channel

Acronym Explanation
PCI Peripheral Component Interconnect - a computer bus used inside
standard PCs
PCIe PCI Express
PCICPU A stand alone cPeripheral Component Interconnect based Central
Processor Unit board
PCILIF Peripheral Component Interconnect Link Interface
PCL Point Code
PCM Pulse Code Modulation
PCU Packet Control Unit
PD Protocol Discriminator
PDC Personal Digital Cellular
PDN Packet Data Network
PDP Packet Data Protocol
PDTCH Packet Data Traffic Channel
Protocol Data Unit
PDU
Power Distribution Unit
PLMN Public Land Mobile Network
PNCH Packet Notification Channel
POP-3 Post Office Protocol version 3
PPCH Packet Paging Channel
PPU Protocol Processing Unit
PRACH Packet Random Access Channel
PSCD Packet Serving Cell Data
PSOS Real-time Operating System by Integrated Systems Inc.
PSTN Public Switched Telephone Network
PSU Power Supply Unit
PTCCH Packet Timing Advance Control Channel
PTCH Packet Traffic Channel
PTMSI Packet Temporary Mobile Subscriber Identity
QAH Quest Alarm Handler
QARDWH MasterClaw Active Roamers DWH
QCTCL MasterClaw Call Trace Command Line
QES MasterClaw Event Service
QISUPDWH MasterClaw ISUP Data Warehouse
QLVT MasterClaw Link Validation Tool
QLVTC MasterClaw Link Validation Tool Client
QLVTS MasterClaw Link Validation Tool Server
QMC MasterClaw Management Console
QMCPI QMC Plug-In
QMCPI-DWH- DWH Alarm management Console plug-in
ALARM
QMCPI-TOPO QMCPI Topology plug-in tool used to view/modify topology
QMON MasterClaw Software Components Monitoring

Acronyms
Acronym Explanation
QNCKPI MasterClaw Network Call KPI
QoS Quality of Service
QPA MasterClaw Protocol Analysis - old UNIX based
QPA2 MasterClaw Protocol Analysis - new Java GUI
QPAS2 MasterClaw Protocol Analysis Server
QPECC MasterClaw Protocol Event Collector Client
QPECS MasterClaw Protocol Event Collector Server
QPM MasterClaw Probe Manager
QPTL MasterClaw Portal
QRS MasterClaw Roaming Statistics
QRSDWH MasterClaw Roaming Statistics DWH
QST MasterClaw Statistics Application
QTCAPDWH MasterClaw TCAP KPI DWH application
QTOBS MasterClaw Traffic Observer
QTOBSCFG MasterClaw Traffic Observer Configuration Tool
QTRG MasterClaw Trigger
QXDRS XDR Generator Server
RA Routing Area
RAC Routing Area Code
RACH Random Access Channel
RAI Routing Area Identity
RAN Radio Access Network
RANAP Radio Access Network Application Part
RAND Random number
RAU Routing Area Update
RDBMS Relational Database Management System
RF Radio Frequency
RFQ Request For Quotation
RLC Radio Link Control
RMAN Oracle Restore Manager
RNC Radio Network Controller
RR Radio Resource
RSC Regional Surveillance Centre
RSL Radio Signalling Link, protocol at A-bis interface
RTCP Real Time protocol Control Protocol
RTT Round-trip time.
RV Release Value
RVG Release Value Group
SAC Service Area Code
S-CSCF Serving-CSCF
SABM Set Asynchronous Balanced Mode
SACCH Slow Associated Control Channel

Acronym Explanation
SAPI Service Access Point Identifier
SAW Stop and Wait
SB Synchronisation Burst
SCCP Signalling Connection Control Part
SCD Special Customer Delivery
SCH Synchronisation Channel
SDCCH Stand-alone Dedicated Control Channels (used, before the TCH
assignment, for identification, authentication, roaming and call set-
up)
SDLT Simple Data Loading Tool
SFP Small Form-factor
SGSN Serving GPRS Support Node
SIM Signalling Input Mediator
Subscriber Identity Module
SIP Session Initiation Protocol
SIP(T) SIP for telephones
SM Session Management
Safe Mode switch
SMS Short Message Service
SMSC Serving Mobile Switching Centre
SN Subscriber Number
SNDCP Sub-Network Dependent Convergence Protocol
SNMP Simple Network Management Protocol
SNR Serial Number
SoIP Signalling over IP
SP Signalling Point
SPC Signalling Point Code
SQL Structured Query Language
SRES Signed Response
SRNC_ID Serving Radio Network Controller ID
SS Supplementary Services
SS7 Signalling System 7
SSL Secure Sockets Layer
SSN Sub System Number
STM1 Synchronous Transport Module, with data rate 155.52Mbit/s.
STP Signalling Transfer Point
TAC Type Approval Code
TBF Temporary Block Flow
TCAP Transaction Capabilities Application Part
TCD Traffic Conditioning Device. A device that can receive Ethernet
based network traffic and manipulate, filter and/or redirect it
towards MasterClaw probes.
TCH Traffic Channel (used for speech or data services)
TCO Total Cost of Ownership

Acronyms
Acronym Explanation
TCP/IP Transmission Control Protocol/Internet Protocol
TDM Time Domain Multiplexing
TDMA Time Division Multiple Access
Transaction Data Record
TDR
TCAP Data Record
TEI Terminal Endpoint Identifiers
TEID Tunnel End-point ID. A number unique defining a tunnel ID in one
direction.
TeMIP Telecommunications Management Information Platform
TI Transaction Identifier
TID Tunnel ID. A field in the Gb release ’98 header, comprising of IMSI
and NSAPI.
TLLI Temporary Logical Link Identifier
TMSI Temporary Mobile Subscriber Identity
TOBS Traffic Observer
TOM Tunnelling of Messages
TRAU Transcoding and Rate Adaption Unit
TRX Transceiver
TT Transfer Time
UA Unnumbered Acknowledge
UDP User Datagram Protocol
UDT / UDTS The TCAP layers use exclusively the connectionless service of
SCCP (protocol class 0 and 1). The consequence is that SCCP-
UDT messages are the only candidates for transport of TCAP
messages.
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunications System
URD User Requirement Document
USF Uplink Status Flag
UTC Coordinated Universal Time
UTRAN UMTS Terrestrial Radio Access Network
VAS Value Added Service (Location based service, SMS welcome etc.)
VDR Voice Over IP Data Record
VLDB Very Large Data Base
VLR Visitor Location Register
VoIP Voice over IP
WAN Wide Area Network
WAP Wireless Application Protocol
xDR A generic term for Data Record (may be ADR, TDR, etc.)
AAMM Anonymous Access Mobility Management
AAPDP Anonymous Access Packet Data Protocol


System Administration Manual

Uploaded by

Document Information

Original Title

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

System Administration Manual

Uploaded by

Copyright:

Available Formats

MasterClaw

This document is intended for MasterClaw versions: 7.0.2

II System Administration — Administrator Manual

Copyright ©2017 Anritsu. All Rights Reserved. ISO 9001:2000 certified.

System Administration — Administrator Manual III

1.1 Scope and Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 2

1.2 References and Applicable Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 3

1.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 – 4

2.2 User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 7

2.3 Linux User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 8

2.4 Oracle User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 15

2.5 PostgreSQL User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 27

2.6 Rainstor User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 30

2.7 Vertica User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 31

2.8 User Administration of Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 – 33

3.1 MasterClaw Software Components Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 2

IV System Administration — Administrator Manual

3.2 Hardware Server Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 16

3.3 Session Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 – 18

4.2 Clients and Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 4

4.3 Portal User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 5

4.4 MasterClaw Capability Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 7

4.5 The Security Capability Configuration Plug-in (QMCPI-SEC). . . . . . . . . . . . . . . . . . . . . . . 4 – 18

4.6 Interfaces and External Firewalls /VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 43

4.7 Further Information on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 69

System Administration — Administrator Manual V

4.8 Internal Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 74

4.9 Protection of Subscriber Confidential Data Sent Over Networks . . . . . . . . . . . . . . . . . . . . 4 – 75

4.10 Protection of User Confidential Data Sent over Networks . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 76

4.12 Disk Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 78

4.14 Sec-Linux Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 – 81

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2

5.5 Configuring Security Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 8

5.6 Enabling/Disabling Plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 10

5.7 Configuring Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 12

5.8 Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 13

5.9 Pre Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 14

5.11 Post Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 16

5.12 Plugins Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 – 17

VI System Administration — Administrator Manual

6.1 Certificate Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 2

6.2 Disk Space Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 4

6.3 Protocol Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 6

6.4 Timezone Updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 – 7

System Administration — Administrator Manual VII

7.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 2

7.2 Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 – 3

8.1 Environment and Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 – 2

VIII System Administration — Administrator Manual

System Administration — Administrator Manual IX

X System Administration — Administrator Manual

This document contains an overall description of how to manage the MC

System Administration — Administrator Manual 1– 1

1.1 Scope and Purpose

1.1.1 Topics Within the Scope of This Document

System configuration Guidelines and procedures for MasterClaw system administration.

1.1.2 Topics Outside the Scope of This Document

1– 2 System Administration — Administrator Manual

Further documentation can be found at other Anritsu internal repositories:

System Administration — Administrator Manual 1– 3

1.3 Typographical Conventions

Note: Indicates neutral or positive information that emphasises or

1– 4 System Administration — Administrator Manual