XServer, удаленная рабочая станция Debian

Я хочу настроить компьютер без рабочей станции под управлением Debian Linux. Я бы хотел запустить XServer на другом компьютере. Представьте себе тонкого клиента, хотя машина "тонкого клиента" на самом деле довольно громоздкая. В максимально возможной степени я хочу, чтобы на компьютере с тонким клиентом чувствовалось, что я делаю все локально, при этом фактически сохраняя все файлы (за исключением config, cache и, возможно, секретных ключей ssh) на удаленной рабочей станции и выполняя все Процессорная обработка на удаленной рабочей станции. Два компьютера подключены к локальной сети.

Итак, тонкий клиент для ввода с клавиатуры, мыши и отображения графического интерфейса. Все остальное (менеджер рабочего стола, все программное обеспечение, вся обработка) на рабочей станции.

Как мне это сделать? VNC на самом деле не подходит, поскольку требует (или, кажется, требует), чтобы я вошел локально, на рабочей станции, а затем просто повторил рабочий стол удаленно. Я мог бы использовать ssh, но для этого нужно, чтобы на компьютере с тонким клиентом была запущена полная среда рабочего стола, но я действительно хочу как можно меньше.

Мне не нужно держаться за руки, я просто не уверен, какие у меня есть варианты. Это очевидно возможно, мы делали это еще в начале 90-х, я просто не знаю как. Тонкий клиент имеет много места на жестком диске, достаточно мощности процессора и 32 ГБ оперативной памяти, просто рабочая станция более мощная. И лучше контролируется. Но сидит в шкафу, без монитора.

3 ответа

Ваш вопрос поднимает ряд концепций, для подробного обсуждения которых требуется нечто большее, чем книга (... поскольку большинство этих "концепций" возникли в первые годы XWindow и развивались до сегодняшних дней...).

Следовательно, я не хочу казаться сумасшедшим, говоря, что я собираюсь дать вам подробный ответ.

Тем не менее, я коснусь этого, касаясь некоторых моментов, которые вы должны четко учитывать при приближении к перемотке приложений в системах Unix/Linux/XWindows:

  1. "Система X Window " лежит в основе почти всех приложений Linux, которые показывают своего рода графический интерфейс. Предлагая вам самостоятельно проверить детали (существует более 30 лет истории, в которой вы можете искать), я хочу подчеркнуть очень важный момент: изначально X11 была спроектирована так, чтобы каждое приложение могло работать на хосте. и, в то же время, отображается (как и для GUI) на совершенно другом хосте. Это без единого явного усилия, требуемого программистом.

    Это радикально отличается от того, к чему привыкли люди на платформе Win32, где только добавление явного уровня (RDP и связанные с ним службы терминалов) обеспечивает аналогичное поведение, начиная с нескольких десятилетий назад (но, безусловно, отсутствовало в Win 3.XX, Windows 95, Windows 98, Windows NT и, возможно, в некоторых более поздних системах. Не говоря уже о проблемах лицензирования...)

    Таким образом, это означает - в общем - что в начале 90-х вы могли сидеть перед X-Terminal и показывать приложение, которое вы работали на другом сервере. Именно на развязку вы указываете в своем ОП.

Итак, возвращаясь к вашему вопросу, вы, безусловно, можете запустить свое приложение X11 на железном железе, которое у вас есть в шкафу, и визуализировать его GUI где-то еще.

Этого достаточно? К сожалению нет.... Позвольте мне объяснить, почему:

  1. " удаленное приложение " и " удаленный рабочий стол ": иногда этого было бы достаточно, чтобы иметь его на моем рабочем столе (я имею в виду графические элементы, которые отображаются на мониторе моего ноутбука, где я использую полный рабочий стол Ubuntu) GUI приложения, которое работает где-то еще. Например, у меня есть обычный рабочий стол, но... окно "firefox" связано с "firefox", работающим на другой машине. В таком случае я получаю доступ к удаленному приложению в своей среде рабочего стола.

    В других случаях я бы предпочел, чтобы удаленный компьютер отображал весь рабочий стол, а не отдельные приложения. Следовательно, удаленная система должна решать немного больше проблем, поскольку... есть также какое-то "специальное" окно (то, которое покрывает весь монитор и не представляет какую-либо границу, более или менее) для рендеринга, а в верхней части - для рендеринга весь набор настольных приложений (строка меню, строка состояния и т. д. и т. д.). В таком случае я получаю доступ ко всему удаленному рабочему столу.

