Internal Web Services

11.1 Changing Internal Web Service Passwords

In general, after the initial configuration is complete and before deploying or turning up services, you must update the internal web service passwords.

11.2 Changing TPD Web Service Password

Perform the following procedures to change the OS-level provisioning web service password.

Updating TPD Web Service Password on Active NO

Log in as admusr on the source server.
```
login: admusr
Password: <current admin user password>
```
Run the following command to reset the TPD web service password:
```
$ /usr/TKLC/appworks/sbin/resetTpdPassword
```
You are prompted to provide a password:
```
password: <enter the new password>
```
Step result: The command copies and installs the new password to each reachable server in the topology, and flushes client password caches.
Run the following command to verify that the web service is still functional:
```
$ AppWorks Network interfaces
```
Step result: You can see a list of network interfaces reported by the Web Service backend:
```
{
“element”:[
“eth0”,
“eth1”
]
}
```

This update command synchronizes the TPD web service (tpdprovd) password on all reachable servers in the topology. Any servers added to the topology after running this command are automatically configured to use the new password. If any servers were not reachable when this command is run, run the command again later when those servers are reachable.

Updating TPD Web Service Password on PMAC

Some DSR deployments include a PMAC system to support installation and growth. Once you update the tpdProvd password on servers in the DSR topology, the PMAC loses the ability to inventory deployed DSR nodes. You can restore the inventory function by running the following procedure on the PMAC:

Update the password on a given server or group of servers (assuming all passwords are the same for the group) either using linux passwd command on the server(s) or by some other means.
From a PMAC shell, use the following command to add the password(s) to the PMAC database and update the PMAC messaging interface. This command prompts the user for the password and echo asterisks as characters are entered.
```
/usr/bin/sudo /usr/TKLC/smac/bin/pmacadm addProvdCredentials --flushBAs=yes
```
Note:
--flushBAs can be set to no if entering multiple passwords and set to yes on the last added password. If --flushBAs is not set to yes on the last password entry, a sentry restart must be performed on the PMAC to flush out all the Broker Agents (server interfaces) in the PMAC messaging system and must be rebuilt using the new passwords.
1. The new password can be verified using the following command:
```
/usr/bin/sudo /usr/TKLC/smac/bin/pmaccli getHostCommStr --ip=<ipv4 address of the server> --accessType=ro
```
  This should return a valid response with a password. If it fails, there may be a tpdProvd password mismatch issue between the PMAC and the server.
2. If a password must be removed and the exact spelling of the password is known, it can be deleted from the PMAC database and messaging system using the following command:
```
/usr/bin/sudo /usr/TKLC/smac/bin/pmacadm deleteProvdCredentials --flushBAs=yes
```
  Note:
  You are prompted for the password.

11.3 Changing the Configuration Web Services Password

The following procedures are used to change the configuration web services password.

Update Configuration Web Service Password on Active NO

Perform the following steps to update configuration web service password on an active NO:

Log in as admusr on the active NOA server.
```
Login: admusr
Password: <current admin user password>
```
Reset the TPD web service password by running:
```
$ /usr/TKLC/appworks/sbin/resetSoapPassword
```
You are not be prompted for a password. The resetSoapPassword command generates a large random string which is used as the new password.

Note:
The command copies and installs the new password to each reachable server in the topology, and flushes client password caches. You might see output related to these activities.
Restart all the servers in the topology from active NOA GUI:
1. Log in to the active NOA GUI.
2. Navigate to Main Menu, and then Status & Manage, and then Server.
3. Restart all the servers in the topology in below mentioned order.
  1. The non-Active OAM Servers, that is Standby or Spare NO, Standby or Spare SO, DR-NO.
  2. All the C-level servers.
  3. The active OAM servers, that is active NO and active SO.
Verify if the web service is functional:
```
$ AppWorks Alarms getData
```
You should see a list of active alarms as reported by the Web Service backend.
```
[
    <alarm list (if any)>
]
```

This update command synchronizes the configuration web services password on all reachable servers in the topology. After running this command, any servers added to the topology is configured to use the new password. If any servers were not reachable when this command is running, then run the command again later when those servers are reachable.

Some DSR deployments include an IDIH system to support message trace and debugging. Once you update the servers in the DSR topology, IDIH loses the ability to interact with the deployed DSR nodes. You can restore the IDIH function by running this procedure on the IDIH:

