TETRA System Release 7.0: CDD Server, Commissioning Manual

CDD Server, Commissioning Manual
TETRA System Release 7.0

DN03533691-15-5en
(TRADXTAPP00057) 05/2017
The content of this document and its appendices and any information provided (all together "document") is for information purposes
only and is subject to change without notice. The document only specifies the products and services identified in the document. The
document is confidential and contains legally privileged information.
The document is only intended for the use of the recipient and the customer whose representative the recipient is, and may only be used
for the purposes for which the document is submitted. The document or any part of it may not be reproduced, disclosed or transmitted
without the prior written permission of Airbus Defence and Space.
Airbus Defence and Space will reasonably ensure that the information provided in the document is free from material errors and
omissions. However, the suggestions, directions, comments and statements made in the document (e.g. regarding the compatibility,
performance and functionality of mentioned hardware and software) are not intended to be and cannot be considered as binding. The
customer assumes full responsibility for using the document or any part of it. All comments and feedback are welcomed by Airbus
Defence and Space and are used as part of the continuous development and improvement of Airbus Defence and Space’s products,
services and the document.
Airbus Defence and Space disclaim and exclude all representations, warranties and conditions whether express, implied or statutory,
including but not limited to the correctness, accuracy or reliability of the document, or otherwise relating to the document. Airbus Defence
and Space’ total liability for any errors in the document is limited to the documentary correction of errors. Airbus Defence and Space will
not be liable for any direct or indirect damages arising from the use of the document or otherwise relating to the document.
Airbus Defence and Space® is a registered trademark of Airbus Defence and Space. Other product names, trademarks or other
identifiers mentioned in the document may be trademarks of their respective companies and are mentioned for information purposes only.
Copyright © 2016–2017 Airbus DS SLC, all rights reserved.
DN03533691-15-5en TETRA System Release 7.0
2/133 This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation
Contents
1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 Scope of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 How this document is organised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Typographic conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Site requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Dimensions and weight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Power requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 UPS-initiated automatic CDD shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 IP Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Serial management of CDD nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Local administration of HP ProLiant DL380 Generation9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Cabinet accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Checking and unpacking the CDD delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Installing and connecting the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Positioning the CDD node(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Duplicated CDD cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Single node CDD unit cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Inspecting the installation work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Checking the iLO admin user and IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Deleting the user account in iLO system controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Checking or configuring IP address for the iLO system controller and setting iLO host name . . . . . 25
4.8 Exiting from iLO configuration utility and rebooting the system. . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9 Tidying up the equipment room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10 Product collection and safe disposal of the equipment within the European Union . . . . . . . . . . . 26
5 Powering up/down the CDD units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Powering up and down a CDD node using the physical power button . . . . . . . . . . . . . . . . . . . . 29
5.2 Powering down a CDD node using iLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Powering up a CDD node using iLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Powering down a CDD node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TETRA System Release 7.0 DN03533691-15-5en
This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation. 3/133
6 Configuration overview and prerequisite information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1 Prerequisite information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7 Security-hardening the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8 Configuring CDD node(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.1 Checking or configuring the node NET MGT port (iLO) IP address and hostname definitions via
ILO web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2 Setting NTP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3 Setting time zone and time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.4 Activating the Remote Console’s licence and testing the remote console . . . . . . . . . . . . . . . . . . 40
8.5 Checking the internal raid configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.6 Installing the operating system and CDD software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.6.1 Software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.6.2 Troubleshooting with the installation media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.6.3 CentOS Linux configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.6.3.1 Configuration walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.6.3.2 Host and domain name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.6.3.3 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.6.3.4 Domain Name System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.6.3.5 Updating /etc/hosts file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.6.3.6 Time servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.6.3.7 Super user account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6.3.8 User account management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.6.3.9 Enabling Webmin interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.6.3.10 Local console keyboard layout selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.6.3.11 Timezone selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.6.3.12 Boot loader accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.6.3.13 Booting to rescue or emergency mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.6.3.14 Configuring static persistent routes in route-interface files . . . . . . . . . . . . . . . . 57
8.6.4 HP ProLiant DL380 Gen9 firmware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.6.4.1 System password protection (recommended) . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.6.4.2 Booting from USB memory stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.7 Checking and configuring autopower on and power-up delay settings . . . . . . . . . . . . . . . . . . . . 59
9 Configuring the DNS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

9.1 Setting up the master DNS records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.2 Setting up the slave DNS records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10 Configuring duplicated CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.1 Changing the configuration to support duplication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.2 Finalizing the CDD configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11 Configuring the management interface <optional> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

11.1 Connecting the interface Ethernet cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11.2 Configuring the management interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11.3 Transferring the sending of traps from the production network to the management network . . . . . 94
12 Creating and configuring the Solid database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

12.1 Performing the Solid environment check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
12.2 Creating, starting, initialising and shutting down the database . . . . . . . . . . . . . . . . . . . . . . . . . . 96
12.2.1 Creating and starting a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
12.2.2 Initialising the database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12.2.3 Shutting down and restarting the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
12.3 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
13 Testing the IP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
14 Integrating CDD with the NMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
15 Finalising the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16 Starting up and shutting down the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A Instructions for starting up and shutting down the Webmin service . . . . . . . . . . . . . . . . . . . . . 109
A.1 Starting up the Webmin service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.2 Shutting down the Webmin service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
B Instructions for starting up and shutting down the BIND DNS service . . . . . . . . . . . . . . . . . . . . 111
B.1 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.1.1 Starting up the DNS service with CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.1.2 Shutting down the DNS service with CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.2 Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.2.1 Starting up the DNS service with Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.2.2 Shutting down the DNS service with Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.3 Error of NDC command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C Checking the firewall settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

C.1 Checking DNS firewall settings via Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
C.2 Checking DNS and Webmin firewall settings via CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
D Quick guide to the vi editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E Listing of CDD node services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
F Disabling the IP Path MTU Discovery protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
G Configuring the PuTTY window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

G.1 Normal use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
G.2 iLO console via serial port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
H Example printouts of duplicate_cdd.ksh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
I Modification of password policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
List of Tables.
Table 1 CDD environmental requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table 2 Weights and dimensions of the CDD server (for a single HP ProLiant DL380 (Gen9)) . . . . . 14
Table 3 CDD server power requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 4 Ports and interfaces in the HP ProLiant DL380 (Gen9) HW model . . . . . . . . . . . . . . . . . . . 22
Table 5 Usernames and default passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Table 6 Default IP address definitions for the CDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
List of Figures.
Figure 1 Duplicated CDD LAN (Ethernet)- and serial-interface connections . . . . . . . . . . . . . . . . . . . 16
Figure 2 Single node CDD LAN (Ethernet-) and serial-interface connections. . . . . . . . . . . . . . . . . . . 17
Figure 3 Duplicated CDD cable connections, back view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 4 Single node CDD’s cable connections, back view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 5 Product collection and disposal within the European Union. . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 6 Overview of the CDD configuration and start-up process . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 7 Rufus settings for TETRA CDD Server image burning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 8 Configuration: For module BIND DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 9 Zone Default settings for master zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 10 Defining the Other DNS Servers for the duplicated CDD . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 11 Defining the Forwarding and Transfers for the duplicated CDD . . . . . . . . . . . . . . . . . . . . . . 64
Figure 12 Creating the Master Zone (forward) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 13 Editing the Zone Parameters of the master server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 14 Checking the Zone Options of the master server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 15 Create the Master Zone (reverse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 16 Checking the Zone Options of the Master Zone (reverse) . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 17 Adding the Address Records for the master server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 18 Checking the reverse Address Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 19 Bind DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 20 Configuration: For module BIND DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 21 Configuring the Zone Defaults of the slave server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 22 Other DNS Servers for the slave server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 23 Configuring the Forwarding and Transfers for the slave server . . . . . . . . . . . . . . . . . . . . . . 74
Figure 24 Creating the Slave Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 25 Checking the Zone Options of the slave server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 26 Creating the Slave Zone (reverse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 27 Checking the Zone Options settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 28 Bind DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 29 Edit Slave Zone forward updated from master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 30 Edit Slave Zone reverse updated from master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 31 Rules of firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 32 Create new rule to firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 33 PuTTY character set translation settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
DOCUMENT AMENDMENTS
VERSION DATE COMMENTS CHAPTER

UPDATED
15-5 05/2017 Minor modifications. 8.6.3.13

Appendix E
15-4 02/2017 Section Configuring static persistent routes in 8.6.3.14
route-interface files added.
15-3 12/2016 Added more instructions for configuring the PuTTY Appendix G
window.
15-2 10/2016 Note concerning using auto-negotiation on the network 2.4
interfaces is added
Section Checking the internal raid configuration 8.5
updated.
Section Time servers updated. 8.6.3.6
Appendix Instructions for starting up and shutting down Appendix B
the BIND DNS service updated.
Appendix Modification of password policy added. Appendix I
Minor changes.
15-1 05/2016 This is the first version of the CDD Server,
Commissioning Manual for HP Gen9 HW and CentOS
Linux OS.
References
1. CDD Server and Audit Trail Server, Product Description DN0115944
2. CDD Server, User's Guide, DN03533676
3. Guide to TETRA Documentation, DN00126445
4. Integrating CDD Server with NetAct TETRA, DN03351245
5. Integrating TETRA System Network Elements with NetBoss XT, TRADXTAPP00079
6. License Terms of 3rd Party Software, TRASYSAPP00296
PAGE INTENTIONALLY LEFT BLANK
1 About this document
This document gives instructions for installing, configuring and commissioning the Configuration and Data
Distribution server (CDD). The document is primarily intended for the personnel doing this work.
Note
The installation and related work described in this document takes about one day to complete. It is highly
recommended that the person commissioning the CDD has participated in CDD-specific training offered
by Airbus Defence and Space.
The CDD is a mandatory network element in all Airbus Defence and Space's TETRA networks which
have more than one DXT (it is optional in single-DXT networks). A network will generally have 1–4 CDDs
depending on its size and data distribution requirements.
CDD can exist as a single node server or as a duplicated CDD server solution. The single node CDD consists
of a single server and is intended for small networks. The duplicated CDD consists of two concurrently
running redundant servers (nodes), each of which contains a hot standby Solid database. The duplicated
CDD is primarily intended for medium and large networks.
• The server hardware is based on HP ProLiant DL380 Generation9 (Gen9).
For more information about single node CDD and duplicated CDD, see CDD Server, Product Description,
TRADXTAPP00182.
This document contains both generic instructions (applicable to both the single node CDD and duplicated
CDD), and instructions that are specific to either of the two solutions. In the case of specific instructions, the
applicability is clearly indicated.
We welcome any suggestions for further improvement of this document. Also, should you find any errors or
omissions in this document, please forward your comments to your Airbus Defence and Space representative
or e-mail them to tetra.cudo@airbus.com.
For information on the Linux CDD open source codes, see CINFODIN.
For information on the Linux CDD open source licences, see the document License Terms of 3rd Party
Software, TRASYSAPP00296
1.1 Scope of this document

This edition of the document applies only to a CDD running the TETRA Release 7.0 level software, or
higher, and comprising the following units:
• HP ProLiant DL380 Generation9 (Gen9) server unit(s) running the CentOS Linux 7 OS
• optional display and keyboard
1.2 How this document is organised
• Chapter 1 explains what this document is about, who it is intended for and how it is organised.
• Chapter 2 details the site requirements as they relate to the CDD and associated equipment. These
requirements include temperature and humidity levels, power feed and grounding, clearances and
accessibility etc.
• Chapter 3 tells you how to check and unpack the CDD delivery.
• Chapter 4 tells you how to install and connect the CDD units.
• Chapter 5 gives instructions for powering up/down the CDD units.
• Chapter 6 gives an overview of the CDD configuration process as a whole and lists the information
you will need to do it.
• Chapter 7 gives information on security-hardening the CDD.
• Chapter 8 gives instructions on configuring the CDD node(s).
• Chapter 9 contains instructions for configuring the DNS server.
• Chapter 10 gives instructions for configuring the CDD to work in the duplicated mode.
• Chapter 11 instructs how to configure the optional management interface.
• Chapter 12 gives instructions for creating and configuring the Solid database.
• Chapter 13 tells you how to test the IP connections between DXTs and CDD.
• Chapter 14 gives instructions on integrating the CDD and the NMS.
• Chapter 15 gives instructions for finalising the installation.
• Chapter 16 gives instructions for starting up and shutting down CDD applications.
• Appendix A gives instructions on starting up and shutting down the Webmin service.
• Appendix B gives instructions on starting up and shutting down the BIND DNS service.
• Appendix C gives instructions on checking the firewall settings.
• Appendix D is a quick guide to the vi editor.
• Appendix E lists CDD node services.
• Appendix F gives instructions for disabling the IP Path MTU Discovery protocol.
• Appendix G instructs how to configure the PuTTy window to ensure a correct view of configuration
windows from the console.
1.3 Typographic conventions

The typographic conventions used in customer documentation for Airbus DS TETRA System are explained in
the document Guide to TETRA Documentation, [ 3. ].
Note
If the sign \ is used at the end of a line in this document, it denotes that the command has been divided
on two separate lines for documentation purposes.
2 Site requirements
Site requirements relating to the CDD are given in this chapter.
The CDD is normally positioned next to the DXT.
2.1 Environment
The basic environmental requirements for the equipment room in which the CDD will be installed are
presented in Table 1 .
Table 1 : CDD environmental requirements
Parameter Range
Ambient operating -12...+40°C
temperature
non-operating -30...+60 °C
Relative humidity operating 8...90% non-condensing
non-operating 5...95% non-condensing
Altitude operating 3050m
Maximum allowable altitude
change rate is 457 m/min.
non-operating 9144 m
Maximum allowable altitude
change rate is 457 m/min.
2.2 Dimensions and weight

The equipment room layout plan must allocate enough space for the CDD server hardware. The CDD server
hardware is based on HP ProLiant DL380 Generation9 (Gen9). The HP ProLiant DL380 (Gen9) server is
2U high and will be mounted on a 19-inch rack. The single node CDD takes one 2U space in the rack and
the duplicated CDD takes 2 x 2U space.
The HP ProLiant DL380 (Gen9) server requires a rack whose depth is 1000 mm or more.
The dimensions of the CDD server are given in Table 2 .
Table 2 : Weights and dimensions of the CDD server (for a single HP ProLiant DL380 (Gen9))
Unit Height Width Depth Weight

HP ProLiant DL380 8.73 cm (3.44 in.) 44.55 cm (17.54 in.) 67.94 cm (26.75 in.) 14.759 kg (32.6
Generation9 (Gen9) lb.)1)
1) 8SFF chassis with 1xSFF HDD and 7 HDD blanks, 1x processor, 1x power supply (plusblank), 1x Flexible Smart Array, 1x Riser installed.
2.3 Power requirements

The CDD server power requirements are presented in the table below.
Table 3 : CDD server power requirements
Characteristics Required supply voltage Power consumption
Single node CDD 100-120 VAC 200-240 VAC 1-phase max. 1000 W
(50/60 Hz)
Duplicated CDD 100-120 VAC 200-240 VAC 1-phase max. 2000 W
(50/60 Hz)
Two 230 VAC UPS feeds equipped with IEC plugs are recommended for each CDD node. Two feeds per one
node enable the implementation of a redundant power supply.
2.3.1 UPS-initiated automatic CDD shutdown

Airbus Defence and Space strongly recommends that a UPS (Uninterruptible Power Supply) supporting the
automatic shutdown feature of the CentOS Linux 7 operating system be used to supply power to the CDD.
Products or auxiliary modules/software with CentOS Linux 7 support are offered by various manufacturers,
please refer to their instructions.
2.4 IP Backbone
The duplicated CDD and single node CDD communicate with DXT(s) and possibly other elements (TCS,
NMS, ATS, other CDDs) over a TCP/IP network called the IP Backbone. In a network comprising multiple
DXT sites the IP Backbone consists of the site LANs inter-networked by a WAN. Physically, the interface
between the CDD and the site LAN switch is implemented with Ethernet connections.
Figure 1 shows how the duplicated CDD units, clustered site LAN switch and the DXT's own internal LAN
switch units (SWU0/1) are interconnected in a bonded configuration. Bonding is a feature of the CentOS
Linux operating system which provides fault tolerance on the interface between the CDD and other network
elements. Each CDD node interfaces to the LAN switches through two network interfaces (Ethernet ports)
one of which is designated as the primary interface and the other as a secondary interface in the bonded
interfaces. In the event of a failure on the primary interface, the system will automatically switch to using the
secondary interface. Bonding operates at the Layer 3 level.
The CDD is placed on a separate VLAN (Virtual LAN) along with the other network elements with which it
communicates. A VLAN is a logical grouping of LAN-switch Ethernet ports defined by means of configuration
tables inside the switch. The VLAN architecture brings a number of advantages such as data-traffic isolation
among different VLANs.
Please refer to the site-specific documentation for information on LAN-switch port allocation for CDD use.
Note
Make sure that auto-negotiation is enabled on the LAN switch’s Ethernet ports to which the Linux-based CDD
is connected. Auto-negotiation is usually enabled by default.
Do not force full duplex mode on the network interfaces in the Linux-based CDD, including the nodes and
LAN switches. If it is used, it can cause for example CDD switchovers or drops in capacity.
Figure 1 : Duplicated CDD LAN (Ethernet)- and serial-interface connections
Figure 2 shows how the single node CDD unit, clustered site LAN switch and the DXT's own internal LAN
switch units (SWU0/1) are interconnected in a bonded configuration. The single node CDD interfaces to the
LAN switches through two network interfaces (Ethernet ports), one of which is designated as the primary
interface and the other as a secondary interface in the bonded group. Bonding works similarly as in the
duplicated CDD environment (see above).
192.168.0.2
XX.XX.XX.XX Default IP address
Serial port
10.10.10.12
Ser
Mgt
Etherne t port
Net Mgt
iLO
Procuction ne twork etherne t ports
1 2
HP ProLiant DL380 eno1, eno2 = bond0
Generation9 (Gen9) 3 4 Managemen t network etherne t ports
(Node 1) eno3, eno4 = bond1 (op tional)
1 2 3 4 Managemen t ne twork (optional)
Prod Mgt
LAN-Switch LAN-Switch
10.10.10.91 10.10.10.92
DXT
dn00505x1x0xen
Figure 2 : Single node CDD LAN (Ethernet-) and serial-interface connections
2.5 Serial management of CDD nodes

The serial port on a CDD node (i.e. server unit) is normally used only to change the iLO IP address and
during the checking of the first user account of iLO.
To use the node serial port, you must cable-connect it via an RS-232 connector to a configuration workstation.
Instructions for changing the IP address of the node serial port are given in Section 8.1 .
2.6 Local administration of HP ProLiant DL380 Generation9

Local administrative console can be used by connecting a display and keyboard to the server. Keyboard and
display are not included in the delivery.
2.7 Cabinet accessibility
The equipment-room layout plan must allocate enough free space around the CDD cabinet to allow easy
access from front and back at all times. The use of the CDD rack is optional. The HP ProLiant DL380
Generation9 (Gen9) server requires a 19” rack whose depth is 1000 mm or more.
3 Checking and unpacking the CDD delivery
Before accepting and unpacking the CDD delivery, visually check that the packaging is intact and that no
obvious damage has occurred. Unpack the delivery in accordance with the HP instructions.
Check all items in the delivery against those listed in the System Record. Keep the System Record pages.
The CDD delivery comprises the following:
• one node for single node CDD
• two nodes for duplicated CDD
The delivered node does not contain any operating system at all. It needs an USB based installation before it
is configured working as a CDD server.
The CDD documents provided by Airbus Defence and Space are not delivered with the single node CDD but
are part of Airbus DS TETRA System documentation set delivered to the customer.
Note
Make sure all items included in the delivery are carefully stored, so that they are available when needed.
Note
When you open the box in which the CDD for TETRA HW is delivered, check that it includes an envelope
which contains the Remote Console’s license for iLO.
Notice that the CDD delivery does not include the following items:
• Ethernet cables for connecting the CDD nodes to the DXT LAN-switch ports
• cables for network connections (IP connections)
• 19” rack
• mouse, keyboard and display
The mouse, keyboard and display are not normally needed in the CDD server. CDD is normally
configured through network connection with a web interface using a separate PC or laptop
(configuration client).
4 Installing and connecting the CDD
The work described in this chapter can be done by any authorised persons with the necessary skills and
experience in IT installation.
4.1 Positioning the CDD node(s)

Position the CDD node(s) in accordance with the site-specific equipment location plan. Connect the 100–120
/ 200–240 VAC UPS connectors to the corresponding site power supply receptacles.
4.2 Duplicated CDD cabling

The duplicated CDD is delivered with the HP ProLiant DL380 (Gen9) server units (nodes). The CDD’s
external cable connections are shown in Figure 3 .
Connect the CDD’s LAN port cables to the LAN switch ports designated for this purpose in the site-specific
installation instructions.
Figure 3 : Duplicated CDD cable connections, back view
Table 4 : Ports and interfaces in the HP ProLiant DL380 (Gen9) HW model
Net Port Interface Bond Comments
1 eno1 bond0 Production interfaces

2 eno2
3 eno3 bond1 Management
interfaces
4 eno4
4.3 Single node CDD unit cabling

The single CDD is delivered with the HP ProLiant DL380 (Gen9) server unit (node). The CDD’s external
cable connections are shown in Figure 4 .
Connect the CDD’s LAN port cables to the LAN switch ports designated for this purpose in the site-specific
installation instructions.
Figure 4 : Single node CDD’s cable connections, back view
4.4 Inspecting the installation work

The CDD installation work must be inspected and approved by a designated Airbus Defence and Space
technician before power is connected to any CDD unit. Airbus Defence and Space will not be responsible for
any damage resulting from faulty installation if this has not been done.
4.5 Checking the iLO admin user and IP address

Note
When the iLO admin user and IP address have been checked/changed to OK, iLO can be configured via web
UI . See the instruction in Section 8.1 .
Note
Null modem cable is needed for iLO serial port access. The cable is delivered with the CDD server.
Note
Set the default password for admin: use 'tetraadmin'.
1. Set the following parameters for the terminal client, e.g. PuTTY:
• Set window size to 100 columns and 31 rows.
• Set speed to 115200 baud/s.
• Set backspace key to Ctrl-H (Otherwise use Ctrl-H key sequence for back space).
• 8N1 (Data/Parity/Stop) XON/XOFF.
Connect the null modem cable between the serial terminal node and the CDD server node.
2. Power up the CDD server by pressing the power on button nodes on the front panel.
Note
If the default iLO IP addresses are used when installing duplicated CDD server system, change the
second CDD node’s iLO IP address for example to 192.168.0.3. If this is not done, the system has two
identical IP addresses in the network.
3. Wait in the serial console until it starts to print the system initialization data. The print shows IP address
of iLO if its already configured. In case of a new node the IP address should be 192.168.0.2. If the
address is not set, set it according to Section 4.7 .
Example print out:
(C) Copyright 1982 - 2015 Hewlett-Packard Development Company, L.P.
Early system initialization, please wait...
iLO 4 IPv4: 192.168.0.2
iLO 4 IPv6: FE80::3EA8:2AFF:FE1B:E616
3%: System Chipset Initialization
6%: QPI Link Initialization – Start
9%: QPI Link Initialization – Complete
4. When the node prints to the console string For access via BIOS Serial Console: select
Press 'ESC+9' for System Utilities.
Example print:
(C) Copyright 1982 - 2015 Hewlett-Packard Development Company, L.P.
HP ProLiant DL380 Gen9
BIOS Version: P89 v1.40 (05/06/2015)
Serial Number: CZ35359SWS
System Memory: 16 GB
1 Processor(s) detected, 8 total cores enabled, Hyperthreading is enabled
Proc 1: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
HP Power Profile Mode: Balanced Power and Performance
Power Regulator Mode: Dynamic Power Savings
Advanced Memory Protection Mode: Advanced ECC Support
Inlet Ambient Temperature: 21dC / 69dF
Boot Mode: UEFI
Redundant ROM Detected - This system contains a valid backup system ROM
HP SmartMemory authenticated in all populated DIMM slots.
For access via BIOS Serial Console:
Press 'ESC+9' for System Utilities
Press 'ESC+0' for Intelligent Provisioning
Press 'ESC+!' for One-Time Boot Menu
Press 'ESC+@' for Network Boot
5. Select System Configuration →iLO 4 Configuration Utility →User Management →Edit/Remove User.
Check that a user either with name <nodename>-admin or admin exists:
a. Select Action →Edit.
b. Check that the user has loginname = admin and following priviliges: Administer User Accounts,
Remote Console Access, Virtual Power and Reset, Virtual Media and Configure Settings.
c. If you want to change the admin user’s default password for example in cases where it does not
meet the site’s password policy, you can change it now:
i. Select Password and press Enter
ii. Type the password to the text box and press Enter.
iii. Confirm the password and press Enter.
d. If the username is admin, change it to <nodename>-admin:
i. Select the User Name entry and press Enter.
ii. Edit the username to <nodename>-admin and press Enter.
e. If the admin user does not exist, create it according to instructions in step 6. . Otherwise jump
to step 8. .
6. Select System Configuration →iLO 4 Configuration Utility →User Management →Add User.
7. Enter the following user information:
Leave the following parameters to yes: Administer User Accounts, Remote Console Access,
Virtual Power and Reset, Virtual Media and Configure Settings.
Set New User Name for example to <nodename>-admin.
Set Login Name to default user admin.
Enter default password tetraadmin or enter the password according site policy.
Tip
Select a line for modification and press Enter. A text box opens where you can add data. Add data
to the box and press Enter. The data is stored to system. If the text box contains pre-filled data and
backspace is not working, try the Ctrl-H key sequence. If the sequence is working set Ctrl-H for
backspace in the terminal configuration.
8. Exit from Add User or Edit/Remove User and User Management menu by pressing Esc.
4.6 Deleting the user account in iLO system controller

If user account was created with a wrong user name, for example, the user can be deleted as follows:
1. Select System Configuration →iLO 4 Configuration Utility →User Management →Edit/Remove User.
2. Navigate with arrow keys to the user you want to delete. Select Action and Delete.
3. Exit from the Edit/Remove User and User Management menu by pressing Esc.
4.7 Checking or configuring IP address for the iLO system

controller and setting iLO host name
Note
If the network has several CDD nodes, remember allocate unique IP addresses to every iLO unit.
To check or configure static ip-address for iLO follow procedure described below:
1. Select System Configuration →iLO 4 Configuration Utility →Network Options.
If you want use default network configuration of the iLO, check that the configuration is:
Address:192.168.0.2
Netmask:255.255.255.0
Gateway: 192.168.0.1
To exit Network Options, jump to the step 3. .
If you want to configure the address according to the used network, jump to step 2. .
2. Configure parameters:
Leave following parameters to as they are: MAC Address, Network Interface Adapter and
Transceiver Speed.
Switch DHCP Enable to off.
Set DNS Name to <nodename>-nad.
Set IP Address, Subnet Mask and Gateway IP Address according to the used network.
3. Exit from the Network Options and iLO 4 Configuration Utility menu by pressing Esc.
When you exit from the iLO 4 Configuration Utility the iLO console prompts about pending changes.
Answer yes and exit from the System Configuration.
4.8 Exiting from iLO configuration utility and rebooting the

system
When you have completed the configuration select Reboot the System.
After the reboot you can continue with more detailed iLO configuration and Linux CDD installation with
the iLO web interface.
4.9 Tidying up the equipment room

When you have completed the installation of the CDD, remove all packaging and trash from the room and
see that all tools, equipment and cables etc. which are not required during normal operation of the CDD are
removed or stored appropriately.
The equipment room should be kept clean and tidy at all times.
4.10 Product collection and safe disposal of the equipment

within the European Union
Guidelines for product collection and safe disposal of the equipment are indicated with a sticker placed on the
equipment, shown in the figure below.
Product collection and disposal within European Union
Do not dispose the
product as unsorted
municipal waste.
The crossed-out
wheeled bin means that
at the product end-of life
the product must be taken
to separate collection.
Note: this is applicable only
within European Union
(see WEEE Directive 2002/96/EC)
DN0577953
Figure 5 : Product collection and disposal within the European Union
5 Powering up/down the CDD units
5.1 Powering up and down a CDD node using the physical
power button
Physical power button of a node is located on the upper right side of the node in the front panel. It illuminates
in amber when the node’s power is off or green when the node is powered up. The nodes are powered on
and powered off simply by pressing the power button.
5.2 Powering down a CDD node using iLO

Open the connection to the system controller via the web user interface.
1. Select Power Management and then Server Power.
2. Select Graceful Power Off:, click Momentary press and confirm the command by clicking ok in
the confirmation dialog box.
5.3 Powering up a CDD node using iLO

Open the connection to the system controller via the web user interface.
1. Select Power Management and then Server Power.
2. Select Power On:, click Momentary press and confirm the command by clicking ok in the confirmation
dialog box.
5.4 Powering down a CDD node

Note
When duplicated CDD is in use, perform the procedure described below in both nodes.
1. Log in to CDD node through SSH or Remote Console via iLO web UI as a user who has the
superuser role. Switch to root account with sudo. You should get to the following prompt:
root@singlenodecdd:/#.
2. Ensure that the CDD application and Solid database are shut down.
Shut down the CDD by disabling the HA. Note that in a duplicated CDD, this has to be done on both
nodes if the aim is to power down both CDD nodes.
root@singlenodecdd: /opt/TETRAcddha/util# ./disable-cddha
Check the CDD running status.
root@singlenodecdd: /opt/TETRAcddha/util# ./status-cddha
root@singlenodecdd: /opt/TETRAcddha/util# iscdd
3. Power down the node by executing the command systemctl poweroff.
Example:
root@singlenodecdd: /# systemctl poweroff
If you logged in via an SSH session, the session closes immediately.
6 Configuration overview and prerequisite
information
Note
The CDD server does not have a separate CDD workstation. As an option, a display and keyboard can be
connected to the server.
Note
For the IP network configuration, a PC or laptop is needed.
Configuration of the CDD can begin when the CDD hardware has been installed, connected and powered up
as described in the preceding chapters of this document. The information which you will need to have ready
before you can begin the configuration is summarised in Section 6.1 .
The usernames and default passwords required during the configuration are listed in Table 5 .
For further information on logging in, users and passwords see Chapter About logins, users and passwords of
document CDD Server, User's Guide (DN03533676).
For further information on the iLO, see Appendix iLO principles of document CDD Server, User's Guide
(DN03533676).
Table 5 : Usernames and default passwords
Unit Username Default password Usage

CDD root tetra Note: It is possible to log in with the root account
right after the installation of CDD before execution of
configure linux script starts.
master User-defined Login account for the user which have superuser
password role. The created user has superuser role in
cdd and Webmin. Created when the CDD server
is commissioned. Username master is given
as an example, other suitable usernames can
be freely chosen. User-defined usernames are
recommended.
cdduser no password/no The cdduser user account is only accessible via
login sudo.
admin tetraadmin iLO login.
webminadmin changeme Webmin services admin user for CDD related tasks.
Can configure, enable and disable DNS and firewall
services and mange users and webmin.
webminuser changeme Webmin services user account for CDD related
tasks.
Can configure, enable and disable DNS and firewall
services.
Figure 6 : Overview of the CDD configuration and start-up process
6.1 Prerequisite information
You must have the following information ready before you begin configuration:
• The system IDs of all DXTs in the network and the DNS names and IDs of the relevant DXT computer
units:
– Server IP Unit (SIPU)
or if SIPU is not available:

– Central Memory and Marker (CMM)
or if CMM is not available:

– Operation and Maintenance Unit (OMU)
• The DNS names and ID numbers of all CDDs in the network.
• The MNI (Mobile Network Identity)
or
the MCC (Mobile Country Code) and MNC (Mobile Network Code).
(The MNI is calculated from the MCC and MNC).
• IP addresses for the following:
Single node CDD:
– CDD node (address for the node, NET MGT address and address for the optional management
interface)
Duplicated CDD:
– virtual name and virtual address
– virtual name and address for the management interface (optional)
– first CDD node (address for the node, NET MGT address, and optional management interface's
node name and address)
– second CDD node (address for the node, NET MGT address and optional management interface's
node name and address)
Common to both duplicated CDD and single node CDD:

– DXT computer units connected to CDD
– Default gateway (router)
– Used network number
– Used netmask
– NMS (option)
– ATS (option)
– Used NTP (Network Time Protocol) server
– Used DNS server(s)
The DNS service should provide name resolving for CDDs and DXTs.
– There are four alternative ways in which the DNS service can be provided:
♦ DNS for duplicated CDD
♦ DNS for single node CDD
♦ Separate DNS server supplied by the customer
Default IP address information for the CDD is given in Table 6 . A blank column is provided in the table
for entering the actual IP addresses.
• Used domain
• Host names for the following:
Duplicated CDD:
– CDD nodes (defaults = cdd1, cdd2).
– duplicated CDD name, also known as virtual CDD name (default = cdd).
Note
The duplicated CDD name and the host names can be replaced with names other than the default
ones during the installation phase. This is necessary if there is more than one CDD in the network
because two CDDs are not allowed to have the same host name.
Single node CDD:

– CDD node (no default, name can be chosen freely)
Host names for the management interface (optional).
Table 6 : Default IP address definitions for the CDD
Object Default IP address Actual IP Actual IP

address for address for
duplicated single node
CDD CDD
Duplicated 10.10.10.11 cdd.mfg.domain cdd N/A
CDD
Node 1 10.10.10.12 cdd1.mfg.domain cdd1
Node 2 10.10.10.13 cdd2.mfg.domain cdd2 N/A
Node 1 / Net 192.168.0.2 cdd1-nad.mfg.domain cdd1-nad
Mgt port (iLO)
Node 2 / Net 192.168.0.3 cdd2-nad.mfg.domain cdd2-nad N/A
Mgt port (iLO)
DXT 10.100.1.20 dxt1.corenet.example dxt1
Note
Depending on DXT type, the DXT interface unit type can vary.
7 Security-hardening the CDD
Security hardening of the CDD server is implemented with the following tools and methods:
• Minimalistic installation
• Minimalistic services
• Hardening of operating system
• Activation of secure administration
• Device control
• Firewall
• User access control
Security hardening and activation of secure administration of CDD is taken into use through customized
installation image and installation scripts.
For more information on checking the firewall settings, see Appendix C .

For more information on listing CDD node services, see Appendix E .
For more information on security hardening, see Chapter Security-hardening the CDD in document CDD
Server, User's Guide, DN03533676.
8 Configuring CDD node(s)
Perform the configuration procedures in this chapter in the order presented and, in the case of duplicated
CDD, in both nodes. All procedures are done from the console.
Note
At the CentOS Linux OS startup the following error messages can occur:
[ 0.062910] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 330)
[ 4.106187] i8042: can't read CTR while initializing i8042
[ 1.358960] power_metter ACPI000D:00: Ignoring unsafe software power gap!
You can ignore these error messages.
8.1 Checking or configuring the node NET MGT port (iLO) IP

address and hostname definitions via ILO web UI
The CDD is delivered with the default configuration. IP address definitions are pre-configured. The network
operator needs to check or change these settings in order to integrate the CDD into the network. The CDD
configuration is done via a console login through the node NET MGT port, so the IP address definition of this
port must be configured first. See Section 4.5 for setting up a serial port connection to iLO serial port and
Section 4.7 for setting up the IP address for iLO connection.
1. Log in to the iLO web UI as the admin user.
To login to the iLO web UI, type the IP address or FQDN node name to the web browser’s address
field. Use the admin user credentials given earlier (Section 4.5 ).
2. Set up the net management:
• Check or set the iLO hostname and domain name:
Select Network →iLO Dedicated Network Port and General tab.
If the Name or domain name needs to be changed, write the hostname and domain name to the
text boxes. Hostname format is <hostname of CDD node>-nad.
Click the Submit button after modification are done. If the domain name is grey and you are not
able to write the domain name into the text box, disable DHCPv4, DDNS server registration
and WINS server registration by unticking the check boxes on the IPV4 tab. Leave the Ping
Gateway on Startup tick box checked. Also disable all IPv6 features from the IPv6 tab by
unticking all check boxes.
• Check or set iLO hosts IP addresses:
Select Network →iLO Dedicated Network Port and IPv4 tab.

If you want to use the static IP address, untick Enable DHCPv4 tick box.
Add the address values (IPv4 Address, Subnet Mask and Gateway IPv4 Address) to dedicated
text boxes.
• Set iLO hosts DNS:
Add the DNS address value (Primary DNS Server) to the dedicated text box. Also add the
Secondary DNS Server and Tertiary DNS Server addresses if available.
Click Submit and then the Reset button after the modifications are done. Pressing the Reset
button resets the iLO.
3. Test the network connection to the net management of the system controller.
Test the changed address either by pinging or logging in to the web user interface.
8.2 Setting NTP client

When the Network Time Protocol (NTP) service is available in the network, set the NTP information for iLO.
Up to two IP addresses can be specified by a server index.
To set the NTP client:
1) Select Network →iLO Dedicated Network Port and SNTP tab.
2) If static IP address is used, untick the Use DHCPv4 Supplied Time Settings check box.
3) Untick the Use DHCPv6 Supplied Time Settings and Propagate NTP Time to Host check boxes.
4) Add the address value (Primary Time Server) to the dedicated text box. Also add the Secondary Time
Server address if available.
8.3 Setting time zone and time