Исходя из вашего вопроса, неясно, интересуетесь ли вы "удаленными приложениями", "удаленным рабочим столом" или обоими.

Это все? Пока нет... к сожалению.

  1. " транспорт ": очевидно, что отделение логики приложения (работающей на сервере) от графического интерфейса пользователя (отображение на удаленном дисплее) подразумевает необходимость надежного сетевого канала связи. Когда разрабатывался X11, возможно, я еще не родился (кстати: мне 46!). Не было интернета. И не было понятия "риски, связанные с сетью". Таким образом, в протоколе X11 не было абсолютно никакой точки безопасности. Таким образом, если вы сидели перед X-Terminal с IP a.b.c.d От этого вы бы просто telnet e.f.g.h и оттуда запустите что-то вроде:

xclock --display a.b.c.d:0.0

и вдруг появилось окно xclock. В то время, если ваш друг сидел на терминале y.z.x.w и ты бы дал ему root оболочка на e.f.g.h, вы из a.b.c.d), может просто:

telnet e.f.g.h
su -
xterm --display y.z.x.w:0.0 &

и вдруг у вашего друга появилось окно xterm с правами root и без ввода пароля!

Пожалуйста, имейте в виду, что мы говорим о сроках, когда системы Win32 не существовали. В лучшем случае это было время Windows 3.11.

Теперь перенесемся на 20 лет. Интернет прибыл. Проблемы безопасности с этим. И неожиданно многие люди обнаружили, что легко захватить "видео", "мышь" и "клавиатуру", проходящие по незашифрованному сеансу X11.

Было реализовано несколько решений (многие из которых до сих пор неизвестны / неизвестны мне), но, безусловно, лучшим из них является SSH-X11-Forwarding. Благодаря этому, все еще сейчас, в 2017 году, каждый день, когда я сажусь на свой рабочий стол, на работе, я:

  • поместите мой ноутбук на док-станцию ​​и включите его (в углу моего стола);
  • войти в систему на моем настольном компьютере (оставить включенным, с дисплеем / сеансом "заблокированным"), подключенным к двум большим 27"дисплеям;
  • с моего рабочего стола, ssh к моей записной книжке с ssh -X verzulli@10.0.72.21;
  • из полученного терминала запустите thunderbird &;

Итак, у меня есть мой thunderbird, установленный и работающий на ноутбуке (со всеми связанными архивами) и отображающий на гораздо более удобных дисплеях 2 x 27".

Это... несмотря на то, что прошло более 30 лет с момента появления X11... и без необходимости какой-либо формы лицензирования!

Это все? Еще нет:-)

  1. X.client против X-Server: думая о том, что я делаю каждый день с моей Thunderbird, вы должны увидеть, что:

    • thunderbird X-клиент работает на моем ноутбуке, где никто не сидит впереди;
    • Мой настольный ПК с Linux - это X-сервер, который получает X11-поток от клиента и отображает его на локальном дисплее.

    Похоже, что роль клиента и сервера поменялись местами. Это именно то, что происходит с вещами, которые вы называете "Тонкий клиент": они НЕ являются клиентами с точки зрения сети: они являются "серверами". Вот почему для отображения удаленного приложения X11 на вашем устройстве вам необходим работающий на нем X-сервер: потому что вам нужен X-сервер, способный понимать поток X11, поступающий из сети (... с клиента) и правильно отображать полученное изображение.

    В предыдущих ответах вам рассказывали о Xnest, и на самом деле я бы добавил Xephyr: они:

    • стандартные приложения X11, с точки зрения локального XServer. Как таковые они типично отображаются "локально" на локальном дисплее;

    • они являются X-серверами, в том смысле, что они могут принимать поток X11 удаленного приложения (как правило, весь удаленный рабочий стол) и отображать его ВНУТРИ одного окна.

