Skip to content

README_ru.md

Latest commit

 

History

History
77 lines (62 loc) · 8.65 KB

README_ru.md

File metadata and controls

77 lines (62 loc) · 8.65 KB

linux-terminal-service-manager

Linux Terminal Service Manager (LTSM) это набор программ для организации доступа к рабочему столу (сервер Linux) на основе терминальных сессий (с использованием протокола VNC или RDP)

Основные зависимости:

  • systemd, sd-bus
  • sdbus-cpp
  • system libs: gnutls, xcb, zlib

Демо доступ

Вы можете подключиться через HTML5 прямо сейчас

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

Docker демонстрация

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

Схема взаимодействия компонентов

ltsm_diagram
реализованы следующие компоненты:

LTSM_service

основная служба, менеджер dbus ltsm.service.manager, получает команды от LTSM_connector, запускает login и users сессии на базе Xvfb (Лицензия GPLv3)
см дополнительно: wiki: LTSM service

LTSM_connector

является только обработчиком сетевого протокола VNC и RDP, а основной сетевой частью занимается служебный xinetd/(systemd sockets), также он является клиентом dbus ltsm.manager.service, подключается к Xvfb через механизм shared memory (Лицензия на коннектор Affero GPLv3)
см дополнительно: wiki: LTSM connector

LTSM_helper

ltsm_helper
ltsm_helper_token
графическая утилита входа в систему, является клиентом dbus ltsm.manager.service (Лицензия GPLv3)
см дополнительно: wiki: LTSM config

LTSM_sessions

ltsm_session
графическая утилита управления сессиями пользователей, является клиентом dbus ltsm.manager.service (Лицензия GPLv3)
см дополнительно: wiki: LTSM administrator

LTSM_vnc2sdl

Это экспериментальный графический клиент, в котором реализован механизм множественных каналов данных, максимально до 253.

Основные реализованные улучшения:

  • Работает буфер обмена utf8 в обе стороны (проблема для большинства клиентов VNC)
  • шифрование трафика через gnutls
  • Автоматическая раскладка клавиатуры, в приоритете всегда раскладка со стороны клиента (на стороне сервера ничего не нужно настраивать)
  • Передача файлов через drag & drop (со стороны клиента на удаленную виртуальную сессию)
  • Реализована печать файлов (с помощью дополнительного backend для CUPS)
  • Реализован редирект звука через PulseAudio
  • Реализован редирект смарткарт через PCSC
  • Реализовано сканирование документов (с помощью дополнительного backend для SANE)
  • Реализован редирект директорий через FUSE (пока только в режиме read only)
  • Реализована аутентификация в виртуальную сессию через PKCS11 (модуль rutoken или другой) с хранилищем сертификатов в LDAP
  • Реализована SSO аутентификация через GSSAPI (kerberos5)
  • Реализовано кодирование x264 через ffmpeg

Механизм каналов реализован через абстрактные схемы unix://, file://, socket://, и режим доступа ReadOnly, WriteOnly, ReadWrite.
Например для обычной передачи файла создается типовой канал (клиент сервер): file:///src_file1 (ReadOnly) и file:///dst_file2 (WriteOnly), далее в сессии пользователя запускаются информационные GUI диалоги о передаче и выборе папки назначения, после которых файл автоматически сохранится в удаленной сессии (дополнительно реализованы уведомления через dbus desktop notify).
C помощью данной схемы каналов возможна передача любого потока данных в обе стороны, но инициатором создания канала всегда является сервер.

Печать со стороны сервера (в удаленной сессии пользователя) реализуется таким образом - на сервере в cups добавляется собственный backend для печати, который знает в какой unix сокет печатать в сессии пользователя, со стороны клиента поток можно отправлять в сетевой принтер socket://127.0.0.1:9100, также в локальный cups или в file:///dev/usb/lp0. В этой схеме системный администратор настраивает принтер только один раз для сервера, например командой lpadmin -p ltsm -D "LTSM virtual printer" -E -v ltsm:///var/run/ltsm/cups/username -m raw. Модуль для cups автоматически получает сокет из этой схемы, меняет username на реального и отправляет в него задание печати. Этот же формат сокета на стороне LTSM сервиса назначается в конфигурационном файле. Сокеты на стороне сервера работают в listen режиме поэтому допускаются множественные подключения от клиента. Каждое подключение занимает один канал (253 макс). Как только с одной из сторон освободится дескриптор считается что передача данных завершена и канал можно использовать повторно. Редирект звука, сканирования и pcscd работает по аналогичной схеме.

Все эти реализованные возможности вы можете протестировать в версии docker.

Программное обеспечение зарегистрировано в реестре российского ПО, Номер заявления: 246869, Дата регистрации: 01.11.2021.

Roadmap

  • добавить записи видео всех рабочих сессий (видеофикация)
  • добавить поддержку VirtualGL
  • добавить редирект video через PipeWire
  • добавить клиента для MacOs/Windows