RPC remote shell

Who it’s for

Engineers supporting devices that expose a command line — a gateway, an industrial PC, a Linux-based controller — where diagnosing a problem means running a command on the device rather than reading its telemetry. The widget gives that a place on a dashboard instead of requiring SSH access to each unit.

What it does

The RPC remote shell emulates a terminal session against the device over RPC, sending typed commands and printing what comes back. The device has to implement the command handling itself; the widget provides the terminal, the transport and the transcript.

• A terminal in the dashboard — commands and responses accumulate as a session rather than as isolated calls.
• Works wherever the platform can reach the device, which is often the case for units behind NAT that SSH cannot reach directly.
• The request timeout is configurable, so a slow link is distinguishable from a command that hung.
• Access follows the dashboard, so shell access is granted by dashboard permissions rather than by distributing device credentials.
• The RPC remote shell requires a custom implementation on the device: there is no standard method it calls, and without firmware support the terminal accepts input and returns nothing.

How to set up

Data keys

The RPC remote shell takes no data keys — commands are typed into the terminal.

Method	Direction	Parameters	Sent when
The device’s shell method	Two-way (request-response)	The typed command line	On each command entered

RPC

Setting	Default	Effect
RPC request timeout	Platform default	How long each command waits for its response, in milliseconds

Implement the command handling on the device before deploying the widget, and decide there what may be run. The device is the only place a restriction can be enforced — the widget sends whatever is typed.

How to customize

• To support long-running commands — raise the RPC request timeout, since a command that takes longer than the timeout appears to have failed even when it completed.

Tips

• Restrict the command set on the device rather than relying on who can see the dashboard. Dashboard permissions decide who reaches the terminal, but only the device can decide what a command is allowed to do, and a shell that accepts anything is a shell that will eventually be given something.
• Raise the timeout to match the slowest command you expect to run. A shell that times out mid-command leaves the operator unsure whether it ran, which is worse than waiting, and the command usually did run.