Терминальный сервер. Настройка сетевых сервисов.

Тайное знание

В X.org есть универсальный драйвер для устройств ввода evdev, который можно использовать, в том числе, для клавиатуры и мыши. Единственный недостаток evdev --- ему надо сказать, какой конкретно device-файл использовать, в отличие от mouse, для которого весь ввод сводится в device-файл /dev/mice. Так вот, для указаний девайса есть специальные симлинки в каталогах /dev/input/by-id и /dev/input/by-path.

Посмотрим, как эта проблема решается, пока что вручную, но более или менее однозначно. При этом по ссылке с именем --- текстовым идентификатором в /dev/input/by-id доступно само устройство, поэтому при подключении мыши к любому порту она будет работать.

Section "InputDevice"
    Identifier  "Mouse using evdev" # Произвольный идентификатор
    Driver      "evdev"
    Option      "Device" "/dev/input/by-id/usb-A4Tech_Ps.2+USB_Mouse-event-mouse" # Имя устройства, в /dev/input/by-id/ или в /dev/input/by-path/
EndSection

ALT Linux Terminal Server

Мы рассмотрим, как устроен дистрибутив ALT Linux Terminal Server (в дальнейшем ALTSP, ALT Linux Terminal Server Project).

Этот дистрибутив был разработан дополнительно к госзаказу (в рамках которого изготовлены Лёгкий Линукс, Линукс Юниор и Линукс Мастер). Над ним работала принципиально другая команда, из Киева, фактически ресурсы (деньги и, что более важно, людей) пришлось делить на большее количество работы. Дело в том, что команда, которая его разрабатывала, занималась внедрением подобных решений на разных предприятиях, и у них уже были наработки, пригодные для внедрения, правда, только авторами и только в благоприятной среде. Они воспользовались открывшимся ресурсом, чтобы доработать все это до дистрибутива, и, надо сказать, работы было много.

Что он себя представляет?

В документации по ALT Linux есть статья Георгия Курячего ("Linux-класс за час, или X-терминалы, тонкие и ленивые"), довольно старая, еще для ALT Linux Compact 3.0.

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

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

В настоящее время, по сравнению со статьей, которая была написана 2 года назад, существует чуть более правильный вариант --- тот же самый Live CD, только записанный на flash-носитель. По сравнению с Live CD существенно возрастает скорость чтения и исчезают затраты на позиционирование, т.к. flash-носитель --- это устройство прямого доступа (отсутствует понятие позиционирования). Кроме того, его можно так разметить, что часть его будет содержать основные файлы системы, как Live CD, а часть будет доступна для записи пользовательских данных. Такой вариант называется по аналогии --- Live Flash.

Недостаток Live Flash в том, что flash-носители быстро изнашиваются, особенно ограничен их ресурс на перезапись. В ALT Linux используется простейший способ построения Live Flash: образ существующего Live CD просто записывается на flash-носитель.

У обеих этих технологий (Live CD и Live Flash) на сегодняшний день есть существенный недостаток: содержимое системной области недоступно на запись, т.е. нельзя изменить состав установленных программ, и т.п. Теоретически, с помощью unionfs можно сконструировать файловую систему, которая будет поддерживать запись в системный раздел, но это приводит к другим проблемам. Одним словом, сбалансированного дистрибутива на базе Live Flash нет.

Ещё одна проблема в том, что существующий парк компьютерной техники может очень различаться по характеристикам и подходить не для всех видов программ и работ. Можно представить себе старый компьютер, на котором Live CD будет работать неприемлемо медленно и, возможно, нестабильно. Часто встречаются именно такие компьютеры, которые, с одной стороны, желательно задействовать в полезной работе, с другой стороны, даже при установке Linux на них, аппаратных ресурсов явно недостаточно для полезной работы. Такие компьютеры мы отнесём к классу машин, на которых нам желательно использовать Linux без установки его на жёсткий диск.

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

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

