VNC с буфером обмена, звуком и микрофоном: x-combo-remote

Я думаю, что с ИИ количество приложений которые отражают странность автора, а не предпочтение большинства стало больше. Проще короче себя почувствовать ни таким как все стало легче и себе угодить стало легче. Но возможно это просто статистическая погрешность на фоне просто возросшего количества нового ПО.

Вроде как раньше человек хотел по своему, но скорее всего времени и усилий чтобы сделать по-своему тратить не хотел, поэтому он все-таки разбирался с более популярными решениями, а потом и понимал, «а зачем?». Но с другой стороны мы бы лишились многого крутого софта, если бы многие авторы не ложили на всех, вместо делания чего-то своего. Просто вход и цена пойти таким одиноким волком делать что-то была явно выше.

Да если, что я понял что это просто скрипт, а не полноценная утилита, но все-таки весьма странное нагромождение всего ради того, чтобы угодить себе.

Да как я понял ssh socket ложится в tmp, так что к нему может подключиться любой пользователь с доступом к /tmp :)

Хорошо, если тебе удобно. Но Ш - феерическое Г.

Скрипт не работает, если в системах например чистая Alsa а не ПшПшАудио.

Еще один заменитель Remmina? Ну пусть будет

А чем двунаправленный буфер обмена реализован?

Вообще он в внц изначально есть, но часто не работает.

Какое то долгое время назад, я искал способ передавать с микрофона подключенного к венде звук на линукс(нужно было слушать какие звуки издает тестовый стенд в офисе). В итоге после долгих плясок с pulseaudio и попытками поставить его на венду и передавать звук по сети, оказалось проще всего записывать с микрофона в файл и скачивать этот файл. Почему не заработало по RDP я сейчас уже не помню. Возможно в офисе была венда не серверная, которая не давала RDP-сервер поднять. А вот картинка была как раз по VNC тогда.

Микрофон можно по протоколу VBAN передавать.

Для GNU Linux есть исходный код, который нужно скомпилировать. Там есть режимы отправки и приёма.
Для Windows простое графическое приложение «VBAN Emitter» для отправки и «VBAN Receptor» для приёма. Или сложное графическое приложение «Voicemeeter» для отправки, приёма, и много чего ещё.

Приложением xsel и логикой bash. Постоянно проверяется локальный и удалённый через SSH буфер обмена xorg. Изменения буфера обмена синхронизируются.

А такое всё ещё используют?

В моём скрипте нет закладок и графического интерфейса.
В Remmina нет альтернативного буфера обмена, звука, микрофона для VNC.
Они совершенно разные по смыслу.

Давным давно, когда я работал сисадмином, главным недостатком VNC для меня было то, что при подключении к физической консоли экран остаётся разблокированным (видно всё, что происходит в сессии). Сейчас эта проблема как-то штатно решается? Для поддержки юзера это, скорее, полезная возможность: можно видеть происходящее на его экране и показать, что нужно сделать. Но при подключении к серверу или админской рабочке - вредная фича.

Пожалуй, админские задачи нужно решать по SSH. Однако иногда нужен графический интерфейс, а проброс отдельных окон по SSH/X11 не всегда удобен и возможен.

Насколько я помню, эту задачу решал NX от NoMachine. Он мог предоставлять отдельные виртуальные рабочие столы, не связанные с физической сессией. Но NX — закрытая проприетарщина.

Но NX — закрытая проприетарщина.

Зато удобно, быстро, хорошо.

Запустить headless-сервер с доступом только по vnc можно было примерно всегда. Он называется Xvnc, не путать с X11vnc.
Другое дело, что нельзя как в винде, превратить удалённую сессию в локальную, и наоборот. Это реально бесит. Но это особенность графического сервера, а не протокола vnc.

А такое всё ещё используют?

Ну если ПшПшАудио только пыш-пыш делает, то что остается использовать?

Я бы переделал подключение с TCP сокетов на loopback на domain-сокеты. К незапароленному vnc на loopback любая дрянь прилипнуть может, а к грамотно настроенному сокету - только работающая под тем же пользователем, или под рутом.

Ну если ПшПшАудио только пыш-пыш делает, то что остается использовать?

pipewire

Так в VNC есть буфер обмена и так.

Что касается звука, то на практике оказалось удобнее его отдельным потоком слать, чтобы он с графической частью друг другу лаги не создавали.

В Wayland в этом направлении ничего не изменилось?

В wayland на это вообще забили. Унифицированного решения для удалённых сеансов там нет, и не предвидится. Говорят, в gnome сделали rdp с поддержкой сессий, но я не проверял.

См. опрос Какой звуковой сервер вы используете в своей системе повседневно?

P.S. это не feature request. Для проброса звука я использую Jack. VNC в основном не использую.

Да, видал в центре управления, но тоже руки не дошли протестировать.

Штатно? В GNU Linux нет такого понятия)) Это конструктор, ограниченный лишь твоей фантазией.