The time zone and time needs to be set for iLO. It is recommended that you select the time zone from the
available options by using the server's location or the time zone abbreviation (for example, EET or EST).
To set the time zone:
1) Select Network →iLO Dedicated Network Port and SNTP tab.
2) Select the time zone value from the drop-down box.
3) Click Submit and then the Reset button after the modification is done. Pressing the Reset button
resets the iLO.
8.4 Activating the Remote Console’s licence and testing the

remote console
Activating the license
The license is included in an envelope in the box in which the CDD for TETRA is delivered. The license
must be activated.
1) Select Administration →Licensing.
2) Enter the license activation key.
3) Click Install.
If you need to change the license, enter the new key to the Activation Key field and click Install. The
existing key is replaced by the new key.
Testing the remote console
Note
.NET Integrated Remote Console (.NET IRC)
The .NET IRC provides remote access to the system KVM and control of Virtual Power and Media from a
single console built on the Microsoft .NET Framework.
If you are using Windows 7, Windows 8 or Windows 8.1, a supported version of the .NET Framework is
included in your operating system. The .NET Framework is also available at the Microsoft Download Center.
The .NET IRC supports the following versions of the .NET Framework: 3.5 (Full), 4.0 (Full), and 4.5.
Internet Explorer is the default browser for .NET IRC use. Other browsers can be used, but they might
require extra plugins.
Note
Java Integrated Remote Console (Java IRC)
The Java IRC provides remote access to the system KVM and control of Virtual Power and Media from a
Java applet based console. Java IRC requires the availability of Java.
.NET IRC:
1) Open the remote console by selecting Remote Console →Remote Console.
2) Check that the .NET Framework Detection status is OK. If the status is not OK, see .NET requirements
above the .NET Framework Detection.
3) If the requirements are OK click the Launch button. Click the Run button if the Application Run
Security Warning window pops up. Opening the console may take around 3 minutes.
Java IRC:
2) Check the Recommended/Supported Version of Java from the Java tab.
3) If the Java version meets the requirements, click the Launch button.
You can find further instruction on using the remote console from the Remote Console help. Launch the
Remote Console Help by clicking the ? button which is located on the upper right corner of the web page.
8.5 Checking the internal raid configuration

