Linux-класс за час, или X-терминалы, тонкие и ленивые

Терминальный класс? Зачем?

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

Пример: развёртывание компьютерного класса из N рабочих мест и одного сервера с определённой настройкой того и другого и определённым клиентским и серверным программным наполнением. Как правило, с настройкой сервера справиться нетрудно, особенно подготовив её заранее (взять уже настроенную систему и принести её на съёмном жёстком диске). В конце концов, можно провести пару часов за пультом, устанавливая пакеты и настраивая службы и пользовательское окружение.

Неприятности начинаются, когда встаёшь из-за рабочего стола и понимаешь, что впереди ещё десять двадцать сеансов установки и настройки системы на рабочие места. Неплохо, если все компьютеры-рабочие станции совершенно однотипны, а система имеет режим пакетной установки. Можно просто сделать эталонное рабочее место, а потом растиражировать его. Не дай бог только задумать какое-то изменение на рабочих станциях после установки и обнаружить, что пакетного режима для внедрения этих изменений нет.

Собственно, до установки — пакетной или ручной — системы на рабочие станции дело часто и вовсе не доходит, так как ответственный за класс администратор настрого запретил менять что-либо существенное на рабочих местах. Ему тоже пригрезилось двадцать сеансов установки.

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

Между тем, при определённых ограничениях на ресурсы, эта задача решается с помощью X-терминалов¹, называемых также «тонкими клиентами». Смысл решения в том, что на рабочих станциях нужно запустить единственный программный продукт — X-терминал, после чего запускать программы, изменять окружение, работать с файлами и т. д. пользователи будут уже на сервере, а рабочая станция окажется только устройством ввода-вывода («клавиатура–мышь–монитор–сеть»).

Необходимые знания

По сути дела, такая технология не требует никаких модификаций программного обеспечения, имеющегося в составе дистрибутива. Удалённый доступ организуется средствами штатной графической подсистемы X11 (в современных дистрибутивах обычно используется реализация X11 по имени X.Org), отсюда и название технологии.

Клиент-серверная модель X11

X11 реализует строгое разделение клиентской (прикладной) и серверной (интерфейсной) сторон. X-сервер занимается только вводом и выводом: вводом данных с клавиатуры и мыши и выводом графики на видеоадаптер. Запускается X-сервер на рабочей станции — на машине, перед монитором которой сидит пользователь, двигая мышь и нажимая на кнопки. Кроме того, X-сервер выполняет запросы на ввод-вывод, приходящие к нему по сети и другим каналам управления. Стандарт этих запросов называется, естественно, X-протоколом версии 11.

X-клиент — это программа, которая для ввода и вывода использует X-запросы к X-серверу. Никто не мешает X-клиенту, как и любому другому процессу Linux, использовать стандартные потоки ввода-вывода, но X-клиентом он становится, послав запрос серверу. Если клиент и сервер запущены на одной машине, используется специальный файл-дырка (сокет) — обычно он называется /tmp/.X11-unix/X0. Если на разных, запросы передаются по сети (порт 6000)².

Идентификация

Конечно, не всякий X-клиент может использовать ресурсы X-сервера. Неразумно разрешать кому угодно считывать данные с клавиатуры на рабочей станции: а вдруг в это время вводится пароль? Для доступа к серверу нужен ключ, только зная этот ключ программа (независимо от того, кто и где её запустил) сможет зарегистрироваться на X-сервере и начать обмениваться с ним запросами и ответами. Ключами можно манипулировать с помощью команды xauth, которая хранит их в домашнем каталоге пользователя. Таким образом, полученный ключ запоминается с помощью xauth, после чего все программы этого пользователя получат право доступа к серверу. В подавляющем большинстве случаев ключ передаётся автоматически: если клиент и сервер запущены одним и тем же пользователем, ключ у него уже есть, а если разными или на разных машинах, ключ переносит программа, организующая сетевое подключение (например, xdm или ssh).

