Различия между версиями 33 и 34
Версия 33 от 2008-07-13 00:34:30
Размер: 12691
Редактор: MaximByshevskiKonopko
Комментарий:
Версия 34 от 2008-07-13 00:39:39
Размер: 12444
Редактор: MaximByshevskiKonopko
Комментарий: Прочитал в педивикии про Avahi, вдохновился.
Удаления помечены так. Добавления помечены так.
Строка 80: Строка 80:
Дальше происходит автоматическое обновление DNS. В качестве DNS-сервера используется avahi-daemon. Вообще, Avahi --- реализация протокола Zeroconf, позволяющего машинам в сети без конфликтов распределить между собой IP-адреса.
##Об этом уже было рассказано раньше. --- Чёрт, а было ли?
''^^^ Чертовски странный абзац. Не пойму, что с ним делать. -- MaximByshevskiKonopko <<DateTime(2008-07-13T01:29:16+0400)>>''
Дальше происходит автоматическое обновление DNS. В качестве DNS-сервера используется avahi-daemon. Вообще, Avahi --- реализация протокола Zeroconf, среди возможностей которого --- работа с широковещательным DNS и обнаружение DNS-служб в сети.
Строка 100: Строка 98:
|| 67 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, MaximByshevskiKonopko || || || || 69 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, MaximByshevskiKonopko || || ||

Терминальный сервер со стороны администратора

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

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

../terminal_server_alterator_network.png

Для правильного функционирования терминальной сети необходимо настроить 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. Но, опять же, имеются в виду запросы только на чтение.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

69

1

1

1

1

MaximByshevskiKonopko, ОльгаТочилкина, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080709/03TerminalServer (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:39:51)