Linux Terminal Service Manager (LTSM) is a set of service programs that allows remote computers to connect to a Linux operating system computer using a remote terminal session (over VNC or RDP)
main dependencies:
- systemd, sd-bus
- sdbus-cpp
- json parser
- freerdp
- system libs: gnutls, xcb, zlib
--- vnc
vncviewer 62.109.12.152
--- rdp
xfreerdp /v:62.109.12.152
logins: demo1, demo2, demo3, demo4
pass: demo
docker pull docker.io/ltsm/devel
docker run -i -t docker.io/ltsm/devel
The following components are implemented:
The main service, dbus owner ltsm.service.manager, receives commands from LTSM_connector, and starts login and users sessions based on Xvfb (GPLv3 license)
see also: wiki: LTSM service
It is just a graphics protocol handler, and the main network part is handled by the service xinetd/(systemd sockets), and it is also a dbus client ltsm.manager.service, it connects to Xvfb via the shared memory mechanism (Affero GPLv3 license)
see also: wiki: LTSM connector
GUI login utility, and it is a dbus client ltsm.manager.service (GPLv3 license)
see also: wiki: LTSM config
GUI users sessions management utility, and it is a dbus client ltsm.manager.service (GPLv3 license)
see also: wiki: LTSM administrator
This is an experimental graphical client that implements the mechanism of multiple data channels, up to a maximum of 253.
Main improvements implemented:
- Works utf8 clipboard in both directions (problem for most VNC clients)
- Automatic keyboard layout, client-side layout always takes precedence (nothing needs to be configured on the server-side)
- File transfer via drag & drop (client side to remote virtual session)
- Implemented file printing (using an additional backend for CUPS)
- Implemented audio redirect via pulseaudio
- Implemented pkcs11 support via pcscd redirect
- Implemented scanning redirect (using an additional backend for SANE)
- Directory redirection via FUSE has been implemented (so far only in read only mode)
- Implemented authentication to a virtual session via rutoken with certificate storage in LDAP
- Implemented SSO authentication via GSSAPI (kerberos5)
- Implemented x264 encoding/decoding via ffmpeg
The mechanism of pipes is implemented through the abstract schemes unix://, file://, socket://, and the access mode ReadOnly, WriteOnly, ReadWrite.
For example, for a normal file transfer, a typical channel is created (client-server): file:///src_file1 (ReadOnly) and file:///dst_file2 (WriteOnly), then in the user session, informational GUI dialogs are launched about the transfer and selection of the destination folder, after which the file automatically saved in the remote session.
Also, using this mechanism, it is possible to transfer any data stream in both directions, but the initiator of creating a channel is always the server.
So printing from the server side (in a remote user session) is implemented in this way - on the server, cups adds its own backend to configure the printer, which knows which unix socket to print in the user session, from the client side, the stream can be sent to the socket:// network printer 127.0.0.1:9100, also to local cups or file:///dev/usb/lp0. In this scheme, the system administrator configures the printer only once per server. The audio redirect, scanning and pcscd redirect works according to a similar scheme.
You can test all implemented features in the docker version.
ROADMAP
- add video recordings of all working sessions (video recording)
- add VirtualGL support
- add a video redirect via PipeWire
- work with graphics accelerated via Cuda GPU (there are no technical capabilities yet)
- build client for MacOs/Windows