Обратите внимание на то, что со стороны X-сервера идентификацию можно вообще отменить для определённых адресов в сети (например, так: “xhost + адрес_доверенной_машины”). Однако такая отмена — большая брешь в безопасности системы (пароли!) и ею можно пользоваться только в отладочных целях. В дистрибутивах ALT Linux сервер вообще не принимает запросов из сети (запускается с параметром “-nolisten tcp”); если всё-таки это необходимо, стоит этот параметр в файле /etc/X11/xinit/xserverrc закомментировать.

Адресация

«Имеет право доступа» — ещё не значит «подключается и работает». X-клиенту необходимо знать идентификатор X-сервера. Точнее говоря — идентификатор экрана, так как X-сервер может предоставлять их несколько (два экрана — типичная ситуация для «двухголовых» видеоадаптеров). Идентификатор экрана в общем случае выглядит так: адрес: номер_сервера.номер_экрана. Адрес — это сетевой адрес компьютера, на котором запущен X-сервер; номер_сервера — это номер, под которым сервер зарегистрирован на этом компьютере (как мы уже знаем, по умолчанию это 0), а номер_экрана — номер экрана на этом X-сервере. Чаще всего адрес — это либо доменное имя компьютера, либо IP-адрес, либо ключевое слово “unix”, означающее, что соединение с сервером можно установить через файл-дырку, не используя сеть. Адрес и номер_экрана (вместе с точкой) можно опустить, строка вида “:0” соответствует “unix:0.0”.

Большинство программ-клиентов имеют параметр запуска “-display идентификатор_экрана”, позволяющий непосредственно направить клиент к определённому X-серверу, и все без исключения используют переменную окружения DISPLAY, в которой этот идентификатор можно задать раз и навсегда. Переменную DISPLAY обычно устанавливают системные сценарии и программы, посредством которых пользователь подключается к X-серверу в первый раз, но никто не мешает сделать это из командной строки вручную.

Окновод и рабочий стол

X-сервер сам не делает ничего: он только принимает события от клавиатуры и мыши и передаёт их X-клиенту, которому на данный момент принадлежит фокус ввода, а также принимает X-запросы от клиентов и выполняет их (рисует что-нибудь). X-сервер может изменить размер окна X-клиента, переместить его по экрану или над и под окном другого X-клиента, но по своей инициативе этого не делает. Надо, чтобы кто-нибудь (какой-нибудь X-клиент, больше некому) ему это приказал. Для удобства всем этим, а также искусственным переключением фокуса, рисованием красивых рамочек и кнопочек и ещё тысячей разных мелочей занимается специальная программа-окновод — window manager (оконный менеджер).

Окноводов для X11 создано несколько десятков. Отличаются они дизайном, поведением, возможностями, размером, способом и глубиной настройки и вообще всем, чем только можно. В дистрибутивах ALT Linux Compact обычно используется всего два — довольно простой и очень небольшой IceWM и kwin, входящий в состав рабочего стола KDE, без которого его запускать особого смысла нет.

Рабочий стол — это уже целая архитектура X-клиентов, общающихся между собой по специальным каналам. Если для IceWM, помимо окновода, запускается ещё пара программ, заставка и системный лоток, то для KDE их необходимо более десятка. Впрочем, и по предоставляемым возможностям они ощутимо различаются. Кстати, никто не мешает, используя IceWM, запускать и программы, являющиеся частями KDE, нужно только помнить, что вместе с такой программой стартует и добрая половина основных служб самого KDE, без которых его приложения не работают.

Диспетчер экранов и сеанс работы

Чтобы не мучить пользователя ручной настройкой DISPLAY и ручным запуском составных частей рабочего стола, запуск всего необходимого заложен в систему сценариев. В частности, запуск всех X-клиентов, которые пользователь хочет видеть после входа в систему, можно оформить в виде командного сценария на sh под именем .xsession или добавлять такие сценарии в подкаталог .xsession.d домашнего каталога пользователя. Запуск сразу всех необходимых для IceWM и KDE X-клиентов уже оформлен в виде сценариев — starticewm и startkde соответственно.

