Configuration for Initial Use

After completing the steps outlined in the Installation section, configure Provider Connectivity Assurance for first-time use.

1. Provision Tenants Support and Metadata Categories

A tenant can support an arbitrary list of customer-defined metadata. However, when used with the Skylight Gateway RESTConf API, certain metadata categories are mandatory for proper operation.

Execute the provisionTenant.sh utility to set up newly-created metadata with the appropriate metadata categories and run additional administrative tasks:

$ bin/provisionTenant.sh config/variables.lite.env

Upon successful execution, the required metadata categories will be provisioned.

To verify, log on to the Provider Connectivity Assurance application, and confirm in the Settings ▶ Metadata that the following metadata categories have been added:

1. ne_id
2. ne_id_reflector
3. ne_id_sender
4. vlan_id
5. service_name

For example:

2. Change the Super-Admin Password

By default, the Provider Connectivity Assurance application and its REST APIs use a preset password. It is strongly recommended to change this password and store it securely.

There are two ways to change the password:

• Remotely via REST API
• By executing the changeMasterPassword.sh utility in skylight-installer

Password Change via REST API

Using a REST API client such as curl or postman, send the following patch command (curl example):

## First authenticate with the existing master password and retrieve the token from the Authorization header returned by this call:

curl --location -vvv ''https://{{deployment_uri}}/api/v1/auth/login' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=admin@datahub.com' \
--data-urlencode 'password=the_old_pwd'

## Using the returned "Authorization: Bearer {{token}} in the answer from above, execute the following command to update the password"

curl --location --request PATCH 'https://{{deployment_uri}}/api/v1/auth/me/password' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {{token}}' \
--data '{
    "oldPassword": "the_old_pwd",
    "newPassword": "the_new_pwd"
}'

Password Change via changeMasterPassword.sh Utility

$ bin/changeMasterPassword.sh config/variables.lite.env

Follow the on-screen prompt to complete the operation.

Take note of these password requirements:

• More than 8 characters
• At least one capital and one lowercase letter
• At least one numerical character
• At least one non-alphanumeric character

Store the New Password in Vault

Once the password is set, it is a good idea to re-store it in vault. To do this, re-execute the following command to configure vault.

After setting the password, it is recommended to store it securely in Vault. Run this commane to reconfigure Vault:

# configure vaults
bin/configureVault.sh config/variables.lite.env

At the prompt, enter the new password.

Storing the password in Vault allows passwordless execution of administrative commands like tenant provisioning and creation.

3. Post-Installation Cleanup

After installation is complete and the system is operational, remove all key material from the tmp/ folder, as Vault now securely stores this information.

4. Additional Setup Considerations

Sensor Collector and Proxy Servers

If the Sensor Collector (formerly Skylight Roadrunner) is behind a proxy server, update the Sensor Collector's .env file by adding the following lines at the end:

https_proxy=http://<address_of_https_proxy:port>
http_proxy=http://<address_of_http_proxy:port>

The .env file is included in the downloadable Sensor Collector archive. For information on downloading and deploying a Sensor Collector, see Deploying Sensor Collector in Docker.

Sensor Collector and Insecure TLS Connections

If Provider Connectivity Assurance was deployed using self-signed TLS certificates, certain tools—including Sensor Collector and cURL—may refuse to connect due to an unverified TLS certificate.

This may be true if you did not provide TLS certificates during Installation.

In production environments, this behavior protects against man-in-the-middle attacks. However, in development environments, you can bypass this validation by adding the following line to the Sensor Collector .env file:

RR_INSECURE=true

Save the file and restart Sensor Collector using

bin/run.sh

Next Steps

After successful configuration for first use, you can now configure a connector and begin sending data to the Provider Connectivity Assurance platform.

For more information, see:

• Agent: actuate - Configuration
• Sensor Collector