6.7. LN Manager Web UI

The LN manager can serve a browser-based user interface on the same TCP port as the normal manager connection.

6.7.1. 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/.

6.7.2. 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 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:

alice s3cret
bob another_password

Each non-empty line is interpreted as <username> <password>.

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 <authfile>.sessions next to the configured auth file. That sessions file is also forced to mode 0600.

6.7.2.1. Example configuration

Config file:

instance
name: example webui instance
manager: :43809
webui_auth_file: %(env HOME)/.config/ln_manager/webui.keys

Environment override:

export LNM_WEBUI_AUTH_FILE="$HOME/.config/ln_manager/webui.keys"

6.7.3. Connecting From A Browser

  1. Start ln_manager normally, for example:

    ./python/links_and_nodes_manager/ln_manager -c path/to/config.lnc --webui

  2. Open the manager URL in a browser:

    http://HOST:PORT/

    Example:

    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.

6.7.4. 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, forward_x11 targets that display.

  • If DISPLAY is absent or empty, a browser start of forward_x11_to_gui uses the authenticated web user’s private VNC-backed X display. Existing 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:

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:

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:

http://MANAGER_HOST:MANAGER_PORT/

If webui_https_cert_file is configured, the same manager port also accepts HTTPS:

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 Web UI HTTPS Certificates for the practical certificate options.

6.7.4.1. 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:

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:43809:MANAGER_HOST:MANAGER_PORT target-pc

Then open:

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:

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:

Host ln-target
  HostName target-pc.internal
  User alice
  ProxyJump bastion.example.org
  ForwardX11 no

Then use:

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.

6.7.4.2. Starting GUI Processes From The Web UI

For new config files, prefer forward_x11_to_gui for processes that are meant to open windows for the operator who clicked start:

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 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.

6.7.4.3. 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:

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:

vncviewer -via ln-target localhost:90

The equivalent manual tunnel is:

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:

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.

6.7.5. 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

6.7.6. Process and Log Tabs

The main web UI can also open lightweight browser tabs for one specific data stream.

6.7.6.1. 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:

/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.

6.7.6.2. 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:

/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.

6.7.6.3. Log

The manager log tab also contains an open in tab button. That opens:

/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:

/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:

wget -q --user=USER --password=PASSWORD -O - \
  "http://<IP>:<PORT>/lnm/log?raw&level=debug&limit=15"

To keep following new messages:

wget -q --user=USER --password=PASSWORD -O - \
  "http://<IP>:<PORT>/lnm/log?raw&level=info&follow"

6.7.7. 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:<TOPICNAME> 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.

6.7.8. Parameters Tab

The parameters tab shows live 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 Web UI WebSocket Protocol for the JSON messages and links_and_nodes_manager_client.ManagerClient helper methods.

6.7.9. 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.

6.7.10. Diagnostics Download

The web UI has a global save all button in the top bar. It starts a normal browser file download from:

/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.

6.7.11. 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.

6.7.12. Private X Display

The 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 forward_x11.

For new browser and remote-GUI workflows, prefer forward_x11_to_gui over 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 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 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 disable_forward_x11_to_gui_fallback. For the complete remote/headless startup recipe, see Headless Browser Operation With X Clients.

The VNC X server is represented as a normal manager process named vnc:<username>. 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 Headless Browser Operation With 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:

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:<display> command instead.

6.7.12.1. 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-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: <vnc_session name>. For real X servers, allow the Unix user running the started process to access the display, for example on gpu_node:

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.

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=<process-name>. The manager proxies that browser connection to localhost:<vnc_port> 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:

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 vncserver_process_template.

A useful Debian/Ubuntu-style ~/.vnc/xstartup can use the standard x-terminal-emulator and x-window-manager alternatives:

#!/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 vncserver_process_template. For a web user alice, ln_manager first tries a template named <vncserver_process_template>_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.

6.7.13. Current Capabilities

The browser UI vendors xterm.js for process terminals and noVNC for browser VNC display access. Their bundled license texts are included in Third-Party Runtime Licenses.

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

6.7.14. Protocol Reference

If you want to build your own browser or non-browser client, see Web UI WebSocket Protocol. That page also documents the links_and_nodes_manager_client Python 3.11+ reference client.