Регистрация в системе непосредственно в графической среде — дело специального класса X-клиентов, именуемых диспетчерами экранов (display manager). Таких программ написано несколько, по одной для каждого вида рабочего стола плюс стандартная — xdm. Стандартный xdm довольно беден изобразительно, поэтому обычно используется диспетчер экранов, входящий в состав рабочего стола, например, kdm из KDE. Диспетчер, подобно программе login, спрашивает входное имя и пароль пользователя, после чего запускает выбранный сеанс работы. Kdm, вдобавок, позволяет выбрать пользователя из списка и даже использовать для этого собственную фотографию.

Но главное для нас свойство диспетчера экранов — возможность «перекинуть» по сети регистрацию пользователя с одного компьютера на другой. Нетрудно понять, как это делается. Диспетчер, предлагающий регистрацию через сеть, периодически посылает об этом широковещательные сообщения вида «заходите к нам на огонёк». Диспетчер на рабочей станции все такие приглашения регистрирует; полный список можно посмотреть в виде меню, выбрать оттуда нужный удалённый компьютер, кликнуть его («ау! где вы там?») и пожалуйста: диспетчер на рабочей станции сам перезапустит X-сервер с возможностью приёма соединений по сети (параметры “-once -query адрес_компьютера”), а первым X-клиентом у сервера будет диспетчер экранов удалённого компьютера! Относительную безопасность передачи паролей при таком соединении, соблюдение подлинности обеих сторон (а вдруг в процессе перезапуска произошла подмена) и т. п. берёт на себя протокол XDMCP. Для того, чтобы kdm стал рассылать приглашения, необходимо в секции [Xdmcp] настроечного файла /etc/X11/kdm/kdmrc установить настройку Enable в true и перезапустить kdm.

Дистрибутив ALT Linux Compact — возможности Travel CD

Наш пример будет опираться на настройки, имеющие место в дистрибутиве ALT Linux Compact 3.0. Если вы используете какому-нибудь другую версию дистрибутива Linux, задача может решаться и проще, и сложнее, и совсем не решаться. ALT Linux Compact 3.0 вышел в трёх вариациях — дистрибутив для установки на одном CD, так называемый Travel CD и дистрибутив для установки на одном двухслойном DVD, включающий в себя возможности Travel CD и основную часть репозитория стабильных программ ALT Linux Sisyhpus.

Подробнее о Travel CD. Самый известный аналог Compact Travel — дистрибутив Knoppix на базе Debian GNU Linux, авторы которого, а вслед за ними и весь мир, называют подобную технологию Live CD («Живой Диск»). Идея Live CD в том, чтобы работать с Linux даже на тех компьютерах, где Linux нет, а менять что-либо на жёстком диске строго запрещено. Из положения можно выйти, установив все нужные программы на CD заранее (такое устройство будет, конечно, доступно только на чтение), а для записи файлов завести небольшую виртуальную файловую систему в памяти. Останется только в конце работы сложить нужные файлы на дискету или flash-диск, либо скопировать их куда-нибудь по сети. К жёсткому диску при этом система вообще не обращается, хотя при необходимости его можно использовать.

Две главные трудности Live CD — разнообразие аппаратуры и нехватка ресурсов. Для того, чтобы одно и та же операционная система с одного и того же диска могла работать практически на любом компьютере, необходимо помнить множество различных настроек различных устройств и уметь их автоматически подбирать. С другой стороны, как бы это ни было сложно, именно этим занимается программа-установщик системы, и его части по-умному внедрены в Live CD. Впрочем, всегда остаётся слой компьютеров (как правило — самых старых и самых новых), на котором Live CD уже или ещё не запускается.

Касаемо нехватки ресурсов, именно — оперативной памяти. Нехватка возникает от того, что нельзя ничего записывать на жёсткий диск. Обычная Linux-система создаёт на жёстком диске специальный раздел (swap), на которой выгружается временно не используемые страницы оперативной памяти. Пока запускаемые пользователем программы вместе помещаются в физически имеющуюся оперативную память. Хорошо, если нет — та часть памяти, что дольше всего не использовалась, выгружается на диск, освобождая дополнительное место. Когда эти страницы памяти на самом деле понадобятся программе, выгрузится что-нибудь ещё. Только для Live CD такой раздел завести негде. В Knoppix внедрены некоторые дополнительные средства, позволяющие смонтировать файловую систему на диске и разместить область подгрузки в файле, но это — уже прямое нарушение заповеди «ничего не трогай». В ALT Linux Compact Travel автоматических средств для этого нет, хотя вручную, конечно, можно сделать что угодно.

