***************** 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. It also allows operating the manager from a browser when the manager process has no local X display. This is a display/runtime mode, not a reduced Python dependency set: ``ln_manager`` still uses Python GI and GLib internally, so the ``gi`` / ``GLib`` runtime packages must still be installed. 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. .. _ln_manager_webui/headless-x-clients: Headless Browser Operation With X Clients ========================================= A useful remote setup is to run ``ln_manager`` on a target PC without opening a local GTK window and without requiring a local X display, control it from a browser, and still start graphical tools from the web UI. The manager process still needs its normal Python GI/GLib runtime, but it does not need a usable ``DISPLAY`` for this browser workflow. In that setup, let the manager create a private VNC-backed X display for web-started GUI processes instead of inheriting SSH X11 forwarding from the login shell. The important distinction is: * ``--without-gui`` stops the local GTK manager window from opening, but the manager still requires Python GI/GLib for its main loop. * It does not clear environment variables inherited by ``ln_manager``. * If ``DISPLAY`` is still set, :ref:`process/forward_x11` targets that display. * If ``DISPLAY`` is absent or empty, a browser start of :ref:`process/forward_x11_to_gui` uses the authenticated web user's private VNC-backed X display. Existing :ref:`process/forward_x11` processes can use the same fallback when they are started from the browser web UI, unless ``disable_forward_x11_to_gui_fallback`` disables it. This matters when you SSH to the target PC with X11 forwarding enabled. A shell started by ``ssh -X`` or ``ssh -Y`` usually has a ``DISPLAY`` such as ``localhost:10.0``. If ``ln_manager`` inherits that value, ``forward_x11`` processes started from the web UI will try to show their windows through the SSH-forwarded X display on your local desktop. That often works on a LAN, but it can be very slow over long-latency internet links and can feel surprising when you expected a browser-contained remote desktop. Starting the manager deliberately without an X display avoids that: .. code-block:: bash ssh -x target-pc DISPLAY= ln_manager -c /path/to/config.lnc --without-gui ``ssh -x`` disables SSH X11 forwarding for that login. The ``DISPLAY=`` prefix is still useful because it makes the manager startup command explicit and also protects against shell startup files or SSH configuration that set ``DISPLAY`` anyway. The assignment affects only that one ``ln_manager`` process. If you also configure the web UI auth file through the environment, put both assignments on the same command: .. code-block:: bash DISPLAY= LNM_WEBUI_AUTH_FILE=$HOME/.config/ln_manager/webui.keys \ ln_manager -c /path/to/config.lnc --without-gui After startup, note the manager host and port reported in the log, or use the ``manager:`` value from the config file. The browser URL is: .. code-block:: text http://MANAGER_HOST:MANAGER_PORT/ If :ref:`webui_https_cert_file ` is configured, the same manager port also accepts HTTPS: .. code-block:: text https://MANAGER_HOST:MANAGER_PORT/ This is useful when the browser is not running on the manager host. Browser APIs used by remote-operator workflows, including keyboard lock and some clipboard operations, are restricted to secure contexts. Plain ``http://localhost`` and ``http://127.0.0.1`` can be treated as secure by browsers because they are local to the browser, but plain HTTP to another host usually is not. Use a certificate trusted by the browser to avoid certificate warnings and to make the HTTPS origin behave like a normal secure site. See :doc:`ln_manager_webui_https_certificates` for the practical certificate options. Access Through SSH ------------------ If the manager port is directly reachable from your workstation, open the URL directly. On untrusted networks, or when the target PC is reachable only by SSH, use an SSH tunnel or SOCKS proxy. For a fixed local port tunnel: .. code-block:: bash ssh -N -o ExitOnForwardFailure=yes \ -L 127.0.0.1:43809:MANAGER_HOST:MANAGER_PORT target-pc Then open: .. code-block:: text http://127.0.0.1:43809/ The ``MANAGER_HOST:MANAGER_PORT`` part is interpreted on the SSH server side. If the manager runs on the same target PC and listens on loopback, this is often ``127.0.0.1:MANAGER_PORT``. If the manager log reports a specific host name or interface address, use a name or address that the target PC can resolve and reach. For a SOCKS proxy: .. code-block:: bash ssh -N -D 127.0.0.1:1080 target-pc Configure the local browser to use SOCKS5 proxy ``127.0.0.1:1080``, then open the manager URL as seen from the target-side network. If that host name is only resolvable inside the target network, enable remote DNS resolution for the browser's SOCKS proxy. For target PCs behind a bastion or jump host, put the SSH route into ``~/.ssh/config`` and reuse that host alias: .. code-block:: text Host ln-target HostName target-pc.internal User alice ProxyJump bastion.example.org ForwardX11 no Then use: .. code-block:: bash ssh -N -o ExitOnForwardFailure=yes \ -L 127.0.0.1:43809:MANAGER_HOST:MANAGER_PORT ln-target .. note:: The `OpenSSH ssh(1) manual `_ documents ``-L`` as local port forwarding and ``-D`` as dynamic SOCKS forwarding. The SSH server must permit TCP forwarding; the `sshd_config(5) manual `_ documents ``AllowTcpForwarding``. ``ExitOnForwardFailure=yes`` makes SSH fail early if the requested tunnel cannot be created. Starting GUI Processes From The Web UI -------------------------------------- For new config files, prefer :ref:`process/forward_x11_to_gui` for processes that are meant to open windows for the operator who clicked ``start``: .. code-block:: lnc process scope-like tool node: target-pc add flags: forward_x11_to_gui command: some-x-client When such a process is started from the browser web UI, ln_manager allocates or reuses the authenticated web user's private VNC-backed X display and passes that display to the process. The top-bar ``X display`` button turns green while the private display is available; clicking it opens the vendored noVNC viewer. Existing configs that still use :ref:`process/forward_x11` can also work in this headless browser workflow when the manager has no ``DISPLAY``. In that case a browser start of a ``forward_x11`` process falls back to the same private web display. This compatibility behavior is useful during migration, but ``forward_x11_to_gui`` is clearer for new interactive browser workflows. If a web-started X client appears on your local desktop instead of in the browser VNC display, the manager probably inherited ``DISPLAY`` from SSH X11 forwarding or from the environment that launched it. Stop the manager and start it again with ``DISPLAY=`` as shown above. The process detail pane also shows the selected ``X display`` target for running X-forwarded processes. Using A Native VNC Viewer ------------------------- The browser noVNC viewer is the simplest option because it uses the same web UI URL, authentication, and SSH tunnel or SOCKS proxy as the rest of the web interface. A native VNC client can still be useful when you want a separate viewer window or native viewer features. The default ln_manager VNC server listens only on localhost of the manager host and uses no VNC password. Do not expose that port directly on a network. Use SSH or the authenticated manager web proxy. If the private web display is ``:90``, the matching VNC TCP port is ``5990``. TigerVNC's ``vncviewer`` can create the SSH tunnel itself: .. code-block:: bash vncviewer -via target-pc localhost:90 With ``-via``, ``localhost`` means "localhost as seen from the gateway named after ``-via``", not localhost on your workstation. This is exactly what the default ln_manager VNC server needs, because it listens on the target side. If your SSH route uses a jump host, use the same SSH alias that you use for the manager tunnel: .. code-block:: bash vncviewer -via ln-target localhost:90 The equivalent manual tunnel is: .. code-block:: bash ssh -N -o ExitOnForwardFailure=yes \ -L 127.0.0.1:5990:127.0.0.1:5990 ln-target vncviewer localhost::5990 ``localhost::5990`` uses an explicit VNC TCP port. ``localhost:90`` uses VNC display-number syntax and maps to the same port. .. note:: The `TigerVNC vncviewer manual `_ documents ``-via`` and the ``VNC_VIA_CMD`` environment variable. Current TigerVNC runs an SSH local-forward command using the variables ``L``, ``H``, ``R``, and ``G`` for the local port, remote host, remote port, and gateway. Its documented default includes ``sleep 20``. That short remote command keeps the SSH session alive long enough for the viewer to connect through the tunnel. Some client versions or desktop launchers make this visible as a connection delay of about 20 seconds. In that case, either be patient or override ``VNC_VIA_CMD`` on the workstation where ``vncviewer`` runs. For example, when launching from a shell: .. code-block:: bash export VNC_VIA_CMD='/usr/bin/ssh -f -o ExitOnForwardFailure=yes -L "$L":"$H":"$R" "$G" sleep 5' Put that in your local ``~/.bashrc`` or another local shell startup file if you want it every time you launch ``vncviewer`` from a terminal. Do not make the sleep too short for your SSH authentication path; if the tunnel closes before the viewer connects, the VNC connection will fail. Some older VNC viewer man pages use ``%L`` / ``%H`` / ``%R`` / ``%G`` placeholders instead of shell variables, so check your local ``man vncviewer`` before overriding this variable. 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. Private X Display ================= The :ref:`process/forward_x11_to_gui` process flag is meant to use the X display attached to the GUI context that sent the start-process request. That GUI context can be the built-in GTK GUI, a remote GUI connection via ``ln_manager --connect X:Y``, or the browser web UI. If there is no separate GUI context for the request, the flag falls back to the same manager-display behavior as :ref:`process/forward_x11`. For new browser and remote-GUI workflows, prefer :ref:`process/forward_x11_to_gui` over :ref:`process/forward_x11` unless the manager process' own X display is specifically desired. It makes the started window appear close to the operator who sent the request. For the browser web UI, the GUI context is a private VNC-backed X server allocated per authenticated web-UI user. The top-bar ``X display`` button starts or reuses that server, then opens the vendored noVNC browser viewer for the display. Processes started from that web user with :ref:`process/forward_x11_to_gui` receive the private web ``DISPLAY`` value instead of the manager process' own ``DISPLAY``, even when ln_manager itself was started with a normal GUI. Inside the noVNC viewer, ``F8`` toggles an options panel with clipboard transfer controls, keyboard helpers, viewer settings, fullscreen, and screenshot download. To send an actual ``F8`` key press to the VNC session, either press ``F8`` twice quickly or open the options panel and use ``Send F8``. The keyboard helpers can send ``Escape``, ``F8``, ``F11``, ``Alt+Tab``, ``Ctrl+Alt+Enter``, ``Ctrl+Alt+Escape``, and ``Super`` to the VNC session, and can release stuck remote modifier keys. The viewer settings can disable viewport scaling or automatic remote session resizing. Disabling automatic resize is useful when several browser windows observe the same VNC session and should not resize the shared desktop whenever one viewer changes size. The scale and resize settings are stored in browser local storage and reused by later VNC viewer windows from the same browser profile. The noVNC viewer can exchange plain-text clipboard contents with the VNC session. When text is copied inside the VNC session and the VNC server sends a clipboard update, the options panel shows it as the remote clipboard and the ``Copy To Local`` button writes it to the browser's local clipboard. For the opposite direction, paste text into the ``Local clipboard`` field and press ``Send To Remote``. Browser paste events while the VNC screen has focus also send the pasted plain text to the remote clipboard automatically. This updates the remote clipboard; if the focused remote application does not insert the text immediately, use that application's paste command after the clipboard has been sent. The ``Read Local`` button uses the browser's asynchronous Clipboard API. Modern browsers usually expose clipboard reads only in secure contexts, such as HTTPS or localhost, and may still require a user gesture or permission prompt. When the manager web UI is served over plain HTTP from another host, browsers may not expose local clipboard reading at all. In that case, manually paste into the ``Local clipboard`` field and then press ``Send To Remote``. For compatibility with existing configs, processes using :ref:`process/forward_x11` also use this private web X display when they are started from the browser web UI and the manager process has no ``DISPLAY`` environment variable. This fallback can be disabled for the whole instance with the ``disable_forward_x11_to_gui_fallback`` instance flag, or for a single process with :ref:`process/disable_forward_x11_to_gui_fallback`. For the complete remote/headless startup recipe, see :ref:`ln_manager_webui/headless-x-clients`. The VNC X server is represented as a normal manager process named ``vnc:``. ln_manager stores the web username, display number, and VNC port as daemon process properties, so after a manager restart it can rediscover still-running VNC servers from the daemon process list. Config reloads carry these generated VNC server processes into the new config instead of asking the user to stop them. Processes started with X forwarding also store their selected X target as daemon process properties. The process detail pane shows this as ``X display``, so another web user can see whether a running process is using the manager's X display or the private X display of a specific authenticated web user. ln_manager vendors the noVNC JavaScript viewer, but it does not vendor the VNC X server itself. The manager host must provide a suitable Xvnc server binary. The built-in template tries common TigerVNC binary names such as ``Xvnc`` and ``Xtigervnc`` and reports an error if none is available. Display numbers are allocated from ``:90`` upward. Before using a number, ln_manager skips displays already known in this LN instance and skips VNC ports that already accept a localhost TCP connection on ``5900 + display``. The default server template binds the VNC port to localhost and disables VNC passwords; remote browsers reach it only through the authenticated manager web port at ``/lnm/vnc/ws``. Users can also connect with a native VNC viewer. Because the default VNC server listens only on localhost of the manager host, viewers running elsewhere need an SSH hop to that host. TigerVNC's ``vncviewer`` supports this directly with ``-via``. This requires a working SSH setup to reach the manager host named after ``-via``; see :ref:`ln_manager_webui/headless-x-clients` for tunnel, SOCKS, jump-host, and ``VNC_VIA_CMD`` examples. If the manager runs on host ``X`` and the private display is ``:90``, use: .. code-block:: bash vncviewer -via X localhost:90 The noVNC ``F8`` options panel shows a command in this form for the current private display. If the browser reached the manager through a local tunnel or an alias, replace the suggested ``-via`` host with an SSH host name that reaches the manager host. When the noVNC page itself was opened through ``localhost``, the panel omits ``-via`` and shows a local ``vncviewer localhost:`` command instead. Configured VNC Displays ----------------------- The ``X display`` button can also expose VNC servers declared in the LN config. If the config contains any process with ``vnc_session`` and ``vnc_port``, the button opens a small menu instead of directly opening the private web-user display. The first menu item is still the private per-user X display. The following items are the configured VNC displays in config order. Configured VNC displays are normal ``process`` sections; no separate top-level section is needed. A command-backed VNC display starts through normal ln_manager process mechanics, and noVNC waits until that process has reached its configured ready state. A commandless declaration represents an externally managed VNC server and is not started or stopped by ln_manager. Manager UIs hide or disable start/stop controls for commandless configured VNC declarations. Configured VNC session names must be unique. For LN-managed TigerVNC ``Xvnc`` sessions, prefer built-in-:ref:`internal configured vncserver template`. If you write a custom Xvnc command instead, ``ready_regex: Listening for VNC connections`` is a useful readiness marker. TigerVNC also has an automatic authentication blacklist; use ``-UseBlacklist=0`` for LN-managed browser sessions unless that blacklist is explicitly desired. For a hardware-backed OpenGL/CUDA desktop, start a VNC server such as ``x11vnc`` on top of a real X server that is already using the graphics hardware, for example an X server running on ``:0`` on ``gpu_node``. ``Xvnc`` servers are useful for remote desktop sessions and can still be started by ln_manager, but they typically do not provide a hardware GPU/OpenGL context. Processes can send their GUI windows to one of these configured VNC sessions with ``forward_x11_to_vnc: ``. For real X servers, allow the Unix user running the started process to access the display, for example on ``gpu_node``: .. code-block:: bash DISPLAY=:0 xhost +si:localuser:USERNAME When the process runs on another LN node, ln_manager forwards to the X server's Unix socket. Depending on how the daemon is run, the X server may see the daemon-side Unix user for that forwarded local connection; use a matching X authority or xhost setup for that deployment. .. code-block:: lnc process remote xvnc desktop use_template: internal configured vncserver template("remote Xvnc desktop", "80", "5980") node: vnc_node process externally started gpu_node x11vnc node: gpu_node vnc_session: gpu_node hardware X11 desktop vnc_port: 5900 vnc_display: 0 process xlogo on gpu_node hardware X11 desktop node: gpu_node command: /usr/bin/xlogo forward_x11_to_vnc: gpu_node hardware X11 desktop When a browser opens a configured VNC display, noVNC is loaded as ``/lnm/vnc?session=``. The manager proxies that browser connection to ``localhost:`` on the process' ``node``. For remote nodes, ln_manager uses the existing LN TCP forwarding machinery. On Ubuntu 24.04, a typical minimal setup is: .. code-block:: bash sudo add-apt-repository universe sudo apt update sudo apt install tigervnc-standalone-server metacity ``tigervnc-standalone-server`` provides the TigerVNC X server used by the default template. ``metacity`` provides a lightweight window manager, which is the first window-manager candidate ln_manager tries when it has to create a default ``~/.vnc/xstartup``. The default VNC server process starts a window manager via ``~/.vnc/xstartup`` for the user running that process. If the file already exists, it is used as-is. If it does not exist, ln_manager creates a minimal one using the first available window manager from ``metacity``, ``xfwm4``, ``openbox``, ``mutter``, and ``i3``. Users who want a different window manager should first customize ``~/.vnc/xstartup``. If that is not enough, they can replace the whole process command through :ref:`instance/vncserver_process_template`. A useful Debian/Ubuntu-style ``~/.vnc/xstartup`` can use the standard ``x-terminal-emulator`` and ``x-window-manager`` alternatives: .. code-block:: sh #!/bin/sh export LANG=C.UTF-8 export LC_CTYPE=C.UTF-8 unset LC_ALL [ -r "$HOME/.Xresources" ] && xrdb "$HOME/.Xresources" xsetroot -solid black # Helps GNOME applications avoid X keyboard map problems in minimal sessions. export XKL_XMODMAP_DISABLE=1 exec dbus-run-session -- sh -c 'x-terminal-emulator & exec x-window-manager' ``dbus-run-session`` gives applications launched from the VNC session a D-Bus session bus, which is needed by tools such as ``gnome-terminal``. The UTF-8 locale avoids failures from terminal applications that require UTF-8. The ``x-terminal-emulator`` and ``x-window-manager`` commands are Debian alternatives; install a terminal emulator and a window manager if either command is missing. Users can replace or specialize the VNC server command with :ref:`instance/vncserver_process_template`. For a web user ``alice``, ln_manager first tries a template named ``_for_alice`` and falls back to the generic template if it does not exist. The generated ``~/.vnc/xstartup`` is created on the host where the VNC server process starts. The built-in template uses the manager host. If a custom template starts the VNC server elsewhere, configure that remote user's ``~/.vnc/xstartup`` too, or use a shared home directory so the same file is visible there. 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`` * a private VNC-backed ``X display`` with a noVNC browser viewer for processes that use ``forward_x11_to_gui`` when started from the web UI, and as a fallback for ``forward_x11`` when the manager has no ``DISPLAY`` * 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.