Orb CLI¶

You should familiarise yourself with the Orb CLI (command line interface) as it enables you to perform some operations a lot more quickly than via the GUI (graphical user interface).

Locating the executable in a terminal¶

If you have freshly installed Orb, you may want to open a terminal, and locate the executable.

OSX:

/Applications/lnorb.app/Contents/MacOS/lnorb

Windows:

C:\Users\Administrator\Downloads\orb-<version>-windows-<edition>-x86_64/lnorb/lnorb.exe

Linux:

~/Downloads/orb/main.py

Note

In a future release of Orb, expect the executable to be named orb. Until then, mentally substitute orb with the correct executable name. In Linux and OSX, create an Alias. In Windows add your install directory to the PATH.

Running tests¶

Orb comes with its pytest suite included, so that the build system can test the binary before making it available to the public, and so that users can test the build on their setup, too.

The test are safe to run: if you have existing nodes setup, the tests will not touch them; they’ll only use alter the public nodes.

$ orb test run-all-tests

Connecting to Orb’s public nodes¶

LND¶

To connect to LND via REST:

$ orb node create-orb-public lnd rest

Or to connect via GRPC:

$ orb node create-orb-public lnd rest

Core-Lightning¶

To connect to Orb public Core-Lightning node via REST:

$ orb node create-orb-public cln rest

(please note, we are somewhat ignoring Core-Lighting’s GRPC interface as it is still very new, and Orb can use all the existing RPC endpoints via REST).

Showing node information¶

The next thing you’ll want to do is see what nodes are available to Orb:

$ orb node list

Or show more information:

$ orb node list --show-info

You may notice the information displayed is the same regardless of whether you are interacting with an LND or Core-Lightning node, and regardless of whether connecting over REST or GRPC.

Orb abstracts the implementation type, enabling you to get on with your daily operations in an implementation-independent way.

Commands and sub-commands¶

You may (or may not) be familiar with git. It uses commands, and subcommands, e.g:

$ git origin add

Orb CLI works in exactly the same way.

$ orb <command> <sub-command>

Arguments and Options¶

Arguments come after a sub-command, and do not require to be preceded by two dashes. Options on the other hand are preceded by two dashes, e.g –use-node.

CLI changes¶

Deciding on how to group commands and sub-commands, and what should be an argument vs. an option etc. are hard design decisions, thus expect argument / option names, order etc. to change quite a lot for as long as Orb remains in v0.x.x.

Once Orb reaches v1, the API and CLI will become stable, and if there are breaking changes then Orb’s major version will be incremented (to v2, v3 etc.).

This is a strict requirement, as a stable CLI / API enables you to use Orb in your own automation workflows without the fear of breaking changes when updating minor versions.

Getting help¶

$ orb --help

Getting help on commands¶

$ orb node --help

Getting help on sub-commands¶

$ orb node ssh-wizard --help

CLI reference¶

Now that are you are a bit more familiar with Orb’s CLI, here’s the full command reference.