Если вам вздумается без конца запускать разнообразные программы, пожирающие память, то через какое-то время вы заметите, что каждый следующий запуск идёт намного медленнее предыдущего. Это она — загрузка и выгрузка страниц. Не то для Travel CD: выгружать некуда, и с окончанием свободного места в памяти программы попросту перестанут запускаться.

Есть и ещё один недостаток всех Live CD: скорость чтения данных с лазерного диска на порядки ниже скорости чтения данных с винчестера (жёсткого диска). Особенно это касается работы не с потоками данных (для которых лазерный диск был разработан), а с настоящей файловой системой, когда считывающей головке лазерного привода приходится метаться от начала к концу диска и обратно. Этому горю помочь нельзя — если, конечно, вы не собираетесь использовать терминальный класс, в котором с CD загружается только часть системы и X-сервер, а вся работа ведётся на «нормальной» удалённой Linux-машине.

Варианты терминального класса

Нулевой вариант

Для начала стоит решить для себя: а нужна ли вообще вся эта возня с X-терминалами? В самом деле, если вся задача — запустить сетевой навигатор или почтовую программу, то проще всего наплодить Travel CD и работать именно с ними. Медленную скорость загрузки Firefox, Thunderbird и даже OpenOffice.org можно стерпеть — тем более, что, однажды загрузившись, программы начинают работать довольно быстро.

Однако в случае, когда работа предстоит разнообразная, требующая дополнительной настройки персональных рабочих мест, запуска различных программ и т. п., недостатки технологии Live дают о себе знать, и терминальный класс представляется логичной и несложной заменой классу с Travel CD.

Тренировочный вариант: сервер приложений

Вооружившись полученными знаниями, построим терминальный класс... вообще не устанавливая Linux, из двух компьютеров с двумя Travel CD. Одна машина будет сервером приложений, другая — X-терминалом. На самом деле это потребует даже больше действий по сравнению со стандартной ситуацией: Linux-сервер с установленной системой и произвольный клиент, загружаемый с Travel CD.

Сначала изготовим сервер приложений. Загрузим первую попавшуюся машину с Travel CD. Вместо диспетчера экранов нам предлагается т. н. autologin — автоматический вход в систему под именем altlinux и без пароля. Автоматический вход надо отменить, для чего следует перейти в системную консоль (Ctrl-Alt-F1³), зарегистрироваться как суперпользователь root (у него тоже нет пароля! а зачем пароль, когда ничего испортить нельзя?) и удалить файл /etc/sysconfig/autologin:

[root@Compact root]# rm -f /etc/sysconfig/autologin
[root@Compact root]# killall X

Последовательность клавиш для возврата в графический режим зависит от того, какую системную консоль захватывает графическая оболочка. Для дистрибутивов ALt Linux эта консоль — седьмая, и переход в графический режим, соответственно, Ctrl-Alt-F7.

Вторая задача — запустить kdm в широковещательном режиме, чтобы пользователи могли регистрироваться на этой машине дистанционно. Как сказано выше, для этого нужно отредактировать файл /etc/X11/kdm/kdmrc, заменив в секции [Xdmcp] строку Enable=false на Enable=true. Делать это надо, разумеется, с правами суперпользователя, например, из той же системной консоли. Если вы не умеете обращаться с редактором vim, воспользуйтесь mcedit -a /etc/X11/kdm/kdmrc⁴. В нашем примере мы воспользуемся тем, что строка “Enable=false” в этом файле одна, так что её можно легко изменить пакетным текстовым редактором sed прямо из командной строки:

[root@Compact root]# sed -i~ -e 's/^Enable=false/Enable=true/' /etc/X11/kdm/kdmrc
[root@Compact root]# diff /etc/X11/kdm/kdmrc /etc/X11/kdm/kdmrc~
 112c112
 < Enable=true
 ---
 > Enable=false
