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)
Go to file
Afletdinov Andrey 4a5e77a5d8 Merge branch 'devel' 2024-03-31 21:30:59 +08:00
.github/workflows fixed sonar scanner version 2024-03-24 16:59:07 +08:00
doc LTSM version 20240331 2024-03-31 21:28:49 +08:00
etc fixed config 2024-03-24 17:10:36 +08:00
src LTSM version 20240331 2024-03-31 21:28:49 +08:00
AUTHORS authors 2021-05-14 18:46:30 +08:00
CMakeLists.txt LTSM version 20240331 2024-03-31 21:28:49 +08:00
LICENSE Initial commit 2021-05-14 08:46:38 +00:00
README.md update readme 2024-03-24 23:46:12 +08:00
README_ru.md Merge branch 'devel' 2024-03-24 23:46:31 +08:00
sonar-project.properties cmake remove version 2023-04-01 08:35:44 +08:00

README.md

linux-terminal-service-manager

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)

Linux Only!

main dependencies:

Developer indicators

Build Status Bugs Vulnerabilities Security Rating Reliability Rating OpenHub Rating

Demo access

--- vnc
vncviewer 62.109.12.152
--- rdp
xfreerdp /v:62.109.12.152

logins: demo1, demo2, demo3, demo4
pass: demo

Docker demonstration

docker pull docker.io/ltsm/devel
docker run -i -t docker.io/ltsm/devel

The scheme of interaction of components

ltsm_diagram
The following components are implemented:

LTSM_service

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

LTSM_connector

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

LTSM_helper

ltsm_helper
ltsm_helper_token
GUI login utility, and it is a dbus client ltsm.manager.service (GPLv3 license)
see also: wiki: LTSM config

LTSM_sessions

ltsm_session
GUI users sessions management utility, and it is a dbus client ltsm.manager.service (GPLv3 license)
ltsm_show_session
see also: wiki: LTSM administrator

LTSM_vnc2sdl

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