To check the internal raid configuration:
1) Connect to the console through iLO console.
2) Login to the iLO web UI.
Type the IP address or FQDN node name to the web browser’s address field. Use the admin user
credentials given earlier (Section 4.5 ).
4) Click the Launch button in either .NET or Java IRC section, depending on the method usable.
• If the NET method is used, click the Run button if the Application Run Security Warning window
pops up.
• If the Java IRC method is used, click the Continue button if the Security Warning about web site
pops up. Then click the check box I accept the risk and want to run this application and Run
button if Security Warning about Java Integrated Remote Console pops up.
Opening the console in both cases may take about 3 minutes.
5) When the console opens, shutdown the node by clicking Momentary Press on the power switch.
You can find this item on console’s upper left corner, Power Switch →Momentary Press.
The node shuts down immediately.
6) Restart the node by clicking Momentary Press on the power switch again.
7) Wait until the function bottom selection appears on the console’s bottom line. Press F9 when the F9
changes its colour to white.
8) Select System Configuration →Embedded RAID : Smart Array P440ar Controller →Exit and launch HP
Smart Storage Administrator(HPSSA).
Wait until the Smart Storage Administrator window opens.
9) Configure settings.
Note
In this window use mouse for configuration.
9.1 Click Smart Array P440 →Configure →Logical Devices.

9.2 Select Show all.
9.3 Check that you see one Logical Drive 1 with RAID 1 configuration and two SAS HDD’s.
The capacity of a RAID 1 logical drive is the same as one SAS HDD.
9.4 Check that SAS HDDs are on their own ports (Port 1, Box 3, Bay 1 and Port 2, Box 3, Bay 5).
In practice this means that SAS HDD’s are installed physically in slot 1 and slot 5 in the HP
ProLiant DL380 (Gen9) server.
After checking the SAS HDDs, do one of the following:
• If the configuration is as described, exit from the Smart Array P440 application clicking X
on the screen’s upper right corner and click OK for confirmation. Then click the switch
symbol on the same upper right corner. Reboot the server by clicking the reboot symbol.
Continue to Section 8.6 .
• If the configuration was not as specified, follow the instructions in topic Configuration not
as specified below.
Configuration not as specified
If the disks were not in their correct slots but raid configuration was correct, follow the instructions below:
1) Exit from the Smart Array P440 application by clicking X on the screen’s upprer right corner. Then click
OK for confirmation.
2) Click the switch symbol on the screen’s upper right corner.
3) Shutdown the server by clicking the shutdown symbol.
4) When the server is on power off state, move disks to their correct slots (1 and 5).
5) Start the server again by clicking Momentary Press on the power switch on the console’s upper
left corner.
6) Recheck the disk configuration and continue to Section 8.6 .
If the disks were on their correct slots but raid configuration was not correct, follow the instructions below.
Note that if raid configuration is RAID 0, there is no redundancy for logical disk at all.
1) Delete the Logical Drive 1 by selecting Logical Drive 1 and clicking the Delete Logical Drive button
on the right. Click Yes for confirmation.
2) Click the Create Array button.
3) Select both SAS HDD disks from Bay 1 and Bay 5 and click the Create Array button.
4) Select raid level RAID 1 and check that rest of the parameters are on their default values:
StripSize/FullStripeSize: 256KiB/256KiB
Sectors/Track: 32
Size: Maximum Size
Caching:Enabled.
5) Check array details and click the Finish button.
6) Exit from the Smart Array P440 application by clicking X on the screen’s upprer right corner. Then click
OK for confirmation.
7) Click the switch symbol on the screen’s upper right corner.
8) Reboot the server by clicking the reboot symbol and continue to Section 8.6 .
8.6 Installing the operating system and CDD software
Note
Airbus Defence and Space Linux CDD installation iso image is available in Airbus Defence and Space's
online service Cinfodin.
The TETRA CDD Server software and its platform CentOS Linux can be installed from a USB memory stick
that has been created from the appropriate ISO image. The image can be used to install the minimal set of
CentOS Linux packages required for the CDD Server and the CDD Server software. The name of the image
is formatted as follows: TETRA-CDD-Server_R<main release>-CD<CD number>-v<version>.iso,
for example TETRA-CDD-Server_R70-CD20-v1.iso.
8.6.1 Software installation

Install the software by following the steps below:
1) Create installation media by burning the ISO image to a USB memory stick.
The USB memory stick must be at least 2 GB in size.
In Windows, for example, a free of charge program called Rufus can be used. Rufus can be
downloaded from web site https://rufus.akeo.ie. Figure 7 shows suitable settings for TETRA CDD
Server image burning.
Note
The installation media must be labelled TETRA_CDD. If the label is anything else the installation
will fail.
Figure 7 : Rufus settings for TETRA CDD Server image burning
2) You are strongly recommended to protect the firmware configuration changes and boot source selection
with an Admin password unless you have done it already. See Section 8.6.4.1 for further instructions.
3) Insert the created installation USB drive media to the server’s right side USB connector.
4) Connect to the console through iLO console.
4.1 Login to the iLO web UI by typing the IP address or FQDN node name to the web browser’s
address field. Use the admin user credentials given earlier (Section 4.5 ).
4.2 Open the remote console by selecting Remote Console →Remote Console.
4.3 Click the Launch button in either .NET or Java IRC section, depending on the method usable.
• If the NET method is used, click the Run button if the Application Run Security Warning
window pops up.
• If the Java IRC method is used, click the Continue button if the Security Warning about web
site pops up. Then click the check box I accept the risk and want to run this application and
Run button if Security Warning about Java Integrated Remote Console pops up.
Opening the console in both cases may take about 3 minutes.
5) Reboot the node for USB installation.
5.1 When console opens shutdown the node by clicking Momentary Press on the power switch.
You can find this item from the console’s upper left corner, Power Switch →Momentary Press.
The node will shut down immediately
5.2 Restart the node by clicking Momentary Press on the power switch again.
5.3 Wait until the function bottom selection appears to console’s bottom line. Press F11 until the F11
symbol changes its colour to white. The Boot Menu opens after a while.
6) Boot the server from your installation media.
Select the boot source from the menu. Select your memory stick, you will likely find it from the bottom
part of the list. Do not select Generic USB Boot as it is not the correct device/media.
You will see a menu where you can select either installation or some troubleshooting options. The
troubleshooting options are introduced later.
Select the item Install TETRA CDD Server with CentOS Linux from the menu and press Enter. The
CentOS Linux packages and TETRA CDD Server software are automatically installed on the server.
E.g, the disk is partitioned automatically.
The server reboots once the installation is completed.
7) Remove the installation media from the server to avoid involuntary re-installations. The need for
this depends on your hardware boot settings.
8) Configure CentOS Linux as described in Section 8.6.3 .
8.6.2 Troubleshooting with the installation media

The installation images contain tools for troubleshooting. Under menu item Troubleshooting you can find
menu item Rescue a CentOS Linux system which can be use to boot a mini CentOS Linux. Once the mini
CentOS Linux comes up it tries to find existing installation from the hard disk. If it does find one, it mounts the
root file system and you can try to fix the problem. For further information refer to Section 8.6.3.13 .
8.6.3 CentOS Linux configuration

Once the installer has completed installation you must log in using the root account and the default
password (users and default passwords are listed in Table 5 ). Upon the first log in you are prompted to
select a suitable keyboard and timezone (see Sections 8.6.3.10 and 8.6.3.11 ). You will be automatically
logged out once to make sure the selected keyboard and timezone become effective. Log in again using
the root account credentials.
In order to complete the CentOS Linux customization, you (as a root user) must execute the following
command:
$ configure_linux
The command walks you through the remaining CentOS Linux configuration and customization steps when
you execute the command for the first time. Reboot the node after the execution of the configure_linux
command. Reboot ensures that the new settings become effective. Use command systemctl reboot to
reboot the node.
Note
As a final step the script locks the root account. The subsequent logins must be done using the superuser
account created during the final customization step.
Note
If you quit the configure_linux process before all the steps have been completed, the same walkthrough
steps are executed later when you execute the configure_linux utility.
You can execute CentOS Linux reconfiguration with the same command later on. In this case you can go
through all settings in walkthrough style or select an individual configuration step. Since the root account
has been locked already, the command must be re-executed with sudo, i.e.
$ sudo configure_linux
Reboot the node after changing the following configuration options:
• Walkthrough of all settings
• Network interface settings
• Hostname settings
Reboot ensures that the new settings become effective. Use command systemctl reboot to reboot the
node.
Introduction to dialogs
The configure_linux utility uses various dialog boxes where you can type in your parameters and
selections. You can navigate between the different parts of the dialog box using the Tab and arrow keys.
You can select/check list items by moving on top of the item that you want to select/check and then pressing
the Space bar.
The currently selected button is indicated with the button label surrounded by the (highlighted) characters <
>. For example,
< Ok > Cancel
indicates that the Ok button is active. Once you press Enter the action indicated in the selected button is
executed. If you are editing the content of a multi-line text box, then no button is active, and pressing Enter
causes a new line to appear in the text box.
You can cancel configuring one configuration item by selecting Cancel and pressing Enter. You must confirm
the cancellation since incomplete configuration likely leads to non-working setup. If you choose to cancel one
configuration item, configure_linux process jumps to the next item.
You can abort configuration by pressing Ctrl-C. You must confirm the abortion since incomplete configuration
likely leads to non-working setup. If you choose to abort configuration, configure_linux exits immediately.
The items you set before aborting configure_linux are left to their current values (the original values
are not resumed).
8.6.3.1 Configuration walkthrough
When the configure_linux utility is executed for the first time the utility walks you through a set of
mandatory settings. These steps are introduced in Sections 8.6.3.2 - 8.6.3.7 .
Once you have completed all the steps the utility opens a menu where you can select different individual
configuration items. The menu includes a few additional settings that were not executed during the
walkthrough.
8.6.3.2 Host and domain name
The first things to configure are the TETRA CDD Server host and domain names. Type the hostname and
domain name to the hostname and domain name boxes, respectively. The full hostname (concatenated as
host.domain) must follow the hostname rules presented in RFC 1123:
• The hostname can contain only letters from a-z and A-Z (in case insensitive manner), numbers 0-9,
and hyphen '-'. Other characters are not allowed.
• The full hostname is split into parts (labels), and the parts are separated with a single dot '.'. For
example, if the full hostname is host.sub-domain.domain, the labels would be host, sub-domain,
and domain.
• Maximum label length, i.e. the string between two dots, must not exceed 63 characters.
• The total hostname length including the dots must not exceed 256 characters.
The hostname must be unique within your domain; creating a duplicate host name will cause problems on
the network after you have installed and configured CentOS Linux.
For example,
Hostname: cdd-server
Domain: acme.com
Once you are ready, select the Ok button and press Enter. If your input is valid the hostname will be set.
8.6.3.3 Network configuration
The production network interface is implemented as a bonded interface of two physical interfaces. To
configure the network, follow the steps below:
1) Select two physical interfaces to be assigned to the bonded interface.
You must select the pre-selected first two interfaces for the bond. Once you are ready, select the
Ok button and press Enter.
Note
If you are reconfiguring the network and you have an existing management bond interface, the
interfaces assigned to the management bond are not shown in the list. If you wish to assign those
physical interfaces to the production bond, you must first delete the management bond.
Note
If user(s) experience connection problems while using SSH (for example the connection works in the
same network segment but connections behind routing do not work), the user(s) must check that
gateway, prefix/netmask etc. are configured correctly.
2) Type in the IPv4 address and prefix length to be assigned to the interface as well as an IP address
of the gateway.
The IP address must be unique and follow your site’s address conventions. If the address is not
formatted like this, a system/network failure can occur.
3) Select the Ok button and press Enter.
If your input is valid the bonded interface is configured and brought up.
For example,
IPv4 address: 10.10.10.10
Prefix length: 24
Gateway address: 10.10.10.1
For using auto-negotiation on the LAN switch’s Ethernet ports to which the Linux-based CDD is connected,
see section 2.4 .
For instructions on configuring static persistent routes (if needed), see section 8.6.3.14 . Static routes shall
only be configured for remote networks or hosts if the default gateway route, configured above in step 2, is
not suitable. Remote in this context means any networks or hosts that are not directly attached to the system.
8.6.3.4 Domain Name System
The Domain Name System configuration consists of two parts. To configure the Domain Name System,
follow the steps below:
1) Set the DNS server IPv4 addresses (domain names cannot be used).
Type in valid DNS server IPv4 addresses one for each line. The lines starting with # are discarded
automatically.
For example,
# Add DNS servers one per line (this line will be discarded)
10.10.132.35
If you have previously defined DNS server addresses they are shown and you can either remove or
edit them. If you do not want to specify any DNS servers, just leave the input box blank or all lines
commented with #.
3) Specify the DNS search domains. Type in valid DNS search domains one for each line.
The lines starting with # are discarded automatically.
For example,
# Add DNS search domains one per line
acme.com
bikes.acme.corp
If you have previously defined DNS search domains they are shown and you can either remove or
edit them. If you do not want to specify any DNS search domains, just leave the input box blank or
all lines commented with #.
8.6.3.5 Updating /etc/hosts file
The /etc/hosts file contains static IP address for hostname mappings. Usually the file contains mappings
for the local host address and the current IP addresses and host names. You can add more mappings by using
the configure_linux utility if you wish. Add one IPv4 address and its associated hostnames to one line.
Use one or more space(s) as a separator. Typically no additions are needed if DNS is used for IP addresses,
except for IP address – hostname pair(s) for the possible NMS(es) (which can be configured at a later stage).
For example,
10.10.10.20 machine machine.acme.com
10.100.100.4 fileserver4 fs4 fs4.acme.com
The lines starting with # are discarded automatically. If you have previously defined mappings they are shown
and you can either remove or edit them. If you do not want to specify any mappings, just leave the input
box blank or all lines commented with #.
Once you are ready select the Ok button and press Enter.
Note
Do NOT add localhost or the current hostname and their respective addresses to the hosts file. The
configure_linux utility adds them to the /etc/hosts file automatically.
Do NOT either add the configuration for the duplication with the configure_linux script. Instead, use the
duplicate_cdd.ksh script, see Section 10.1 . Modification of the duplication configuration which is found
in the /etc/hosts file can be made with the configure_linux script.
8.6.3.6 Time servers
TETRA CDD Server can update its clock from the network time servers (network time sources). Use of
network time is mandatory from TETRA Release 7.0 onwards.
Type in the time server IPv4 addresses or names one per line. The lines starting with # are discarded
automatically.
For example,
10.1.1.190
10.1.1.192
ts1.ntp-pool.acme.com
ts2.ntp-pool.acme.com
If you choose to specify the time servers with their domain names, the hostname to IP address mapping must
be available in your DNS server or /etc/hosts file. Otherwise, the time servers are not accepted by the
underlying time management software (chrony).
If you have previously defined time servers they are shown and you can either remove or edit them. You must
define at least one time server.
Once you are ready select the Ok button and press Enter.
Checking the chronyd status after walk through procedure
You can check the NTP synchronization status with the chronyc sources command.
If you need a print with more details, use the –v option.
Example:
root@cdd1:cdd: /# chronyc sources -v
210 Number of sources = 1
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp161n.client.lab 4 6 377 28 -280us[-1398us] +/- 121ms
root@cdd1:cdd: /#
You can also use a more illustrative command timedatectl. The command prints the status of the internal
clocks, synchronization, DST and the current time zone.
Example:
root@cdd1:cdd: /# timedatectl
Local time: Wed 2016-10-12 14:31:48 EEST
Universal time: Wed 2016-10-12 11:31:48 UTC
RTC time: Wed 2016-10-12 11:31:48
Time zone: Europe/Helsinki (EEST, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2016-03-27 02:59:59 EET
Sun 2016-03-27 04:00:00 EEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2016-10-30 03:59:59 EEST
Sun 2016-10-30 03:00:00 EET
root@cdd1:cdd: /#
8.6.3.7 Super user account
As the last step of the first time configuration walkthrough you must create a super user account. To create
the super user account, follow the steps below:
1) Choose the account name.
The default account name is master.
Select the name carefully, it is NOT POSSIBLE TO CHANGE the super user account name later on!
This configuration step can be executed only once. The subsequent walkthroughs will skip this step.
3) Type a new password for the new super user account (note that you must confirm the password
three times).
The password must meet the quality requirements described in Section 8.6.3.8 .
Once the new account has been created and password set successfully, the root account is locked. Once
you exit from the shell you will not be able to log in as a root user again. Instead, you must use the newly
created super user account.
8.6.3.8 User account management
You can manage TETRA CDD Server user accounts through the configure_linux utility. Select Manage
CDD user accounts from the main menu. A new menu will open where you can select to add new accounts,
remove existing accounts, reset password for an existing account, or list all the current accounts.
It is strongly recommended that you manage the user accounts using the configure_linux utility. In
principle, nothing prevents you form using the traditional Unix account management tools but the advantage
of the configure_linux utility is that the environment, roles, groups etc. will be configured automatically,
thus making the account management process a lot easier.
The account password must fulfil certain quality requirements:
• The password must contain at least 8 characters.
• The password must contain characters from at least three of the following character classes:.
– down cased letters
– up cased letters
– numbers
– punctuation
• The same character can be repeated consecutively at most twice.
• The passwords expires in 90 days. After that you are forced to select a new password.
• The password change interval is one day, i.e. after changing a password, you must wait for at least one
day until you can change the password again.
Add user
To add a new user account, follow the steps below:

1) Type in name for the account.
3) Select one or more roles for the account.
The roles are:
• SUPERUSER
• SYSADMIN
• CDDADMIN
For more information on the roles, see Section Roles in CDD Server, User's Guide, DN03533676.
5) Set a password for the new account.
Remove existing user
To remove an existing user account, follow the steps below:

1) Select the account you want to remove from the list.
You will be prompted to confirm that you really want to remove the account. Note that:
• Only one account can be removed at a time.
• The super user account cannot be removed. Therefore, it cannot even be selected.
• The account's home directory and all the files in the home directory will be removed.
Reset password
In order to reset a forgotten password for an existing user account, select the account, select the Ok button,
and press Enter. Now you can type in a new password for the user (note that you must confirm the new
password twice).
Edit roles of a user
1) Select the account for modification from the list.

3) Select or deselect one or more roles for the account. Note that you have to leave at least one role for
the account. The roles are:
• SUPERUSER
• SYSADMIN
• CDDADMIN
List
You can list the existing TETRA CDD Server user accounts and their respective roles.
8.6.3.9 Enabling Webmin interface
You can enable the Webmin interface through the configure_linux utility by following the steps below:
1) Execute the configure_linux utility:
$ sudo configure_linux
2) Select the menu option i and press Enter.
The Webmin interface is then enabled automatically.
For information on configuring the DNS server through the Webmin interface, see Chapter 9 .
8.6.3.10 Local console keyboard layout selection
Local console keyboard layout is selected during the first log in. If you want to change the local console
keyboard layout, select the suitable one from the list by pressing Space, select the Ok button, and press
Enter. If you wish you can test your selection and select another keyboard layout if the selected one is
not behaving correctly.
8.6.3.11 Timezone selection
Timezone is selected during the first log in. If you want to change the timezone, use the tzselect utility (you
can launch it from the configure_linux utility or directly from the command line).
The tzselect asks you to select first the continent or ocean, then country, and possibly an additional
area such as a state. Select you location or the closest location and answer yes if you wish to save the
new timezone.
Optionally you can define the timezone also using Posix TZ format if you know your timezone specification.
8.6.3.12 Boot loader accounts
The boot loader has been protected with an account and password. This means that the boot time arguments
cannot be modified or the system cannot be booted to the rescue, emergency, or single user mode (these
are different from the Linux rescue mode boot available on the menu) without knowing appropriate access
credentials. The account default values are the same as for ILO:
• account: admin
• password: tetraadmin
The boot loader access credentials can be modified through the configure_linux utility. Select Manage
boot loader accounts from the main menu. A new menu opens where you can select to add new accounts,
remove existing accounts, reset password for an existing account, or list all the current accounts.
It is strongly recommended that you manage the user accounts using the configure_linux utility. In
principle, nothing prevents you from editing the boot loader configuration files directly but the advantage of
the configure_linux utility is that all the required steps are done automatically thus making the account
management procedure very simple.
The boot loader account password do not have such a strong requirements as the CDD Server user
accounts have. However, to prevent intruders from gaining easy access to your system, consider using
strong passwords.
The changes become effective once you select the Done button from the menu and press Enter. You will
return to the main configure_linux menu. If you wish to abandon all the changes, press Ctrl-C. This
returns you to the main configure_linux menu and the changes you have made are discarded.
Add boot loader account
To add a new user account, follow the steps below:
1) Type in a name for the account.
3) Select a password for the user.
5) Repeat the selected password
The new account is created.
Remove boot loader account
In order to remove an existing user account, select the account to be removed from the list, select the Ok
button and press Enter. You will be prompted to confirm that you really want to remove the account.
Note
if you remove all the accounts, you will not be able to access to the boot loader configuration anymore until
you add a new one. You are strongly adviced to keep always at least one account active.
Reset password
In order to reset a forgotten password for an existing account, select the account, select the Ok button, and
press Enter. Now you can type in a new password for the account.
List
You can list the existing boot loader accounts.
8.6.3.13 Booting to rescue or emergency mode
If the TETRA CDD Server does not boot up after software update or hardware changes, the passwords are
lost, etc the server can be booted to rescue or emergency mode. There are a few different ways of doing it.
Booting with rescue initramfs
Normally the TETRA CDD Server is booted up using so called host-only initramfs which is tailored especially
for the hardware the software is installed on. The host-only initramfs contains only the kernel drivers that
are need for the current hardware, thus making the initramfs smaller and faster to load than a generic
initramfs that supports "all" hardware.
The rescue initramfs is needed, e.g., if a new hardware is installed or replaced with different one. In this
case it may be necessary to boot up the system using the generic rescue initramfs to make the system
recognize thew new hardware for the first time.
For the boot menu, select the menu item: Centos Linux (0-rescue-###) 7 (Core) and press enter. During
boot up phase, the host-only initramfs is regenerated and the old one will be replaced with the new one. Next
time the TETRA CDD Server can be booted up using the normal initramfs.
This operation is available for everyone, i.e. the boot loader access credentials are not needed when you
select this option.
Rescue with bootable USB
Boot the TETRA CDD Server using the installation media. From the boot loader's main menu select
Troubleshooting and then select Rescue a CentOS Linux system and press Enter.
When prompted, try mounting the file system in Read-Write mode, i.e. select the Continue button and press
Enter. If mounting to Read-Write mode fails you can try mounting to Read-Only mode as instructed by the
software. However, in the latter case you can just inspect the system and not make any changes to it.
If you manage to mount the original root file system to Read-Write mode you can change the master account
password, for instance.
$ chroot /mnt/sysimage
$ passwd superu
$ exit
$ exit # system boots
Now the master account password has been changed and the user can log in with the changed password.
Rescue or Emergency boot with current installation
The normal CentOS Linux Rescue and Emergency mode booting instructions do not work well in the TETRA
CDD Server environment, since the root account has been locked during the commissioning phase. In order
to access the root file system the root account would be needed in the normal rescue or emergency boot
ups. These are described in in wiki based documentation of CentOS, Section Setting Up grub2 on CentOS 7
and chapter Rescue Mode and Emergency Mode:
https://wiki.centos.org/HowTos/Grub2
TETRA CDD Server can be booted to an emergency mode where authentication is bypassed by following
the steps below:
1) Select item CentOS Linux (3.###) 7 (Core) from the boot loader menu, and press e to edit the boot
arguments.
In order to edit the boot arguments, you must provide appropriate boot loader credentials (see Section
8.6.3.12 ).
2) Scroll down on the screen until you find a line starting with linux16 (HW w/ BIOS) or linuxefi (HW
/w UEFI).
3) Add string rd.break to the end of the line.
Press Ctrl-e to jump to the end of the line.
4) Press Ctrl-x to boot.
In a few seconds you will land to emergency mode and you will see a shell prompt. At this point the
original root file system has been Read-Only mounted to /sysroot.
5) You can re-mount the root file system to Read-Write mode with:
$ mount /sysroot -o remount,rw
and make it the root directory (i.e. /) with:
$ chroot /sysroot
6) Do the changes you want and once finished, execute the following commands:
$ sync
$ exit
$ mount /sysroot -o remount,ro # This may not be necessary
If you wish to reboot the TETRA CDD Server, execute the following command:
$ reboot
If you whish to continue with start up procedure, execute the following command:
$ exit
Note
If you change a password, note that the punctuation characters may be difficult to use if you normally
use some other keyboard layout than us.
8.6.3.14 Configuring static persistent routes in route-interface files
General
Static routes are for traffic that must not, or should not, go through the default gateway. The default gateway
is for any and all traffic which is not destined for the local network and for which no preferred route is
specified in the routing table.
To configure static routes to be persistent after a system restart, they must be placed in per-interface
configuration files in the /etc/sysconfig/network-scripts/ directory. The file name should be of the format
route-ifname (where ifname is bond0 for the production network and bond1 for the management network).
Example
If a route to a remote production sub-network is required, a static route can be specified as in the following
example using the ip command arguments format (each line is parsed as an individual route):
10.10.10.0/24 via 192.168.0.10 dev bond0
where 10.10.10.0/24 is the network address and prefix length of the remote or destination network. The
address 192.168.0.10 is the IP address leading to the remote network. It is preferably the next hop address
but the address of the exit interface will also work. The “next hop” means the remote end of a link, for
example a gateway or router. Add as many static routes as required.
The following is an example of a route-interface file for the production network (route-bond0) using the ip
command arguments format. The exit interface is bond0 and a dedicated router (other than the default
gateway) is available at 192.168.0.10. The two static routes are for reaching the 10.10.10.0/24 production
sub-network and the 172.16.1.10/32 production host:
10.10.10.0/24 via 192.168.0.10 dev bond0

172.16.1.10/32 via 192.168.0.10 dev bond0
In the above example, packets going to the 10.10.10.0/24 production sub-network and 172.16.1.10/32
production host will be directed to 192.168.0.10. Packets going to the local 192.168.0.0/24 production
sub-network will be directed out the bond0 interface attached to that network.
Default gateway
The default gateway is e.g. 192.168.0.1 and shall be configured by using the configure_linux script to the
/etc/sysconfig/network-scripts/ifcfg-bond0 file. Packets to unknown remote networks will use the default
gateway, therefore static routes should only be configured for remote networks or hosts if the default route is
not suitable. Remote in this context means any networks or hosts that are not directly attached to the system.
Management interface
Similarly, static persistent routes can be configured for the management interface, in the
/etc/sysconfig/network-scripts/route-bond1 file. See also Chapter 11 .
Taking routes into use
Reboot the node after having configured the static persistent routes. Reboot ensures that the new settings
become effective. As the root user, use command systemctl reboot to reboot the node.
Note
If you forget to set correct routes for e.g. the management interface (if applicable) you may lose connectivity
to the server.
8.6.4 HP ProLiant DL380 Gen9 firmware configuration
This section introduces a few firmware configuration items for the HP ProLiant DL380 Gen9 device.
8.6.4.1 System password protection (recommended)
It is strongly recommended that you protect your device from unauthorized firmware configuration changes
and boot source selections. This can be done by setting an admin password as follows.
1) Switch on your device and press F9 System Utilities until the F9 symbol changes its colour to white.
After a while, a menu window appears.
2) Select System Configuration.

-> BIOS/Platform Configuration (RBSU)
-> Server Security
-> Set Admin Password
3) Type your password and press Enter. Confirm the password and press Enter.
4) Press F10 to save the change.
5) Press the Esc key 3 times and select Reboot the System from the menu. The system reboots and
next time when you want to change the configuration or select the boot source, you will be prompted to
provide the password.
Note
If you wish to remove the password, execute the steps above but instead of typing a new password,
press Enter twice.
8.6.4.2 Booting from USB memory stick
In order to boot HP ProLiant DL380 Gen9 from the USB memory stick:
1) Press F11 Boot Menu once the selection becomes available on the bottom of your screen.
After a while, you will be prompted to provided the Admin password if you have set it as described and
recommended in Section 8.6.4.1 . Upon successful authorization you will land to a menu where you
can select the boot source.
2) Select the boot source from the menu.
Select your memory stick, you will likely find it from the bottom part of the list. Do not select Generic
USB Boot as it is not the correct device/media.
8.7 Checking and configuring autopower on and power-up
delay settings
Check that the system restores the last power state if a power failure has occurred. Also check that power
on delay is set to Random up to 120 Seconds:
1) Select Power Management →Server Power.

2) Click Restore Last Power State and Random up to 120 Seconds.
3) Click Submit.
9 Configuring the DNS server
The CDD can be operated as a domain name server (DNS). In the duplicated CDD, one of the server nodes
is configured as the master DNS and the other one as the slave DNS. The single node CDD is configured in
the same way as the master DNS, except no slave DNS is configured.
9.1 Setting up the master DNS records

These instructions apply to both the duplicated CDD and single node CDD. Note, however, that some of the
steps apply only to the duplicated CDD or the single node CDD; this is indicated in the relevant steps.
Steps:
1) Check that the Webmin service is running. If it is not running, start it
For instructions, see Appendix A .
2) Log in to Webmin as a user who has the superuser role or belongs to the webminadmingroup
group: https://<ip>:10000.
3) In Webmin, select Servers ⇒ BIND DNS Server.
4) On the Bind DNS Server page, click the Module Config link at the top of the page to configure the
start, stop, and restart commands for the DNS server binary.
4.1 On the Configuration: For module BIND DNS Server page, check that the following parameter
values correspond to the values listed in the following table. For the other parameters, use the
parameters' default values.
Parameter Change default value to
Chroot directory to run BIND under select radio none
Default PID file location(s) /run/named/named.pid
Command to start BIND systemctl enable named;systemctl
start named
Command to stop BIND systemctl stop named;systemctl
disable named
Command to apply BIND configuration, systemctl restart named
Other command
For instructions on how to start up and shut down the BIND DNS service from the command
line, see Appendix B .
4.2 Save the changes by clicking the Save button.
Figure 8 : Configuration: For module BIND DNS Server
5) Check the DNS server’s listening address.
On the Bind DNS Server page click Addresses and Topology and set the listening port number
and address to their default values.
6) Check the Zone Defaults settings.
6.1 In the Bind DNS Server page's Global Server Options section, select Zone Defaults.
6.2 On the Zone Defaults page, check the following values.

Parameter Change default
value to
Refresh time 60 s
Transfer retry time 60 s
Allow queries from.. Default
6.3 If needed, click the Save button.
Figure 9 : Zone Default settings for master zone
7) This step applies to the duplicated CDD only.

Configure the Other DNS Servers settings.
7.1 In the Bind DNS Server page's Global Server Options section, select Other DNS Servers.
7.2 In the Other DNS Servers page's IP address field, fill in the Slave DNS's IP address. Leave the
other values to their default values.
7.3 Click the Save button.
Figure 10 : Defining the Other DNS Servers for the duplicated CDD
8) This step applies to the duplicated CDD only.
Configure the Forwarding and Transfers settings.
8.1 In the Bind DNS Server page's Global Server Options section, select Forwarding and
Transfers.
8.2 In the Forwarding and Transfers page's Servers to forward queries to field, fill in the IP
address(es) of the Slave DNS. Leave the field Port (optional) empty.
Leave the other values to their default values.
Figure 11 : Defining the Forwarding and Transfers for the duplicated CDD
9) Create the Master Zone in the master DNS server for forwarding the DNS queries.
9.1 On the Bind DNS Server page's Existing DNS Zones section, click the Create master zone link.
9.2 On the Create Master Zone page, define the values for the following parameters.
Parameter Values
Zone type Forward (Names to Addresses)
Domain name / Network client.lab *)
Records file Automatic