[root@Compact root]# service dm restart
 Stopping display manager service:			[ DONE ]
 Starting display manager service:			[ DONE ]

Сервер приложений готов. Заметим, что на нём можно было вообще не запускать X-сервера (графической среды), один только широковещательный диспетчер экранов, но это потребовало бы больших трудов и ручной настройки.

Тренировочный вариант: рабочая станция

Всё, что необходимо сделать на рабочей станции, это загрузить её с Travel CD, отменить авторегистрацию (уже известным способом) и выбрать в меню пункт «Удалённый вход»:

Если kdm на сервере приложений уже широковещает, и оба компьютера подключены к одной локальной сети, то список удалённых подключений будет непуст.

Осталось только выбрать нужный компьютер из списка принимающих удалённое подключение и... увидеть стандартное приглашение kdm! Пусть вас не обманет сходство: это приглашение, как и весь последующий сеанс работы, запущено с удалённой машины. Проверить это легче лёгкого: зарегистрироваться с рабочей станции (у пользователя altlinux нет пароля) и запустить команду who в консоли на удалённой машине:

[root@Compact root]# who
 root     tty1         Feb 12 14:07 (localhost)
 altlinux 169.254.112.94:0 Feb 12 14:22 (169.254.112.94)

Это был «тренировочный» способ организации терминального класса «из ничего». применений на практике ему не так уж много — разве что в классе, где все машины, кроме одной, совсем плохонькие, зато эта одна — мощнее некуда. Программы с сервера приложений, изготовленного из Travel CD, запускаются точно так же медленно, а ресурсы кончаются намного быстрее — сообразно количеству работающих пользователей.

Ленивый вариант

В действительности нужен один компьютер с установленной операционной системой — например, с тем же ALT Linux Compact 3.0. Желательно на этом компьютере иметь побольше оперативной памяти и завести swap-область приличного размера. Как это сделать — написано в инструкции по установке, здесь повторяться не стоит. Для работы пяти-семи человек достаточно стандартной установки, а оперативной памяти должно быть от 64 до 128 мегабайтов на пользователя. Установка Compact 3.0 по умолчанию не включает автоматическую регистрацию, поэтому всё, что нужно — это включить широковещательный режим kdm, как показано выше. «Ленивый сервер» готов.

А вот «ленивый клиент» готов заранее: в меню загрузки ALT Linux Compact 3.0 Travel уже есть пункт «X Terminal»! При выборе этого пункта запускается только графическая подсистема и заранее перенастроенный kdm в режиме удалённого входа, так что ничего делать не надо.

Можно работать.

Что хотелось бы иметь на сервере, или Разумный вариант

Ленивый вариант терминального класса отличается от тренировочного тем, что администратор облегчает себе жизнь, пользуясь подготовленными настройками системы. В то же время оба варианта похожи: в них не предусмотрено облегчить жизнь пользователя: бери, что дают. А то, что дают в офисном дистрибутиве, выглядит недостаточным для полноценной работы сервера. В первую очередь дополнительной настройки требуют подсистемы учётных записей и автоматической настройки рабочих станций.

Разумный вариант: пользователи класса

Если сервер — результат установки Compact 3.0 по умолчанию, на нём будет заведена только одна пользовательская учётная запись. Можно оставить и так, предложив пользователям X-терминалов регистрироваться одинаково, однако это неудобно: начнутся споры на тему «чей файл», «кто перенастроил мою почту» и т. п. Намного правильней завести каждому пользователю свою учётную запись с собственным паролем, окружением и т. п., благо Linux это с лёгкостью позволяет. В ALT Linux можно воспользоваться программой «ALT Linux control center» (команда acc), либо завести их вручную с помощью, например, такого сценария:

[root@Compact root]# for N in alex george nik; do useradd $N; done
[root@Compact root]# passwd george
 passwd: updating all authentication tokens for user george.

 You can now choose the new password or passphrase.
  . . .
 Enter new password:
 Re-type new password:
 passwd: all authentication tokens updated successfully.

