Using the Admin tab in RLSI
The ADMIN tab in the SC//Reliant™ Local Status Indicator (RLSI) collects maintenance and diagnostic actions for the node you are connected to. Unlike the STATUS tab, which only reports, some of the actions here change the node's state.
IMPORTANT: One of these buttons reboots the physical node. Confirm which node you are on and that the cluster is in a state where it is safe to act before using anything on this tab. See Before you act.
The actions
Which buttons appear depends on how RLSI is configured for the node, so the set on a given node may differ from this.
| Button | What it acts on | Risk |
|---|---|---|
| Reboot | The physical node itself, not a VM. | High. Takes the node and everything on it out of service. |
| Reboot Payment Container | The payment container on the node. | Interrupts payment processing for about a minute. |
| Run Puppet | Configuration management on the node. | Applies pending configuration changes, which can restart services. |
| Perform a Ping Test | Nothing. Read-only. | None. |
| Perform a Traceroute | Nothing. Read-only. | None. |
| Network Configuration | Nothing. Read-only. | None. |
Both reboot actions ask you to confirm, and the prompt names what is being restarted — either the Edge Appliance, meaning the node, or the Payment Container. Read the prompt before selecting OK. It is the check that catches a mis-aimed click.
Reboot
Reboot restarts the physical node, and every VM and container on it stops with it. On a clustered node the store's workloads move to the other node, which is a service interruption.
IMPORTANT: Rebooting a clustered node is planned maintenance, not a first-response action, and the cluster has to be prepared beforehand. Do not use this button to fix a problem — escalate instead. See Performing maintenance on a node.
RLSI is served by the node, so the console goes unreachable as soon as the node goes down and stays that way until it has finished starting. Check progress from the other node at the site.
If your goal is to recover a single misbehaving VM, reboot that VM from the VMS tab instead. See Managing virtual machines in RLSI.
Reboot Payment Container
This restarts the payment container, leaving the node and its other workloads running. Payment processing is unavailable while it restarts, so treat it as a customer-visible interruption.
-
Select Reboot Payment Container, and confirm when prompted.
-
Wait for the restart to finish. The button is replaced by a progress message with a countdown, and the page reloads itself when the countdown expires.
The Payment Container is now rebooting. Please allow 1 minute for this process to complete. Do not press reload. Page will refresh automatically in 53 secondsDo not reload the page yourself, and do not select the button again. Allow the full minute.
Run Puppet
Run Puppet applies any configuration that is pending for the node. This does real work — it can restart services whose configuration has changed — so read the output rather than starting it and navigating away.
Puppet is deliberately turned off on some nodes while planned work is in progress, so that configuration does not change mid-task. If you do not know whether work is in progress on the node, escalate rather than running Puppet.
For how configuration changes are normally deployed, see Deploying changes to your environment.
Perform a Ping Test
A ping test from RLSI runs on the node, so it reports what the node can reach rather than what your own computer can reach. That is the reason to use it: a destination that answers from your desk may be unreachable from the store.
-
Select Perform a Ping Test.
-
In ENTER TARGET ADDRESS, type a hostname or IP address, then select Ping.
-
Read the results, which appear below the form.
-
Select Back to return to the ADMIN tab.
Two lines carry most of the answer:
- The first line shows the address actually pinged. If you entered a hostname, this confirms the node resolved it — so a failure here is a DNS problem rather than a connectivity one.
- The summary line reports packets transmitted, received, and the packet loss percentage.
0% packet lossis a clean result.
The test sends five packets and stops, so it is a point-in-time sample. Run it again if you are chasing something intermittent.
Perform a Traceroute
A traceroute shows the path traffic takes from the node to a destination, and where it stops. Use it after a ping fails, to see how far the traffic gets.
The form works the same way as the ping form: enter a target address, select Traceroute, and read the results below. It takes longer than a ping, because unresponsive hops are waited out before the trace moves on.
Each numbered line is one hop, with three timings. Hop 1 is the node's own gateway.
* * * means that hop did not reply, and this is usually not a fault — many routers forward traffic normally while declining to answer traceroute probes. What matters is whether the trace reaches the end.
- Stars for a few hops, then the trace continues. Normal.
- Stars from one hop onward all the way to the end. Traffic is not getting past the last hop that answered. Note that hop and escalate.
Network Configuration
This opens a read-only view of the node's interfaces, grouped as Physical (the LAN ports), Virtual (the container VLAN, loopback, and VPN tunnel), and All Interfaces, which reports every interface in one output including bridges.
Selecting any of them reports that interface's current state. The word RUNNING in that output means the interface has a link — an interface that is enabled but has nothing plugged in shows UP BROADCAST MULTICAST without it.
This view is read-only and is most useful for capturing the node's network state to include in an escalation. For what the rest of the output means, see Troubleshooting RLSI issues.
The LAN numbers against each interface are labels and are not reliable on every node, so do not rely on them to identify a port.
Related documentation
- Using the SC//Reliant Local Status Indicator (RLSI): reaching the console, and what to check before acting.
- Troubleshooting RLSI issues: what to do when an action does not behave as expected.
- Reading the Status tab in RLSI: the checks referenced above.
- Managing virtual machines in RLSI: restarting a VM rather than the node.
- Performing maintenance on a node: the procedures to follow before rebooting a clustered node.