В общем, ничто не мешает вам использовать уже установленный XServer вашей машины, без необходимости использования Xephyr или Xnest. Другими словами, вы можете захотеть использовать XServer, установленный на вашем собственном Linux-хосте, для подключения к удаленному хосту, запрашивающему весь поток X11-desktop-stream. В целом это было бы так просто, как:

  • выйти из X11, вернуться в текстовый CLI (без GUI);
  • просто запустите что-то вроде: X -query a.b.c.d

где a.b.c.d это IP-адрес хоста, где протокол XDMCP был настроен и включен (более или менее).

Гуру на этом сайте скажут, что я слишком упрощен.... и они правы! Поэтому, пожалуйста, воспользуйтесь вышеуказанным подходом (X -query) только как пункт для дальнейшего расследования.

Мы закончили? Да... но не раньше, чем добавить пару других быстрых моментов:

  1. Эффективность протокола: X11, разработанный более 30 лет назад, определенно является неэффективным протоколом: у вас будет немало проблем при использовании его с пропускной способностью ниже 100 Мбит / с (кстати: в моем офисе у меня гигабитное соединение между тетрадь и мой рабочий стол). YMMW, но, пожалуйста, имейте это в виду, когда вы будете экспериментировать (xclock окно может появиться даже через 30 секунд, когда вы запустите его на своем удаленном VPS). У меня нет проблем с признанием того, что RDP от Microsoft, появившийся много лет спустя, невероятно более дружественен к пропускной способности. С этой точки зрения RDP действительно превосходит X11;

  2. Для решения пункта 5 было предпринято много усилий несколькими проектами. Главные из них - IMHO - это NX и связанный с ним FreeNX (к сожалению, этот проект кажется мертвым);

  3. По моему мнению, в нынешние дни (2017 г.) попытка добиться удаленного доступа ко всему рабочему столу (без Xnest или, что лучше, Xephyr) намного сложнее, чем раньше... и, безусловно, гораздо сложнее, чем удаленное использование только тех приложений, которые вам нужны., Это связано с тем, что современные настольные среды развивались на более высоком уровне, что... у них много проблем с "подгонкой" на удаленном дисплее X11 (подумайте об удивительных анимациях, которые вы можете получить с помощью технологий, подобных compiz, и сопутствующие требования для достойного удаленного рендеринга (помимо проблем безопасности, связанных с внутренними уязвимостями протокола X11).

Это все.

Я действительно знаю, что я абсолютно НЕ ответил на ваши вопросы: я только надеюсь дать вам действительно хорошее представление об этом замечательном мире X11... вы будете счастливы открыть для себя:-)

На клиенте вам потребуется достаточно ОС для загрузки, загрузки библиотек, управления локальным видео / клавиатурой / мышью и запуска X-сервера. На удаленном безголовом устройстве выполните обычную установку того, что вы хотите, и настройте на нем greeter (gdm, kdm, mdm, xdm - это типичные варианты, в зависимости от среды рабочего стола и т. Д.), Чтобы разрешить запросы через протокол XDMCP. Как только это будет сделано, на локальном клиенте запустите X-сервер и скажите ему, чтобы он запросил приветствующего на удаленном хосте. Приложения запускаются с удаленного хоста, взаимодействие с пользователем происходит на локальном клиенте.

Вы даже можете запустить полную ОС на своем локальном компьютере, а когда вам понадобится что-то с пульта, вы можете использовать Xnest чтобы вложить второй X-сервер в свой текущий, запросить удаленный хост и запустить второй рабочий стол как приложение, очень похожее на работу VNC.

Включите автоматический вход на тонкий клиент. Установите приложение запуска на рабочем столе тонкого клиента на ваш выбор программ удаленного входа. Рассмотрим RDP, который также легко подключается к любым серверам Windows, которые у вас могут быть.

Тонкому клиенту потребуется достаточно графического интерфейса для запуска X-сервера или его аналога. Существуют специализированные, легкие, доступные только для чтения корневые дистрибутивы тонких клиентов, такие как LTSP. Или просто ssh -X и запускать удаленные программы ad-hoc.

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

Другие вопросы по тегам