Теперь диспетчер экранов kdm покажет список заведённых пользователей, а в пунктах меню — возможные варианты рабочих столов. Для экономии памяти на сервере приложений (всё-таки все программы запускаются там), можно порекомендовать пользователям выбирать пункт “IceWM”:

Системный администратор может установить и другие оконные менеджеры, например, WindowMaker или FVWM2, и настроить их.

Разумный вариант: автоматическая сетевая настройка и доменные имена

При старте Compact Travel опрашивает имеющиеся сетевые устройства и присваивает им адреса из внутреннего (intranet) диапазона (169.254.0.0 — 169.254.255.254), предварительно проверяя, не занят ли соответствующий адрес. Предполагается, что среди более, чем шестидесяти тысяч адресов найдётся свободный. Однако, если в локальной сети имеется служба автоматической настройки абонентов DHCP (dynamic host configuring protocol), система воспользуется ею: в этом случае заработает и доступ в Интернет, и преобразование доменных имён (DNS), что сделает работу намного удобнее.

Если служб DHCP и DNS в локальной сети нет, их несложно организовать. Для этого необходим «большой» дистрибутив ALT Linux — например ALT Linux Compact 3.0 DVD (серверные программы не включены в CD-версию дистрибутива). Для DHCP рекомендуется воспользоваться пакетом dhcp-server, а для DNS — pdnsd.

Пакет dhcp-server содержит демон dhcpd и практически не имеет альтернативных реализаций. Настраивать его надо редактированием файла /etc/dhcp/dhcpd.conf и запуском службы dhcpd. Пакет pdnsd — небольшая и очень простая замена более мощному и сложному bind. Самv pdnsd применяется, в-основном, для кеширования DNS-запросов при работе на очень тонких линиях связи (например, по модему), но его легко превратить в локальный DNS-сервер, отредактировав файл /etc/hosts и указав этот файл в качестве источника в /etc/pdnsd.conf. Для более подробного знакомства с настройкой dhcpd и pdnsd обращайтесь к руководствам по ним, которые поставляются в ALT Linux в составе пакетов, и не забывайте, что в дистрибутивах ALT Linux файл /etc/hosts необходимо распространять в изолированные окружения командой update_chrooted conf.

Недостатки терминального класса и борьба с ними

Поход за дискетой

Главный недостаток терминального класса на основе «тонких» клиентов (с запуском всех приложений на сервере) проявится сразу после того, как кто-либо из пользователей захочет переписать данные на дискету или flash-диск. Несмотря на то, что окружение у каждого пользователя X-терминала своё, внешние устройства всё равно общие, и устройства эти подключены к серверу, а не к рабочей станции — ведь все программы запускаются на сервере! Чтобы иметь доступ ко внешним устройствам на локальном компьютере, надо и регистрироваться локально, а не по сети... с чего начали, тем и закончили?

Есть несколько способов обойти этот недостаток, не исправляя. Во-первых, можно возложить на администратора работу по копированию пользовательских файлов на пользовательские дискеты: файлы-то все на одной машине, в домашних каталогах пользователей (/home/входное_имя/). Перед началом и после окончания работы к администратору выстраивается небольшая очередь с дискетами и flash-дисками — и это разумное решение, например, для учебного класса, где копирование файлов с системы на систему — ситуация нештатная и требующая контроля. Ведь за какой X-терминал ученик ни сядет, доступ к своему домашнему каталогу ему гарантирован, зачем тогда дискета?

Во-вторых, никто не запрещает регистрироваться локально на X-терминалах; это можно сделать, например, с системной консоли (Ctrl-Alt-F1). После чего уже сравнительно просто передать файл с удалённой машины на внешнее устройство рабочей станции. Для этого на удалённой машине должен быть запущен сервис Secure Shell (sshd), а на рабочей станции — установлен клиент ssh (точнее, scp, Secure Copy):

