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.

Сегодня есть WLR_BACKENDS=headless labwc -s wayvnc и прочие для headless-wayland-сессии с vnc, если по каким-то причинам не нравится X

От шрифтов и UI на русском конечно глаза вытекли… В целом за стремление респект, но как заметили выше, есть решения проще, лучше и без костылей :)

Пишите, кто что думает об этой поделке.

Я не думаю о ней совсем: не надо оно мне. :))

Но зато я думаю о тебе, что ты молодец: мне оно ни к чему, а кому-то наверняка сгодится. :)

Большую часть я писал без намерения выкладывать.
Когда решил всё таки выложить, была идея всё на английский перевести, но решил так оставить. Пускай Интернет знает что русские тоже изучают GNU Linux)

Круто! Еще бы USB пробрасывать

Это выглядит сложно

Это не то что несложно, это очень просто.

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

Лучше расскажите как настроить vnc так, чтобы через него нумпад всегда работал как нумпад

А поискать? Не, никак? :))

Вот тут Алиска рассказывает: https://yandex.ru/search/?text=как настроить vnc так%2C чтобы через него нумп...

А зачем? ЭЦП да аппаратные ключи защиты что ли?
Или пробросить клавиатуру, чтобы решить сразу все вопросы с раскладкой?)

Нужно получить одинаковое состояние NumLock на локальном и удалённом узле.
Например на удалённом он сейчас отключён, а на локальном включён. Без VNC отключи на локальном узле, а теперь подключи VNC и включишь сразу на обоих узлах.

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

Например программатор или еще что нибудь. Да вот даже звуковую карту. Причем USB не знаю можно в какую сторону пробрасывать, либо удаленное в локальное, либо наоборот