Configuring RLSI
The SC//Reliant™ Local Status Indicator (RLSI) is installed and configured through Puppet, driven by properties set on a node or node group in the SC//Reliant Platform Manager. This page describes those properties, how to turn RLSI on, and how to confirm a change took effect.
How RLSI is configured
RLSI is configured in the SC//Reliant Platform Manager. Puppet applies that configuration on the node on its next run, which has two consequences:
- A change is not live until Puppet has run. See Applying a change.
- Editing RLSI's configuration file on the node does not hold.
/opt/rlsi/rlsi.conf.yamlis Puppet-managed, so the next run overwrites it. Change the property instead. The file is still worth reading, because it shows what is currently applied rather than what is intended. See Applying a change.
For nodes in a cluster, set these properties at the node group level so both nodes get the same configuration from one place. When a cluster fails over to the secondary node, you should find the same tabs and checks there. Configure per node only where the nodes genuinely differ.
Turning RLSI on
Before you start, the node needs RVC running, since RLSI carries out most of its actions by calling it, and a per-customer certificate — see Certificates. If you intend to enable the VMS or BACKUPS tabs, the node also needs at least one KVM domain.
- Access the SC//Reliant Platform Manager and log in.
-
Assign the Puppet profile to the node or node group.
Profile Purpose profiles::rlsiInstalls and configures RLSI. Required. profiles::rlsi_musicAdds the music player. Optional, and requires profiles::rlsias well. -
Add the RLSI properties. At minimum you need the version, at least one check, and the tabs you want.
The RLSI properties alone do not install RLSI. Without
profiles::rlsiassigned, Puppet has nothing to act on. -
Deploy the change and confirm the service is up, as described in Applying a change.
To reach the console once it is running, see Using the SC//Reliant Local Status Indicator (RLSI).
The RLSI properties
Rlsi Enabled Checks, Rlsi Enabled Tabs, and Rlsi Publicly Available Tabs have similar names and are easily confused. They act at different levels: the first governs the content of one tab, while the other two govern which tabs exist and whether they need a login. None of the three affects the VMS or BACKUPS tabs, which the configuration hash governs instead.
| Property | What it controls |
|---|---|
Rlsi Version | Which version of the RLSI package to install. Puppet holds the node at this version. You can run apt-cache policy rlsi on a node to determine which versions are available. |
Rlsi Enabled Checks | The content of the STATUS tab — which pieces of information about the node it reports. It has no bearing on which tabs exist. At least one check is required. See Choosing which checks appear. |
Rlsi Enabled Tabs | Which tabs exist, from music, logs, and admin. No effect on VMS or BACKUPS. See Hiding the Logs and Admin tabs. |
Rlsi Publicly Available Tabs | Which of those same tabs skip the login. Its values are a subset of Rlsi Enabled Tabs — listing a tab here that is not enabled does nothing. |
Reliant Local Status Interface Configurations | A hash enabling and configuring the backups, cluster, virtual machine, and music player features. See The configuration hash. |
Rlsi Enabled Buttons | Which optional buttons appear on the ADMIN tab, such as failover and pxe_boot_sync. |
Rlsi Listen Port | The port RLSI serves on. See Setting the listen port. |
A node group's property list may also show individual entries such as Rlsi Vms Enable and Rlsi Music Enable. These are settings from inside Reliant Local Status Interface Configurations surfaced on their own, not a second mechanism. Set them in the hash.
Choosing which checks appear
Each value in Rlsi Enabled Checks produces one row on the STATUS tab. At least one check must be enabled, or RLSI errors rather than showing an empty page.
These are the values the property accepts.
| Group | Check names |
|---|---|
| Connectivity and routing | exthost_ping_status, puppet_ping_status, vpn_gateway_ping_status, routing_status, failover_status |
| Addresses | vpn_tun_ip, interface_address, interface_gateway |
| Filesystem usage | root_file_system_usage, var_file_system_usage, aloha_system_usage, mgrwork_system_usage |
| Node identity | hostname, date, store_number |
| Workloads and services | virtual_nodes, keepalived_status |
Enable only the checks that are meaningful for the node. A check whose subject is not present reports NOT APPLIABLE rather than failing, so an over-broad list produces rows carrying no information — aloha_system_usage on a node with no /kvm/aloha, for example.
The order you list the checks in does not control the order they appear on the tab. RLSI renders the rows in its own fixed order, so a node that lists hostname and date first still shows them well down the page.
For the row label each check produces and the messages each can report, see Reading the Status tab in RLSI.
Hiding the Logs and Admin tabs
The LOGS and ADMIN tabs appear when they are listed in Rlsi Enabled Tabs, and are hidden when they are not. To hide one, remove its value — logs or admin — from the property and deploy the change.
The property also accepts music, although the music player is normally enabled through Music Player Options in the configuration hash.
The STATUS tab is RLSI's home page and cannot be hidden. The VMS and BACKUPS tabs are controlled by the configuration hash rather than by this property, so removing them from Rlsi Enabled Tabs has no effect.
The configuration hash
The Reliant Local Status Interface Configurations hash contains some configuration settings for the RLSI interface. Each section has its own Enable this option toggle, and turning a section on both enables the feature and reveals its settings.
| Section | What it enables | Settings, with defaults |
|---|---|---|
| KVM Backup Options | The BACKUPS tab, so local users can create and restore snapshots and backups. | Full Back up Target Directory - File Tree, default /mnt/. See The backup target directory. |
| Cluster | The cluster status in the header bar. Enable where the Edge Appliances are an HA cluster. | Polling Time (in seconds), default 30. |
| Virtual Machines | The VMS tab, so local users can see the VM list and change VM states. | Polling Time and Action Polling Time (in seconds), both default 30. The second applies while an action such as a shutdown is running. |
| Music Player Options | The RLSI Music Player package. | Version, default latest. |
IMPORTANT: Turning a section off is the only way to withhold its tab, because VMS and BACKUPS cannot be password protected. The BACKUPS tab can restore a VM and the VMS tab can force a VM off, so each capability is either available to anyone who can open the console or turned off entirely.
Choosing polling intervals
Each poll is a request the node has to serve, and the interface warns that setting a low value will impact the performance of each device.
The constraint is load rather than a fixed floor: a polling time too low for the number of VMs on the node produces a 502 Bad Gateway when the VMS tab is opened, so the more VMs, the longer the interval needs to be. A lab node with one VM tolerates a much shorter interval than a store node running several.
Start from the default, lower it only where you need more responsive status and the node has few VMs, and raise it if the tab starts returning 502. Remember that the interval is also how far behind the displayed status can be. See Managing virtual machines in RLSI.
The backup target directory
The directory must exist on the node. If the configured path is absent, the BACKUPS tab raises an internal server error rather than showing an empty folder list. Either set a path that exists or create it on the node — the default is Puppet-managed.
Set it to the same location configured for RVC, so backups taken through RLSI and through the RVC command line land in the same place. See Managing virtual machines in RLSI.
Setting the listen port
RLSI serves HTTPS on port 443, which is how it is normally reached. Rlsi Listen Port changes that, so leave it unset unless you need a non-standard port.
The property description reads (Default is 80). That is the underlying web server's default, not the effective one — because RLSI serves over SSL by default, an unset Rlsi Listen Port gives HTTPS on 443. Port 80 applies only on a node where SSL has been explicitly disabled, which is unusual.
Setting a non-standard port changes how the console is reached, so record the change somewhere your team will find it. Someone browsing to https://<node> afterwards gets a connection refused and no explanation. See When RLSI does not respond.
Certificates and credentials
Both are per-customer, held in the customer's repository and installed on the node by Puppet.
Certificates
Two files are required, named exactly rlsi_server.crt and rlsi_server.key. Because the certificate is issued per customer, browsers warn on connection — see Reaching the console.
Credentials for password-protected tabs
There is no password field in the Platform Manager and no per-node password to set. Authentication uses a per-customer credential database, together with a lookup file that maps a number to its password. For how a user logs in with it, see Logging in.
If a customer has no credential database, do not password protect any tab: the tab becomes unreachable rather than protected. Arrange for the credential database first.
The RLSI version
Rlsi Version sets the version a node runs, and Puppet holds it there. To change it, set the property and deploy, then confirm the result on the node.
apt-cache policy rlsi | headInstalled in that output is the version running now, and it should match Rlsi Version. If the two disagree, Puppet has not applied the change or the run failed. Ignore Candidate — it reports the newest version the repository offers, not the version the node is meant to run, so Candidate being higher than Installed is normal rather than a sign of drift.
The same output lists every version available to the node, which is where to check the exact string — including the revision suffix, such as -0 — if Puppet reports that a version does not exist.
Applying a change
A property change does nothing until Puppet applies it.
-
Make the change in the Platform Manager, at node group level for a cluster.
-
Run Puppet to deploy it. On a cluster, deploy to both nodes so they match.
For the available methods, how to preview a change first, and what to confirm before deploying, see Deploying changes to your environment.
-
Confirm the run completed without errors. An error means the catalog did not apply, so the change is not in effect.
-
Confirm the result on the node.
cat /opt/rlsi/rlsi.conf.yaml systemctl status rlsirlsi.conf.yamlshows what RLSI actually received, as distinct from what the Platform Manager intends: a property that reads correctly in the Platform Manager but is absent here has not been deployed. Anactive (running)service means RLSI is serving.RLSI is served by nginx, so if you need its logs they are in two places:
journalctl -u rlsi.servicefor the service, and/var/log/nginx/for the web layer.
Related documentation
- Using the SC//Reliant Local Status Indicator (RLSI): reaching the console once it is configured.
- Troubleshooting RLSI issues: what to do when a change does not take effect, or a tab does not appear.
- Reading the Status tab in RLSI: the checks, their labels, and the messages they report.
- Managing virtual machines in RLSI: the VMS and BACKUPS tabs, which the configuration hash enables.
- Using the Admin tab in RLSI: the ADMIN tab and its actions.
- Deploying changes to your environment: running Puppet to apply a change, previewing it first, and verifying the result.