В большинстве проектов Raspberry Pi используется не в качестве полноценного настольного ПК, а в качестве сетевого мини-компьютера или устройства для управления различной электроникой (веб-камеры, wi-fi модули, 3G-модемы, системы "умный дом" и пр.). Например, я в будущем планирую использовать его как веб-сервер, взаимодействующий с моим USB-устройством. Для подобной работы Raspberry Pi не требуется ни монитор, ни клавиатура. А подключать их каждый раз для программирования и настройки неудобно и хлопотно. Гораздо удобнее использовать для этих целей монитор и клавиатуру основного компьютера и работать с Raspberry Pi по локальной сети. Такое взаимодействие двух компьютеров реализуется с помощью специального сетевого протокола SSH.
Итак, наша цель - получить возможность полноценной работы с Raspberry Pi через локальную сеть, причем так, как будто мы работаем непосредственно с самим мини-компьютером. Под катом - как управлять Raspberry Pi через SSH в Linux.
Исходное состояние
К Raspberry Pi подключено всего два провода: сетевой кабель, соединяющий его с роутером, и шнур питания:
На Raspberry Pi включен SSH, номер порта SSH оставлен по умолчанию (22), автоматическая загрузка графической оболочки отключена. Имя пользователя и пароль также оставлены по-умолчанию (pi / raspberry). В локальной сети Raspberry Pi получил ip-адрес 192.168.1.35 (в настройках роутера я закрепил этот адрес за Raspberry, чтобы он впоследствии не изменился).
Что хотим?
Используя главный компьютер, подключенный к локальной сети, хотим удаленно работать с Raspberry Pi. Причем работа с Raspberry по сети должна быть такой же, как и при непосредственном подключении к нему монитора и клавиатуры. Такое взаимодействие двух компьютеров реализуется с помощью протокола SSH. В Linux удаленно взаимодействовать с Raspberry Pi можно тремя способами:
1. Работать с консолью Raspberry по сети;
2. Удаленно запускать отдельные графические приложения так, чтобы работали они на Raspberry, а окно программы отображалось на мониторе главного ПК;
3. Удаленно работать со всей графической оболочкой Raspbian по принципу удаленного рабочего стола. В этом случае монитор, клавиатура и мышь главного компьютера становятся монитором, клавиатурой и мышью Raspberry Pi.
1. Работа с консолью Raspberry Pi через SSH в Linux
Допустим, мы не желаем работать с графической оболочкой Raspbian и хотим просто получить доступ к консоли Raspberry Pi. В Linux (во всяком случае в дистрибутивах, основанных на Ubuntu) это делается очень просто - на главном компьютере открываем терминал и набираем всего одну команду:
ssh pi@192.168.1.35
Примечание: в случае запроса аутентификации ответить yes.
Этой командой мы устанавливаем связь по протоколу SSH с удаленным компьютером 192.168.1.35 и представляемся ему пользователем pi. После ввода пароля этого пользователя мы сразу получим доступ к консоли Raspberry, о чем будет свидетельствовать приветствие в командной строке:
С этого момента все, что мы видим и набираем в терминале равносильно тому, что мы набирали бы на клавиатуре, подключенной непосредственно к Raspberry.
2. Запуск графических приложений Raspberry Pi через SSH в Linux
Чтобы предлагаемые ниже решения были понятны, приведу сперва небольшое теоретическое отступление.
В отличие от Windows, графический интерфейс в Linux основан на оконной системе X Window System (она же "иксы"). В двух словах ее "фишка" в том, что она имеет клиент-серверную архитектуру и позволяет выводить графический интерфейс не только локально работающих программ-клиентов, но и удаленных программ, работающих на других компьютерах. Именно эта особенность X Widnow позволяет программам в Linux выполняться на одном компьютере, а выводить графику - на другом (что нам и нужно). В случае с Raspberry Pi работа будет построена следующим образом:
На главном компьютере с ОС Linux (например, Ubuntu или Linux Mint) уже работает X-сервер, занимающийся графическим интерфейсом всех запущенных программ (клиентов). Устанавливая SSH-соединение, Raspbian нужно сказать, чтобы в качестве X-сервера для отображения графики она использовала не свой сервер, а удаленный X-сервер главного ПК. Для этого в терминале главного компьютера набираем:
ssh -X pi@192.168.1.35
Ключ X заставляет перенаправлять данные графического интерфейса от Raspberry (192.168.1.35) на главный ПК через SSH-соединение (т. н. X-Forwarding).
После установки соединения, как и в предыдущем разделе, мы получаем доступ к консоли Raspberry Pi, но теперь в случае запуска любого графического приложения Raspberry (например, файлового менеджера "pcmanfm"), его окно появится прямо на нашем рабочем столе.
Удобно.
3. Работа с графической средой Raspbian через SSH в Linux
Благодаря клиент-серверной архитектуре X Window System, в Linux-системах организовать "трансляцию" рабочего стола Rasperry Pi на другой компьютер наиболее просто и изящно. В этом разделе речь пойдет о том, как именно это лучше сделать и почему.
Существующие решения
Сперва хотелось бы сказать пару слов о разных способах подключения к рабочему столу Raspberry, которые часто попадаются в Интернете, и которые я считаю не оптимальными.
а) Использование VNC для управления удаленным рабочим столом
VNC - это кроссплатформенная система для графического управления удаленными рабочими столами. В интернете полно инструкций, как с помощью нее управлять рабочим столом Raspbian: для этого нужно установить на Raspberry VNC-сервер, на главный компьютер VNC-клиент или вьювер, правильно их настроить и т.д. Инструкции по настройке при этом могут представлять собой длинные простыни.
Если для Windows такой способ может быть как-то полезен, то для Linux-системы и Raspberry смысла в нем я не вижу вообще. Зачем на оба компьютера ставить дополнительное ПО, если в самой концепции Linux "из коробки" уже заложена возможность трансляции графики на удаленный ПК? Поэтому отметаем этот способ, тем более, что не хотелось бы на Raspberry вносить какие-либо изменения только для удаленного управления.
а) Использование VNC для управления удаленным рабочим столом
VNC - это кроссплатформенная система для графического управления удаленными рабочими столами. В интернете полно инструкций, как с помощью нее управлять рабочим столом Raspbian: для этого нужно установить на Raspberry VNC-сервер, на главный компьютер VNC-клиент или вьювер, правильно их настроить и т.д. Инструкции по настройке при этом могут представлять собой длинные простыни.
Если для Windows такой способ может быть как-то полезен, то для Linux-системы и Raspberry смысла в нем я не вижу вообще. Зачем на оба компьютера ставить дополнительное ПО, если в самой концепции Linux "из коробки" уже заложена возможность трансляции графики на удаленный ПК? Поэтому отметаем этот способ, тем более, что не хотелось бы на Raspberry вносить какие-либо изменения только для удаленного управления.
б) Использование вложенного X-сервера Xephyr
Xephyr - это приложение для запуска в Linux вложенного X-сервера в отдельном окне. Устанавливается на главный ПК, после запуска появляется обычное окно заданного размера, в которое можно выводить графику от других приложений. Тонкости настроек расписывать не буду, перейдем сразу к резюме. Плюс такого решения хотя бы в том, что на Raspberry Pi не требуется ничего устанавливать. Однако и неудобств хватает: все же это дополнительное приложение, которое нужно устанавливать на главный компьютер, каждый раз отдельно запускать и указывать нужные настройки. Хотелось бы все же обойтись штатными средствами Linux.
Оптимальное решение
Поскольку на главном ПК стоит Linux, то на нем (в дисплее 0) уже работает X-сервер, способный отображать графический интерфейс с удаленной машины. А значит, его можно заставить отображать всю графическую оболочку Raspbian. Действительно, если установить SSH-соединение между компьютерами с ключом -X и в консоли Raspberry Pi набрать "startlxde", то на главном ПК мы увидим удаленный рабочий стол Raspbian, полностью функциональный, но с некоторыми ошибками: рабочий стол и значки будут от Raspberry, а панель задач - от главного ПК. При этом нельзя будет переключаться между рабочими столами обеих машин. Такое поведение объясняется конфликтом оконных менеджеров двух компьютеров. Чтобы этого избежать, на главном ПК нужно запустить отдельную независимую сессию X-сервера без оконного менеджера на другом дисплее (под номером 1) и использовать запущенный X-сервер для отображения рабочего стола Raspberry Pi.
Для этого на главном ПК набираем в терминале:
sudo xinit -- :1
Примечение: для корректного выполнения этой команды в системе должен быть установлен терминал системы X Window - "xterm". Для его установки: sudo apt-get install xterm
Эта команда приведет к запуску на дисплее 1 отдельного X-сервера, в результате чего появится пустой экран с открытой консолью xterm:
В этой консоли набираем команду для SSH-соединения с Raspberry Pi и команду запуска графической оболочки:
ssh -X pi@192.168.1.35
startlxde
На экране появится удаленный рабочий стол Raspberry Pi, с которым можно полноценно работать так, как будто мы работаем непосредственно с самим мини-компьютером.
Для переключения между дисплеями (рабочим столом главного ПК и удаленным рабочим столом Raspberry) служат сочетания клавиш Ctrl+Alt+F8, Ctrl+Alt+F9 (или Ctrl+Alt+F7, Ctrl+Alt+F8 в зависимости от дистрибутива Linux).
Для завершения сеанса удаленного доступа достаточно закрыть терминал.
В итоге мы получили полный удаленный доступ к Raspberry Pi, при этом не внося никаких изменений на Raspberry, не устанавливая и не настраивая на главном ПК никакого дополнительного софта. Предложенное решение позволяет максимально точно воспроизводить рабочий стол Raspberry Pi в полноэкранном режиме. При этом сохраняется возможность одновременной и независимой работы как с удаленным мини-компьютером, так и с главным ПК, переключая рабочие столы простым сочетанием клавиш.
Вместо выводов
В качестве резюме приведу все вышеописанное, но без лишнего текста:
1. Работа с консолью Raspberry Pi через SSH в Linux
ssh pi@192.168.1.35
2. Запуск графических приложений Raspberry Pi через SSH в Linux
ssh -X pi@192.168.1.35
имя_приложения
3. Удаленный рабочий стол Raspberry Pi в Linux (загрузка оболочки на Raspberry предварительно отключена)
sudo xinit -- :1
ssh -X pi@192.168.1.35 - набирать в открывшейся консоли xterm
startlxde
для переключения между рабочими столами - Ctrl+Alt+F8, Ctrl+Alt+F9 (или Ctrl+Alt+F7, Ctrl+Alt+F8 в зависимости от дистрибутива Linux).
Все вышеописанное протестировано в Linux Mint 13, Ubuntu 12.04, Ubuntu 13.04 и должно работать в других версиях Linux.
Отличная статья!
ОтветитьУдалитьВсе завелось и работает удаленно на Ubuntu 12.04.2
Не понял только почему у меня не хочет переключаться между рабочими столами
У меня в Linux Mint 13 и Ubuntu 12.04 немного отличались сочетания клавиш для переключения: в Mint Ctrl+Alt+F8 и F9, а в Ubuntu - сдвинуты влево (Ctrl+Alt+F7 и F8).
Удалить1) Попробуйте другие клавиши из ряда F[x]
2) Что-то вообще происходит при нажатии Ctrl+Alt+F7... и др.? Или вообще никакой реакции нет?
3) Если не запускать x-сервер и не устанавливать ssh-соединение, а просто в системе понажимать эти сочетания - будет ли переключаться рабочий стол на черный экран и обратно?
4) Если ничего не поможет я бы попробовал поискать что-то на тему "переключение tty в Ubuntu 12.04.2", может какие-то специфичные настройки сочетаний клавиш...
Это не критично, поищу решение.
УдалитьДругие сочетания проверял. Запустив только систему переключение не работает. При попытках переключиться используя разные сочетания клавиш ничего не происходит, вообще ничего.
Есть правда один нюанс, система на виртуалке. Сама Ubuntu 12.04.2 LTS с оф. сайта.
Дополню - вместо опции -X более старые клиенты могут просить опцию -Y
ОтветитьУдалитьЗдравствуйте
ОтветитьУдалитьнабираю в терминале
sudo xinit -- :1
появляется черный экран, в углу белый прямоугольник примерно на четверть экрана, надпись root@compname:~# □.
И все.
Не реагирует на клавиши, команды вводить не получается.
Стояла Ubuntu 12.10, установил 13.04 - то же самое.
Что я делаю не так?
Уточнение: А вы мышку наводили на белый прямоугольник? Когда указатель мыши за его пределами - он не в фокусе и на клавиатуру не реагирует.
УдалитьТолько что поставил Ubuntu 13.04 с нуля в виртуальной машине - все отлично работает
PS. Если не поможет - уточните, не используется ли в ваших системах программа xneur или другой софт, следящий за раскладкой клавиатуры и вводимым текстом?
only one lxsession can be executed at a time не могу разобрать в чём дело.
ОтветитьУдалитьСкорее всего у вас Raspberry при включении стартует с графической оболочкой. Отключите в его настройках автоматическую загрузку оболочки, (как оговорено вначале статьи) чтобы при подаче питания после загрузки raspberry был в режиме командной строки, а не рабочего стола.
Удалитько втрой малине вообще подключаться не хочет,вначале с ключом были проблемы,теперь вроде подключается но не выполныет lxsession или startlxde вообще никакой реакции
ОтветитьУдалитьМожно ли организовать подобное управление, если у "сервера" на убунту есть выход в Интернет, а у "клиента" малинки 3g модем? Обязательно ли делать модему белый ip?
ОтветитьУдалитьСпасибо
С 3G модемами не работал, поэтому из личного опыта не скажу. А вообще думаю будет зависеть от провайдера и самого модема. Все что требуется - это чтобы не блокировался порт SSH (по умолчанию 22) и чтобы можно было настроить проброс портов извне на серый IP-модема. По идее, если эти условия выполняются, то на "сервере" соединяясь с малиной, можно указывать внешний IP-адрес, под которым провайдер выпускает модем в Интернет. Скорей всего как-то так.. Поищите в направлении "проброс портов 3G" с вашим модемом и провайдером.
УдалитьВообще, у себя опробовал такую схему - все работает без проблем с любой машины, имеющей выход в интернет. Дома роутер, в роутер воткнут распберри. Провайдер выдает роутеру динамический IP-адрес, т.е. белого адреса нет, роутер находится за NAT провадера, насколько я понимаю. На роутере настроен проброс портов извне на внутренний локальный IP распберри (192.168.1.хх). Оставляю малину включенной и подключенной к роутеру, перед выходом из дома записываю, какой IP мне выдал провайдер. Прихожу на работу, запускаю Линукс, проделываю все, что описано в статье, только вместо 192.168.1.35 указываю записанным мной адрес роутера - машины соединяются без проблем, могу управлять с работы домашней малиной. Это из личного опыта :)
УдалитьМожете использовать DDNS для удобства. Есть отличный сайт no-ip.com. Один из немногих бесплатных и качественных. Сам пользуюсь...
УдалитьДобрый день! меня интересует такой вопрос, на сколько я понял ОС ставится на флешку, но у флешки мылый ресурс чтение/запись, был опыт печальный на работе, flashdrive здох чз год эксплуатации, тоже линукс стоял. На нем стоял тфтп сервер для загрузки по PXE, ну и как хранилище использовался(хранилище отдельно монтировалось). Ваше мнение по поводу надежности установки и работы линуха с флехи?
ОтветитьУдалитьВообще, самому это интересно. Понятно, что это зависит от режима работы - если система установлена, время от времени ставятся какие-нибудь программы и, например, работает веб-сервер - то я думаю можно вообще не беспокоиться, т.к. в основном данные только считываются и лишь иногда перезаписываются, причем в небольших объемах. Даже если возникнет несколько битых ячеек (например, из-за частой перезаписи какого-то системного файла) - система сможет автоматом переназначить адрес битой ячейки в файлововй системе ext4 (если на флешке есть свободное место). ИМХО - не думаю, что проблема будет актуальна, если только у вас не высоконагруженный сервер с массовыми перезаливками больших файлов. То, что ваша флешка сдохла через год - честно говоря, удивлен, возможно была другая причина? Но это все личное мнение - живучесть флешек не засекал, поэтому могу ошибаться
УдалитьА можно отобразить рабочий стол Малины на винде восьмой?
ОтветитьУдалитьНу или на седьмой хотя бы
Можно, ищите Putty и XMing. Первая программа - это для SSH соединения и эмуляции удаленного терминала (т.е. заменяет команду ssh -X pi@192.168.хх.хх). Вторая программа - это эмуляция X-сервера в окне (как бы вместо xinit.., который в Linux'е встроен "из коробки"). В общем копайте в этом направлении
УдалитьА без роутера можно? Просто один конец в Малинку, другой в комп. И какой провод нужен? И будут ли какие нибудь доп настройки?
ОтветитьУдалитьПри соединении двух компов нужен перекрестный кабель. Теоретически можно и без роутера (да и практически тоже вроде так делают), но имхо это все "костыли". Доп. настройки точно будут, какие - на скажу, т.к. не пробовал. Предполагаю, что нужно будет настраивать DHCP-сервер на главном компе, возможно что-то еще.
УдалитьА вообще, если хотите мое личное мнение - лучше купить роутер и не мучаться. Сам когда-то долго практиковал соединение компов напрямую. И вроде все работало, но время от времени постоянно натыкаешься на палки в колеса - то неравномерное распределение скорости главным компом, то служба отвалится, не можешь работать с одним компом без другого, то настраиваешь права доступа и т.д. и т.п. Когда купил роутер - понял, что все это были костыли, ибо о проблемах забыл вообще. Более того, наличие роутера позволит держать распберри всегда включенным и видным из интернета (что сильно расширяет сферы его применения). Если работать через главный комп - это уже проблема. Но это лично мое мнение, не навязываю :)
УдалитьСпасибо большое за статью. Самое оно. У меня есть один вопрос. А какая скорость канала, минимальная, необходима для запуска удаленного сервера x-windows? Допустип 100 кбит будет достаточно или нет?
ОтветитьУдалитьНичего не могу ответить - честно говоря, не знаю :)
УдалитьА на Fedore пойдёт
ОтветитьУдалитьДистрибутив не имеет значения.
Удалить