Master server rho *)
Email address root@rho.client.lab *)
Refresh time 60 s
*) Note that this is only an example value.
9.3 Click the Create button.
Figure 12 : Creating the Master Zone (forward)
10) Edit the domain's Zone parameters.

10.1 On the Bind DNS Server page's Existing DNS Zones section, click the master zone you created.
10.2 On the Zone Parameters page, check that the parameter values are correct. Note that these
parameter values are usually filled in automatically.
Parameter Value
Master server rho.client.lab*)
Refresh time 60 s

Figure 13 : Editing the Zone Parameters of the master server
11) Check the domain's Zone Options.

11.1 On the Bind DNS Server page's Existing DNS Zones section, click the master zone which you
created.
11.2 On the Zone Options page, check that the following parameters are set to the following values:
Parameter Value
Check names? Ignore
Notify slaves of changes? Default
Leave the fields Allow updates from..,, Allow transfers from..,, Allow queries from..,, Also
notify slaves.. empty.
Figure 14 : Checking the Zone Options of the master server
12) Create the Master Zone for the reverse DNS query (Addresses to Names).
12.1 On the Bind DNS Server page's Existing DNS Zones section, click the Create master zone link.
12.2 On the Create Master Zone page, define values for the following parameters.
Note
Leave out the last octet of the network's IP address. For example, if your network address
is 10.30.49.0 use 10.30.49 instead.

Zone type Reverse (Addresses to Names)
Domain name / Network: 10.30.49 *)

Master server rho.client.lab *)
Refresh time 60 s
Figure 15 : Create the Master Zone (reverse)
13) Edit the reverse domain's Zone parameters.
13.1 On the Bind DNS Server page's Existing DNS Zones section, click the reverse master zone
which you created in the previous step.
13.2 Check that the parameter values are correct. These values are usually filled in automatically.
value to
Master server rho.client.lab *)
Refresh time 60 s
value to
Leave the other values to their default values. The Zone Parameters page is shown in figure 13 .
14) Check the domain's Zone Options settings.
14.1 On the Bind DNS Server page's Existing DNS Zones section, click the reverse master zone
you created.
14.2 Check that the following values have been defined.

Parameter Value
Check names? Ignore
Leave the fields Allow updates from..,, Allow transfers from..,, Allow queries from..,, Also
notify slaves.. empty.
Figure 16 : Checking the Zone Options of the Master Zone (reverse)
15) Add the host address pairs to the master zone.
15.1 In the Bind DNS Server page's Existing DNS Zones section, select the master zone.
15.2 On the Edit Master Zone page, select A - Address.
15.3 In the Address Records page's Add Address Record field, fill in the domain's short name and
select the domain's IP address.
For example, short name rho and IP address 10.30.49.104.
Figure 17 : Adding the Address Records for the master server
16) Check that addresses were added automatically to the reverse master zone as well.
16.1 In the Bind DNS Server page's Existing DNS Zones section, select the reverse master zone (for
example, 10.30.49).
16.2 On the Edit Master Zone page, select PT- Reverse Address.
16.3 On the Reverse Address Records page, check that added hosts are listed. If the records are not
found, check the configurations of the master forward and master reverse zones.
Figure 18 : Checking the reverse Address Records
17) Start the DNS server by clicking the Start Name Server button at the bottom of the BIND DNS Server
page.
Note
If start of Name Server fails with the following error print out:
Failed to start BIND : Job for named.service failed because the control process exited with error code.
See "systemctl status named.service" and "journalctl -xe" for details.
check first that the hostname of the CDD server node is added to DNS configuration tables.
Figure 19 : Bind DNS Server
18) Test the functionality of the Master DNS server with DNS client by using the nslookup command.
18.1 Check the mapping from name to address:
root@cddadm1: ~# nslookup <host name> <ip address of master DNS \
server>
Example:
root@rho: /# nslookup pi.client.lab 10.90.110.138
Server: 10.90.110.138
Address: 10.90.110.138#53
Name: pi.client.lab Address: 10.30.49.105
root@rho: /#
18.2 Check the mapping from address to name:

root@cddadm1: ~# nslookup <ip address of host> <ip address of master \
DNS server>
Example:
root@rho: /# nslookup 10.30.49.105 10.90.110.138
Server: 10.90.110.138
Address: 10.90.110.138#53
105.49.30.10.in-addr.arpa name = pi.client.lab. root@rho: /#
19) This step applies to the single node CDD only.

After you have configured the DNS service in the single node CDD, shut down the Webmin service by
using the service webmin stop command. For instructions, see Appendix A .
9.2 Setting up the slave DNS records

These instructions apply only to the duplicated CDD.
Steps:
1) Log in to Webmin as a user who has the superuser role or belongs to the webminadmingroup
group: https://<ip>:10000.
2) In Webmin, select Servers ⇒ BIND DNS Server.
3) On the Bind DNS Server page, click the Module Config link at the top of the page to configure the
start, stop, and restart commands for the DNS server binary.
3.1 On the Configuration: For module BIND DNS Server page, check that the following parameter
values correspond to the values listed in the following table. For the other parameters, use the
parameters' default values.
Chroot directory to run BIND under select radio button none
Default PID file location(s) /run/named/named.pid
Command to start BIND systemctl enable named;systemctl
start named
Command to stop BIND systemctl stop named;systemctl
disable named
Command to apply BIND configuration systemctl restart named
Figure 20 : Configuration: For module BIND DNS Server
4) Check DNS server’s listening address.
On the Bind DNS Server page click Addresses and Topology and set the listening port number
and address to their default values.
5) Configure the Zone Defaults settings.
5.1 In the Bind DNS Server page's Global Server Options section, select Zone Defaults.
5.2 On the Zone Defaults page, use the parameters' default values, except change the following
values.
value to
Refresh time 60 s
5.3 If changes were made, click the Save button.
Figure 21 : Configuring the Zone Defaults of the slave server
6) Configure the Other DNS Servers settings.
6.1 In the Bind DNS Server page's Global Server Options section, select Other DNS Servers.
6.2 In the Other DNS Servers page's IP address field, fill in the Master DNS's IP address. Leave the
other values to their default values.
Figure 22 : Other DNS Servers for the slave server
7) Configure the Forwarding and Transfers settings.
7.1 In the Bind DNS Server page's Global Server Options section, select Forwarding and
Transfers.
7.2 In the Forwarding and Transfers page's Servers to forward queries to field, fill in the IP
address(es) of the Master DNS. Leave the field Port (optional) empty.
Figure 23 : Configuring the Forwarding and Transfers for the slave server
8) Create the Slave Zone in the slave DNS server.
8.1 On the Bind DNS Server page's Existing DNS Zones section, click the Create slave zone link.
8.2 On the Create Slave Zone page, define the values for the following parameters.
Zone type Forward (Names to Addresses)
Domain name / Network client.lab *)

Master servers 10.90.110.138 *)
Server port Default

Figure 24 : Creating the Slave Zone
9) Check that the domain's Zone Options settings are correct.
9.1 On the Bind DNS Server page's Existing DNS Zones section, click the slave zone which you
created.
9.2 On the Zone Options page, check that the following parameters are set to the following values:
Parameter Value
Master servers 10.90.110.138 *) **)
Server port Default

Maximum transfer Default
Records file /var/named/slaves/client.lab.hosts*) **)
Check names? Ignore
Allow updates from Default
Allow transfers from Default
Allow queries from Default
Also notify slaves Default
**) Usually filled in automatically
Figure 25 : Checking the Zone Options of the slave server
10) Create the Slave Zone for the reverse DNS query (Addresses to Names).
10.1 On the Bind DNS Server page's Existing DNS Zones section, click the Create slave zone link.
10.2 On the Create Slave Zone page, define values for the following parameters.
Note
Leave out the last octet of the network's IP address. For example, if your network address
is 10.30.49.0 use 10.30.49 instead.

Zone type Reverse (Addresses to Names)
Domain name / Network 10.30.49 *)

Master server 10.90.110.138 *)
Server port Default
Figure 26 : Creating the Slave Zone (reverse)
11) Check the domain's Zone Options settings.
11.1 On the Bind DNS Server page's Existing DNS Zones section, click the reverse slave zone you
created.
11.2 On the Zone Options page, check that the following values have been defined.
Master servers 10.90.110.138 *) **)
Server port Default

Maximum transfer Default
Records file /var/named/slaves/10.30.49.rev*) **)
Check names? Ignore
Allow updates from.. Default
Allow transfers from.. Default
Also notify slaves.. Default
**) Usually filled in automatically
Figure 27 : Checking the Zone Options settings
12) Start the DNS server by clicking the Start Name Server button at the bottom of the BIND DNS Server
page.
Figure 28 : Bind DNS Server
13) Check that the DNS tables are downloaded from the Master server.
13.1 In the Bind DNS Server pages's Existing DNS Zones section, select the created forward slave
zone.
On the Edit Slave Zone page, the link Addresses shows the amount of downloaded records
in parenthesis.
Figure 29 : Edit Slave Zone forward updated from master
13.2 In the Bind DNS Server pages's Existing DNS Zones section, select the created reverse slave
zone.
On the Edit Slave Zone page, the link Reverse Addresses shows the amount of downloaded
records in parenthesis.
Figure 30 : Edit Slave Zone reverse updated from master
14) Test the functionality of the master and slave DNS servers with the DNS client by using the nslookup
command.
14.1 Check the mapping from name to address from the master DNS server:
root@cddadm1: ~# nslookup <host name> <ip address of master DNS \

server>
Example:
root@rho: /# nslookup rho.client.lab 10.90.110.138
Server: 10.90.110.138
Address: 10.90.110.138#53
Name: rho.client.lab
Address: 10.30.49.104
root@rho: /#
14.2 Check the mapping from address to name from the master DNS server:
root@cddadm1: ~# nslookup <ip address of host> <ip address of master \

DNS server>
Example:
Server: 10.90.110.138
Address: 10.90.110.138#53
104.49.30.10.in-addr.arpa name = rho.client.lab.
root@rho: /#
14.3 Check the mapping of name to address from the slave DNS server:
root@cddadm1: ~# nslookup <host name> <ip address of slave DNS \

server>
Example:
root@rho: /# nslookup rho.client.lab 10.90.110.139
Server: 10.90.110.139
Address: 10.90.110.139#53
Name: rho.client.lab
Address: 10.30.49.104
root@rho: /#
14.4 Check the mapping of address to name from the slave DNS server:
root@cddadm1: ~# nslookup <ip address of host> <ip address of slave \

DNS server>
Example:
Server: 10.90.110.139
Address: 10.90.110.139#53
104.49.30.10.in-addr.arpa name = rho.client.lab.
root@rho: /#
10 Configuring duplicated CDD
This section gives instructions for configuring the CDD nodes to work in the duplicated mode. Perform the
configuration procedures in this chapter in the order presented. All procedures are done from the console.
Note
Before you start configuring the duplicated CDD, both the primary and secondary node must be installed and
powered on, and the operating system must be running. The nodes must also be connected to the network.
10.1 Changing the configuration to support duplication

The nodes for duplicated CDD are first installed with single node default configuration. Companion node
references and virtual address configurations needed for duplicated CDD are not set. Needed settings are
inserted by connecting each node via NET MGT port or some other applicable console connection.
Run duplicate_cdd.ksh on both nodes

1) Log in to the node as a user who has the superuser role. Switch to root account with sudo:
sudo su -
2) Change to directory /opt/TETRAcddha/util and run script duplicate_cdd.ksh:
root@cdd1: ~# cd /opt/TETRAcddha/util
root@cdd1: /opt/TETRAcddha/util# ./duplicate_cdd.ksh
3) The following message will appear on the screen, for entering the required information:
3.1 ./duplicate_cdd.ksh accessed at /opt/TETRAcddha/util by cdduser pts/3
Jun 20 09:56 (<FROMNODE>)
./mkdha.conf.ksh accessed at /opt/TETRAcddha/util by cdduser pts/3 Jun
20 09:56 (<(<FROMNODE>)
Please fill the following:
mkdha.conf.ksh:SOLID_SID:assign virtual CDD name ->
cdd
where <FROMNODE> is the node, from where you have connected to the current one. Enter the
name for duplicated service.
3.2 mkdha.conf.ksh:CNODE:assign companion node ->
cdd2
Enter the duplicated CDD companion node's host name.
3.3 mkdha.conf.ksh:PNODE:assign preferred node
mkdha.conf.ksh:Preferred node must be either this node or companion
node->
cdd1
Enter the preferred primary node's host name. Preferred primary node is the node which is
selected as primary node if no other criteria can be used for the selection. The same node
must be configured as preferred primary at both nodes, if no special reason exists, select cdd1
at both nodes.
3.4 mkdha.conf.ksh:VIPA:assign virtual ip address
mkdha.conf.ksh:Give address in the dot-decimal notation ->
10.10.10.11
Enter the IP address for duplicated service.
3.5 mkdha.conf.ksh:SUMMARY
mkdha.conf.ksh: SOLID_SID : cdd
mkdha.conf.ksh: CNODE : cdd2
mkdha.conf.ksh: pnode : cdd1
mkdha.conf.ksh: VIPI: bond0
mkdha.conf.ksh: VIPA : 10.10.10.11
mkdha.conf.ksh:Do you want to save this information?
mkdha.conf.ksh:answer "yes" or "no" ->
yes
Select "yes" for confirmation.
3.6 ./mksolidhac.ini.ksh accessed at /opt/TETRAcddha/util by cdduser pts/2
Jun 17 18:39 (<FROMNODE>)
mksolidhac.ini.ksh:starting...
mksolidhac.ini.ksh:reading...
EREIP: Do you want to use default router value 10.10.10.1 ?
mksolidhac.ini.ksh:answer either "yes" or "no" ->
yes
Select "yes" for default external reference equipment IP or "no" for entering different IP for ERE.
3.7 ./init_hosts.ksh accessed at /opt/TETRAcddha/util by cdduser pts/2 Jul
5 15:04 (<FROMNODE>)
"10.10.10.11 cdd.<DOMAINNAME> cdd" added to the "hosts".
init_hosts:Give companion nodés IP address or skip this with typing
"skip".
init_hosts:Give address in the dot-decimal notation or "skip" ->
10.10.10.13
where <DOMAINNAME> is the domain, where the current node belongs to. Enter the duplicated
CDD companion node's IP address.
3.8 ./duplicate_ssh.ksh accessed at /opt/TETRAcddha/util by cdduser pts/1

Jul 5 15:04 (<FROMNODE>)
duplicate_ssh.ksh:Generating ssh keys for cdduser at cdd2
duplicate_ssh.ksh:Copying key to cdd2. Please give password of cdduser

if asked.
The authenticity of host 'cdd1 (10.10.10.12)' can't be established.
RSA key fingerprint is c8:8f:50:23:b2:14:41:e0:2e:86:69:03:66:1a:3c:fe.
Are you sure you want to continue connecting (yes/no)? —>
yes
3.9 Password:
Enter password for super user.
Examples on printouts of duplicate_cdd.ksh script are shown in Appedix H ,
10.2 Finalizing the CDD configuration

Activate the Virtual IP Address in the preferred primary node by running VipaUp.ksh:
sudo su -
2) Change to directory /opt/TETRAcddha/util/:
root@cdd1: ~# cd /opt/TETRAcddha/util/
root@cdd1: /opt/TETRAcddha/util#
3) Run the script:
root@cdd1: /opt/TETRAcddha/util# ./VipaUp.ksh
The following message will appear on the screen:

./VipaUp.ksh accessed at /opt/TETRAcddha/util by cdduser pts/12 Jul 2 08:13
(<FROMNODE>)
VipaUp.ksh:Do you want to assign virtual address to this node?
VipaUp.ksh:answer either "yes" or "no" ->
yes

VipaUp.ksh:VIPA taken into use
Check that the Virtual IP Address is now active in the node:
root@cdd1:cdd: /opt/TETRAcddha/util# ./status-cddha

L O C A L C D D N O D E (cdd1)
---------------------------------------+
HA_OFFLINE |solid |solidhac |
|OFF |OFF |
---------------------------------------+
rqm |mel |cas |ccm |
OFF |OFF |OFF |OFF |
---------------------------------------+
xcm |mux |dxsam |mcm |
---------------------------------------+
tcsproxy |loadlim |snmpd |
OFF |OFF |OFF |
---------------------------------------+
logpos: N/A |12:28:10 10.02.16|
---------------------------------------+
cdd1 has following bonds configured :
--------------------+
bond0: |
eno1 UP |
eno2 UP |
bond0 UP |
--------------------+
VIPA (10.10.10.11) is taken into use on interface bond0
root@cdd1:cdd: /opt/TETRAcddha/util#
Create trusted ssh link between duplicated CDD nodes
Duplicated CDD should now have been configured as instructed in 10.1 and earlier in this chapter. Next, the
already generated keys can be taken into use by running the command
cat /tmp/<companion_node>_id_dsa.pub >> ~/.ssh/authorized_keys
Example:
cdduser@cdd1: ~$ cat /tmp/cdd2_id_dsa.pub >> ~/.ssh/authorized_keys
on both nodes as cdduser.
After completing this phase, you can delete the <companion_node>_id_dsa.pub files.
After the configuration, test, as cdduser, that the ssh connection works from node 1 to node 2 and vice
versa, without a password.
11 Configuring the management interface
<optional>
If required, a separate network interface for management purposes can be taken into use in the single node
CDD and duplicated CDD. A separate management interface is needed in the CDD if you want to separate
the network management type of communication (such as SSH connections and SNMP communication)
from the communication in the production network (such as handling TCS client and Tactilon requests and
communication with the DXT network).
If the optional management interface is not implemented or used, skip this chapter.
11.1 Connecting the interface Ethernet cables