Самое простое - - - - - - - - - - - -
RDP сервер xrdp и любой RDP клиент. Просто установить пакет xrdp и уже можно подключаться. Это как раз то что тебе нужно. Сеанс в фоне, который не отображается на физическом мониторе узла, к которому ты подключаешься.
Но это нагружает сеть сильнее чем VNC. (по крайне мере у меня)

Именно VNC - - - - - - - - - - - -
TigerVNC сервер. Он запускает X сеанс в фоне, который можно увидеть только удалённо через VNC.
Установи пакет tigervnc-standalone-server и одной командной запусти VNC сервер, сеанс, и какое-нибудь приложение в нём.

vncserver -xstartup /usr/bin/xterm

Или сразу целое графическое окружение

vncserver -xstartup /usr/bin/startxfce4

Оно ответит номер дисплея и порта, куда подключаться по VNC.
New Xtigervnc server 'iv-pilysos:1 (ivanet)' on port 5901 for display :1.
А когда закончишь выполни выход из системы, если в грфическом окружении есть такая кнопка, или принудительно закрой сенс.

vncserver -kill :1

Я когда-то использовал этот вариант, но у меня в xfce4 постоянно были проблемы с переключением раскладки клавиатуры. По этому я придумал следующий способ.

VNC вручную - - - - - - - - - - - -
Тот же x11vnc и создание фонового сеанса X11.
Создай сеанс X11 в фоне, пускай номер дисплея будет :99, один виртуальный монитор с номером 0, разрешением 1280x720 и глубиной цветности 24.

Xvfb :99 -screen 0 1280x720x24 &

Теперь задай номер нового дисплея в переменную $DISPLAY и запускай приложения в фоновой сесси.

export DISPLAY=:99
xfwm4 &
xfce4-terminal &
firefox &

Или сразу целое графическое окружение

startxfce4 &

Чтобы увидеть фоновый сеанс, запусти к нему x11vnc, например вот так, или с другими настройками

x11vnc -xkb -repeat -rfbport 5900 -localhost -nowireframe -nopw -timeout 20 -display :99

И подключись через VNC.
Когда закончишь работать, выполни выход из системы, или заверши процесс Xvfb через pkill или любой диспетчер задач вроде htop.

И кстати во всех 3-х способах, что я описал, графика будет рендериться исключительно процессором. Таковы фоновые сеансы X11.

Штатно - это в протоколе VNC. Штатно - это то, что можно использовать на предприятии, в продакшене, если хотите. Что будет, если ваш фоновый сеанс упадёт по какой-то причине? Есть какой-то процесс, который это отслеживает и корректно поднимет этот сеанс? Что если у меня в этом сеансе будет открыт какой-то важный документ или конфиг и в этот момент этот сеанс упадёт? Понятно, что Linux - конструктор, но есть решения, которые продуманы и учитывают все тонкости.

Это выглядит сложно, но возможно я попробую изучить и приделать в этот скрипт.

Встроенный буфер обмена в VNC плохо работает. Ломает кирилицу, иногда просто не работает. То что я реализовали через SSH и bash логику работает несколько лучше.

Звук и так через отдельное приложение. Через module-tunnel-sink в pipewire или pulseaudio. Это может работать даже когда VNC не запущен.

Я таких не знаю.

Если процесс VNC сервера или клиента упадёт, то это не повлияет на то что открыто в сеансе. Его можно легко перезапустить и продолжить. Можно написать простой скрипт что будет его перезапускать.
А если упадёт xorg - то и приложения в сеансе закроются. Тут лишь изучение логов и устранение причин падения. Точно так же как и с xorg запущенном на физическом мониторе.

То что он глючный я заметил, но мне кажется это баги vnc-клиента/сервера, их там лучше пофиксить. Впрочем, возможно сделать альтернативный канал проще и быстрее чем копаться в багах того софта.

Про звук я имел ввиду не отдельное приложение, а отдельное tcp-соединение до сервера (не то что внутри ssh прокинуто, а отдельный ssh в твоём случае). Впрочем, в твоём случае (module-tunnel-sink стримит сырой поток отсчётов без сжатия, насколько я понял) речи про медленные каналы всё равно не идёт, так что возможно это не важно. Я себе звук сделал через libfdk-aac, сжимая его на одном конце и разжимая на втором (разумеется вся эта логика самостоятельная прога а не модуль pulse).

Другое дело, что нельзя как в винде, превратить удалённую сессию в локальную, и наоборот. Это реально бесит

Очевидный же способ как это накостылить можно. Удалённая сессия легко превращается в локальную если ты подключишься по vnc на локалхост. Хотя всякие opengl и подобное там работать нормально не будут, но для офисных или административных нужд это несущественно.

Это было бы крутым решением в 2000 году. В 2026 такое как-то стыдно с серьезным видом предлагать.

Год тут ни при чём. Это очевидный костыль, о чём я и написал. Но если видеоускорение не требуется - вполне работоспособный.

Я к тому, что есть, например, NX. Там все эти нюансы реализованы штатно. А скрипты, написанные на коленке, это не та история, которую стоит внедрять на предприятии. Вот и вопрос был про штатную реализацию в VNC, не в xRDP.