[root@Compact root]# scp george@169.254.56.249:file /media/floppy/

 The authenticity of host '169.254.56.249' can't be established.
 RSA key fingerprint is 9d:17:85:40:4c:cf:bb:e3:57:ec:86:35:69:bf:33:7a.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added '169.254.56.249' (RSA) to the list of known hosts.
 george@169.254.56.249's password:
 file                              100%   29     0.3KB/s   00:00

В-третьих, можно применить другую технологию совместной работы, отличную от описанных выше «ленивых и тонких» X-терминалов. Создание таких терминальных классов, в зависимости от типа дистрибутива, может происходить и полуавтоматически, и совсем вручную. Дистрибутивы ALT Linux Compact, строго говоря, не предназначены для серверных разработок, хотя версия 3.0 DVD включает все необходимые составные части.

Двадцать лазерных дисков

Ещё одно неудобство терминального класса на базе любого Live CD: Live CD. Вернее, их количество и необходимость с них загружаться. Довольно быстро возникает идея: большинство компьютеров умеют загружаться по сети. Ну так пусть по сети на них загружается то же самое, что и на Live CD — скорость работы повысится, двадцать Live CD отправятся в сейф.

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

• настроить службы DHCP и TFTP
• подобрать конфигурацию загрузчика PXE (например, pxelinux из пакета syslinux)
• решить, куда размещать «то же самое» — содержимое Live CD (раньше оно было на CD, а теперь? в памяти целиком? в сети?)
• самостоятельно сформировать стартовую операционную систему, которая, собственно, загружается по сети, добывает содержимое Live CD и начинает работать, как ни в чём не бывало

Последний пункт — самый сложный, требует дополнительного знания сразу нескольких областей (сетевое взаимодействие, архитектура Linux, особенности стартовой системы конкретного дистрибутива и т. п.). Перед Compact 3.0 эта задача даже и не ставилась. Видимо, сетевая загрузка «Live» — дело будущего.

Другие подходы

«Толстые клиенты»

Кроме носителей данных, бывают иные внешние устройства, в первую очередь — мультимедийные, пользоваться которыми можно только напрямую. Просмотр фильма с удалённого компьютера мало того, что загружает сеть распакованным видеопотоком — по сути, последовательностью кадров — он не использует аппаратные возможности видеоадаптера, связанные с обработкой исходного формата (например, аппаратное декодирование MPEG). А если запустить на одной машине сразу десять видеопроигрывателей, совсем не очевидно, что и она, и локальная сеть хорошо справятся с такой нагрузкой. Другое дело, если проигрыватель запущен на рабочей станции, а файл с фильмом (который в десятки раз меньше потока кадров) добывается с удалённого компьютера.

Ещё курьёзнее ситуация со звуком. Если запустить аудиопроигрыватель на удалённой машине, что запищит? Скорее всего, аудиоколонки на удалённой машине (если они там есть). Самый простой выход: аудиопроигрыватель надо запускать прямо на рабочей станции. И видеопроигрыватель тоже: кому нужны фильмы без звука?

Можно решить эту задачу и так: запустить на рабочей станции аудио-сервер (аналог X-сервера для звуковых данных, например, arts или esd), а на удалённой машине запускать только те звуковые программы, что умеют с этим сервером работать. Останется только стандартным для данного звукового сервера способом сообщить этим программам, где он находится.

Так или иначе, представление о рабочем месте, как о клавиатуре, мыши и графическом дисплее, стоящем на тонкой и плоской коробочке, в которой работает только X-сервер, меняется. Теперь эта коробочка (она называется «компьютер») заметно толстеет: на ней запускаются некоторые X-клиенты — а стало быть, на ней должно, хотя бы отчасти, воспроизводиться пользовательское окружение, быть доступен домашний каталог и т. п.

«Толстый клиент» гораздо требовательнее к оперативной памяти рабочей станции. Проще всего сделать т. н. «бездисковый клиент» — рабочую станцию, поведение которой не отличается от обычной Linux-станции, за исключением того, что загрузка её происходит по сети, и все файловые системы монтируются тоже по сети, а жёсткий диск не используется. В этом случае все X-клиенты (в том числе и весь рабочий стол) будут запускаться с рабочей станции. Swap-область такой машине просто необходима, её принято перенаправлять в файл, располагающийся на сервере, то есть опять-таки через сеть (swap через сеть работает очень, очень медленно и может съесть всю её пропускную способность).