In each node, connect two Ethernet cables to the two free NIC LAN ports to which the eno3 and eno4
interfaces are configured. For more information on cabling, see chapters 4.2 and 4.3 .
11.2 Configuring the management interface

The management interface is configured by running the configure_manag_if.ksh script in each node.
Note
Make sure that the HA is shut down in the CDD node in which you are going to configure the management
interface.
1) As root user, change to the directory /opt/TETRACDD/scripts/feature/manag_if.
root@cdd2:cdd: /# cd /opt/TETRACDD/scripts/feature/manag_if
2) Run the script.
root@cdd2:cdd: /opt/TETRACDD/scripts/feature/manag_if# \
./configure_manag_if.ksh
Note
If the management interface's information is changed, the former information is removed unless stated
otherwise.
When prompted by the script, give the following information:
Note
The script automatically defines bond1 as the management interface. For a CDD node configured to
work in the duplicated mode, the script defines bond1 also as the virtual CDD management interface.
For a single node CDD, the script does not define the virtual CDD management interface (the value is
left empty in the manag_if.conf file).
2.1 Domain of management interface

Note
This domain is given for the CDD node name and the virtual CDD name of the management
interface and additionally acts as a DNS search domain of the management interface. If more DNS
search domains are needed for the management interface, these can be added with command
nmcli con mod bond1 +ipv4.dns-search <DNS search domain> (Note that the + sign
in the command is important as it keeps the earlier defined DNS search domain configuration.).
2.2 CDD node name of management interface

Note
If you give a hostname that is already in the /etc/hosts file, you will be notified about that. If
you continue, the lines containing the hostname will be removed from /etc/hosts file also
in cases where the domain name is different.
2.3 CDD node IP address of management interface

2.4 Network prefix of management interface
2.5 Gateway IP address of management interface
2.6 Configure 0 – 4 DNSes for the management interface
Note
If more DNSes are needed at a later stage for the management interface, these can be added with
command nmcli con mod bond1 +ipv4.dns <DNS IP address> (Note that the + sign in
the command is important as it keeps the earlier defined DNS IP address configuration.).
2.7 Select two network interfaces for management interface bonding

Select eno3 as interface 1 for management interface bonding and eno4 as interface 2 for
management interface bonding.
Note
The two network interfaces are bound together into a single, bonded, channel to provide interface
redundancy.
2.8 Virtual CDD name of management interface
This cannot be defined for a single node CDD. In case of a single node CDD, the script adds the
same name as in step 2.2 to the manag_if.conf file.
Note
If you give a hostname that is already in use, you will be notified about that. If you continue, the
lines containing the hostname will be removed from /etc/hosts file also in cases where the
domain name is different.
2.9 Virtual CDD IP address of management interface

This cannot be defined for a single node CDD. In case of a single node CDD, the script adds the
same IP address as in step 2.3 to the manag_if.conf file.
2.10 Do you want the traps to be sent from CDD IP address of the management interface (instead of
from the production interface's IP address)?
Select either value 1 or 0. The value 1 enables the CDD trap sender address of the management
interface. If you select the value 0, the CDD trap sender address of the production interface
is used instead.
Note
It is possible to enable the management interface's IP address to be used as the CDD trap sender
address at a later point. For instructions, see chapter 11.3 .
In step 3 and 4 , a Network Address Translation (NAT) rule is added to CDD’s firewall for outgoing
traps. That is, in a single node CDD, the traps will then be sent from the CDD node IP address of
management interface and in a duplicated CDD, the traps will be sent from the Virtual CDD IP
address of management interface. The NMS needs this information to be able to identify the CDD.
Additionally in step 3 and 4 below, static routes are configured for the trap destination host(s). In
case the traps are sent to the management network, the routes include bond1 as the exit interface
and the gateway IP address of the management interface defined in step 2.5 above. In case the
traps are sent to the production network, the routes include bond0 as the exit interface and the
gateway IP address of the production interface defined in section 8.6.3.3 .
For instructions on configuring static persistent routes for other purposes than the trap destination
host(s) (if needed), see section 8.6.3.14 . Static routes may be needed e.g. for remote
management sub-networks or hosts. Remote in this context means any networks or hosts that are
not directly attached to the system.
2.11 Do you want to save this information?
The information of the management interface to be saved is displayed, as shown in the following
example.
Example:
configure_manag_if.ksh:SUMMARY
configure_manag_if.ksh: MANAG_IF_CDD_INTERFACE : bond1
configure_manag_if.ksh: MANAG_IF_CDD_VIRTUAL_INTERFACE : bond1
configure_manag_if.ksh: MANAG_IF_DOMAIN : mfg.domain
configure_manag_if.ksh: MANAG_IF_CDD_OWN_NODE_NAME : cdd2-mgt
configure_manag_if.ksh: MANAG_IF_CDD_OWN_NODE_IP_ADDRESS : 10.90.85.52
configure_manag_if.ksh: MANAG_IF_PREFIX : 24
configure_manag_if.ksh: MANAG_IF_GATEWAY : 10.90.85.1
configure_manag_if.ksh: MANAG_IF_DNS_1 : 10.20.55.55
configure_manag_if.ksh: MANAG_IF_DNS_2 :
configure_manag_if.ksh: MANAG_IF_CDD_VIRTUAL_NAME : cdd-mgt
configure_manag_if.ksh: MANAG_IF_CDD_VIRTUAL_IP_ADDRESS : 10.90.85.50
configure_manag_if.ksh: MANAG_IF_CDD_TRAP_SENDER_ADDRESS_ENABLED : 1
Check the information. If you answer yes, then:
• The management interface is added to the interface list and the CDD node IP address of
management interface and the network prefix of management interface are assigned to the
management interface. Also the gateway, DNS search domain and DNSes of management
interface are assigned to the management interface. The state of the management interface
is also set to up.
• The given information is updated to the following files:
– /etc/sysconfig/network-scripts/ifcfg-<management interface>
(given CDD node IP address, prefix, gateway, DNS search domain and DNS(es) of
management interface)
– /etc/hosts (given management hostnames with domain and IP addresses)
– /etc/resolv.conf (given DNS search domain and DNS(es) of management interface)
• All given management interface information is stored to the following file:

/opt/TETRACDD/scripts/feature/manag_if/manag_if.conf
Note
The virtual CDD IP address of management interface is saved to the manag_if.conf file, but
it is not activated on the virtual CDD management interface (that is, bond1) at this point even
if the CDD node is configured to work in the duplicated mode. The virtual CDD IP address
of management interface will be activated when this node becomes the primary node of the
duplicated CDD, that is, when this node is activated by CDD HA. Then the virtual CDD IP address
of management interface and the network prefix of management interface will be assigned to the
virtual CDD management interface.
The virtual CDD IP address of management interface is deactivated on this node when the CDD
HA deactivates this node (for example, a switchover is performed to the other node which then
activates the virtual CDD IP address of management interface there). This way for example
SNMP GET requests can be performed from the NMS by targeting the virtual CDD IP address of
management interface. These requests will then be routed to and handled by the active CDD node.
3) If you selected to use the CDD trap sender address of the production interface (value 0) in step 2.10 ,
run the following script to ensure that the traps are sent out from the IP address of the CDD production
interface (Note that in a duplicated CDD this is the Virtual CDD IP address.).
Though, if you are transferring the trap sending from the management network to the production
network and generally always if you need to change the trap destination host(s), then you need to
perform step 4 instead.
root@cdd2:cdd: /opt/TETRACDD/scripts/tools# ./activatesnmp.ksh
4) If you selected to use the CDD trap sender address of the management interface (value 1) in step
2.10 , perform the following steps to complete the transferring (or modification) of the trap sending
to the management network.
These steps need to be performed whenever you change the trap destination host(s), e.g. also from
the management network to the production network (Note that in this case you need to define the trap
destination host(s) of the production network and not management network below).
4.1 Define the management network's trap destination host(s) to the /etc/hosts file by using the
configure_linux script.
Note
It is not enough to place this configuration only to the DNS records.
Example:
10.90.85.170 osspkgmgmt1.mfg.domain osspkgmgmt1
where osspkgmgmt1 is the common trap destination hostname for the management interface.
4.2 Define the management network's trap destination host(s) to snmpd process's configuration.
The preparesnmp.ksh script also adds a NAT rule to CDD’s firewall for outgoing traps so that
the traps are sent out from the IP address configured in step 2 for the CDD management interface
(Note that in a duplicated CDD this is the Virtual CDD IP address of management interface.).
Note
The host(s) can be defined as hostname(s), fully qualified name(s) or IP address(es) for the
preparesnmp.ksh script.
root@cdd2:cdd: /opt/TETRACDD/scripts/tools# ./preparesnmp.ksh –n <trap

destination hostname/IP address>
where <trap destination hostname/IP address> must be the same as that added to
the /etc/hosts file.
Example:
root@cdd2:cdd: /opt/TETRACDD/scripts/tools# \
./preparesnmp.ksh –n osspkgmgmt1
The trap destination host you have entered is saved as a SNMPv2c trap destination (with the
trap2sink configuration directive) in the /etc/snmp/snmpd.conf file.
Note
It is possible to give more than one trap destination host to the /etc/hosts file and for the
preparesnmp.ksh script, for example:
root@cdd2:cdd: /opt/TETRACDD/scripts/tools# \
./preparesnmp.ksh –n osspkgmgmt1 –n osspkgmgmt2
In the end, the snmpd process is restarted.
5) If the DNS service is used, configure the IP address — hostname (also domain) pairs of the IP
addresses configured for the CDD management interface to the DNS records, and optionally configure
also the trap destination host(s) to the DNS records.
6) Reboot the node by using the systemctl reboot command.
7) Check the configuration.
7.1 Using the command ip addr show, verify that:
• The CDD node IP address of management interface is correctly activated on the
management interface.
• The network interface configuration is generally OK in this CDD node.
7.2 Verify that the content of the /etc/sysconfig/network-scripts/ifcfg-<management
interface>, /etc/hosts, and /etc/resolv.conf files is correct.
7.3 Test the management interface by pinging it from the management network.
7.4 For a duplicated CDD, try to activate the virtual CDD IP address of management interface in the
node, if it has not already been activated by CDD HA.
1) Run the ./manag_if_VipaUp.ksh script.
root@cdd2:cdd: /opt/TETRAcddha/util# ./manag_if_VipaUp.ksh
When you run the script, the following message will appear on the screen. Select yes
for confirmation.
root@cdd2:cdd: /opt/TETRAcddha/util# ./manag_if_VipaUp.ksh
./manag_if_VipaUp.ksh accessed at /opt/TETRAcddha/util by
superu pts/1 2015-11-12 14:43 (rdc10.tetra.lab)
Running on non-Solaris host (/usr/sbin/ip address add 10.90.85.50/24 dev bond1 / ping -c 3)
manag_if_VipaUp.ksh:Checking current status of cdd-mgt...
PING status: 1
manag_if_VipaUp.ksh:Do you want to assign virtual IP address of management interface
(=10.90.85.50) to this node?
manag_if_VipaUp.ksh:answer either "yes" or "no"->
yes
plumbing mVIPI with command: /usr/sbin/ip address add 10.90.85.50/24 dev bond1 ...
... Done.
manag_if_VipaUp.ksh:Virtual IP address of management interface (=10.90.85.50) has been taken
into use on bond1.
2) Check that the virtual CDD IP address of management interface is now active in the node.
Example:
---------------------------------------+
|OFF |OFF |
---------------------------------------+
---------------------------------------+
---------------------------------------+
OFF |OFF |13345 |
---------------------------------------+
logpos: N/A |14:16:43 23.12.15|
---------------------------------------+
--------------------+
bond0: |
eno1 UP |
eno2 UP |
bond0 UP |
--------------------+
--------------------+
bond1: |
eno3 UP |
eno4 UP |
bond1 UP |
--------------------+
VIPA (10.90.110.35) is not taken into use in cdd2
VIPA of management interface (10.90.85.50) is taken into use on interface bond1
3) Test the virtual CDD IP address of management interface by pinging it from the management
network.
4) Deactivate the virtual CDD IP address of management interface.
root@cdd2:cdd: /opt/TETRAcddha/util# ./manag_if_VipaDown.ksh
Example:
root@cdd2:cdd: /opt/TETRAcddha/util# ./manag_if_VipaDown.ksh
./manag_if_VipaDown.ksh accessed at /opt/TETRAcddha/util by superu pts/0 2015-11-12 14:58
(rdc10.tetra.lab)
manag_if_VipaDown.ksh:Do you want to take out virtual IP address of management interface from
this node?
manag_if_VipaDown.ksh:answer either "yes" or "no"->
yes
manag_if_VipaDown.ksh:Taking out virtual IP address of management interface
(=mVIPA=10.90.85.50) with command: "ip addr del 10.90.85.50/24 dev bond1"
manag_if_VipaDown.ksh:mVIPA has been taken down.
---------------------------------------+
|OFF |OFF |
---------------------------------------+
---------------------------------------+
---------------------------------------+
OFF |OFF |13345 |
---------------------------------------+
logpos: N/A |14:16:43 23.12.15|
---------------------------------------+
--------------------+
bond0: |
eno1 UP |
eno2 UP |
bond0 UP |
--------------------+
--------------------+
bond1: |
eno3 UP |
eno4 UP |
bond1 UP |
--------------------+
VIPA of management interface (10.90.85.50) is not taken into use in cdd2
5) After the CDD HA has been started up in this node and the node has been activated, test the
virtual CDD IP address of management interface also by pinging it from the management
network. Check also that the virtual CDD IP address of management network is correctly
taken into use by executing the command status-cddha -b.
11.3 Transferring the sending of traps from the production
network to the management network
If you want to switch from using the CDD trap sender address of the production interface to using the CDD
trap sender address of the management interface sometime after the management interface has already
been configured, perform the following steps.
1) Shut down the HA of the CDD node.
2) In the manag_if.conf file, enable the CDD trap sender address of the
management interface by changing the value 0 to 1 on the line that contains
MANAG_IF_CDD_TRAP_SENDER_ADDRESS_ENABLED.
3) Define the management network's trap destination host(s) to the /etc/hosts file and optionally to the
DNS, and run the preparesnmp.ksh as instructed in steps 4.1 — 4.2 in chapter 11.2 .
4) Start up the HA of this CDD node.
12 Creating and configuring the Solid database
Note
After you have created and configured the database as instructed in this chapter you must shut down the
database engine.
Note
When creating a database for duplicated CDD, the simplest way is to create the database with
soldb_recreate.ksh. Perform it on both nodes in situations where the CDD network is created from
scratch. If the database is intended to be copied from another CDD, running the soldb_recreate.ksh
script is not needed on the primary node (but needed in the secondary node).
12.1 Performing the Solid environment check

Perform the following procedures in all nodes.
Build the environment
1) Log in to the node as a user who has the superuser and cddadmin role. Switch to cdduser account
with sudo:
sudo su - cdduser
2) Change to directory /opt/TETRACDD/db/scripts:
cdduser@cdd2: /opt/TETRACDD/db/scripts/admin$
cd /opt/TETRACDD/db/scripts
3) Run buildenv.ksh:
cdduser@cdd2: /opt/TETRACDD/db/scripts$ . ./buildenv.ksh
This will assign values to environment variables SOLIDDIR, SOLID_SID and SOLID_HOME, and expand
your PATH and LD_LIBRARY_PATH variables.
Perform the Solid environment check
You can view the definitions of SOLIDDIR, SOLID_SID, SOLID_HOME, PATH and LD_LIBRARY_PATH
with the following commands:
• cdduser@cdd1:cdd: ∼$ env | grep SOLID
The result should be of the form:
SOLIDDIR=/solid01/soldata/cdd
SOLID_SID=cdd
SOLID_HOME=/opt/solid/Solid7.0
• cdduser@cdd1:cdd: /opt/TETRACDD/scripts/tools# env | grep PATH
The result should be of the form:
LD_LIBRARY_PATH=/opt/solid/Solid7.0/bin
PATH=/opt/solid/Solid7.0/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/dt/bin:/opt/
SUNWspro/bin/:/usr/atria::/opt/TETRACDD/db/scripts/admin
12.2 Creating, starting, initialising and shutting down the

database
This chapter describes how to create, start and initialise a new database.
If no previous database exists, create a new database from scratch as instructed in this chapter.
If, however, you are adding a single node CDD or duplicated CDD to a running network, an existing CDD's
database can be copied to the CDD being commissioned by using the DownloadAndInstallDb.ksh script.
• In the single node CDD, follow the instructions given in chapter Adding a CDD to a running network in
the document CDD Server, User's Guide, (DN03533676) and then continue to chapter 13 .
• In the duplicated CDD, create and start the database for the secondary node as instructed in chapter
12.2.1 . Then continue by following the instructions in the chapter Adding a CDD to a running network
in the document CDD Server, User's Guide, (DN03533676). After you have added the CDD to the
running network as instructed in CDD Server, User's Guide, continue to chapter 13 .
12.2.1 Creating and starting a database

Perform the procedure in all nodes.
Note
Create the database in the node of the single node CDD and in both the primary and secondary node
in the duplicated CDD.
This procedure will work even if there is a database already running.

CAUTION
EXECUTING THE PROCEDURE BELOW WILL DELETE ALL EXISTING DATABASES!
1) Change to directory /opt/TETRACDD/db/scripts/admin:

cdduser@cdd1:cdd: ∼$ cd /opt/TETRACDD/db/scripts/admin
2) As cdduser, create the database by executing the following script:
cdduser@cdd1:cdd: ∼$ ./soldb_recreate.ksh
This creates a database on your system with the same name as the virtual name and starts the
database engine. The DBA (Database Administrator) username is dba and the password dba.
12.2.2 Initialising the database
Before the CDD can begin operating, you must initialise the database with the system parameter MNI. This is
done by editing the fillDb_<virtual name>.sql and executing its contents.
Note
If you are configuring the database for a single node CDD, replace the virtual name with the single node
CDD's node name.
Note
If you are configuring the database for a duplicated CDD, you have to perform the procedures presented in
this chapter only on the preferred primary node.
Editing fillDb_<virtual name>.sql and executing its contents

