Запускаем графические приложения на сервере без иксов с удаленным доступом к ним по VNC
https://debian.pro/515
Иногда возникает необходимость запускать графические приложения на сервере. Поднимать иксы из-за этого глупо. Дырка, ресурсы, иксы будут работать медленно на всяких Cyrus на 8 мб. А может и иксы не получится поднять вообще (ну нет нужных устройств в /dev, что поделаешь). С OpenVZ такое часто бывает.
У нас остается вариант использовать ssh -X. Но проброс иксов (кстати, в этом случае не обязательно на сервере иметь запущенным X-сервер) может работать медленно и у нас не получится запустить приложение в фоне (если уж быть совсем занудой, то получится, но с матами и этому будет посвящен отдельный трактат). В общем для запуска браузера на быстром коннекте подойдет, но не более.
Сейчас кто-то задаст вопрос «на кой черт оно тебе надо?». Поясню. Во-первых браузер доступный отовсюду с сохраненными паролями (таскать их на флешке и втыкать в вендовозки, которые могут копировать содержимое — опасно). VPN поднять получится далеко не на всех чужих ПК. Во-вторых — браузер, за сохранность которого мы можем не бояться в открытых сетях. Понятно, что это не для видео, а для банковских интерфейсов или webmoney/ЯД. В-третьих может придти заказчик и сказать «надо и всё тут». Ну а про случаи, когда нужна запущенная в фоне утилита с графической мордой я молчу. Мало ли что там быдлокодеры пишут =) Я же использовал данный способ для запуска Firefox с запущенными iMacros-скриптами на домашнем сервере, чтобы зря не гонять шумный десктоп (да-да, когда то у меня был шумный десктоп. Это сейчас водянка и огромные тихие кулеры на HDD).
Ладно, определились с целями (пусть будет джастфофан). Теперь определимся с реализацией.
У линуксячьего VNC-сервера есть режим эмуляции X-среды. Да, дергаются все библиотеки, но фактического запуска иксов не происходит. Экономятся ресурсы, не нужна видеокарта. А самое главное, что можно спокойно отключиться и с сессией ничего не случится.
Кто-то скажет про то, что медленно или некрасиво. Медленно решается туннелированием через SSH со сжатием. Некрасиво — нам ехать, а не шашечки.
Все действия я буду воспроизводить на OpenVZшной машинке, чтобы уж наверняка.
Поставим нужные пакеты:
root@remote-server:~# aptitude install xvnc4server
Оно спросит кучу зависимостей, что логично. Придется их ставить.
Ещё нам понадобится простенький, но функциональный оконный менеджер. В подобных случаях я использую обычно fluxbox (да и на десктопе его использовал очень долгое время). В нем есть все необходимое. Ещё я запускаю gnome-panel (уж очень удобные апплеты и менюшки), но это опционально.
Поставим fluxbox:
root@remote-server:~# aptitude install fluxbox
Теперь становимся пользователем и всё дальше выполняем от имени пользователя. В данном примере я использую пользователя inky
root@remote-server:~# su inky
Для начала запаролим VNC-сервер:
inky@remote-server:~$ vnc4passwd
Теперь впишем в конфиг vnc-сервера весь софт, который нужно запускать при старте vnc-демона.
inky@remote-server:~$ editor /home/inky/.vnc/xstartup
У меня файл выглядит так:
#/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
#x-window-manager &
fluxbox &
AeroFS &
gnome-panel &
Главное тут то, что нам нужно заменить x-window-manager & на fluxbox & или запуск любого другого оконного менеджера.
Всё готово для запуска. Собственно, запустим:
inky@remote-server:~$ vnc4server -geometry 1350x600
-geometry 1350×600 — разрешение виртуального экрана. Подберите себе сами удобное.
Внимательно ищем строчку вот такого рода:
New ‘remote-server:1 (inky)’ desktop is remote-server:1
Если :1 — то vnc слушает порт 5901, если :2 — то 5902 и так далее. Данная информация будет полезна анальным рабам стивобалмера, и тем, кто дочитает статью до конца (там будет про безопасность). Обычный же VNC клиент в Linux сможет прицепиться к адресу remote-server:1
Чтобы остановить vnc-server правильно используем такую команду:
inky@remote-server:~$ vnc4server -kill :1
Всё. Теперь мы можем цепляться к нашему VNC-серверу и запускать там какие-либо приложения. Если вы выбрали Fluxbox — не поленитесь сменить тему Флюкса на FluxNight — с ней намного комфортнее, чем со стандартной (пкм по столу, styles и там выбираете).
Теперь о безопасности. Понятное дело, что цепляться к VNC напрямую в прослушиваемой wifi-сети не очень хорошая идея. Мы обернем наш VNC в ssh туннель.
Закроем все соединения к VNC, кроме локальных (все команды дальше исходят из того, что vnc-server стартовал на :1):
root@remote-host:~# iptables -I INPUT -p tcp --dport 5901 ! -i lo -j DROP
root@remote-host:~# iptables -I INPUT -p tcp --dport 6001 ! -i lo -j DROP
Теперь никто не сможет подцепиться к нашему VNC снаружи.
Мы же пробросим себе порт VNC-сервера на локальную машину (выполняем уже на лаптопе):
user@laptop:~$ ssh -L 5910:127.0.0.1:5901 user@remote-server
Теперь мы можем VNC клиентами цепляться к localhost:5910 и localhost:10
Виндузятники могут пробросить порты в Putty или использовать openssh-клиент (у него такой же синтаксис как и в нормальных ОС).
В общем-то всё. Мы получили шифрование и сжатие VNC-трафика. Ну а то, про что было написано в начале статьи мы получили уже давно.
В ходе следования выполнения инструкций из статьи на сервере стало занято на 20 мегабайт больше памяти и на 100 метров больше дисково пространства, что более чем отлично. На VNC запустилось без особых вопросов. По скорости — на сервере в хетзнере из москвы я смог с ветерком полазить по gmail, убить ноутбук не хотелось.
Удачного использования и не светите свои данные в открытой сети ;)
P.S. — из VNC-клиентов крайне советую использовать Remmina — действительно клевая вещь. Она умеет целиком пробрасывать клавиатуру в VNC, вместе со всякими alt-f2 и c-a-del.
Иногда возникает необходимость запускать графические приложения на сервере. Поднимать иксы из-за этого глупо. Дырка, ресурсы, иксы будут работать медленно на всяких Cyrus на 8 мб. А может и иксы не получится поднять вообще (ну нет нужных устройств в /dev, что поделаешь). С OpenVZ такое часто бывает.
У нас остается вариант использовать ssh -X. Но проброс иксов (кстати, в этом случае не обязательно на сервере иметь запущенным X-сервер) может работать медленно и у нас не получится запустить приложение в фоне (если уж быть совсем занудой, то получится, но с матами и этому будет посвящен отдельный трактат). В общем для запуска браузера на быстром коннекте подойдет, но не более.
Сейчас кто-то задаст вопрос «на кой черт оно тебе надо?». Поясню. Во-первых браузер доступный отовсюду с сохраненными паролями (таскать их на флешке и втыкать в вендовозки, которые могут копировать содержимое — опасно). VPN поднять получится далеко не на всех чужих ПК. Во-вторых — браузер, за сохранность которого мы можем не бояться в открытых сетях. Понятно, что это не для видео, а для банковских интерфейсов или webmoney/ЯД. В-третьих может придти заказчик и сказать «надо и всё тут». Ну а про случаи, когда нужна запущенная в фоне утилита с графической мордой я молчу. Мало ли что там быдлокодеры пишут =) Я же использовал данный способ для запуска Firefox с запущенными iMacros-скриптами на домашнем сервере, чтобы зря не гонять шумный десктоп (да-да, когда то у меня был шумный десктоп. Это сейчас водянка и огромные тихие кулеры на HDD).
Ладно, определились с целями (пусть будет джастфофан). Теперь определимся с реализацией.
У линуксячьего VNC-сервера есть режим эмуляции X-среды. Да, дергаются все библиотеки, но фактического запуска иксов не происходит. Экономятся ресурсы, не нужна видеокарта. А самое главное, что можно спокойно отключиться и с сессией ничего не случится.
Кто-то скажет про то, что медленно или некрасиво. Медленно решается туннелированием через SSH со сжатием. Некрасиво — нам ехать, а не шашечки.
Все действия я буду воспроизводить на OpenVZшной машинке, чтобы уж наверняка.
Поставим нужные пакеты:
root@remote-server:~# aptitude install xvnc4server
Оно спросит кучу зависимостей, что логично. Придется их ставить.
Ещё нам понадобится простенький, но функциональный оконный менеджер. В подобных случаях я использую обычно fluxbox (да и на десктопе его использовал очень долгое время). В нем есть все необходимое. Ещё я запускаю gnome-panel (уж очень удобные апплеты и менюшки), но это опционально.
Поставим fluxbox:
root@remote-server:~# aptitude install fluxbox
Теперь становимся пользователем и всё дальше выполняем от имени пользователя. В данном примере я использую пользователя inky
root@remote-server:~# su inky
Для начала запаролим VNC-сервер:
inky@remote-server:~$ vnc4passwd
Теперь впишем в конфиг vnc-сервера весь софт, который нужно запускать при старте vnc-демона.
inky@remote-server:~$ editor /home/inky/.vnc/xstartup
У меня файл выглядит так:
#/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
#x-window-manager &
fluxbox &
AeroFS &
gnome-panel &
Главное тут то, что нам нужно заменить x-window-manager & на fluxbox & или запуск любого другого оконного менеджера.
Всё готово для запуска. Собственно, запустим:
inky@remote-server:~$ vnc4server -geometry 1350x600
-geometry 1350×600 — разрешение виртуального экрана. Подберите себе сами удобное.
Внимательно ищем строчку вот такого рода:
New ‘remote-server:1 (inky)’ desktop is remote-server:1
Если :1 — то vnc слушает порт 5901, если :2 — то 5902 и так далее. Данная информация будет полезна анальным рабам стивобалмера, и тем, кто дочитает статью до конца (там будет про безопасность). Обычный же VNC клиент в Linux сможет прицепиться к адресу remote-server:1
Чтобы остановить vnc-server правильно используем такую команду:
inky@remote-server:~$ vnc4server -kill :1
Всё. Теперь мы можем цепляться к нашему VNC-серверу и запускать там какие-либо приложения. Если вы выбрали Fluxbox — не поленитесь сменить тему Флюкса на FluxNight — с ней намного комфортнее, чем со стандартной (пкм по столу, styles и там выбираете).
Теперь о безопасности. Понятное дело, что цепляться к VNC напрямую в прослушиваемой wifi-сети не очень хорошая идея. Мы обернем наш VNC в ssh туннель.
Закроем все соединения к VNC, кроме локальных (все команды дальше исходят из того, что vnc-server стартовал на :1):
root@remote-host:~# iptables -I INPUT -p tcp --dport 5901 ! -i lo -j DROP
root@remote-host:~# iptables -I INPUT -p tcp --dport 6001 ! -i lo -j DROP
Теперь никто не сможет подцепиться к нашему VNC снаружи.
Мы же пробросим себе порт VNC-сервера на локальную машину (выполняем уже на лаптопе):
user@laptop:~$ ssh -L 5910:127.0.0.1:5901 user@remote-server
Теперь мы можем VNC клиентами цепляться к localhost:5910 и localhost:10
Виндузятники могут пробросить порты в Putty или использовать openssh-клиент (у него такой же синтаксис как и в нормальных ОС).
В общем-то всё. Мы получили шифрование и сжатие VNC-трафика. Ну а то, про что было написано в начале статьи мы получили уже давно.
В ходе следования выполнения инструкций из статьи на сервере стало занято на 20 мегабайт больше памяти и на 100 метров больше дисково пространства, что более чем отлично. На VNC запустилось без особых вопросов. По скорости — на сервере в хетзнере из москвы я смог с ветерком полазить по gmail, убить ноутбук не хотелось.
Удачного использования и не светите свои данные в открытой сети ;)
P.S. — из VNC-клиентов крайне советую использовать Remmina — действительно клевая вещь. Она умеет целиком пробрасывать клавиатуру в VNC, вместе со всякими alt-f2 и c-a-del.