***************** LN Manager Web UI ***************** The LN manager can serve a browser-based user interface on the same TCP port as the normal manager connection. Overview ======== The browser UI is built into ``ln_manager`` itself: * normal HTTP requests fetch static HTML, CSS and JavaScript * the browser then upgrades to a WebSocket connection on the same manager port * after the upgrade, the browser receives manager snapshots and live updates This means you do not need an additional web server or proxy just to inspect or control an already running manager. If the GTK GUI is running for that same manager instance, its top-right ``web ui`` button opens the ``/lnm/`` entry point in the user's preferred browser, and its ``docs`` button can open the built-in LN documentation at ``/doc/``. Authentication Setup ==================== The browser UI is intentionally disabled until an authentication file is configured. You can configure that file in one of 2 ways: * instance config key :ref:`webui_auth_file ` * environment variable ``LNM_WEBUI_AUTH_FILE`` If both are set, ``LNM_WEBUI_AUTH_FILE`` wins. The authentication file format is very simple: .. code-block:: text alice s3cret bob another_password Each non-empty line is interpreted as `` ``. Security requirements: * the file must exist * the file must not be readable by group or others * ``chmod 600`` is the usual choice After successful login, ``ln_manager`` stores a cookie-backed session in a second file named ``.sessions`` next to the configured auth file. That sessions file is also forced to mode ``0600``. Example configuration --------------------- Config file: .. code-block:: lnc instance name: example webui instance manager: :43809 webui_auth_file: %(env HOME)/.config/ln_manager/webui.keys Environment override: .. code-block:: bash export LNM_WEBUI_AUTH_FILE="$HOME/.config/ln_manager/webui.keys" Connecting From A Browser ========================= 1. Start ``ln_manager`` normally, for example: .. code-block:: bash ./python/links_and_nodes_manager/ln_manager -c path/to/config.lnc --webui 2. Open the manager URL in a browser: .. code-block:: text http://HOST:PORT/ Example: .. code-block:: text http://localhost:43809/ 3. The browser asks for HTTP Basic Auth credentials. 4. After successful login, the browser stores an authentication cookie and the page opens. If authentication is not configured, the browser receives a short plain-text message that explains how to set up the auth file. Useful browser URLs =================== The main web UI lives below ``/lnm``. The plain root URL ``/`` redirects there. Useful entry points are: * ``/lnm`` for the normal multi-tab web UI * ``/lnm/topics`` to open the main UI with the topics tab selected * ``/lnm/services`` to open the main UI with the services tab selected * ``/lnm/parameters`` to open the main UI with the parameters tab selected * ``/lnm/network`` to open the main UI with the network usage tab selected * ``/lnm/loggers`` to open the main UI with the LN daemon logger tab selected * ``/lnm/md`` to open the main UI with the message-definition tab selected * ``/md`` for the standalone message-definition browser * ``/save-all`` to download the compressed ``save all`` diagnostics archive Process and Log Tabs ==================== The main web UI can also open lightweight browser tabs for one specific data stream. Processes --------- When a process is selected in the main process view, the header contains an ``open in tab`` button. That opens a dedicated URL of the form: .. code-block:: text /lnm/procs/PROCESS/NAME This dedicated process page shows only that one process and its terminal. It subscribes only to updates for that process. Live terminal output is requested only when the page creates that process terminal, so it avoids process-output traffic for terminals the user never opens. This is useful when you want to keep separate browser tabs open for a few important processes. Groups ------ When a group is selected in the main process view, the same header contains an ``open in tab`` button. That opens a dedicated URL of the form: .. code-block:: text /lnm/groups/GROUP/NAME This dedicated group page keeps only the selected group subtree in the process list. It subscribes only to process state updates for processes contained in that group, recursively. Live terminal output is requested lazily for child processes whose terminals are actually opened. This is useful when one browser tab should focus on one subsystem while still allowing you to switch between its child processes. Log --- The manager log tab also contains an ``open in tab`` button. That opens: .. code-block:: text /lnm/log This is a log-only page. It subscribes only to manager log messages and does not request process, topic or service updates. The normal full UI log tab is still available as ``/lnm/log-tab``. For command-line tools, the same endpoint also supports a raw plain-text mode: .. code-block:: text /lnm/log?raw Raw log options: * ``level=debug|info|warning|error`` selects the minimum log level * ``limit=N`` limits the initial output to the last ``N`` matching log messages * ``follow`` keeps the HTTP response open and streams new matching log messages with HTTP chunked transfer encoding Without ``limit``, the raw endpoint returns all currently retained in-memory log messages matching the requested level. Example: .. code-block:: bash wget -q --user=USER --password=PASSWORD -O - \ "http://:/lnm/log?raw&level=debug&limit=15" To keep following new messages: .. code-block:: bash wget -q --user=USER --password=PASSWORD -O - \ "http://:/lnm/log?raw&level=info&follow" LN Daemon Logger Tab ==================== The ``loggers`` tab controls LN daemon logger objects. These are the built-in daemon-side per-port ring-buffer loggers exposed by the LN logger API. They are not ``lnrecorder`` recordings. The tab lets you: * create or delete a named LN daemon logger * add topics through an overlay picker instead of showing all topics inline * configure samples, divisor, and timestamp-only mode for the selected topics * see estimated binary size, estimated duration, active state, and fill level * start, stop, or ``stop + download`` a logger for quick experiments * download data as ``pickle`` by default, or as ``matlab`` / ``raw`` The topic detail pane also has a collapsed LN daemon logger section. It uses the fixed logger name ``topic:`` and is meant for quick single-topic captures without switching to the full logger tab. Only one daemon-side ring-buffer configuration can be active for one concrete daemon port at a time. If several LN daemon loggers include the same topic, do not expect them to record that topic independently at the same time. Parameters Tab ============== The ``parameters`` tab shows live :term:`LN parameter` provider blocks in a tree. Parameter values are queried on demand from clients that provide the ``ln/parameters/query_dict`` service; they are not part of the normal manager snapshot because large systems can expose many parameters. The top pane lists parameter names and current output values. Use the pattern field to restrict the query, then click ``refresh`` or enable auto-refresh. The browser also refreshes the list when parameter-provider clients or parameter query services appear or disappear. Selecting a parameter opens a detail pane with: * current input value reported by the provider * override value editor * current output value after override handling * description, provider client, and provider service links Scalar values use one text field. One-dimensional arrays are shown as aligned columns. Two-dimensional arrays are shown as separate input, override, and output tables. The small down-arrow button copies the current input value into the override editor. The adjacent copy button copies a plain text representation of the input vector or matrix to the browser clipboard. ``set override`` sends the entered fixed value through the provider's ``ln/parameters/override_dict_single`` service. ``reset override`` clears the override again so the provider output follows its input value. The ``open scope`` button asks the provider's matching ``request_topic`` service to publish this parameter as an LN topic, then opens ``ln_scope`` on the parameter's ``.output`` field. This mirrors double-clicking a parameter row in the GTK parameters tab. Programmatic access uses the same WebSocket protocol. See :doc:`reference_webui_protocol` for the JSON messages and ``links_and_nodes_manager_client.ManagerClient`` helper methods. Network Tab =========== The ``network`` tab estimates topic, service-call, manager connection, web UI, and TCP-forwarding traffic between configured hosts and host interfaces. Press ``refresh`` to start an asynchronous sample. The manager first refreshes known topic publisher rates, then samples counters. The tab shows: * logical host-to-host traffic, showing real measured values inline when they differ from the estimate * measured TX/RX traffic per configured host interface, including forwarding hops * indented child rows showing which topic or TCP forwarding contributes to a host/interface total * configured networks and gateway hosts * possible problems when measured traffic is more than 5 percent below the theoretical value The host traffic table is an endpoint view. A row ``host A -> host B`` means that the manager attributes traffic to the logical source and destination hosts. It deliberately does not expand multi-hop routes into intermediate host rows. For example, a topic published on ``host A`` and subscribed on ``host D`` should appear as ``host A -> host D`` in host traffic even when it is forwarded through ``host B`` and ``host C``. Service-call accounting is shown the same way: request bytes are attributed from the client host to the provider host, response bytes from provider host to client host, and ``pkts/s`` is the service-call rate. The estimated interface traffic table is the physical interface view. It shows where traffic is expected or measured to leave and enter configured interfaces, including intermediate forwarding hosts. TCP forwarding traffic, such as X11 forwards, daemon connection hops, tcp-tunnel states, arbiter/ssh/telnet startup forwards, service protocol filter forwards, and forwarded service calls, is counted from daemon byte counters and shown here. For TCP forwards theoretical and measured bandwidth are identical because the manager observes only accepted TCP bytes, not packet loss. The host traffic view counts reused TCP/UDP transport channels only once. HTTP and WebSocket traffic from the web UI itself is shown as separate contributors. Daemon-manager and client-manager connections are shown as separate contributors too. Older ``lnm_remote`` pickle GUI/console connections are shown as separate contributors too. The sample time can be changed before pressing ``refresh``. ``refresh from previous`` compares one counter snapshot against the last manager-side network sample, ignores the sample time, and shows the effective elapsed time in the status line. If there is no previous sample yet, the manager falls back to a normal 2 second sample. The measured view is useful for spotting lossy UDP links, saturated links, or TCP back-pressure. The same statistic is available from the manager console via ``get_network_usage_stats``. Use ``get_network_usage_stats --json`` for the raw JSON payload in MI-console workflows. The cheap topology table is available from ``get_network_topology``. Diagnostics Download ==================== The web UI has a global ``save all`` button in the top bar. It starts a normal browser file download from: .. code-block:: text /save-all The response is a binary ``.tar.bz2`` diagnostics archive. It uses the same manager-side debug collection as the GTK UI and console, but the archive is transferred as plain HTTP instead of through WebSocket messages. Message Definition Browser ========================== The manager also serves a message-definition browser below ``/md``. The same view is embedded into the main web UI ``md`` tab, but ``/md`` is also useful on its own in a separate browser tab. This page lets you inspect the manager's effective message-definition search path: * ``by name`` shows the reachable message definitions as a tree by LN message definition name * ``by path`` shows the manager's configured search-path entries in search order, including invalid directories and shadowed duplicates This makes ``/md`` a convenient way to verify which message-definition directories the running manager currently sees. Current Capabilities ==================== The built-in web UI currently supports: * process tree display using the same manager-side group structure as the GTK UI * default open/closed group state from the config * start/stop process actions * alternate command selection per process * editing the current process command line override * lazy xterm.js-backed process terminals with opt-in live stdout/stderr updates * terminal keyboard input forwarded to the process * terminal resize forwarded as ``send_winch`` * dedicated single-process tabs via ``/lnm/procs/...`` to reduce traffic to one process * dedicated single-group tabs via ``/lnm/groups/...`` to reduce traffic to one recursive process subtree * dedicated log-only tab via ``/lnm/log`` * topics, services, LN daemon logger, and manager log views * creating, configuring, starting, stopping, and downloading LN daemon logger captures * browsing message definitions and the effective manager message-definition search path via ``/md`` or the embedded ``md`` tab * downloading a ``save all`` diagnostics archive via ``/save-all`` Protocol Reference ================== If you want to build your own browser or non-browser client, see :doc:`reference_webui_protocol`. That page also documents the ``links_and_nodes_manager_client`` Python reference client.