1) Change to the directory /opt/TETRACDD/db/scripts/setup, which contains the file
fillDb_prdsys.sql:
cdduser@cdd1:cdd: ∼$ cd /opt/TETRACDD/db/scripts/setup
2) Make a copy of the file fillDb_prdsys.sql to this same directory and change the filename to
fillDb_<virtual name>.sql (keep the original file).
Use the VI editor to edit the contents of the file. For instructions on using the VI editor see Appendix D .
3) Edit the MNI value specified in the fillDb_<virtual name>.sql to correspond to that of your
network. In the example below the MNI value is 409601 (change that value):
-- SYSTEM MNI
-- CDD Server will not start if MNI is not set
insert into CDD_CONFIGURATION (PARAMETER, VALUE)
values ('MNI', 409601);
The MNI (Mobile Network Identifier) is a number which uniquely identifies the network among all
TETRA networks. It can be calculated from the MCC (Mobile Country Code) and MNC (Mobile Network
Code) for your network as follows:
MNI = (MCC x 216) + MNC
Save the file.
4) Copy the edited file fillDb_<virtual name>.sql to the other node with the following command:
cdduser@cdd1:cdd: ∼$ scp /opt/TETRACDD/db/scripts/setup \
/fillDb_<virtual name>.sql cdduser@<secondary node IP address>: \
/opt/TETRACDD/db/scripts/setup/
5) Before running the all.ksh script associated with duplicated CDD installation, the node must be in the
HSB PRIMARY ALONE state. Set the state by running SetPrimaryState.ksh from the directory
/opt/TETRACDD/db/scripts/admin/.
cdduser@cdd1:cdd: ~$cd /opt/TETRACDD/db/scripts/admin
cdduser@cdd1:cdd: ~$./SetPrimaryState.ksh
6) Change to directory /opt/TETRACDD/db/scripts/setup and execute script all.ksh
cdduser@cdd1:cdd: ∼$cd /opt/TETRACDD/db/scripts/setup
cdduser@cdd1:cdd: ∼$./all.ksh <virtual name>
Execution takes a few seconds.
7) Check the connection to the database as username cdd by changing to directory
/opt/TETRACDD/db/scripts/admin and running the following script:
cdduser@cdd1:cdd: /opt/TETRACDD/db/scripts/admin$ ./soldb_getversion.ksh \
<virtual name> cdd cdd
If this script displays the database schema version (e.g. 10.14.0) the connection to the database is
working correctly.
8) Check the file /opt/TETRACDD/db/scripts/setup/SetupErrors.log, it should be empty.
If SetupErrors.log is not empty, it means that database creation has failed due to an internal
error. Browse the results of file fillDb_<virtual name>.log for possible errors in your network
configuration. If there are any errors logged in this file, correct your fillDb_<virtual name>.sql
file, run soldb_recreate.ksh to clear the database, and then re-execute this whole procedure
from the beginning.
9) Start CDD using HA.
Log in to the node as a user who has the superuser role. Switch to root account with sudo:
sudo su -
Start CDD using HA as follows:
cdd1# bash
Current SOLID_SID equals "cdd"
Your Solid Database environment has been defined
properly and it is safe to start/shutdown the
CDD server from directory /opt/TETRACDD/scripts.
root@cdd1: ~# cd /opt/TETRAcddha/util/
root@cdd1: /opt/TETRAcddha/util# ./enable-cddha
In duplicated CDD, check at the preferred primary node that CDD is started up and the node is in the
PRIMARY_ACTIVE state, and that the secondary node is in the SECONDARY_ACTIVE state:
root@cdd1:cdd: /opt/TETRAcddha/util# ./status-cddha -b
---------------------------------------+
HA_ONLINE |solid |solidhac |
PRIMARY_ACTIVE |3193 |3163 |
---------------------------------------+
4074 |4099 |4110 |4209 |
---------------------------------------+
4176 |4045 |4049 |4031 |
---------------------------------------+
4359 |4366 |2510 |
---------------------------------------+
logpos: 86113 |12:55:52 09.02.16|
---------------------------------------+
--------------------+
bond0: |
eno1 UP |
eno2 UP |
bond0 UP |
--------------------+
VIPA (10.90.110.35) is taken into use on interface bond0
fetching companion data...
C O M P A N I O N C D D N O D E (cdd2)
---------------------------------------+
|solid |solidhac |
SECONDARY_ACTIVE |3273 |3215 |
---------------------------------------+
---------------------------------------+
---------------------------------------+
OFF |OFF |2508 |
---------------------------------------+
logpos: 86113 |12:55:54 09.02.16|
---------------------------------------+
--------------------+
bond0: |
eno1 UP |
eno2 UP |
bond0 UP |
--------------------+
12.2.3 Shutting down and restarting the database

If you need to shut down and restart the database manually without HA (HA has to be disabled), do the
following:
1) As cdduser, shut down the database by executing the following script:
cdduser@cdd1:cdd: ∼$ ./soldb_shutdown.ksh
2) Start the database by executing the following script:
cdduser@cdd1:cdd: ∼$ ./soldb_start.ksh
12.3 Network configuration

Note
This procedure is needed only when creating the database from scratch.
Network configuration should be done using the CDD's CLI (Command Line Interface) after the CDD has
been started for the first time:
1) Add and register to the DXTs by means of the CLI (AddDXT, RegDXT).
2) Configure the APN, connection group and MSISDN home DXT by means of the CLI (SetHomeDXT).
3) Run consistency checks, beginning with organisations, to warm up the CDD (DoCC).
After this, you can use the CLI to add more CDDs if you wish and move/add DXTs under the new CDDs.
Note
Re-creation of the database may lead to loss of activation information for some features. For this reason
you should check whether earlier-activated features have remained activated after database recreation
and re-activate them if they are not. See document Feature Activation Manual (DN04161854) for further
information.
13 Testing the IP connections
Note
The Webmin service is disabled by default for security reasons but can be activated by the user if required.
Test the IP connections by pinging from every DXT connected to the CDD and from the CDD to every DXT
with the following commands.
From CDD:
ping <dxt-name>
From DXT:
ZQRX:SIPU,0,0::PING:IP="10.10.10.11",SRC="10.100.1.20";
This command is an example for SIPU, with 10.100.1.20 exemplifying the SIPU IP address. Use the correct
values and DXT units configured in your network:
• If SIPU is not present, use CMM instead.
• If neither SIPU nor CMM are not present, use OMU.
The response will be <virtual name>/<dxt-name> is alive if the IP connection is working correctly,
whereas a timeout is received if the connection is not working. In the event of a timeout, check and correct
the IP-address definitions and re-test the connection.
In the case ping cannot be used (for example a firewall may prevent its use), try to use a telnet client on a
CDD server for testing the connection. Open the connection to SIPU's 832 port with the following command:
telnet <ip-address of DXT computer unit> 832
If the connection is working, the telnet connection is established in a couple of seconds.
Example:
superu@cdd1:cdd /# telnet 10.90.43.136 832
Trying 10.90.43.136...
Connected to 10.90.43.136.
Escape character is '^]'.
Connection to 10.90.43.136 closed by foreign host.
root@cdd1:cdd /#
Do not proceed until the IP connections are working correctly.
14 Integrating CDD with the NMS
If the network, in which you have installed the CDD, has a network management system (NMS), you must
integrate the CDD with the NMS system (NetAct™ TETRA or NetBoss XT® for TETRA).
When the management is done with the NetAct, you need to perform an integration procedure in both the
CDD and NetAct. Full instructions for doing this are given in the NetAct™ TETRA customer document
Integrating CDD Server with NetAct TETRA (DN03351245), in Chapter Integrating CDD Servers.
When the NetBoss XT is used to manage the network, integration steps need to be performed in both the
CDD and NetBoss XT. For instructions, refer to the document Integrating TETRA System Network Elements
with NetBoss XT (TRADXTAPP00079), Chapter Integrating CDD Server to NetBoss XT.
For more information on the NMS, also refer to Chapter Fault management (alarms) in the document CDD
Server, User's Guide (DN03533676).
15 Finalising the installation
As a final step in the installation you are strongly recommended to make backups of the configuration files
and copy them to a safe place. Follow the procedure below.
Making a backup of the configuration files

sudo su -
2) Change to directory /opt/TETRACDD/scripts/tools and run script trans_conf.ksh:
root@cdd1:cdd: /#cd /opt/TETRACDD/scripts/tools
root@cdd1:cdd: /opt/TETRACDD/scripts/tools# ./trans_conf.ksh
The following message will appear on the screen:

root@cdd1:cdd: /opt/TETRACDD/scripts/tools# ./trans_conf.ksh
Copying configurations files to /global/solid/current_cdd/configuration/cdd1/cdd-cdd1_conf
Do you want to take a backup of CDD DB (y/N)? y
Make backup from database...
...
CDD configuration backed up.
Do you want collect CDD log files also (y/N)? n
OK, done.
root@cdd1:cdd: /opt/TETRACDD/scripts/tools#
where <node name> is the name of the node in which you are running this script (e.g. cdd1).
3) In the case of duplicated CDD, repeat step 1 in the secondary node.
4) Store the backup files from directory /global/solid/current_cdd/configuration/<node

name> to a safe place.
16 Starting up and shutting down the CDD
Instructions for starting up and shutting down the CDD applications are given in customer document CDD
Server, User's Guide (DN03533676).
A Instructions for starting up and shutting down
the Webmin service
A.1 Starting up the Webmin service

Check whether Webmin's miniserv.pl service is running by using the command pgrep or systemctl.
In the following example, the miniserv.pl is running as process 18906.
Example:
Example of pgrep command:

superu@cdd1:cdd: ~# pgrep miniserv.pl
18906
superu@cdd1:cdd: ~#
Example of systemctl command:

superu@cdd1:cdd: ~# systemctl is-active webmin
active
superu@cdd1:cdd: ~#
If Webmin is not running, start it with the systemctl start command.
Example:
root@cdd1:cdd: /# systemctl start webmin
root@cdd1:cdd: /#
A.2 Shutting down the Webmin service

The Webmin service can be shut down by using the systemctl stop command.
Example:
root@cdd1:cdd: /# systemctl stop webmin
root@cdd1:cdd: /#
Check that the Webmin service is not running by using the command ps.
In the following example, the process ID of miniserv.pl is not found, which indicates that the
miniserv.pl is not running.
Example:
Example of ps command:
root@cdd1:cdd: /# ps -ef | grep miniserv.pl
root 9716 5931 0 13:21:25 pts/1 0:00 grep webmin
root@cdd1:cdd: /#
Example of systemctl command:

superu@cdd1:cdd: ~# systemctl is-active webmin
inactive
superu@cdd1:cdd: ~#
B Instructions for starting up and shutting down
the BIND DNS service
B.1 CLI
B.1.1 Starting up the DNS service with CLI

Check whether the DNS service is running by using the command systemctl is-active named.
In the following example, the DNS service is running (online).
Example:
root@cdd1:cdd: ~# systemctl is-active named
inactive
root@cdd1:cdd: ~#
If the DNS service is not running, start it with the command systemctl start named.
Example:
root@cdd1:cdd: ~# systemctl start named
root@cdd1:cdd: ~#
B.1.2 Shutting down the DNS service with CLI

The DNS service can be shut down by using the command systemctl stop named.
Example:
root@cdd1:cdd: ~# systemctl stop named
root@cdd1:cdd: ~#
B.2 Webmin
B.2.1 Starting up the DNS service with Webmin

Log in to the webmin by using webminuser, webminadmin or superuser role.
Select Servers →BIND DNS Server and on the right upper corner, click the Start BIND link. When the Bind
DNS service starts the link changes to two links Apply Configuration and Stop BIND.
B.2.2 Shutting down the DNS service with Webmin

Select Servers →BIND DNS Server and on the right upper corner, click the Stop BIND link. When the Bind
DNS service stops the link changes from two links to one link Start BIND.
B.3 Error of NDC command
If the replication between the DNS nodes (Master and Slave) fails and gives a following error NDC command
failed: rnode: /etc/rndc.conf does not exist, correct it by creating rndc.conf again.
Select Servers→BIND DNS Server, and click Setup RNDC on the right lower corner.
On Setup RNDC click Yes, Setup RNDC. After clicking the button the browser returns to BIND DNS Server
page. The configuration is complete.
C Checking the firewall settings
Installation scripts set up firewall rules automatically during installation. If DNS or Webmin does not work
correctly one possible point of failure is the firewall. Note that with procedures described in Sections C.1
and C.2 you can generally check firewall settings.
C.1 Checking DNS firewall settings via Webmin

1) In Webmin, select Networking →FirewallD. Check that the rule list allows incoming packets in port 53
with UDP and TCP protocols.
Figure 31 : Rules of firewall
2) If rules are missing add them with Webmin. In Webmin, select Networking →FirewallD and click
Add allowed port.
Add port 53 to Single port text box and select TCP for the Network protocol setting and then
click the Create button.
Repeat the same operation with the same port but select UDP as the Network protocol setting.
Figure 32 : Create new rule to firewall
3) Apply the new firewall rules by clicking the Apply Configuration button on the Firewalld page.
4) If you have duplicated the CDD remember to check firewall rules on both nodes.
5) After you have configured the DNS service in Webmin, shut down the Webmin service by using the
service webmin stop command. For instructions, see Appendix A .
C.2 Checking DNS and Webmin firewall settings via CLI

1) As root user check the first active zone. Usually public is configured by default. Use command
firewall-cmd --get-active-zones.
Example:
root@cdd1: ~# firewall-cmd --get-active-zones
public
interfaces: bond0 eno1 eno2
root@cdd1: ~#
2) List firewall rules of the default zone (public) with command firewall-cmd --permanent
--zone=public --list-all.
Example:
root@cdd1: ~# firewall-cmd --permanent --zone=public --list-all
public (default)
interfaces:
sources:
services: dhcpv6-client ssh
ports: 42007/tcp 53/udp 42006/tcp 10000/tcp 3330/tcp 40002/tcp 53/tcp 1315/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
root@cdd1: ~#
From ports list, check the following ports:
• DNS: 53/udp, 53/tcp
• Webmin: 10000/tcp.
3) If DNS and/or Webmin rules are missing add them to the default zone (public) with firewall-cmd
commands.
DNS:
firewall-cmd --zone=public --add-port=53/tcp -–permanent
firewall-cmd --zone=public --add-port=53/udp -–permanent
Webmin:
And then reload rules:

firewall-cmd -–reload
4) Check the rules again as instructed in step 2 .

5) If an added rule had e.g. typing error in port, correct it by removing the rule and recreating it again.
Example for a DNS rule with a wrong port number (55):

firewall-cmd --zone=public --remove-port=55/tcp --permanent
Add the rule again with correct port:

And then reload rules:

firewall-cmd -–reload
6) Check the rules again as instructed in step 2 .
D Quick guide to the vi editor
General Startup
To use vi: vi filename
To exit vi and save changes: ZZ or :wq
To exit vi without saving changes: :q!
To enter vi command mode: [esc]
Counts
A number preceding any vi command tells vi to repeat
that command that many times.
Cursor Movement
h move left (backspace)
j move down
k move up
l move right (spacebar)
[return] move to the beginning of the next line
$ last column on the current line
0 move cursor to the first column on the
current line
^ move cursor to first nonblank column on the
current line
w move to the beginning of the next word or
punctuation mark
W move past the next space
b move to the beginning of the previous word
or punctuation mark
B move to the beginning of the previous word,
ignores punctuation
e end of next word or punctuation mark
E end of next word, ignoring punctuation
H move cursor to the top of the screen
M move cursor to the middle of the screen
L move cursor to the bottom of the screen
Screen Movement
G move to the last line in the file
xG move to line x
z+ move current line to top of screen
z move current line to the middle of screen
z- move current line to the bottom of screen
^F move forward one screen
^B move backward one line
^D move forward one half screen
^U move backward one half screen
^R redraw screen
( does not work with VT100 type terminals )
^L redraw screen
( does not work with Televideo terminals )
Inserting
r replace character under cursor with next
character typed
R keep replacing character until [esc] is hit
i insert before cursor
a append after cursor
A append at end of line
O open line above cursor and enter append mode
Deleting
x delete character under cursor
dd delete line under cursor
dw delete word under cursor
db delete word before cursor
Copying Code
yy (yank)'copies' line which may then be put by
the p(put) command. Precede with a count for
multiple lines.
Put Command
brings back previous deletion or yank of lines,
words, or characters
P bring back before cursor
p bring back after cursor
Find Commands
? finds a word going backwards
/ finds a word going forwards
f finds a character on the line under the
cursor going forward
F finds a character on the line under the
cursor going backwards
t find a character on the current line going
forward and stop one character before it
T find a character on the current line going
backward and stop one character before it
; repeat last f, F, t, T
Miscellaneous Commands
. repeat last command
u undoes last command issued
U undoes all commands on one line
xp deletes first character and inserts after
second (swap)
J join current line with the next line
^G display current line number
% if at one parenthesis, will jump to its mate
mx mark current line with character x
'x find line marked with character x
NOTE: Marks are internal and not written to the file.
Line Editor Mode

Any commands form the line editor ex can be issued
upon entering line mode.
To enter: type ':'
To exit: press[return] or [esc]
ex Commands
For a complete list consult the
UNIX Programmer's Manual
READING FILES
copies (reads) filename after cursor in file
currently editing
:r filename
WRITE FILE
:w saves the current file without quitting
MOVING
:# move to line #
:$ move to last line of file
SHELL ESCAPE
executes 'cmd' as a shell command.
:!'cmd'
E Listing of CDD node services
Use the following command to list services which are either enable, static and disabled:
systemctl list-unit-files --type=service
Note
STATE: invalid on the service list is an acceptable state for desktop-related services. It does not affect
the CDD application functionality.
root@cdd1:cdd: : ~# systemctl list-unit-files --type=service

