Skylight Private Cloud - Post-installation steps

Configuring the Skylight Solution for first use ( 23.04+)

This article guides you through the administrative steps that are required before you can use Skylight Solution for the first time.

The Skylight Platform is inherently a multi-tenant platform. Under most circumstances, private cloud infrastructure supports single tenant only. All data stored in the platform (including but not limited to: monitored , metrics data, metadata, dashboards, user profiles, etc) are stored against a specific tenant.

Tenants have their own RBAC rules and user base. This article builds on the steps completed in Skylight Private Cloud Installation

Note:

Part 7: Creating a Tenant

The Skylight platform is a multi-tenant system. At least one tenant needs to be created. Once all of the services above are running, you can create a tenant with the following command:

bin/createTenant.sh config/variables.lite.env

# A sample output:
INFO[0000] obtaining DataHUB IQ credentials
INFO[0000] authenticating with DataHUB IQ
INFO[0000] creating CAS service
INFO[0000] creating tenant in couchdb
INFO[0001] extracting tenant ID and name from couchdb response
DEBU[0001] Extracted tenant ID 911a1847-01a5-4e20-8eae-7963deaf46f0 and name analytics from couchdb response
INFO[0001] registering tenant-info in skylight-aaa
INFO[0001] obtaining private key for SSH connection to leader instance
INFO[0001] obtaining SSH credentials for leader instance
INFO[0001] obtaining leader instance IP address
DEBU[0001] obtained leader instance IP address 10.10.10.243:22
INFO[0001] parsing leader instance IP address
INFO[0001] Connecting to admin@10.10.10.243:22
INFO[0001] reading .next-service-id file on remote system
INFO[0001] writing generated service file on remote system path=/etc/aod/cas/serviceInit/002-analyticsservice.json
WriteRemoteFile about to call Wait()
WriteRemoteFile all done
INFO[0001] re-writing .next-service-id file on remote system id=3
WriteRemoteFile about to call Wait()
WriteRemoteFile all done
Restarting CAS ...
2795ff5ace98

CAS restarted
INFO[0002] The tenant analytics was SUCCESSFULLY provisioned

Before proceeding, you must wait for the Skylight to come back up. To validate this you can run a cURL command against the API:

export TENANTHOST=<host_ip>
export DATAHUBUSER=admin@datahub.com
export DATAHUBPASS=<DefaultPassword>
curl -k -X POST https://${TENANTHOST}:2443/api/v1/auth/login -H 'Content-Type: application/x-www-form-urlencoded' -d "username=${DATAHUBUSER}&password=${DATAHUBPASS}"

You will know when the services are back up when you receive output similar to:

{"data":{"attributes":{"emailAddress":"admin@datahub.com","groups":null,"name":"Datahub Admin","roles":["##ROLES##"],"tenants":["##DEPLOYMENT##"]},"id":"1","type":"users"}}

Part 8: Provisioning tenants support and metadata categories

A tenant can support an arbitrary list of customer defined metadata. However, when using in conjunction with the Skylight Gateway's RESTConf API, some metadata categories are mandatory to ensure proper operation.

Executing the provisionTenant.sh utility sets up the newly created metadata with the appropriate metadata categories, in addition to setting other administrative tasks:

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

Upon successful completion, the required metadata categories are provisioned. You can confirm this by logging in the Skylight application. Under the Settings ▶ Metadata pane, you should see the following metadata categories added:

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

For example:

Part 9: Changing the super-admin password

Until now, the default password has been used to log into the Skylight Platform application (and its accompanying REST APIs). It is advisable to change this password and keep this confidential and stored somewhere safe.

This can be performed in one of two ways:

• Remotely via REST APIs,
• By executing the following utility in the skylight-installer.

Change password 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"
}'

The password is now changed for the super-admin user.

Change password with the changeMasterPassword.sh utility

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

Follow the on-screen prompt to complete the operation. Note that the minimum password requirements mandate that passwords have:

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

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. At the prompt, enter the password that you have set above:

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

Having the new password stored in vault allows some administrative commands, such as tenant provisioning and creation to be performed passwordless.

Part 10: Cleaning Up

Once the installation has completed and the system is operational, remove all key material from the tmp/ folder, as they are now loaded into vault and can be accessed there.

Additional Setup Considerations

Roadrunner and Proxy Servers

If the Skylight Roadrunner is behind a proxy server, the following changes will need to be done to the Roadrunner's .env file, included as part of a downloadable roadrunner archive.

After downloading and deploying a roadrunner, as documented in Setting up Roadrunner, add the following two lines at the end of the .env file of the Roadrunner archive:

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

Roadrunner and insecure TLS

If the Skylight platform was deployed using self-signed TLS servers via a self-generated Certificate Authority (CA) (for instance, if you did not provide TLS certificates in Configuring the vault, Roadrunner (and most other tools such as cURL) might report that they refuse to connect to a server with an unverified TLS certificate.

In production, this is to protect the client from a ‘man in the middle’ attack. However, in some cases, it is useful to suspend this validation (for instance, in development environment). You can have RR bypass this check by adding RR_INSECURE=true in the .env file:

### Edit the Roadrunner .env file
# ... some values
RR_INSECURE=true

Save this file and restart Roadrunner by running the run.sh command.

Next Steps

Following the configuration for first use, you can now configure a connector and begin sending data to the Skylight platform!

For example:

• Agent: actuate - Configuration