Log in as admusr on the active NOA server.
```
Login: admusr
Password: <current admin user password>
```
Retrieve the current configuration web services password in plain text. This is needed below in step 4.
```
$ /usr/TKLC/appworks/bin/aw.wallet credential get cmsoapa password
```
The command prints the current plain text configuration web service password
Example:
```
7w57q9U0OvOtKtgtLVTMajDcXfhCj2F4nyXw45qK6EXNHA9jACyQ
```
Log in as admusr on the IDIH application server.
```
Login: admusr
Password: <current admin user password>
```
Change the user to tekelec by executing sudo su – tekelec command. Then, reset the configuration web service password by running:
```
$ cd /usr/TKLC/xIH/apps/trace-refdata-adapter/
$ ./resetSoapPassword.sh
```
You are prompted to provide a password:
```
password: <enter the password from step 2>
```
The command stores the new SOAP password into IDIH Oracle database.
After executing the command in Step 4, the WebLogic application server has to be restarted on IDIH application server. Type exit to become admusr.
```
sudo service xih-apps stop
sudo service xih-apps start
```
The Weblogic server may take a few minutes to resume its service after executing the command.
Note:
- TraceRefDataAdapter(TRDA) sync must happen automatically after WebLogic server has been restarted. If TRDA sync does not happen automatically, then execute the following command to sync IDIH with DSR. As tekelec user, navigate to /usr/TKLC/xIH/apps/trace-refdata-adapter directory and execute the command ./trda-config.sh < SOAM VIP >, where <SOAM VIP> is a place-holder for SOAM VIP address.
- To verify TRDA sync, look into application.log in the path /var/TKLC/xIH/log/apps/weblogic/apps/application.log.
  Ensure that this log does not show any java exceptions.

11.4 Changing Internal Web Service Certificates and Key Material

In general, the TPD and web services are configured to work with self-signed certificates. You can replace the appworks certificates using the procedures described in this section.

Assumptions

The following procedure assumes that you have already obtained a signed certificate or key file from the customer’s certificate authority and that these files are in the .pem format.

Each server in the topology needs its own certificate or key pair. The certificate must have a DN field that matches the hostname of the server. The following procedures assume the customer provides files in this naming convention:

<hostname>_crt.pem – a PEM encoded X.509 certificate for the host <hostname>
<hostname>_priv.pem – a PEM encoded private key for the host <hostname>

Ensure that the private key file is not protected with a passphrase.

Creating and Distributing a separate Certificate and Key PEM File

Perform the following steps to create and distribute a separate certificate and key PEM file:

Log in as admusr on the active NOA server.
```
Login: admusr
Password: <current admin user password>
```
Copy all of the <hostname>_crt.pem and <hostname>_priv.pem files to the home directory for admusr on the active NOA using a utility such as scp or rsync.
Run the following steps to confirm and verify the certificate or key pairs:
1. Confirm each of the certificate or key pairs are compatible (assume <hostname> is noa):
```
$ openssl rsa -noout -modulus -in noa_priv.pem | openssl md5 
(stdin)= eef417fb3f018862034ae8e9f3a0b56e
```
```
$ openssl x509 -noout -modulus -in noa_crt.pem | openssl md5 
(stdin)= eef417fb3f018862034ae8e9f3a0b56e
```
2. Verify the md5 output matches for each <hostname> certificate or private key pair. Additionally, the md5 should be different for different <hostnames>.
Copy the private key and certificate to the server (again, assume <hostname> is noa):
```
$ scp noa_priv.pem admusr@noa:
$ scp noa_crt.pem admusr@noa:
```
Note:
Repeat the above procedure for each <hostname>.

Installing a separate PEM and CERT File on Each Distinct <hostname>

After creating the separate certificate and private key PEM file for each server in the topology, you must log into each server in the topology and install the PEM file as follows:

Log in as admusr on the <hostname> (assume <hostname> is noa):
```
$ ssh admusr@noa
```

Run the following commands to copy your new certificate/private key pair PEM file into place (assume <hostname> is noa):

$ sudo cp noa_priv.pem /usr/TKLC/appworks/etc/ssl
$ sudo chown awadmin:awadm /usr/TKLC/appworks/etc/ssl/noa_priv.pem
$ sudo chmod 640 /usr/TKLC/appworks/etc/ssl/noa_priv.pem

$ sudo cp noa_crt.pem /usr/TKLC/appworks/etc/ssl/ 
$ sudo chown awadmin:awadm /usr/TKLC/appworks/etc/ssl/noa_crt.pem
$ sudo chmod 640 /usr/TKLC/appworks/etc/ssl/noa_crt.pem

Run the following commands to replace the existing combined certificate or private key file with the new file:

$ sudo mv /usr/TKLC/appworks/etc/ssl/server.crt /usr/TKLC/appworks/etc/ssl/old_server.crt

$ sudo ln -s /usr/TKLC/appworks/etc/ssl/noa_crt.pem /usr/TKLC/appworks/etc/ssl/server.crt 

$ sudo mv /usr/TKLC/appworks/etc/ssl/server.pem /usr/TKLC/appworks/etc/ssl/old_server.pem

$ sudo ln -s /usr/TKLC/appworks/etc/ssl/noa_priv.pem /usr/TKLC/appworks/etc/ssl/server.pem

Run the following commands to restart the configuration web services and exit:
```
$ sudo pm.kill apwSoapServer
$ sudo pm.kill cmsoapa
$ exit
```
Note:
Repeat the above procedure for each and every distinct <hostname>.