По всей вероятности, можно организовать класс бездисковых клиентов с помощью модифицированного Compact 3.0 Travel: CD-часть будет определять и настраивать сеть, монтировать сетевые диски, после чего система будет вести себя так, как это ей предписывается заранее разработанными сценариями на сервере. По сути дела, на сервере нужна целая схема поддержки бездисковых клиентов. ALT Linux Compact — пользовательский дистрибутив, этой схемы не имеющий, так что и режима «толстого клиента» в Travel CD по умолчанию нет.

Можно попытаться организовать «толсто-тонкий» клиент: все приложения, кроме некоторых, запускать с сервера, а этим некоторым организовать доступ к данным на сервере. Или «тонко-толстый»: оставить на рабочей станции только X-сервер да проигрыватели, так что пользователь, волей-неволей, все остальные программы буде запускать всё-таки с сервера. Этому может помочь вот какое соображение: программа терминального доступа Secure Shell (ssh), с помощью которой пользователь будет заходить на сервер, обладает свойством перенаправления некоторых сетевых соединений, в частности — X-запросов. В результате удалённо запущенные X-клиенты без дополнительных настроек передают X-запросы локальному X-серверу, минуя процедуру идентификации или небезопасного применения xhost.

Перенаправление X-запросов происходит так. Команду ssh надо выполнить с ключом -X; тогда сервер Secure Shell (sshd) на удалённой машине зарегистрирует там виртуальный X-сервер (обычно под номером 10, а если такой уже есть — под следующим незанятым) и устанавливает переменную окружения DISPLAY. X-клиент спокойно обращается к этому новому X-серверу, не подозревая о том, что все X-запросы sshd передаёт по установленному соединению, а ssh, сам будучи X-клиентом, ретранслирует их от своего имени уже на машине пользователя:

anyuser@workstation:~> echo $DISPLAY 
 :0.0
anyuser@workstation:~> glxinfo 
 name of display: :0.0
 display: :0  screen: 0
 direct rendering: Yes
 server glx vendor string: SGI
  . . .
anyuser@workstation:~> ssh -X george@linuxserver.some.domain
 george@linuxserver.some.domain's password: 
 Last login: Mon Feb 13 13:59:22 2006 from localhost.localdomain
george@linuxserver:~> echo $DISPLAY 
 localhost:10.0
george@linuxserver:~> glxinfo
 name of display: localhost:10.0
 display: localhost:10  screen: 0
 direct rendering: Yes
 server glx vendor string: SGI
  . . .

Всё бы ничего, только обычному пользователю управляться со смешанным клиентом будет непросто: надо всё время держать в уме, что некоторые программы запускаются «там», а некоторые — «тут», что файлы, доступные «там» не всегда видны «тут» и наоборот, что программа, запущенная «тут» потребляет системные ресурсы, а «там» — сетевые... Ситуацию работы на двух машинах одновременно упростить, увы, нельзя.

Linux Terminal Server Project

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

Но есть и другой подход. Целая команда разработчиков всего мира поддерживает проект Linux Terminal Server, в котором они как раз и занимаются доработкой и пересборкой базовых компонентов Linux для того, чтобы решить основную задачу: организацию удобного в эксплуатации терминального класса на любом оборудовании.

Создатели LTSP устраняют возникающие затруднения естественным для Linux путём: дописывают отсутствующие в программном обеспечении возможности и создают инфраструктуру для их применения. LTSP — «дистрибутив в дистрибутиве». Он требует некоторых усилий по интеграции в базовую систему и содержит всё необходимое для запуска на рабочей станции. В LTSP решены задачи и доступа к локальным внешним устройствам, и разделения приложений на удалённые и локальные, и воспроизведения звука, и многие другие. Исследовать вопрос поглубже можно на русскоязычном сайте проекта, стоит только отметить, что, несмотря на хорошую документацию и массу успешных установок, развёртывание LTSP-класса продолжает оставаться делом квалифицированного системного администратора.