На днях упоминал про систему организации виртуальных рабочих мест Termidesk. Сегодня расскажу о ней подробнее. Это российское программное обеспечение, включённое в реестр отечественного ПО. С его помощью реализуется функционал диспетчера удалённых подключений к виртуальным машинам под управлением операционных систем Linux и Windows.
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
В комментариях в заметке про VDI со мной поделились классным софтом - PVE-VDIClient. Это простой клиент на Python, с помощью которого можно напрямую подключаться к виртуальным машинам PVE по протоколу SPICE. Не нужен никакой дополнительный софт, типа RDP или VNC. Вы напрямую подключаетесь к консоли виртуальной машины.
Для чего это может понадобиться? Например, у вас есть Raspberry Pi и вы хотите сделать тонкий клиент для работы в ОС Windows с пробросом микрофона, камеры и звука. Вот подробное видео реализации:
⇨ https://www.youtube.com/watch?v=TuDrmq4RQzU
Я вчера потратил несколько часов, пока не разобрался полностью как это работает. В итоге запустил PVE-VDIClient на Windows 10 и 11. Рассказываю по шагам, что нужно сделать.
1️⃣ Добавляем в PVE новых пользователей и отдельную группу для них. Назначаем этой группе права доступа: VM.PowerMgmt, VM.Console, VM.Audit. Можно на конкретные виртуальные машины или на все сразу.
2️⃣ Виртуальным машинам, к которым будем подключаться по SPICE, в настройках указываем Display: SPICE и добавляем ещё один USB Device: Spice Port.
3️⃣ На ОС Windows, с которой будем подключаться, устанавливаем Python 3.10. Я установил через Microsoft Store. Далее идём в репозиторий, скачиваем файл requirements.bat и запускаем его. Либо просто вручную установите pip пакеты, которые там указаны.
4️⃣ Далее скачиваем virt-viewer под Windows и устанавливаем. После этого идём в releases и скачиваем последнюю версию PVE VDI client, устанавливаем.
5️⃣ В директорию C:\Program Files\VDIClient кладём файл vdiclient.ini, образец которого есть в репозитории под именем vdiclient.ini.example (example удаляем). Тут важно сделать несколько настроек, без которых у меня ничего не работало.
В разделе [Hosts] пишем адрес своего гипервизора и его порт 8006:
В разделе [SpiceProxyRedirect] редактируем параметр:
prox.zeroxzed.ru - имя хоста, которое можно посмотреть в веб интерфейсе, в разделе System ⇨ Hosts. В инструкции нигде не указано, что нужно это сделать, а дефолтная запись выглядит вот так:
Попробуй тут догадайся, что надо написать.
В разделе [Authentication] есть параметр auth_backend. По умолчанию он имеет значение:
Если поменять его на
Сможете подключаться дефолтной учёткой root, под которой заходите в веб интерфейс. Если это ваш тестовый гипервзиор, то логичнее поступить именно так и не создавать отдельных пользователей.
6️⃣ Теперь можно запускать VDI клиент, подключаться к гипервизору под созданной учётной записью и запускать виртуальную машину. Для увеличения быстродействия и лучшей работы с видео, в гостевые ОС рекомендуется установить SPICE guest tools. Но и без них всё будет работать.
Получилась готовая инструкция, которой в сети нет. Так что если вам интересна эта тема, сохраните к себе. Мне лично очень понравилось. Работать с виртуальными машинами так гораздо удобнее, чем по SSH или RDP. Можно спокойно добавить к машине несколько мониторов и переключаться между ними. В видео, которое я показал выше, автор демонстрирует такую возможность.
Полезные ссылки, которые пригодились в процессе настройки:
Исходники - https://github.com/joshpatten/PVE-VDIClient
Virt-manager - https://virt-manager.org/download/
Spice-guest-tools - https://www.spice-space.org/download.html
PVE SPICE - https://pve.proxmox.com/wiki/SPICE
Raspberry Pi THIN CLIENT for Proxmox VMs -
https://www.youtube.com/watch?v=TuDrmq4RQzU
#vdi #proxmox #виртуализация
Для чего это может понадобиться? Например, у вас есть Raspberry Pi и вы хотите сделать тонкий клиент для работы в ОС Windows с пробросом микрофона, камеры и звука. Вот подробное видео реализации:
⇨ https://www.youtube.com/watch?v=TuDrmq4RQzU
Я вчера потратил несколько часов, пока не разобрался полностью как это работает. В итоге запустил PVE-VDIClient на Windows 10 и 11. Рассказываю по шагам, что нужно сделать.
1️⃣ Добавляем в PVE новых пользователей и отдельную группу для них. Назначаем этой группе права доступа: VM.PowerMgmt, VM.Console, VM.Audit. Можно на конкретные виртуальные машины или на все сразу.
2️⃣ Виртуальным машинам, к которым будем подключаться по SPICE, в настройках указываем Display: SPICE и добавляем ещё один USB Device: Spice Port.
3️⃣ На ОС Windows, с которой будем подключаться, устанавливаем Python 3.10. Я установил через Microsoft Store. Далее идём в репозиторий, скачиваем файл requirements.bat и запускаем его. Либо просто вручную установите pip пакеты, которые там указаны.
4️⃣ Далее скачиваем virt-viewer под Windows и устанавливаем. После этого идём в releases и скачиваем последнюю версию PVE VDI client, устанавливаем.
5️⃣ В директорию C:\Program Files\VDIClient кладём файл vdiclient.ini, образец которого есть в репозитории под именем vdiclient.ini.example (example удаляем). Тут важно сделать несколько настроек, без которых у меня ничего не работало.
В разделе [Hosts] пишем адрес своего гипервизора и его порт 8006:
10.20.1.2 = 8006В разделе [SpiceProxyRedirect] редактируем параметр:
prox.zeroxzed.ru:3128 = 10.20.1.2:3128prox.zeroxzed.ru - имя хоста, которое можно посмотреть в веб интерфейсе, в разделе System ⇨ Hosts. В инструкции нигде не указано, что нужно это сделать, а дефолтная запись выглядит вот так:
pve1.example.com:3128 = 123.123.123.123:6000Попробуй тут догадайся, что надо написать.
В разделе [Authentication] есть параметр auth_backend. По умолчанию он имеет значение:
auth_backend = pveЕсли поменять его на
auth_backend = pamСможете подключаться дефолтной учёткой root, под которой заходите в веб интерфейс. Если это ваш тестовый гипервзиор, то логичнее поступить именно так и не создавать отдельных пользователей.
6️⃣ Теперь можно запускать VDI клиент, подключаться к гипервизору под созданной учётной записью и запускать виртуальную машину. Для увеличения быстродействия и лучшей работы с видео, в гостевые ОС рекомендуется установить SPICE guest tools. Но и без них всё будет работать.
Получилась готовая инструкция, которой в сети нет. Так что если вам интересна эта тема, сохраните к себе. Мне лично очень понравилось. Работать с виртуальными машинами так гораздо удобнее, чем по SSH или RDP. Можно спокойно добавить к машине несколько мониторов и переключаться между ними. В видео, которое я показал выше, автор демонстрирует такую возможность.
Полезные ссылки, которые пригодились в процессе настройки:
Исходники - https://github.com/joshpatten/PVE-VDIClient
Virt-manager - https://virt-manager.org/download/
Spice-guest-tools - https://www.spice-space.org/download.html
PVE SPICE - https://pve.proxmox.com/wiki/SPICE
Raspberry Pi THIN CLIENT for Proxmox VMs -
https://www.youtube.com/watch?v=TuDrmq4RQzU
#vdi #proxmox #виртуализация
Последние заметки про VDI (Virtual Desktop Infrastructure,) породили много вопросов в комментариях на тему того, зачем всё это нужно, если есть протокол RDP для удалённой работы. Во-первых, системы VDI не противопоставляют себя каким-то другим доступам. Более того, они чаще всего включают в себя поддержку и RDP соединений и многих других (VNC, SPICE). Во-вторых, если и сравнивать VDI, то с Remote Desktop Services (RDS) в составе Windows Server.
Например, есть бесплатное решение OpenUDS для организации VDI. Вот его основные возможности:
◽ Поддержка open source платформ виртуализации: oVirt, OpenNebula, Open Stack, XCP-ng, Proxmox, а также платных: Citrix Hypervisor, Microsoft Hyper-V, Nutanix Acropolis, VMware.
◽ Поддержка протоколов доставки рабочего стола: RDP (в том числе через HTML5), X2Go, SPICE (только для QEMU).
◽ Поддержка аутентификации: LDAP (в том числе MS AD), IP/mac-адреса, внутренняя БД, Radius.
◽ Клиенты Linux и Windows для подключений.
Как это выглядит на практике. Вы берёте гипервизоры Proxmox, можно кластер. Настраиваете OpenUDS и подключаете через провайдера гипервизоры к системе. Настраиваете ту или иную аутентификацию пользователей, создаёте их. Готовите шаблоны операционных систем. Настраиваете поведение тех или иных систем. Например, при отключении пользователя система может уничтожаться, а при подключении разворачиваться заново из шаблона. Либо сделать постоянные рабочие места с сохранением состояния.
Далее создаёте транспорт в виде различных протоколов доступа к системам и связываете из с пользователями. Кто-то будет подключаться по RDP, кто-то по X2Go, кто-то по SPICE. Пользователю на компьютер устанавливается openuds-client, с помощью которого он подключается к системам, к которым имеет доступ. Это объяснение на пальцах, как принципе всё работает.
❓Зачем может пригодиться подключение по SPICE, если есть RDP? Во первых, SPICE работает на уровне гипервизора. У вас всегда будет доступ к VM. В теории SPICE умеет работать с видеокартами на хосте, он умеет адекватно обрабатывать видео, прокидывать видеокамеру, микрофон. С его помощью можно организовать полноценное удалённое рабочее место того же дизайнера или проектировщика. Это в теории, на практике там наверняка много нюансов и надо разбираться. Скорее всего не всё и не везде поддерживается. Разработчики Termidesk рассказывали, что они дорабатывали SPICE самостоятельно, чтобы он нормально работал c видеокартами и жал видеопоток от камеры. По умолчанию он этого не делает, поэтому нужен широкий канал для нормальной картинки.
Очень подробное описание и настройка OpenUDS:
⇨ https://www.altlinux.org/VDI/OpenUDS
Я изучил инструкцию. На вид всё довольно просто и логично настраивается. В основном через веб интерфейс. Есть возможность поднять HA кластер:
⇨ https://www.altlinux.org/OpenUDS_HA
Хочу отметить, что у команды altlinux очень хорошие подробные руководства, по которым зачастую копипастом можно настроить.
Для бесплатного продукта очень приличный функционал. Первое, что приходит в голову, где это точно пригодится, даже если нет больших масштабов - учебные классы. Понятно, что обычных офисных сотрудников проще на RDS посадить, но не забываем, что это стоит приличных денег, если мы работаем в белую.
#vdi #виртуализация
Например, есть бесплатное решение OpenUDS для организации VDI. Вот его основные возможности:
◽ Поддержка open source платформ виртуализации: oVirt, OpenNebula, Open Stack, XCP-ng, Proxmox, а также платных: Citrix Hypervisor, Microsoft Hyper-V, Nutanix Acropolis, VMware.
◽ Поддержка протоколов доставки рабочего стола: RDP (в том числе через HTML5), X2Go, SPICE (только для QEMU).
◽ Поддержка аутентификации: LDAP (в том числе MS AD), IP/mac-адреса, внутренняя БД, Radius.
◽ Клиенты Linux и Windows для подключений.
Как это выглядит на практике. Вы берёте гипервизоры Proxmox, можно кластер. Настраиваете OpenUDS и подключаете через провайдера гипервизоры к системе. Настраиваете ту или иную аутентификацию пользователей, создаёте их. Готовите шаблоны операционных систем. Настраиваете поведение тех или иных систем. Например, при отключении пользователя система может уничтожаться, а при подключении разворачиваться заново из шаблона. Либо сделать постоянные рабочие места с сохранением состояния.
Далее создаёте транспорт в виде различных протоколов доступа к системам и связываете из с пользователями. Кто-то будет подключаться по RDP, кто-то по X2Go, кто-то по SPICE. Пользователю на компьютер устанавливается openuds-client, с помощью которого он подключается к системам, к которым имеет доступ. Это объяснение на пальцах, как принципе всё работает.
❓Зачем может пригодиться подключение по SPICE, если есть RDP? Во первых, SPICE работает на уровне гипервизора. У вас всегда будет доступ к VM. В теории SPICE умеет работать с видеокартами на хосте, он умеет адекватно обрабатывать видео, прокидывать видеокамеру, микрофон. С его помощью можно организовать полноценное удалённое рабочее место того же дизайнера или проектировщика. Это в теории, на практике там наверняка много нюансов и надо разбираться. Скорее всего не всё и не везде поддерживается. Разработчики Termidesk рассказывали, что они дорабатывали SPICE самостоятельно, чтобы он нормально работал c видеокартами и жал видеопоток от камеры. По умолчанию он этого не делает, поэтому нужен широкий канал для нормальной картинки.
Очень подробное описание и настройка OpenUDS:
⇨ https://www.altlinux.org/VDI/OpenUDS
Я изучил инструкцию. На вид всё довольно просто и логично настраивается. В основном через веб интерфейс. Есть возможность поднять HA кластер:
⇨ https://www.altlinux.org/OpenUDS_HA
Хочу отметить, что у команды altlinux очень хорошие подробные руководства, по которым зачастую копипастом можно настроить.
Для бесплатного продукта очень приличный функционал. Первое, что приходит в голову, где это точно пригодится, даже если нет больших масштабов - учебные классы. Понятно, что обычных офисных сотрудников проще на RDS посадить, но не забываем, что это стоит приличных денег, если мы работаем в белую.
#vdi #виртуализация
Подписчик поделился информацией об одном любопытном проекте по созданию инфраструктуры рабочих мест на базе Kubernetes, где рабочие места поднимаются в подах. По сути это получается open source аналог Citrix Workspace. Разумеется, с большой натяжкой, так как это всего лишь небольшой бесплатный проект с открытым исходным кодом.
Речь идёт об webmesh-vdi. Основные возможности этой системы:
◽Запуск операционных систем в подах Kubernetes. Соответственно, поддерживается только то, что работает в контейнерах на Linux хосте.
◽Доступ к системам через браузер с поддержкой микрофонов и звуков, передачей файлов.
◽Поддержка MFA через zitadel.
◽Локальная аутентификация пользователей, через LDAP или OpenID.
◽Helm чарт, чтобы всё это быстро развернуть.
Запустить всё это хозяйство можно в существующем кластере Kubernetes через готовый helm chart. Если у вас его нет, а попробовать хочется, то можно запустить на k3s, развёрнутым локально как standalone kubernetes на базе одной ноды. Для этого нужна любая система с установленным docker и пакетом dialog:
Можно ничего не настраивать, а оставить по умолчанию. После установки можно сразу скачать шаблоны ОС:
Установятся 3 шаблона:
▪️ ubuntu-xfce
▪️ ubuntu-kde
▪️ dosbox
На базе этих шаблонов можно создавать рабочие места. Делается это через веб интерфейс, учётка админа была показана в конце установки.
После запуска рабочего места, можно посмотреть, где и как оно запущено. Смотрим список подов кубера:
Все компоненты webmesh-vdi запущены в подах, в том числе и рабочее место на базе ubuntu-kde, которое я создал из шаблона.
Интересный проект. Мне понравился своей относительной простотой и реализацией. Ниже список других упоминаемых мной проектов, на базе которых можно построить инфраструктуру vdi:
- Ravada VDI
- OpenUDS
- PVE-VDIClient
- Termidesk
Если кому любопытно, моё отношение к Kubernetes. А если вы никогда не работали с Кубером, но хотите погонять этот проект, то вот моя статья с базовым описанием команд и в целом по работе с кластером Kubernetes. Этой информации хватит, чтобы хоть немного ориентироваться в том, что там происходит.
#vdi #kuber
Речь идёт об webmesh-vdi. Основные возможности этой системы:
◽Запуск операционных систем в подах Kubernetes. Соответственно, поддерживается только то, что работает в контейнерах на Linux хосте.
◽Доступ к системам через браузер с поддержкой микрофонов и звуков, передачей файлов.
◽Поддержка MFA через zitadel.
◽Локальная аутентификация пользователей, через LDAP или OpenID.
◽Helm чарт, чтобы всё это быстро развернуть.
Запустить всё это хозяйство можно в существующем кластере Kubernetes через готовый helm chart. Если у вас его нет, а попробовать хочется, то можно запустить на k3s, развёрнутым локально как standalone kubernetes на базе одной ноды. Для этого нужна любая система с установленным docker и пакетом dialog:
# curl https://get.docker.com | bash -# apt install dialog# curl -JLO https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/architect/kvdi-architect.sh# bash kvdi-architect.shМожно ничего не настраивать, а оставить по умолчанию. После установки можно сразу скачать шаблоны ОС:
# k3s kubectl apply -f https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/examples/example-desktop-templates.yamlУстановятся 3 шаблона:
▪️ ubuntu-xfce
▪️ ubuntu-kde
▪️ dosbox
На базе этих шаблонов можно создавать рабочие места. Делается это через веб интерфейс, учётка админа была показана в конце установки.
После запуска рабочего места, можно посмотреть, где и как оно запущено. Смотрим список подов кубера:
# kubectl get podNAME READY STATUSprometheus-operator-8545786465-zdt97 1/1 Runningkvdi-manager-57d84fcd49-pbc6l 2/2 Runningkvdi-app-df5c78cc7-kdfrt 2/2 Runningprometheus-kvdi-prometheus-0 3/3 Runningubuntu-kde-qqjmc 2/2 RunningВсе компоненты webmesh-vdi запущены в подах, в том числе и рабочее место на базе ubuntu-kde, которое я создал из шаблона.
Интересный проект. Мне понравился своей относительной простотой и реализацией. Ниже список других упоминаемых мной проектов, на базе которых можно построить инфраструктуру vdi:
- Ravada VDI
- OpenUDS
- PVE-VDIClient
- Termidesk
Если кому любопытно, моё отношение к Kubernetes. А если вы никогда не работали с Кубером, но хотите погонять этот проект, то вот моя статья с базовым описанием команд и в целом по работе с кластером Kubernetes. Этой информации хватит, чтобы хоть немного ориентироваться в том, что там происходит.
#vdi #kuber
В продолжение утренней темы про удалённые рабочие места. Есть интересный проект n.eko по запуску различных браузеров в Docker контейнере с доступом к нему по протоколу WebRTC.
На практике это может выглядеть так. Вы арендуете где-то VPS, ставите туда Docker и запускаете необходимый вам браузер из готового образа neko. Далее со своего рабочего места в браузере открываете этот браузер. Благодаря возможностям WebRTC всё работает быстро в том числе с передачей звука и видео. Спокойно можно смотреть ютуб или любое другое видео.
В дополнение к такому использованию, вы можете подключать к своему браузеру зрителей с возможностью смотреть, что вы там делаете. В таком режиме можно даже фильмы совместно просматривать. Есть отдельный образ с VLC плеером.
Работает это максимально просто и быстро. Создаём compose.yaml с нужным браузером:
И запускаем:
В данном примере
После того, как загрузится и запустится образ, можно идти по ip адресу сервера на порт 8080 и логиниться в neko.
Когда залогинитесь, снизу будет иконка клавиатуры и ползунок. Иконку надо нажать, ползунок подвинуть, чтобы заработало управление внутри контейнера. Справа вверху будут настройки разрешения экрана и некоторые другие. Рекомендую сразу снизить чувствительность скрола мышки. У меня он по умолчанию был очень чувствительный. Было некомфортно пользоваться, пока не нашёл эту настройку.
Neko можно запустить по HTTPS или через обратный прокси. В документации есть примеры настроек для этого. Для прокси удобно использовать упомянутый ранее Traefik. Для него тоже пример конфигурации представлен.
Вот, в общем-то, и всё. Можно пользоваться. С переключением раскладки проблем нет, русский ввод работает. Список готовых образов с браузерами и не только представлен в документации. Можно и обычную систему запустить с xfce, или собрать собственный образ. Есть образы под arm, отдельно с поддержкой видеокарт.
Образы регулярно автоматически обновляются, так что браузеры там свежих версий. Получается хорошее решение для гарантированной изоляции, если хочется запустить в браузере что-то сомнительное. Или просто использовать отдельный браузер с необходимыми настройками и локацией.
Подключаться к такому браузеру можно с мобильных клиентов. Интерфейс адаптирован под разрешения экранов смартфонов.
Отдельно есть проект по управлению виртуальными комнатами с запущенными браeзерами neko - neko-rooms.
⇨ Сайт / Исходники / Neko-rooms
#vdi
На практике это может выглядеть так. Вы арендуете где-то VPS, ставите туда Docker и запускаете необходимый вам браузер из готового образа neko. Далее со своего рабочего места в браузере открываете этот браузер. Благодаря возможностям WebRTC всё работает быстро в том числе с передачей звука и видео. Спокойно можно смотреть ютуб или любое другое видео.
В дополнение к такому использованию, вы можете подключать к своему браузеру зрителей с возможностью смотреть, что вы там делаете. В таком режиме можно даже фильмы совместно просматривать. Есть отдельный образ с VLC плеером.
Работает это максимально просто и быстро. Создаём compose.yaml с нужным браузером:
services:
neko:
image: m1k1o/neko:google-chrome
restart: unless-stopped
shm_size: 3gb
ports:
- 8080:8080
- 52000-52100:52000-52100/udp
cap_add:
- SYS_ADMIN
environment:
NEKO_SCREEN: 1920x1080@30
NEKO_PASSWORD: neko
NEKO_PASSWORD_ADMIN: admin
NEKO_EPR: 52000-52100
NEKO_NAT1TO1: 10.20.1.36
И запускаем:
# docker compose up -dВ данном примере
NEKO_NAT1TO1: 10.20.1.36 - адрес сервера в локальной сети, где я запускаю neko. Если это будет VPS с внешним ip адресом, ничего указывать не надо. Адрес будет определён автоматически. После того, как загрузится и запустится образ, можно идти по ip адресу сервера на порт 8080 и логиниться в neko.
NEKO_PASSWORD: neko - пароль для пользователей, которые смогут только смотреть.NEKO_PASSWORD_ADMIN: admin - пароль для пользователя admin. То есть заходить админом вам надо будет с учёткой admin / admin.Когда залогинитесь, снизу будет иконка клавиатуры и ползунок. Иконку надо нажать, ползунок подвинуть, чтобы заработало управление внутри контейнера. Справа вверху будут настройки разрешения экрана и некоторые другие. Рекомендую сразу снизить чувствительность скрола мышки. У меня он по умолчанию был очень чувствительный. Было некомфортно пользоваться, пока не нашёл эту настройку.
Neko можно запустить по HTTPS или через обратный прокси. В документации есть примеры настроек для этого. Для прокси удобно использовать упомянутый ранее Traefik. Для него тоже пример конфигурации представлен.
Вот, в общем-то, и всё. Можно пользоваться. С переключением раскладки проблем нет, русский ввод работает. Список готовых образов с браузерами и не только представлен в документации. Можно и обычную систему запустить с xfce, или собрать собственный образ. Есть образы под arm, отдельно с поддержкой видеокарт.
Образы регулярно автоматически обновляются, так что браузеры там свежих версий. Получается хорошее решение для гарантированной изоляции, если хочется запустить в браузере что-то сомнительное. Или просто использовать отдельный браузер с необходимыми настройками и локацией.
Подключаться к такому браузеру можно с мобильных клиентов. Интерфейс адаптирован под разрешения экранов смартфонов.
Отдельно есть проект по управлению виртуальными комнатами с запущенными браeзерами neko - neko-rooms.
⇨ Сайт / Исходники / Neko-rooms
#vdi