Raspberry pi 3 *обратный* удаленный рабочий стол
Фактически, регулярное выражение
([0-9]+:.{1,}state UP.{1,}(\n.{1,}?){1,}inet )\K([0-9]{1,3}\.?){4}
, которое вы впервые представили, работает , с соответствующей средой, и Perl:
$ perl -l -0 -ne 'print $& if /([0-9]+:.{1,}state UP.{1,}(\n.{1,}?){1,}inet )\K([0-9]{1,3}\.?){4}/' < output_of_your_ip_addr
192.168.1.100
-0 читает файл полностью (вместо построчно строка), а $ & содержит совпадающую часть (то, что осталось после \ K , отбрасывает левую часть).
Хотя, если Perl можно использовать, я бы просто написал
ip addr | perl -l -0ne 'print $1 while /state UP.*?inet ([0-9.]+)/sg'
, чтобы вывести все совпадения. (Измените , а на , если принимает только первое совпадение. $ 1 содержит то, что соответствует первому () .)
(Отредактировано, старый ответ ниже)
С дополнительным требованием, что вы хотите делать все это из A, не трогая B, проблема с запуском X-сервера на B и подключением к нему приложения на A заключается в том, что этот X-сервер будет использовать только устройства ввода (клавиатуру, мышь), подключенные к B. Таким образом, чтобы использовать ваше приложение, вам придется использовать эти устройства ввода, чего вы не хотите.
В принципе, вы могли бы попытаться использовать устройства ввода из A, но тогда конструкция действительно начинает становиться запутанной...
Поэтому VNC в этой ситуации намного проще.
Установите vnc4server на A. Этот сервер также будет действовать как X-сервер для приложений на A. Запустите xvnc4viewer на A, и используйте его для запуска и управления вашим приложением. Запустите другой vncviewer на B и подключите его к серверу на A, он будет отображать приложение. Это может быть просто directvnc (использовать фреймбуфер RaspPi напрямую, без дополнительных обходных путей через X, поэтому меньше нагрузка на RaspPi), или, если вы хотите продолжать работать с существующим X-сервером на B, то xvnc4viewer.
Самый простой способ - использовать удаленный рабочий стол типа VNC, который, скорее всего, уже доступен в виде пакета в вашем дистрибутиве. Обычно это работает гораздо лучше, чем пересылка X через ssh или иным способом, потому что он гораздо лучше сжимается и не использует X-примитивы по проводам.
Конечно, есть несколько способов настроить пересылку X через ssh или напрямую. Например, вы можете войти в систему через ssh -X с B на A, запустить ваше приложение на A, а вывод отобразить на B. (Вы исключили обратное направление, но ничего не сказали об этом, поэтому я не совсем уверен, нужно ли вам это).
Вы также можете настроить X-сервер на удаленный сеанс через XDMCP. Или заставить отдельное приложение использовать удаленный X-сервер, используя соответствующие настройки xauth и DISPLAY.
Но я бы все же рекомендовал сначала попробовать VNC.
Итак, если вы используете ОС Raspbian на (B), если вы не выполнили никаких конкретных настроек, как вы подозревали, вы, вероятно, используете lightdm .
Конечно, вам нужно указать lightdm, чтобы X-сервер слушал tcp (порт 6000). Для этого нужно установить xserver-allow-tcp = true в файле conf в глобальном разделе [Seat: *] . Вам также может потребоваться явно указать xserver-command = X -listen tcp (см. здесь ). Вы можете выбрать любой дополнительный файл в /etc/lightdm/lightdm.conf.d / *. Conf или непосредственно в /etc/lightdm/lightdm.conf .
Затем, если вы не слишком заботитесь о безопасности, вам, вероятно, также нужно будет запустить (B) некоторую форму команды xhost + , например xhost + IP_OF_ (A) ].
Если вас действительно беспокоят уязвимости LAN , вам не следует использовать напрямую X через tcp в первую очередь, но без ssh вы можете немного повысить надежность, обмениваясь MIT-MAGIC-COOKIE между (A) и (B), запустив (B) xauth extract - $ DISPLAY | ssh (A) xauth merge - .
Затем перезапустите lightdm service lightdm restart или systemctl restart lightdm.service в зависимости от версии вашей ОС.
Последний - проверьте (B), прослушивает ли Xorg 6000 netstat -antp | grep -F 6000