Толстый клиент

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

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

На эту тему тоже есть статья Георгия Курячего, которая была в докладе на тему толстых клиентов на конференции в Переславле (http://heap.altlinux.org/pereslavl2006/kouryachy/abstract.html).

В случае, когда мы не хотим устанавливать линукс на компьютере, но хотим его использовать, у нас есть следующие решения:

Вначале рассмотрим решения для новых компьютеров. Мы могли бы использовать livecd или liveflash, но есть дополнительные ограничения:

• мы не хотим мириться с тем, что livecd медленно работает и трудно организовать записываемую часть
• мы хотим изменять системную часть централизованно для многих компьютеров

Тогда можно поступить так. Жесткий диск, как в случае с livecd или liveflash, не используется вообще, а используется технология загрузки по сети. Есть специальные методы загрузить какую-то небольшую программу через сеть с сервера, которая загрузит большую программу, которая уже делает что-то полезное, например, ядро linux или initrd, который примонтирует сетевой диск.

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

Причём здесь возможна следующая ситуация: содержимое livecd перекладываете на сервер, а потом монтируется так же, как монтировалось бы при загрузке с него локально, с той лишь разницей, что во втором случае он будет смонтирован через NFS или другую распределенную файловую систему. Ещё один вариант, если у вас очень много памяти, можно положить образ на http. Клиент его скачает и будет хранить в оперативной памяти. Недостаток (помимо требуемого объема памяти) --- много качать при каждой загрузке. Естественно, при запуске программ с таким образом организованного толстого сервера новые копии их машинного кода в памяти не создаются.

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

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

• после загрузки системы сетевая активность минимальна. Раздел загрузки на сервере можно отмонтировать, сам сервер выключить, и т.д.
• работает быстрее, чем если бы все было установлено на жестком диске

При такой организации наш компьютер называется толстым терминальным клиентом. Обратите внимание, что это просто продолжение технологий livecd, просто вынесенное в сеть.

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

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

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

При этом следует учитывать разницу в терминологии и помнить --- на терминальном сервере у нас работают программы --- X-клиенты, а на тонком терминальном клиенте запущен X-сервер.

Для построения такой системы используется та же программа, что и для локального графического входа в систему --- менеджер дисплеев X (X display manager), например kdm, входящий в состав окружения рабочего стола KDE. Происходит взаимодействие по следующей схеме:

Локальный вход

На компьютере 1 запущен X-сервер xorg0, работающий с мышкой и экраном, за которым сидит пользователь. К xorg0 как X-клиент подключен display manager xdm0, который может после авторизации пользователя запустить любое приложение, обычно некоторый менеджер окон или целое окружение рабочего стола, например, kde0, и передать ему свое соединение с xorg0.

Удаленный вход

Но пользователь может попросить xdm0 запросить сеть и найти там другой, проанонсированный display manager xdm1, находящийся на компьютере 2, чтобы xdm0 передал своё соединение с xorg0 ему. X-протокол позволяет сделать это по сети. Затем xdm1 может точно так же запустить kde1, уже на компьютере 2, и пользователь сможет с ним удалённо работать.

При такой организации на терминальном клиенте работает две программы: X-сервер Xorg и display manager. Остальные программы, которые выполняют пользовательские задачи, выполняются удаленно на терминальном сервере.

История проекта

Есть такой довольно давний проект --- LTSP (Linux Terminal Server Project. Без буквы A в начале). У него была довольно активная команда разработчиков, не то в Иркутске, не то в Новосибирске. Суть проекта состояла в том чтобы создать дистрибутив, использующий такую технологию (см. диаграмму), чтобы не нужно было руками все настраивать эти сервисы. Начинался этот LTSP ещё на ядре 2.2, то есть это было давно. Тогда задача могла быть решена только единственным способом: с одной стороны, нужно было собирать два разных ядра, одно для сервера, другое для клиента, причем для клиента оно должно было быть сильно изменено, чтобы происходило автоматическое определение железа и потом эту информацию об этом железе можно было передать на сервер. Еще нужно было организовать достаточно развесистую инфраструктуру по приёму этой информации, адаптации соответствующих настоечных файлов, и т.д.

Со временем выяснилось, что сильное изменение и перекомпиляция ядра не обязательны.

Со временем, после появления версии 2.6 ядра Linux и виртуальной файловой системы sysfs, политика по оформлению и регистрации драйверов и аппаратного обеспечения компьютера изменилась и необходимость в сборке отдельного специфического ядра для терминальных клиентов отпала. LiveCD в ALT Linux, к примеру, изготавливается из самого обычного ядра с обычными модулями. Проект же LTSP был, к сожалению, сильно привязан к уже разработанной инфраструктуре и системе патчей, а потому непосредственная интеграция его в обычный дистрибутив не представлялась возможной. Сборка LTSP в рамках ALT Linux, к примеру, была большим bundle-файлом. Он выкладывался в определенное место, после чего целая коллекция скриптов настраивала нужные сервисы, --- только так это работало. Поэтому был создан ALTSP --- ALT Linux Terminal Server Project. Его разработчики скопировали часть инфраструктуры LTSP, избежав при этом необходимости собирать специальное ядро. Результатом работы ALTSP стал специализированный дистрибутив "Линукс Терминал", установка которого практически ничем не отличается от установки дистрибутива "Линукс Мастер", за двумя исключениями:

• отсутствует раздел установщика "Разметка диска": дистрибутив требует для работы выделенный сервер, а потому на соответствующей стадии установки требуется лишь подтвердить передачу всего жесткого диска в распоряжение установщика;
• дистрибутив требует наличия в компьютере двух сетевых карт, причем Интернет должен быть доступен через устройство eth0, а локальная сеть (класс, машины в котором будут загружаться по сети) --- через eth1; устройство eth0 при этом должно получать IP-адрес статически (в случае DHCP создается специальная "обертка", позволяющая загрузиться со статическими настройками и затем перенастроиться на использование DHCP), а IP-адрес для eth1 должен быть 192.168.0.1.

Других видимых различий в процедуре установки "Мастера" и "Терминала" нет. Заметим, что пакетный состав дистрибутивов, естественно, различается. Приглашение XDM (в роли которого выступает kdm) на установленном "Линукс Терминале" выглядит так:

Организуем теперь запуск клиентских машин (рабочих станций, или машин-терминалов). В первую очередь необходимо убедиться, что клиенты и сервер находятся в общей СПД. Во вторую --- настроить на клиентах сетевую загрузку (желательно --- по умолчанию). Заметим, что способов загрузить машину по сети есть несколько. Нужный нам вариант называется PXE. Поддерживающие PXE сетевые карты могут получать настройки по DHCP (используется протокол BOOTP) и использовать протокол TFTP для скачивания первичного загрузчика. Во время загрузки по сети экран рабочей станции может выглядеть, например, так:

Если загрузка прошла успешно, то на экране мы увидим приглашение XDM, ничем с первого взгляда не отличающееся от приглашения XDM на сервере. Однако, как мы понимаем, это результат взаимодействия программы xdm на сервере и программы X (X-сервера) на клиентской машине. Удаленный XDM знает о том, что к нему подключились по сети, и потому предложит другой состав меню.

На машине-сервере:

На машине-клиенте:

Итак, терминальный класс успешно функционирует. При этом, однако, мы должны решить следующие проблемы:

• разделение ресурсов;
• доступ к ресурсам.

Рассмотрим их подробнее.

Проблема разделения ресурсов

Эта проблема касается разделения ресурсов между пользователями. Если в нашем компьютерном классе используются 4 клиентских и одна серверная машина, то 4 одновременно работающих на одном сервере пользователя запускают, соответственно, 4 комплекта программного обеспечения. Если сервер по-прежнему один, а клиентов 24, то комплектов запущенного ПО будет тоже 24. Когда пользователи запускают N комплектов ПО, то они потребляют почти в N раз больше оперативной памяти, используют почти в N раз больше промежутков процессорного времени и генерируют N потоков обмена данными с дисковой подсистемой (по сравнению с одним комплектом ПО).

Практика эксплуатирования терминальных классов показывает, что для нормальной работы пользователей (открыт большой документ в OpenOffice.org, запущен Mozilla Firefox с несколькими вкладками) необходимы следующие объемы оперативной памяти: примерно 256 MB для нужд сервера, по 256 MB для каждого из примерно 8 клиентов и по 128 MB для каждого из клиентов, начиная с девятого (если всего их больше восьми). Экономия при большом количестве клиентов может достигаться, к примеру, за счет эффективного использования механизма разделения памяти. Заметим, что если использовать не KDE (или аналогичную по "тяжести" среду), а, скажем, XFCE, то на 8 клиентов вполне может хватить и 1 GB памяти.

Замеров загрузки CPU и обращений к диску при исследованиях не проводилось. Опыт, тем не менее, говорит, что вместо одного диска разумно использовать RAID-массив. Так или иначе, если в наличии имеется целый класс достаточно старых компьютеров и есть возможность купить хорошую современную машину "под сервер", то использование сетевой загрузки с "тонкими" клиентами является, безусловно, хорошим выбором.

Проблема доступа к ресурсам

На самом деле мы решили только часть поставленной ранее задачи. У нас корректно разделены запуск и выполнение задач, а также ввод-вывод, связанный с подсистемой X11 (сюда относится в том числе работа с клавиатурой и мышью). Задачи запускаются на машине-сервере, а ввод-вывод X11 осуществляется на рабочей станции. Но таким способом не решаются следующие проблемы:

1. Работа с данными осуществляется на сервере, в то время как для работы со сменными носителями разумно использовать клиентские машины.
2. Если запущенная программа, к примеру, проигрывает звук, то его вывод использует оборудование сервера.

Первую из указанных проблем можно решать по-разному. Первый вариант довольно прозаичен: по окончании работы все пользователи выстраиваются в очередь к администратору класса с флэшками. Это, если вдуматься, весьма разумное решение, особенно в случае учебного класса со строгой дисциплиной работы. Второй вариант использует проделанную создателями "Линукс Терминала" дополнительную работу. Рассмотрим эту возможность подробнее. Выведем список подмонтированных файловых систем:

$ mount
/dev/hda2 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
sysfs on /sys type sysfs (rw)
udevfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
shmfs on /dev/shm type tmpfs (rw)
tmpfs on /dev/tmp type tmpfs (rw,nosuid)
/dev/hda6 on /home type ext3 (rw,nosuid)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse (rw,nosuid,nodev,user=user)

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

На скриншоте видна иконка на панели с названием "отмонтированная дискета". Идея проста: устройство, подключенное к локальной машине (рабочей станции) хитрым способом (с помощью системы fuse --- filesystem in userspace) "прокидывается" на сервер. Именно информацию об этом пробросе и сообщила нам программа mount. Тем самым, когда какая-либо программа на сервере обращается к каталогу /home/user/Drives/floppy0, она в действительности заходит на нужную рабочую станцию в соответствующий каталог. Для нелюбознательного пользователя это выглядит точно так же, как работа с обычной машиной.

Таким же образом устроена и работа с CD/DVD-приводами. Функционирование ПО происходит на сервере, при этом диск с клиентской машины доступен с помощью такого же обратного проброса. Кликнем по соответствующей иконке и подмонтируем наш диск, выбрав пункт меню "Подключить":

Посмотрим теперь на вывод программы mount:

$ mount
/dev/hda2 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
sysfs on /sys type sysfs (rw)
udevfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
shmfs on /dev/shm type tmpfs (rw)
tmpfs on /dev/tmp type tmpfs (rw,nosuid)
/dev/hda6 on /home type ext3 (rw,nosuid)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse  (rw,nosuid,nodev,user=user)
ltspfs on /home/user/Drives/atacd-hdc/ type fuse  (rw,nosuid,nodev,user=user)
/dev/hdc on /media/cdrom type iso9660 (rw,noexec,nosuid,nodev,utf8,user=user)

Последние две строки говорят нам о том, что подключение прошло успешно. Изменилась и иконка на панели:

Кликнем по ней и выберем пункт меню "Открыть в новом окне":

Откроется окно с содержимым нашего DVD-диска:

Подобным же образом (проброс сервиса) решается и вторая проблема, касающаяся звукового вывода. Здесь, однако, есть одна неприятная особенность: поскольку работа со звуковой подсистемой в разных видах Unix-систем устроена несколько различающимися способами, то далеко не все программы легко умеют работать с пробросом звука на рабочую станцию. Для тех программ, которые умеют в качестве выходного устройства использовать не конкретные файлы (/dev/dsp), а специальные звуковые подсистемы (иными словами, предоставляют пользователю возможность тонкой настройки), есть возможность использовать esd --- Enlightened Sound Daemon. Эта программа запускается на клиентской машине, принимает сетевые подключения по специальному протоколу и воспроизводит передаваемые ей аудиоданные. На сервере устанавливается переменная окружения ESPEAKER, которая указывает умеющим работать по этому протоколу программам, что для проигрывания звука надо использовать удаленный esd-сервер с заданным адресом. Все собранные с поддержкой библиотеки libesd программы работают именно так. Аналогичная схема используется и для программ, работающих со звуковой системой PulseAudio. Программы, использующие ALSA (Advanced Linux Sound Architecture), работают с помощью специального PulseAudio-плагина (plug-in) к ALSA. Лишь пишущие по старинке в /dev/dsp программы не могут быть настроены для работы по сети. Множество запущенных программ такого типа могут создать какофонию на звуковом устройстве сервера. Для устранения этой проблемы достаточно настроить сервер таким образом, чтобы устройство /dev/dsp в системе отсутствовало: вынуть (физически) звуковую карту, отключить (запретить) загрузку ее модуля ядра и т. п. Тогда можно будет эмулировать /dev/dsp пробрасываемыми по сети средствами.

Подведем итоги. Терминальный класс дает возможность:

• эффективно эксплуатировать устаревшее оборудование;
• администрировать одну машину вместо целого класса (если рабочий процесс допускает возможность использования терминальных клиентов; существенно упрощается при этом, например, процедура переустановки ПО).

Недостатки терминального класса следующие:

• Современные X Window System не работают с некоторыми устройствами, к примеру с S3Trio64.

• Один пользователь не имеет возможности работать на двух рабочих станциях одновременно (различные запущенные в одно время сеансы работы должны использовать различные учетные записи).

Заметим, что на сегодняшний день только "Линукс Терминал" обеспечивает "из коробки" концепцию терминального класса и мобильного рабочего места. Достигается это при помощи личных учетных записей, хранящихся на сервере. Использовать чужие учетные записи пользователь не может, так как они защищены неизвестными ему паролями. Каждый пользователь при этом может сесть за любое свободное рабочее место и получить доступ к своей учетной записи, то есть к своему собственному персонализированному окружению. Управление учетными записями централизованно и абсолютно прозрачно (может производиться, к примеру, с помощью Alterator'а).

Рассмотрим теперь особенности терминального сервера с точки зрения администратора.

Заметим, что на терминальном сервере основной конфигуратор системы --- Alterator --- претерпел некоторые изменения (ср. Настройка с использованием Центра управления), в частности, расширился раздел настройки сети.

Для правильного функционирования терминальной сети необходимо настроить DHCP для загрузки тонких клиентов (напомним, что тонким клиентом называют компьютер-клиент сети с терминальной архитектурой, в которой все задачи по обработке информации перенесены на сервер). Настройки DHCP-сервера находятся в файле /etc/DHCP/dhcpd.conf:

ddns-update-style interim;
ignore client-updates;
allow booting;
allow bootp;

option option-128 code 128 = string;
option option-129 code 129 = string;

use-host-decl-names on;

next-server 192.168.0.1;

subnet 192.168.0.0 netmask 255.255.255.0 {
    range 192.168.0.20 192.168.0.250;
    option domain-name "example.com";
    option domain-name-servers 192.168.0.1;
    option broadcast-address 192.168.0.255;
    option routers 192.168.0.1;
    option subnet-mask 255.255.255.0;
    option root-path "192.168.0.1:/var/lib/ltsp/i586";
    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/i586/pxelinux.0";
    } else if substring( option vendor-class-identifier, 0, 9 ) = "Etherboot" {
        filename "/ltsp/i586/nbi.img";
        #filename "/ltsp/i586/pxelinux.0";
    } else {
        option-129 = " initrd=/ltsp/i586/initrd.img";
        filename "/ltsp/i586/vmlinuz";
    }
}

subnet 10.0.2.0 netmask 255.255.255.0 {}

Здесь объявлена внешняя сеть и присутствует большой блок ее описания. Из всех параметров отметим отметим несколько особенностей:

• Обратите внимание, что здесь присутствует адрес next-server'а (это TFTP-сервер, с которого клиенты получают загрузочные файлы; он может не совпадать с DHCP-сервером)
• Посмотрим на if. Мы знаем, что в процессе загрузки по PXE клиент получает несколько настроек, в числе которых IP, машрутизация, DNS. Кроме того, предоставляется имя файла с загрузчиком на сервере TFTP. Параметр filename встречается трижды: формат конфигурации DHCP довольно сложный, и в ней могут встречаться условные операторы. В данном случае, условный оператор выбирает разные загрузочные файлы в зависимости от клиента.
• При сетевой загрузке можно реализовать подключение сетевых дисков по протоколу NFS. По сети подключается некоторый каталог на заданном сервере, который передаётся параметром option root_path. Указанный каталог подключается клиентом как корневая файловая система.
• На самом деле, на этом не заканчиваются те настройки, которые можно передать по DHCP.

Если у вас не работает загрузка по сети (ваша сетевая карта не поддерживает PXE), то необходимо воспользоваться rom-o-matic (он же Etherboot). Он позволяет изготовить bootrom для сетевой карты. Это значит, что для конкретной карты можно сгенерировать образ, который, будучи загруженным при включении компьютера с какого-нибудь носителя (или даже из BIOS), инициирует сетевую загрузку клиента.

Перейдем к настройке TFTP. Он запускается по умолчанию. Всё, что можно сделать при помощи TFTP --- скачать определённый файл. Если работает PXE, то скачивается pxelinux.0. Это загрузчик, он является частью syslinux. После того, как он загружается на рабочей машине, pxelinux.0 совершает некоторые действия. В первую очередь, он скачивает настроечный файл, отобранный следующим образом: сначала он перебирает настроечные файлы, соответствующие IP, если таковых не находится, полному MAC-адресу, далее --- его частям (при необходимости разных сценариев загрузки для разных машин или групп машин). В директории /var/lib/tftpboot/ltsp/i586/ лежат все файлы, которые могут быть переданы по TFTP:

[root@altsp i586]# ls
System.map-2.6.22-led-tc-alt11  nbi.img-2.6.22-led-tc-alt11
config-2.6.22-led-tc-alt11      pxelinux.0
initrd-2.6.22-led-tc-alt11.img  pxelinux.cfg
initrd.img                      vmlinuz
nbi-2.6.22-led-tc-alt11.img     vmlinuz-2.6.22-led-tc-alt11
nbi.img

pxelinux.cfg/default --- настроечный файл, использующийся по умолчанию. Он выглядит так:

DEFAULT vmlinuz ro initrd=initrd.img root=/dev/nfs nfsroot=/var/lib/ltsp/i586,udp ip=dhcp

Синтаксис здесь такой же, как и везде в syslinux. Мы видим, что ядро специфическое, используется специфический root. Отметим, что параметр nfsroot указывает, где находится корневая ФС.

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

Итак, после выполнения загрузчика (pxelinux.0) запускается ядро, initrd (временная файловая система), подключается корневая файловая система по сети и оттуда происходит дальнейший запуск клиента.

Дальше происходит автоматическое обновление DNS. В качестве DNS-сервера используется avahi-daemon. Вообще, Avahi --- реализация протокола Zeroconf, среди возможностей которого --- работа с широковещательным DNS и обнаружение DNS-служб в сети.

Наконец, расмотрим NFS, network file system, протокол сетевой файловой системы. Сервис, который в терминальном сервере обеспечивает NFS, называется unfsd, который представляет из себя урезанную версию обычного nfsd. На NFS находятся корневая файловая система для клиентов. В GNU/Linux для сетевых томов NFS используется по умолчанию. Отличительные особенности NFS:

• Во-первых, он реализован поверх UDP с соответствующими ограничениями UDP. То есть, NFS-клиент и NFS-сервер обмениваются друг с другом датаграммами, и тот факт, что операция записи не прошла или что-то случилось, отслеживается на уровне прикладном, а не транспортном. Стоит отметить, что NFS является идиолатентной, то есть несколько одинаковых действий выполняются как одно. Единственная трудно решаемая проблема --- проблема блокировки (файла на запись, например). Раньше блокировок вообще не было, потом появился nfslockd.
• Во-вторых, уровень доверия в NFS вынесен на уровень IP. То есть машина с некоторым IP-адресом либо имеет доступ к NFS, либо нет. Так было в NFS версий 2 и 3, так же и в NFS 4. Другое дело, что в случае тонких клиентов мы предоставляем файловую систему любому клиенту, но только на чтение, то есть проблем с блокировкой нет. Настройка NFS-сервера unfsd в таком случае довольно проста:

/var/lib/ltsp/i586       (ro,no_root_squash,async)

Слева указан путь к открываемому на доступ каталогу, справа --- список хостов и параметры в скобках через запятую. Если списка хостов нет, то это означает доступ для всех. Здесь под хостом подразумевается пользователь root на хосте. Поясним некоторые из параметров:

• ro --- readonly,
• no_root_squash --- отключение squashing'а, то есть обработки запросов от клиентов с UID=0 как запросов от пользователя nobody. Но, опять же, имеются в виду запросы только на чтение.

Программное окружение в операционной системе Linux состоит из файлов и утилит для работы с ними, с которыми можно работать из командной строки терминала. Таким образом, если организовать терминальный доступ к машине с Linux'ом, появляется возможность ею управлять. Безусловно, при этом настройка системы всё ещё доступна через Alterator, который по своей сути является лишь графической оболочкой, изменяющей те же самые конфигурационные файлы, но чаще с ними работают напрямую.

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

Есть две возможности узнать пароль при подключении:

• Подсмотреть при помощи программы, записывающей нажатия клавиш (keylogger). В таком случае ssh бессильна и задачей администратора является не допустить подобного взлома машины.
• Перехватить при передаче другому компьютеру по сети. Во этом случае существует две степени защиты:
  • Передавать только хэш пароля.
  • Использовать процедуру начального подключения. Заключается она в обмене уникальными идентификационными данными клиента и сервера --- тем, что называется host key. При первом подключении из неизвестного места по защищённому ssl протоколу происходит обмен идентификационной информацией. В этот момент злоумышленник может перехватить её и заменить на собственную. Вы, воспользовавшись ею, произведёте шифрование данных. Злоумышленник перехватит обратный поток, расшифрует, перешифрует и отправит дальше, тем самым завладев ею. Эта технология называется monkey in the middle, и будет рассмотрена подробнее в материале, посвящённом ssl. Таким образом начальный обмен идентификационной информацией должен быть очень строго проверен. Самый простой способ обеспечить безопасность заключается в том, чтобы запомнить "отпечатки" (fingerprints) тех машин, к которым вы часто подключаетесь, и проверять их каждый раз. Считается, что подделать fingerprint невозможно.

Чтобы использовать ssh в Линукс Мастер надо установить метапакет openssh. Он содержит и сервер и клиент.

# apt-get install openssh

Непосредственно для сервера надо запустить службу opensshd, для чего требуется установить openssh-server.

# service sshd start 

При первом запуске он сгенерирует отпечатки машины (в последствии это можно сделать командой ssh-keygen). Важно сохранять их при переустановке системы, иначе при последующем подключении к уже известной ssh машине, но с другим идентификационным ключом, соединения не произойдёт пока ситуация не будет исправлена.

После запуска службы ssh удалённая машина представляет собой терминальный сервер, к которому можно подключиться. Попробуем сначала добыть отпечаток (fingerprint) из ключа на локальном компьютере

ssh-keygen -l -f /etc/openssh/ssh_host_dsa_key.pub

В зависимости от применяемого способа шифрования можно посмотреть host_rsa_key или host_dsa_key.

Для подключения к удалённой машине надо выполнить команду вида ssh пользователь@удалённая_машина

[user@localhost ~]$ ssh user@172.16.0.1
The authenticity of host '172.16.0.1 (172.16.0.1)' can't be established.
RSA key fingerprint is 86:f8:82:2e:bc:9c:0f:1b:35:c6:a7:a1:11:75:5b:2b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.0.1' (RSA) to the list of known hosts.
user@172.16.0.1's password: 
Last login: Wed Jul  9 19:12:24 2008
[user@demo ~]$ 

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

1. Для начала нужно войти в систему расположенную по адресу https://bugzilla.altlinux.org/. Если вы ещё не зарегистрированы --- пройдите процедуру регистрации.

2. Перейдем по ссылке "Зарегистрировать ошибку".

3. Выберем Distributions.

4. Уточним используемый дистрибутив.

5. Выберем компонент, в котором возникла ошибка.

6. Добавим краткое описание сути возникшей проблемы. Например, "ulogd: неправильное определение статуса".

7. А также все подробности, которые могут относиться к ошибке. Например:

При проверке статуса и останове демона ulogd неправильно задаётся пользователь (root вместо ulogd), от лица которого он запущен. В результате программа start-stop-daemon не может определить его PID и возвращает ошибку.

[root@demo ~]# service ulogd status
ulogd is dead, but stale PID file exists
[root@demo ~]# grep root /etc/init.d/ulogd
        stop_daemon --pidfile "$PIDFILE" --expect-user root -HUP -- $ULOGD
                status --pidfile "$PIDFILE" --expect-user root -- $ULOGD
[root@demo ~]# start-stop-daemon --stop --test --exec /usr/sbin/ulogd --user-fallback-to-name --pidfile /var/run/ulogd.pid --user root
No /usr/sbin/ulogd found running; none killed.
[root@demo ~]# ps -ef | grep ulogd
ulogd     2253     1  0 19:11 ?        00:00:00 /usr/sbin/ulogd -d
[root@demo ~]# start-stop-daemon --stop --test --exec /usr/sbin/ulogd --user-fallback-to-name --pidfile /var/run/ulogd.pid --user ulogd
Would send signal 15 to 2253.

8. Осталось лишь нажать "Сохранить",и информация об ошибке будет отправлена.