Тема моей сегодняшней заметки странная. Начну с предисловия. Как-то один знакомый задал в нашем небольшом телеграм-чате вопрос: «Коллеги, а вы не знаете каких-нибудь веб-терминалов? А то порой нужно зайти на свой сервер с работы, а тут все порезано по самые гланды», ну задал и задал, все сказали «Да вроде сходу ничего не знаем», но у меня, в силу специфики мышления, вопрос его в голове отложился. Однажды ночью я читал документацию по GTK3 и натолкнулся на GDK_BACKEND=broadway. Бэкэнд использующий HTML5 и websockets для отображения GTK3 приложений. Что-то щелкнуло в мозгу, но щелкнуло странно, что вроде кому-то зачем-то нужно было, на зачем не помню и кому тоже.

Пожил я с этими щелчками в голове, вспомнил кому, написал даже человеку, но честно сказал, что при экспериментах на локалхосте у меня описанное в мане по broadwayd запароливание не работает(цитата из мана «You can add password protection for your session by creating a file in $XDG_CONFIG_HOME/broadway.passwd or $HOME/.config/broadway.passwd with a crypt(3) style password hash. A simple way to generate it is with openssl: openssl passwd -1 > ~/.config/broadway.passwd»), а потому с одной стороны вроде вот она фича, которая человеку была нужна, а с другой стороны ее вот так просто не вывесишь, ну как-то вывешивать терминал голым собой в интернеты это явно не наш выбор. Попробовал проксировать через nginx, что бы c https и basic auth(ну или клиентским сертификатом, тут уж дальше как захочется), увидел пустой экран и забросил.

Сегодня ночью вспомнил об этом и решил, что надо таки посмотреть в чем было дело, еще раз глянул в описание broadwayd и понял, что дело у меня было в websockets, ибо проксировать-то я пытался просто proxy_pass, как к http.

В результате чесания в репе таки все у меня получилось. Собственно описание, исходя из того, что gnome-terminal(а запускать мы будем его, вместе с прочим gtk у вас уже стоит).

В конфиге nginx'а добавляем локейшен в котором у нас basic auth и в котором будем проксировать к нашему broadwayd

location /trm/ {
            auth_basic           "closed site";
            auth_basic_user_file /etc/nginx/htpasswd;
            proxy_redirect     off;
            # websocket
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            # end websocket
            proxy_read_timeout 86400;
            proxy_pass http://127.0.0.1:8080/;

Включаем для локейшена basic auth, что бы чужие не прошли(веб-сервер работает только по https, так что добрый провайдер и прочие по пути нас не перехватят), прописываем хедеры необходимые при проксировании вебсокетов, и меняем таймаут, ибо по дефолту proxy_read_timeout в nginx равен 60 секундам, в случае с вебсокетами нам 60 секунд это беда и огорчение. Ну и указываем где у нас нас будет ждать broadwayd

Проверяем конфиг выполнив nginx -t и делаем nginx'у релоад. Под своим пользователем, чей терминал мы хотели, делаем broadwayd -a 127.0.0.1 &. Запускаем broadwayd слушать на lo, по умолчанию запускается на порте 8080, он уже был задан в nginx'е, что проксировать к нему.
GDK_BACKEND=broadway dbus-launch gnome-terminal. Запускаем искомый gnome-terminal.

Обращаемся к нашему веб-серверу из браузера, вводим логин-пароль от basic auth'а и видим перед собой искомый терминал…

"

P.S. Имеем один минус, не работает буфер обмена в приложениях запущенных в broadway(мы же не только терминал, мы можем большинство приложений использующих GTK3 так запустить)

P.P.S. Я не предлагаю подобное решение серьезно на продакшене, хотя, если для обеспечения безопасности доступа использовать клиентский ssl-сертификат, то почему бы и нет, решение будет столь же ±безопасно, как и ssh по ключу)

Не исключаю, что подобный подход может быть использован для создания чего-то более полезного, чем gnome-terminal доступный из браузера.

P.P.P.S. Да. Что бы не возникло вопросов о странности задач которые я описываю в своих статьях скажу сразу, что в силу специфики моего мышления если передо мной, даже случайно, пробежала задача находящаяся в сфере моей компетенции, то я ее решу, рано или поздно, так или иначе. Вне зависимости от того нужно ли оно мне или кому-то еще реально или нет.