UNIT FILE STATE
abrt-ccpp.service enabled
abrt-oops.service enabled
abrt-pstoreoops.service disabled
abrt-vmcore.service enabled
abrt-xorg.service enabled
abrtd.service enabled
arp-ethers.service disabled
auditd.service enabled
autovt@.service disabled
blk-availability.service disabled
brandbot.service static
cdd-fw-config-for-snmp.service enabled
chrony-dnssrv@.service static
chrony-wait.service disabled
chronyd.service enabled
console-getty.service disabled
console-shell.service disabled
container-getty@.service static
cpupower.service disabled
crond.service enabled
dbus-org.fedoraproject.FirewallD1.service enabled
dbus-org.freedesktop.hostname1.service static
dbus-org.freedesktop.locale1.service static
dbus-org.freedesktop.login1.service static
dbus-org.freedesktop.machine1.service static
dbus-org.freedesktop.network1.service invalid
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timedate1.service static
dbus.service static
debug-shell.service disabled
dm-event.service disabled
dnsmasq.service disabled
dracut-cmdline.service static
dracut-initqueue.service static
dracut-mount.service static
dracut-pre-mount.service static
dracut-pre-pivot.service static
dracut-pre-trigger.service static
dracut-pre-udev.service static
dracut-shutdown.service static
ebtables.service disabled
emergency.service static
firewalld.service enabled
fstrim.service static
getty@.service enabled
halt-local.service static
hp-ams.service enabled
initrd-cleanup.service static
initrd-parse-etc.service static
initrd-switch-root.service static
initrd-udevadm-cleanup-db.service static
iprdump.service disabled
iprinit.service disabled
iprupdate.service disabled
irqbalance.service enabled
kdump.service enabled
kmod-static-nodes.service static
ldconfig.service static
lvm2-lvmetad.service disabled
lvm2-lvmpolld.service disabled
lvm2-monitor.service enabled
lvm2-pvscan@.service static
messagebus.service static
microcode.service enabled
named-setup-rndc.service static
named.service disabled
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service disabled
NetworkManager.service enabled
plymouth-halt.service disabled
plymouth-kexec.service disabled
plymouth-poweroff.service disabled
plymouth-quit-wait.service disabled
plymouth-quit.service disabled
plymouth-read-write.service disabled
plymouth-reboot.service disabled
plymouth-start.service disabled
plymouth-switch-root.service static
polkit.service static
postfix.service disabled
quotaon.service static
rc-local.service static
rdisc.service disabled
rdma.service disabled
rescue.service static
rhel-autorelabel-mark.service static
rhel-autorelabel.service static
rhel-configure.service static
rhel-dmesg.service disabled
rhel-domainname.service disabled
rhel-import-state.service static
rhel-loadmodules.service static
rhel-readonly.service static
rsyslog.service enabled
serial-getty@.service disabled
smartd.service enabled
snmpd.service enabled
snmptrapd.service disabled
sshd-keygen.service static
sshd.service enabled
sshd@.service static
sysstat.service enabled
systemd-ask-password-console.service static
systemd-ask-password-plymouth.service static
systemd-ask-password-wall.service static
systemd-backlight@.service static
systemd-binfmt.service static
systemd-bootchart.service disabled
systemd-firstboot.service static
systemd-fsck-root.service static
systemd-fsck@.service static
systemd-halt.service static
systemd-hibernate-resume@.service static
systemd-hibernate.service static
systemd-hostnamed.service static
systemd-hwdb-update.service static
systemd-hybrid-sleep.service static
systemd-initctl.service static
systemd-journal-catalog-update.service static
systemd-journal-flush.service static
systemd-journald.service static
systemd-kexec.service static
systemd-localed.service static
systemd-logind.service static
systemd-machine-id-commit.service static
systemd-machined.service static
systemd-modules-load.service static
systemd-nspawn@.service disabled
systemd-poweroff.service static
systemd-quotacheck.service static
systemd-random-seed.service static
systemd-readahead-collect.service enabled
systemd-readahead-done.service static
systemd-readahead-drop.service enabled
systemd-readahead-replay.service enabled
systemd-reboot.service static
systemd-remount-fs.service static
systemd-rfkill@.service static
systemd-shutdownd.service static
systemd-suspend.service static
systemd-sysctl.service static
systemd-timedated.service static
systemd-tmpfiles-clean.service static
systemd-tmpfiles-setup-dev.service static
systemd-tmpfiles-setup.service static
systemd-udev-settle.service static
systemd-udev-trigger.service static
systemd-udevd.service static
systemd-update-done.service static
systemd-update-utmp-runlevel.service static
systemd-update-utmp.service static
systemd-user-sessions.service static
systemd-vconsole-setup.service static
tcsd.service disabled
teamd@.service static
tuned.service disabled
wpa_supplicant.service disabled
158 unit files listed.
F Disabling the IP Path MTU Discovery protocol
If the IP Path MTU Discovery protocol needs to be disabled in the node, do it by following the procedure
below. Check the state by giving the following command:
root@cdd1:cdd: /# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0
root@cdd1:cdd: /#
Result 0 means enabled, 1 is disabled. If the protocol is enabled and it needs to be disabled, do it according
to the following instruction:
Note
If the parameter needs to be changed, first disable the CDD application because the node needs to be
rebooted during the procedure.
The CDD server uses an MTU value of 1500 bytes and the IP Path MTU Discovery protocol to detect the
need for a smaller outgoing packet size. If the network's MTU size is smaller than 1500, packets larger than
the network MTU must be fragmented. A problem arises if the ICMP message Fragmentation needed and DF
bit set is blocked in the network for some reason (e.g. all ICMP messages blocked by some firewall). When
this happens the IP Path MTU Discovery protocol will not work, with the result that long CDD IP packets
will be blocked. In this case the IP Path MTU Discovery protocol must be disabled in the CDD to allow
fragmentation of CDD packets in the network. Do this by carrying out the following procedure as root user:
1) Change the content of the ip_no_pmtu_disc file from 0 to 1 with a text editor e.g. vi.
root@cdd1:cdd: /# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
1
root@cdd1:cdd: /#
2) Reboot the node by using command systemctl reboot.
G Configuring the PuTTY window
G.1 Normal use
To ensure correct view of configuration windows from the console, set the geometry of the PuTTy window
to 24 rows and 80 columns.
The settings can be changed in the following way:
1) Start the PuTTY program.
2) Load a saved session or create a new one.
3) In the PuTTY Configuration window, select the category Window.
3.1 In the Set the size of the window field, set the value of Rows to 24 and Columns to 80. Leave
the other parameters to their default values.
3.2 Select the category Translation.
• Usually UTF-8 is a good choice (it is the default setting). If the console prints invalid
characters on the terminal, check the remote node locale with command locale. Choose
the corresponding character set from the Remote character set: drop down list. Leave
the other parameters to their default values.
• In case the UTF-8 does not work as desired, the settings shown in the following figure
may turn out to be useful.
Figure 33 : PuTTY character set translation settings
4) Select the Session category. In the Load, save or delete a stored session field, click Save to store the
modified parameters to the loaded or created session. If you were creating a new session, remember
also to add a name for the session in the Saved Sessions.
G.2 iLO console via serial port

To ensure correct view of configuration windows from the iLO serial console, follow the steps below.
The settings can be changed in the following way:
1) Start the PuTTYtel program.
2) Load a saved session or create a new one.
3) In the PuTTY Configuration window, make the following selections in the category window:
3.1 In the Set the size of the window field, set the value of Rows to 31 and Columns to 100. Leave
the other parameters to their default values
3.2 Select the category Serial and set following parameters:
• Serial line to connect to e.g. COM1 or other usable serial port.
• Speed (baud) to 115200
• Data bits to 8
• Stop bits to 1
• Parity to none
• Flow control XON/XOFF
3.3 Select category Terminal and Keyboard. Set the Backspace key to Ctrl-H. Leave the other
parameters to their default values.
3.4 Select the Session category. In the Load, save or delete a stored session field, click Save to store
the modified parameters to the loaded or created session.
If you created a new session, remember to add a name for the session in the Saved Sessions field.
H Example printouts of duplicate_cdd.ksh script
Example from node 1
./duplicate_cdd.ksh accessed at /opt/TETRAcddha/util by
root console Apr 14 14:11
./mkdha.conf.ksh accessed at /opt/TETRAcddha/util by
mkdha.conf.ksh:Please fill the following:
cdd
mkdha.conf.ksh:CNODE:assign companion node ->
cdd2
mkdha.conf.ksh:PNODE:assign preferred node
mkdha.conf.ksh:Preferred node must be either this node or companion node->
cdd1
mkdha.conf.ksh:VIPA:assign virtual ip address
mkdha.conf.ksh:Give address in the dot-decimal notation->
10.10.10.11
mkdha.conf.ksh:SUMMARY
mkdha.conf.ksh:answer "yes" or "no"->
yes
./mkdcdddirs.ksh accessed at /opt/TETRAcddha/util by
./mksolidhac.ini.ksh accessed at /opt/TETRAcddha/util by
mksolidhac.ini.ksh:EREIP: Do you want to use default router value 10.10.10.1 ?
mksolidhac.ini.ksh:answer either "yes" or "no"->
yes
using 10.10.10.1
mksolidhac.ini.ksh:writing...
mksolidhac.ini.ksh:moving...
mksolidhac.ini.ksh:removing temp...
mksolidhac.ini.ksh:...done
./init_hosts.ksh accessed at /opt/TETRAcddha/util by
"10.10.10.11 cdd.mfg.domain cdd" added to the "/etc/inet/hosts".
init_hosts:Give companion nodés IP address or skip this with typing "skip".
10.10.10.13
"10.10.10.13 cdd2.mfg.domain cdd2" added to the "/etc/inet/hosts".
/opt/TETRAcddha/util/duplicate_ssh.ksh accessed at /opt/TETRACDD/db/scripts by
duplicate_ssh.ksh:~/.ssh/ not found.
duplicate_ssh.ksh:Creating one...
duplicate_ssh.ksh:Copying key to cdd2. Please give password of cdduser if asked.
RSA key fingerprint is cc:ab:58:7a:36:e4:fd:b5:09:cd:ba:18:08:ec:47:5f.
Are you sure you want to continue connecting (yes/no)? yes
Password:
duplicate_ssh.ksh:ssh keys generated and copied to /tmp-directory in cdd2
Example from node 2

./duplicate_cdd.ksh accessed at /opt/TETRAcddha/util by
./mkdha.conf.ksh accessed at /opt/TETRAcddha/util by
mkdha.conf.ksh:Please fill the following:
cdd
mkdha.conf.ksh:CNODE:assign companion node ->
cdd1
mkdha.conf.ksh:PNODE:assign preferred node
mkdha.conf.ksh:Preferred node must be either this node or companion node->
cdd1
mkdha.conf.ksh:VIPA:assign virtual ip address
mkdha.conf.ksh:Give address in the dot-decimal notation->
10.10.10.11
mkdha.conf.ksh:SUMMARY
mkdha.conf.ksh:answer "yes" or "no"->
yes
./mkdcdddirs.ksh accessed at /opt/TETRAcddha/util by
./mksolidhac.ini.ksh accessed at /opt/TETRAcddha/util by
mksolidhac.ini.ksh:EREIP: Do you want to use default router value 10.10.10.1 ?
mksolidhac.ini.ksh:answer either "yes" or "no"->
yes
using 10.10.10.1
mksolidhac.ini.ksh:writing...
mksolidhac.ini.ksh:moving...
mksolidhac.ini.ksh:removing temp...
mksolidhac.ini.ksh:...done
./init_hosts.ksh accessed at /opt/TETRAcddha/util by
"10.10.10.11 cdd.mfg.domain cdd" added to the "/etc/inet/hosts".
init_hosts:Give companion nodés IP address or skip this with typing "skip".
10.10.10.12
"10.10.10.12 cdd1.mfg.domain cdd1" added to the "/etc/inet/hosts".
/opt/TETRAcddha/util/duplicate_ssh.ksh accessed at /opt/TETRACDD/db/scripts by
duplicate_ssh.ksh:~/.ssh/ not found.
duplicate_ssh.ksh:Creating one...
duplicate_ssh.ksh:Copying key to cdd1. Please give password of cdduser if asked.
RSA key fingerprint is aa:dc:4f:c8:3f:8d:36:96:8e:86:e8:8f:d1:7a:a7:a4.
Are you sure you want to continue connecting (yes/no)? yes
Password:
duplicate_ssh.ksh:ssh keys generated and copied to /tmp-directory in cdd1
I Modification of password policy
Default password policies of Linux CDD can be reduced after installation and configuration. However, it
is not recommended to do it.
1. Viewing Password Policies of user with command root@cdd1:cdd: /# chage –l superu.
Example:
chage -l superu
Sample outputs:
Last password change : May 21, 2016
Password expires : December 24, 2017
Password inactive : never
Account expires : newer
Minimum number of days between password change : 7
Maximum number of days between password change : 90
Number of days of warning before password expires : 7
2. Editing Password Policies with chage command. Use root.

The following parameters are in use:
-I -1 : This will set the Password inactive to never
-m 0 : This will set the minimum number of days between password change to 0
-M 99999: This will set the maximum number of days between password change to 99999
Example of command:
root@cdd1:cdd: /# chage -I -1 -m 0 -M 99999 superu
Note
This will disable the password expiry of a user if it is already enabled. Not recommended.
Check results:
root@cdd1:cdd: /# chage –l superu
Output:
Password expires : never
Account expires : never
3. Editing Password Policies to default.

Example of command:
root@cdd1:cdd: /# chage -m 7 -M 90 superuser
Check results:
root@cdd1:cdd: /# chage –l superu
Output:
Password expires : May 21, 2016
Account expires : never
Glossary
The meanings of the terms and acronyms used in this document are explained below.
For further information on TETRA definitions, terms and concepts and the meaning of all acronyms
and abbreviations used in TETRA System customer documentation, please see document Glossary
(DN00126469).
Term / acronym Meaning
CDD Configuration and Data Distribution server
CLI Command Line Interface
Duplicated CDD Two CDD servers concurrently running the CDD server application in a
redundant mode.
DNS Domain Name System
DXT Digital Exchange for TETRA. A generic term for digital exchanges in the
Airbus DS TETRA System.
HA High Availability
iLO Integrated LO (Lights-Out; a HP server management feature)
IP Internet Protocol
LAN Local Area Network
MCC Mobile Country Code
MNC Mobile Network Code
MNI Mobile Network Identity
NAT Network Address Translation
NTP Network time protocol
Single node CDD One CDD server running the CDD server application (without duplication)
SwMI Switching and Management Infrastructure of a TETRA network
TCP/IP Transmission Control Protocol/IP Protocol
TCS TETRA Connectivity Server
UPS Uninterrupted Power Supply
Virtual address IP address corresponding to the virtual name
Virtual name A logical name given to the entity of two nodes in the duplicated CDD
environment. In the case of a single node CDD, replace the virtual name with
the CDD name when executing the procedures given in this document.
VLAN Virtual LAN
WAN Wide Area Network

TETRA System Release 7.0: CDD Server, Commissioning Manual

Uploaded by

Copyright:

Available Formats

You might also like

TETRA System Release 7.0: CDD Server, Commissioning 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

TETRA System Release 7.0: CDD Server, Commissioning Manual

Uploaded by

Copyright:

Available Formats

CDD Server, Commissioning Manual

TETRA System Release 7.0

Copyright © 2016–2017 Airbus DS SLC, all rights reserved.

DN03533691-15-5en TETRA System Release 7.0

1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Checking and unpacking the CDD delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Installing and connecting the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Powering up/down the CDD units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

TETRA System Release 7.0 DN03533691-15-5en

7 Security-hardening the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Configuring CDD node(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9 Configuring the DNS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10 Configuring duplicated CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

DN03533691-15-5en TETRA System Release 7.0

11 Configuring the management interface <optional> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

12 Creating and configuring the Solid database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

13 Testing the IP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

14 Integrating CDD with the NMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

15 Finalising the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

16 Starting up and shutting down the CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

C Checking the firewall settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

D Quick guide to the vi editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

E Listing of CDD node services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

TETRA System Release 7.0 DN03533691-15-5en

G Configuring the PuTTY window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

H Example printouts of duplicate_cdd.ksh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

I Modification of password policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

DN03533691-15-5en TETRA System Release 7.0

TETRA System Release 7.0 DN03533691-15-5en

DN03533691-15-5en TETRA System Release 7.0

VERSION DATE COMMENTS CHAPTER

15-5 05/2017 Minor modifications. 8.6.3.13

1. CDD Server and Audit Trail Server, Product Description DN0115944

2. CDD Server, User's Guide, DN03533676

3. Guide to TETRA Documentation, DN00126445

4. Integrating CDD Server with NetAct TETRA, DN03351245

5. Integrating TETRA System Network Elements with NetBoss XT, TRADXTAPP00079

6. License Terms of 3rd Party Software, TRASYSAPP00296

TETRA System Release 7.0 DN03533691-15-5en

DN03533691-15-5en TETRA System Release 7.0

• The server hardware is based on HP ProLiant DL380 Generation9 (Gen9).

1.1 Scope of this document

• optional display and keyboard

TETRA System Release 7.0 DN03533691-15-5en

1.3 Typographic conventions

DN03533691-15-5en TETRA System Release 7.0

The CDD is normally positioned next to the DXT.

Table 1 : CDD environmental requirements

2.2 Dimensions and weight

The dimensions of the CDD server are given in Table 2 .

TETRA System Release 7.0 DN03533691-15-5en

Unit Height Width Depth Weight

2.3 Power requirements

Table 3 : CDD server power requirements

Characteristics Required supply voltage Power consumption

2.3.1 UPS-initiated automatic CDD shutdown

DN03533691-15-5en TETRA System Release 7.0

TETRA System Release 7.0 DN03533691-15-5en