LTSP — вторая жизнь старых компьютеров::Журнал СА 12.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 4346
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 5646
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 6875
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7270
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6342
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 LTSP — вторая жизнь старых компьютеров

Архив номеров / 2003 / Выпуск №12 (13) / LTSP — вторая жизнь старых компьютеров

Рубрика: Карьера/Образование /  Лабораторная работа

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

LTSP – вторая жизнь старых компьютеров

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

Все ОС UNIX и подобные операционные системы изначально отлично подготовлены для полноценной работы в среде клиент-сервер. Даже X-Window не удалось избежать данной участи. Это сетевой продукт, одна часть которого (сервер) взаимодействует непосредственно с пользователем с помощью клавиатуры, мыши и монитора, она обрабатывает команды пользователя и формирует соответствующие запросы на их выполнение. Результаты работы программ передаются также непосредственно ему. А другая (клиент) уже обрабатывает результаты запросов и запускает запрошенные программы, а затем передает результат выполнения обратно серверу. Основой взаимодействия графических приложений с сервером является протокол Х, который реализован так, что ему абсолютно не важно, где находится клиент и сервер. В самом общем случае они работают на одном компьютере, но ничто, повторяю, ничто не мешает разместить их на разных компьютерах, ну разве что отсутствие какой-либо связи между ними.

Такая организация позволяет эффективно использовать компьютерный парк организации: все ресурсоемкие операции выполняются на специально выделенном мощном компьютере. То есть имеется несколько более слабых компьютеров, за которыми работают пользователи. Такие компьютеры используют UNIX с установленным сервером X-Window. Операционная система обрабатывает запросы, создаваемые пользователем, и передает его серверу, который в свою очередь возвращает результат. Эти компьютеры принято называть Х-терминалами. А компьютер, выполняющий основную наиболее трудоемкую работу, называют сервером графических приложений. Конечно же, к ресурсам такого компьютера предъявляются особые требования, особенно это относится к объему оперативной памяти, которой должно теперь хватать на всех, и к скорости дисковых операций. А вот к рабочим станциям пользователя требования уже гораздо ниже. С возлагаемой на них задачей спокойно могут справиться и «четверки».

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

Оказывается, можно. Открытость Linux-систем породила вокруг себя довольно много полезных проектов, и часто для решения какой-нибудь проблемы необходимо просто найти подходящий. Решением вопроса загрузки бездисковых терминалов занимается LTSP (Linux Terminal Server Project).

В чем же преимущество компьютера без диска:

  • Подвижность пользователя, ведь как уже отмечалось, пользователь не связан с конкретным компьютером.
  • Снижение стоимости и упрощение операции обновления программного обеспечения, так как это производится только на одном компьютере.
  • Резервирование, восстановление данных будет происходить также только на одном компьютере.
  • Физическая защита данных лучше, так как единственное, что необходимо защищать – сервер, а его можно поставить в специальном хорошо охраняемом помещении (которое, кстати, можно оборудовать фильтрами от проникновения пыли и аппаратурой для поддержания постоянной температуры, что существенно продлит срок работы сервера).
  • UPS можно предоставить только серверу.
  • Также будет существенно ниже общая цена – экономия = (стоимость жесткого диска + стоимость CD-ROM + стоимость флоппи-дисковода) * количество компьютеров.
  • Защищать от вирусов необходимо только сервер, так как другие компьютеры не имеют жесткого диска.
  • Уровень шума на рабочем месте ниже, так как в компьютере нет частей, которые движутся – практически нет необходимости в администрировании и обслуживании в клиентских компьютерах.
  • Большая долговечность клиентских машин как моральная, так и физическая.
  • Возможность работы в запыленных помещениях (здесь желателен «холодный» процессор типа VIA C3, ЖК монитор).

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

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

Дальнейшую работу условно можно разделить на три этапа: получение IP-адреса, получение образа операционной системы и собственно работа с данными. Чтобы получить IP-адреса, программа загрузки инициализирует широковещательный запрос (для нашего примера 192.168.0.255, по умолчанию используется порт 68, протокол UDP), в котором указывается свой уникальный для каждой сетевой карты МАС-адрес. Для динамического распределения IP-адреса между компьютерами в сети используется служба DHCP. DHCP-сервер, приняв запрос, находит конфигурацию, соответствующую данному МАС-адресу, и возвращает cледующие данные:

  • IP-адрес рабочей станции.
  • Маску сети.
  • Путь к загружаемому ядру ОС.
  • Путь к каталогу, который монтируется в качестве корневого.

Переговоры между клиентом и сервером можно воспроизвести примерно так.

Клиент: «Привет, мой аппаратный адрес 00-02-44-07-FC-C4, дай мне мой IP-адрес».

Сервер: «(Ищет адрес в базе данных.) Ваше имя – aldebaran, ваш IP-адрес – 192.168.0.100, ваш сервер – 192.168.0.1, файл, от которого вы загружаетесь, находится в /tftpboot/ltsp/vmlinuz-2.4.21-ltsp-1 и остальная информация).

Естественно, в сети должен находиться один такой сервер, иначе они передерутся между собой, и, конечно же, необязательно он должен быть нашим сервером графических приложений. После получения адреса клиент должен загрузить ядро операционной системы. Для этого используется протокол TFTP (тривиальный протокол передачи файлов). Это просто облегченная версия протокола FTP, которая не требует идентификации и использует UDP-протокол вместо TCP. Ну а чтобы пользоваться файловой системой, на другом компьютере на сервере должна быть настроена служба NFS. После загрузки ядра оно, уже как и положено, берет бразды правления в свои руки. Вот вкратце и все.

Теперь займемся практической реализацией. Для того чтобы было возможным загружаться описанным выше способом, необходимо записать образ загрузчика, поддерживающего определенную сетевую карту в EPROM (Erasable Programmable Read-Only Memory – перезаписываемая память). Для этого заходим на сайт http://rom-o-matic.net и в выпадающем списке «Choose NIC/ROM type» выбираем марку чипа на сетевой карте. Здесь я допустил ошибку, помня, что сетевая карта NE2000 совместимая, просто скачал образ для NE. И вполне естественно, при загрузке получил что-то вроде «не могу найти NE*-карту». Пришлось раскрывать корпус одного из компьютеров и смотреть, что там такое установлено, заодно и сам узнал марку чипа – rtl8029. В меню «Choose ROM output format» выберите интересующий формат. Доступны следующие варианты образов:

  • Floppy Bootable ROM Image (.lzdsk) – загрузчик с дискеты (на первом этапе лучше воспользоваться именно им).
  • Binary ROM Image (.lzrom) – прошивка ПЗУ сетевой карты.
  • LILO Bootable ROM (.lzlilo) – загрузка с использованием LILO.
  • DOS Executable ROM Image (.com) – DOS-загрузчик тоже подходит, только уберите загрузку himem.sys и emm386.exe, а то работать, скорее всего, не будет, и добавьте соответствующие строки в файл config.sys для загрузки.
  • PXE loadable ROM Image (.lzpxe) – то же, что и второй пункт, но разработки Intel.

Выбираем вариант Floppy Bootable ROM Image, при нажатии на кнопку «Get ROM» вы получаете нужный образ. Чтобы перезаписать его на дискету, воспользуйтесь программой rewrite под Windows, которая входит в состав практически каждого дистрибутива Linux, а в Linux дайте следующую команду:

#cat your_image.lzdsk > /dev/fd0

или

#dd if=/path/to/rom-image of=/dev/fd0 bs=1024

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

Отправная точка в Интернете для поиска необходимой информации и программ – официальный сайт проекта: http://www.ltsp.org.

Конфигурация сервера Athlon 1.3 Гц, 256 Мб, 10 Mбит сетевая карта. Пять клиентов Pentium-100, 16 Мб, Video S3 Trio 3D 4 Мб. Все это настраивалось под операционными системами Linux Mandrake 8.0 и Red Hat 7.3. Для того чтобы это все работало на данных системах, были установлены следующие сервисы: dhcp, nfs, portmap, tftp (клиент и сервер), если понадобится telnet-сессия, то и telnet-сервер и запущена служба xinetd. На установке выше перечисленных сервисов я останавливаться не буду, хотя бы потому, что большинство их входит в состав соответствующих дистрибутивов, и если нет в стандартной поставке, то их всегда можно найти на соответствующем сайте.

Для настройки ltsp нам понадобятся следующие пакеты, которые можно взять с http://prdownloads.sourceforge.net/ltsp, все они доступны как в виде перекомпилированных пакетов в формате rpm или deb, так и в виде исходников. Какие устанавливать – дело вкуса и опыта. Я скачал в формате tgz. Итак, какие необходимо скачать пакеты (версию не указываю специально, так как к моменту выхода статьи все может измениться, плюс уже давно ходит в бетах версия 4):

  • ltsp_core – основной пакет, необходимый для работы;
  • ltsp_kernel – ядро, загружаемое на клиентский компьютер;
  • ltsp_x_core – пакет, необходимый для запуска X-Window версии 4.х на клиентском компьютере;
  • ltsp_x_fonts – пакет со шрифтами (скачал по рекомендации на сайте, но вполне можно обойтись и без него).

Если видеокарта не поддерживается в версии 4.х, необходимо дополнительно выбрать пакет с версией сервера 3.3.6 применительно к видеокарте, установленной на ваших клиентских компьютерах (в моем случае это ltsp_x336_s3), или, если нет, то ltsp_x336_svga, но при этом не будут работать TrueType-шрифты и сглаживание. На сайте также доступны пакеты для поддержки звука, сканера, веб-камер и wireless-устройств на терминале, пакеты для организации Windows-терминала и еще много чего. Первым обязательно должен быть установлен пакет ltsp_core. Установка заключается в распаковке (tar xvzf) и запуске инсталляционного скрипта (cd ltsp_ххх, ./install.sh). Остальные устанавливаются аналогично. Для rpm-пакетов просто дайте команду:

# rpm -ivh ltsp_core-3.0.9-0.i386.rpm

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

Good! We have found RedHat version 7.3

About to install LTSP, using the following settings:

# каталог, в который устанавливаются пакеты

LTSP_DIR = /opt/ltsp

SWAP_DIR = /var/opt/ltsp/swapfiles

# каталог для загружаемого ядра

TFTP_DIR = /tftpboot

# адрес сети

IP_NETWORK = 192.168.0.0

# адрес сервера

IP_SERVER = 192.168.0.1

# маска сети

IP_NETMASK = 255.255.255.0

# широковещательный адрес сети

IP_BROADCAST = 192.168.0.255

После установки всех пакетов перейдите в каталог /opt/ltsp/templates/ и запустите скрипт ./ltsp_initialize, который внесет необходимые изменения в конфигурационные файлы вышеперечисленных сервисов. Внимательно читайте выходные данные, если что-то у вас не установлено, то скрипт выдаст сообщение об ошибке. Теперь давайте перейдем к ручной доводке сервисов.

Сервис dhcp настраивается в файле /etc/dhcpd.conf, который при установке в большинстве дистрибутивов не создается, поэтому первоначально может потребоваться его создать:

#touch /etc/dhcpd.conf

Для того чтобы правильно его настроить, необходимо знать MAC-адрес сетевой карты, IP-адрес сервера и сетевую маску. Для выяснения MAC-адреса я нашел в Интернете множество программ, написал одну на Perl, воспользовавшись модулем с CPAN, затем вспомнил, что демон arpd сохраняет информацию о всех MAC-адресах и их IP-адресах в пределах локальной сети, а проблема решилась проще, чем я думал, при запуске образа, который мы приготовили на дискете раньше, выдается требуемый MAC-адрес сетевой карты, установленной на компьютере.

Для начала о некоторых допущениях, связанных с конфигурацией локальной сети. В сети 192.168.0.0/255.255.255.0 для бездисковых терминалов выделены адреса с 192.168.0.100 по 192.168.0.254. Серверы DHCP и LTSP находятся на компьютере 192.168.0.1. Тогда файл /etc/dhcpd.conf будет иметь такой вид:

subnet 192.168.0.0 netmask 255.255.255.0 {

    range 192.168.0.2 192.168.0.100;

    option subnet-mask            255.255.255.0;

    option broadcast-address      192.168.0.255;

    option routers                192.168.0.1;

    option domain-name-servers    192.168.0.1;

    option domain-name "server.org";

    option log-servers        192.168.0.1;

host term1 {

    hardware ethernet     00-02-44-07-FC-C4;

    fixed-address         192.168.0.100;

    option host-name "term1";

    option root-path      "192.168.0.1:/opt/ltsp/i386";

    filename              "lts/vmlinuz-2.4.21-ltsp-1";

}

Небольшое пояснение. В начале конфигурационного файла расположены инструкции, относящиеся ко всем компьютерам сети. Их смысл очевиден. Поскольку на терминалах нет жесткого диска, то демону журналирования syslogd в строке option log-servers 192.168.0.1 указывается удаленный сервер, который будет записывать от него сообщения. Для того чтобы демон syslogd на сервере мог принимать сообщения от терминалов, в файле конфигурации /etc/sysconfig/syslog, должен использоваться ключ -r:

# Options to syslogd

# -m 0 disables "MARK" messages.

# -r enables logging from remote machines

# -x disables DNS lookups on messages recieved with -r

# See syslogd(8) for more details

SYSLOGD_OPTIONS="-m 0 -r "

Далее идут индивидуальные настройки для каждого компьютера клиента. Здесь можно переопределить настройки сервера индивидуально. В строке hardware ethernet 00-02-44-07-FC-C4 указывается аппаратный МАС-адрес сетевой карты, а в строке fixed-address 192.168.0.100 за ним статически закрепляется IP-адрес. Теперь при запросе клиента с указанным МАС-адресом ему всегда будет выдаваться IP-адрес 192.168.0.100. Остальным же он будет назначаться на общих правилах, из таблицы свободных адресов. Строка option root-path указывает на раздел, который будет смонтирован в качестве корневого с помощью службы NFS, его можно прописать и в глобальной секции, но только в том случае, если в данной сети используются только бездисковые станции, иначе ноутбук шефа будет загружать что попало. Для того чтобы данный ресурс был виден в сети, необходимо в файле /etc/exports сервера LTSP указать каталоги, доступные для сетевого монтирования:

/opt/ltsp/i386 192.168.0.0/255.255.255.0 (ro, no_root_squash)

/var/opt/ltsp/swapfiles (rw, no_root_squash)

Слева указаны каталоги, которые экспортирует сервер, первая строка – корневую систему, а вторая – раздел свопирования, если в нем есть необходимость. Справа указаны опции. Флаги ro и rw указывают на доступ только для чтения и для записи и чтения соответственно. А no_root_squash заменяет пользователя root более безобидным nobody. Параметры ro и no_root_squash, используются в файле по умолчанию, и поэтому их можно смело опустить, но так как-то нагляднее.

Ядро может автоматически определить только PCI сетевую карту, если у вас ISA, то добавьте следующие строки для каждого описываемого клиента.

option option-128     e4:45:74:68:00:00;

option option-129     "NIC=ne IO=0x300";

Здесь хочется отметить, что «option-128» в этом случае не является mac-адресом, это специальный ключ для загрузки Etherboot. Параметр «option-129» указывает ядру, какой именно драйвер сетевой карты необходимо загружать. Параметр filename указывает путь к ядру, который необходимо загружать. Пакет LTSP поставляется с двумя ядрами, поддерживающими большинство сетевых карт: одно описано выше, а второе с префиксом lpp (Linux Progress Patch) в имени. При использовании последнего ядра на компьютере клиента при загрузке отображается статус-бар, данное ядро рекомендуется использовать, после того как удалось все настроить и загрузиться с обычного.

Дополнительно может понадобиться для экспорта домашних каталогов пользователей /home добавить следующие строки в файл /etc/exports:

/home   192.168.0.0/255.255.255.0   (rw)

а в файл /opt/ltsp/i386/etc/fstab:

ltsp-server:/home/ /home nfs defaults,rsize=8192,wsize=8192 0 0

И обязательно добавьте в файл /etc/hosts описание компьютеров сервера и клиентов для нормальной работы службы NFS. Например:

/etc/hosts

127.0.0.1 localhost.localdomain localhost

192.168.0.1  server.org

192.168.0.100     term1

Теперь необходимо перезапустить сервис dhcpd:

[root@grinder etc]# /etc/init.d/dhcpd restart

 Останавливается dhcpd: [ СБОЙ ]

Запускается dhcpd: [ ОК ]

[root@grinder etc]# /etc/init.d/dhcpd status

dhcpd (pid 979) выполняется...

На этом настройку dhcpd можно считать законченной. Теперь о настройках остальных сервисов. Общим для некоторых из них является то, что если сервис запускается с помощью xinetd (tftp, telnet), то он обязательно должен быть разрешен (в файлах /etc/xinet.d/tftp и /etc/xinet.d/telnet), для этого требуется заменить disable = yes на disable = no. Также в целях улучшения безопасности могут быть определены IP-адреса, с которых разрешен доступ к данному сервису (по умолчанию localhost), т.е. в нашем случае only_from = 192.168.0.0. Кстати, вообще вышеописанное желательно проводить в сетях, в которых вы полностью доверяете всем компьютерам, а от внешних собратьев закрыться firewall.

Файл /etc/xinet.d/tftp будет иметь такой вид:

service tftp

{

    socket_type         = dgram

    protocol            = udp

    wait                = yes

    user                = root

    server              = /usr/sbin/in.tftpd

    server_args         = -s /tftpboot

    disable             = no

    per_source          = 11

    cps                 = 100 2

}

На этом настройки данных серверов можно считать законченными. Желательно проверить их работу перед применением.

[root@grinder root]# tftp grinder

tftp> get lts/vmlinuz-2.4.21-ltsp-1

Received 1062469 bytes in 0.9 seconds

tftp> quit

Имя файла указано так потому, что корневой каталог для этого сервиса определен в файле /etc/xinet.d/tftp как server_args= -s /tftpboot, т.е. каталог /tftpboot делается корневым (chroot), и поэтому если указать полный путь, то сервер просто не найдет необходимый файл.

Меньше всего возни с настройкой сервера шрифтов было в дистрибутиве Red Hat. А с настройкой в остальных мне очень помог разобраться документ: http://www.ltsp.org/contrib/AbiWordfont.txt. В файле /etc/X11/fs/config в строке «client-limit = 10» установите число компьютеров клиентов, рекомендуемое не более сорока. В файле /etc/X11/XF86Config (или XF86Config-4, если вы используете четвертую версию сервера) замените строку:

FontPath    "unix/:-1"

на

FontPath    "tcp/localhost:7100"

А в файле /etc/rc.d/init.d/xfs замените строку:

daemon --check xfs xfs -port -1 -daemon -droppriv -user xfs

на

daemon --check xfs xfs -port 7100 -daemon -droppriv -user xfs

и строку:

daemon --check xfs su xfs -c "xfs -port -1" -s /bin/sh

на

daemon --check xfs su xfs -c "xfs -port 7100" -s /bin/sh

Перезапустите сервер и проверьте, слушает ли он порт под номером 7100. Для того чтобы терминалы могли запрашивать у сервера сеанс XDM, требуемый для регистрации пользователя и запуска пользовательской сессии, необходимый при использовании X-Window, требуется в конфигурационном файле /etc/X11/xdm/xdm-config на сервере LTSP внести соответствующие изменения:

! SECURITY: do not listen for XDMCP or Chooser requests

! Comment out this line if you want to manage X terminals with xdm

# этот пункт обязательно закомментировать

! DisplayManager.requestPort:  0

# Эту строчку добавить, правда необязательно. Остальные

# можно не трогать.

DisplayManager.*.setup:/etc/X11/xdm/Xsetup_workstation

Скрипт Xsetup_workstation  имеет такой вид:

 #! /bin/sh

/usr/X11R6/bin/xsetroot -solid "#356390"

if [- x /usr/bin/xsri]; then

    /usr/bin/xsri -geometry +5 +5 -avoid 300x250 -keepaspect /etc/X11/xdm/ltsp.gif

fi

И остался «последний и решительный бой». Правка самого главного конфигурационного файла LTSP /opt/ltsp/i386/etc/lts.conf. Наиболее подробную информацию о настройках тех или иных параметров можно узнать из файла /opt/ltsp/i386/etc/lts.conf.readme. Данный файл состоит из раздела [Default], в котором определяются общие для всех клиентов параметры, и разделов, определяющих индивидуальные для каждого клиента, в них при необходимости можно переопределить те или иные глобальные установки. Благодаря такой схеме появляется возможность более гибкой адаптации к аппаратной конфигурации терминалов. Итак, пример файла lts.conf:

[Default]

     SERVER    = 192.168.0.1

# компьютер, выступающий в роли сервера графических приложений

     XSERVER   = auto

# указывает на то, что система сама определяет тип загружаемого XFree86-сервера

     X_MOUSE_PROTOCOL   = "IMPS/2"

# название протокола манипулятора мыши в данном случае используется мышь со скроллингом,

# если обыкновенная мышь подключаемая к порту PS/2, то попробуйте просто PS/2

     X_MOUSE_DEVICE     =   "/dev/psaux"

# указывает на порт PS/2

     X_MOUSE_RESOLUTION = 50

     X_MOUSE_BUTTONS = 3

     LOCAL_APPS   =  N

     USE_XFS = Y  # используется сетевой сервер шрифтов

    RUNLEVEL  = 5

    SOUND  = Y

    VOLUME   = 75

И секция для клиента. В качестве ее названия может выступать имя хоста, МАС- или IP-адрес, т.е. [term1], [192.168.0.100] или [00-02-44-07-FC-C4].

[term1]

        XSERVER    = XF86_SVGA

# Тип X-сервера, который будет выполняться на клиентской

# станции. Для четвертой версии указывается видеомодуль,

# например nv. Для XFree86 3.3.6 указывается имя сервера

# XF86_SVGA, XF86_S3 и т. д.

    X_MODE_0 = 800x600  40 800 840 968 1056 600 601 605 628 +hsync +vsync

# установка параметров вывода на экран, их может быть

# несколько от X_MODE_0 до X_MODE_10

    X_VIDEORAM = 4096 # количество видеопамяти

    X_MOUSE_PROTOCOL = "Microsoft"

# мышь с последовательным интерфейсом

    X_MOUSE_DEVICE  = "/dev/ttyS0"

# мышь, подключаемая к параллельному порту

    X_MOUSE_RESOLUTION = 50

    X_MOUSE_BUTTONS    = 2 # количество кнопок мыши

# включение эмуляции третьей кнопки мыши

# (нажатием двух имеющихся одновременно)

    X_MOUSE_EMULATE3BTN = Y

    X_MOUSE_BAUD    = 1200

    RUNLEVEL  = 3

Уровень инициализации (RUNLEVEL) 3 загружает командную строку bash_shell в консоли, этот параметр желательно установить первым для отладки работы сервисов, и если все получилось, то использовать либо 4 для telnet-сессии, позволяющей открывать несколько терминалов на сервере и переключаться между ними по Alt-F1 до Alt-F9, либо 5 для автоматического старта X-Windows. Для каждого клиента, как видите, есть возможность определить индивидуальные параметры Х-сервера в секции, но возможен и другой вариант, он особенно удобен, если имеется несколько клиентов с одинаковыми видеокартами.

Для этого необходимо указать в параметре XF86CONFIG_FILE = XF86Config.term1 имя конфигурационного файла для данного клиента и поместить его в каталог /opt/ltsp/i386/etc/X11/ (предварительно создав каталог Х11). Мне в этом смысле немного повезло, на одном из клиентских компьютеров до этого стоял Linux, поэтому генерировать данный файл заново не пришлось. Если у вас другая ситуация, то попробуйте использовать программу /usr/X11R6/bin/xf86config на сервере, установив туда нужную видеокарту (не забудьте сохранить при этом оригинальные файлы). Дополнительно можно переопределить параметры клавиатуры, используемые по умолчанию. Для этого предназначены следующие опции:

  • XkbModel – модель клавиатуры, наиболее распространенные – pc 101, pc 102, pc 105;
  • XkbLayout – раскладка клавиатуры, например us (по умолчанию), ru, ru(winkeys);
  • XkbSymbols – таблица скан-кодов, по умолчанию «us(pc 101)», но можно заменить, например на «us(pc105) + ru».

Раз уже коснулись раскладки клавиатуры, то два слова о том, как использовать русскую. Для установки и переключения на русский вариант (в рассматриваемом случае) раскладки клавиатуры в XFree86 применяется два параметра XkbLayout и XkbOptions. Первый, как уже отмечалось, можно переопределить, а вот для того чтобы была возможность переключаться между раскладками, необходимо выполнить еще некоторые действия. Все настройки, касающиеся параметров XFree86 во всех Linux производятся в файле XF86Config для версии 3 и в XF86Config-4 для четвертой версии. Но для терминалов таких файлов изначально не существует, они генерируются динамически при запуске. Для этих целей используется скрипт /opt/ltsp/i386/etc/rc.setupx3 для клиентов с версией 3 и /opt/ltsp/i386/etc/rc.setupx для четвертой версии, которые, кстати, берут основные параметры для настройки из файла lts.conf. Так вот, для того чтобы переключатель заработал, необходимо после строки XkbLayout «${XkbLayout}» для rc.setupx3 или Option «XkbLayout» «${XkbLayout:-»us»}» для rc.setupx прописать параметр, устанавливающий комбинацию для изменения раскладки, например:

  • XkbOptions «grp:caps_toggle» – переключение по Caps Lock;
  • XkbOptions «grp:alt_shift_toggle» – более привычное для пользователей Windows переключение по Alt + Shift.

Вот и все. Самое интересное, что это действительно работает. На клиентском компьютере загрузить даже KDE с OpenOffice и причем с вполне терпимой скоростью, после перехода на оконный менеджер IceWM и запуска аналога OpenWritera от GnomeOffice – AbiWord система вообще летала. Конечно, при увеличении количества клиентов до 10 желателен сервер помощнее, как минимум оперативной памяти 512 Мб. Наиболее очевидное применение данной технологии – это наши учебные заведения со старыми компьютерными классами, где добавление одного мощного компьютера позволит работать с современным ПО. В организации интернет-кафе с помощью технологии LTSP поможет скрипт: http://prdownloads.sourceforge.net/ltsp/ltsp_phpSiCafe-0.0.1.tgz, назначение которого – учет времени, проведенного пользователями за компьютером. Заинтересовавшимся советую также заглянуть еще на два сайта. Первый http://k12ltsp.org, этот проект предназначен для установки терминального сервера, разработанного для школ, базируется на дистрибутиве Red Hat. Второй http://www.ltsp.ru, как видно из названия, русский сайт проекта. Здесь уже можно найти переводную документацию по работе с бездисковыми станциями, описание установки виртуальной машины VMWare для запуска приложений, написанных под Windows.

Все это, конечно, интересно и работает уже более года, но совсем недавно познакомившись с проектом OpenMosix (http://openmosix.sourceforge.net), предлагающим OpenSource-решение создания кластерных систем на основе компьютеров, соединенных в единую сеть. OpenMosix представляет собой расширение к обычному ядру Linux, при его установке узлы в кластере начинают «общаться» с друг другом, и кластер адаптирует себя к рабочей нагрузке. Процессы, обрабатывающиеся на любом из узлов, при увеличении нагрузки данного компьютера по сравнению с другими способны передаваться на любой другой компьютер кластера. OpenMosix постоянно пытается оптимизировать распределение ресурса между машинами, при этом новый узел может быть добавлен «на лету» и автоматически будет подхвачен кластером. Так как все openMosix расширения выполняются внутри ядра, каждое из приложений, автоматически извлекает выгоду из распределенной вычислительной концепции openMosix. Кластер ведет себя фактически как многопроцессорная система, правда без ограничения на их максимальное число. И естественно возникло желание испытать это все в деле, тем более что большая часть работы уже проделана.

Как и в приведенном выше примере, один из компьютеров играет роль главного (master), а остальные, сколько есть, подчиненные (slave). Для работы понадобятся сами ядра с патчем от openMosix и инструменты для работы openmosix-tools. Все это можно найти на странице http://prdownloads.sourceforge.net/openmosix, где доступны как сами патчи, так и уже перекомпилированые (серверные) ядра для разных платформ, причем уже доступны патчи для ядер серии 2.6. Мы будем устанавливать при помощи патча, самостоятельно компилируя все ядра.

Для этого берем ядро 2.4.22:

# wget -c http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.22.tar.bz2

# wget -c http://tab.tuxfamily.org/download/openmosix/patch-2.4.22-om-20030811.bz2

Теперь все разархивируем:

# tar -xjvf  - linux-2.4.22.tar.bz2

# cd  linux-2.4.22

# bzcat ../patch-2.4.22-om-20030825.bz2|patch -p1

# ln -sf /path/to/linux-2.4.22  /usr/src/linux

Теперь заходим в него:

# cd /usr/src/linux

Конфигурируем серверное ядро:

# make xconfig {menuconfig, gconfig}

И смотрим, чтобы следующие пункты были включены в ядро, а не в виде модулей:

openMosix ---

    openMosix process migration support

    openMosix File-System

Networking options ---

    Packet Socket

    Socket Filtering

    TCP/IP networking

    IP: multicasting

File systems ---

    /proc file system support

Network File Systems ---

    NFS file system support

    NFS server support

    Provide NFSv3 server support

И компилируем новое ядро:

# make dep

# make bzImage && make modules && make modules_install

Для ядер серии 2.6 достаточно ввести make all.

Копируем ядро на свое место:

# mv arch/i386/boot/bzImage /boot/vmlinuz-openmosix

Конфигурируем загрузчик для работы с новым ядром, и после перезагрузки система будет готова. Если установка производится при помощи перекомпилированных пакетов, все вышеописанное (кроме настройки загрузчика) будет в систему добавлено автоматически. Для этого вводим:

# rpm -ivh openmosix-kernel-2.4.22-openmosix1.i686.rpm

Установка slave-ядра

Для начала сохраняем конфигурационный файл основного ядра.

# cp /usr/src/linux/.config /usr/src/linux/.config_master

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

Следующие опции нужно включить в ядро.

openMosix ---

    openMosix process migration support

    openMosix File-System

Networking options ---

    TCP/IP networking

    IP: kernel level auto-configuration

    IP: DHCP support

    IP: BOOTP support

File systems ---

    /proc file system support

Network File Systems ---

    NFS file system support

    Provide NFSv3 client support

    Root file system on NFS

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

# cp /usr/src/linux/arch/i386/boot/bzImage/tftpboot/lts/vmlinuz-openmosix-slave

И настраиваем его загрузку описанным выше способом. В принципе для этого не обязательно иметь установленный полный пакет ltsp, а все необходимое создать вручную, как это все сделать, можно найти в дополнительной литературе, указаной в конце статьи. Но все равно, для того чтобы избежать большого количества ручной работы, советую в таком случае скачать файл ltsp_initrd_kit и ltsp_util_src (http://prdownloads.sourceforge.net/ltsp/ltsp_initrd_kit-3.0.11-i386.tgz и http://prdownloads.sourceforge.net/ltsp/ltsp_util_src-3.0.0-i386.tgz).

Все, что мы делали до сих пор, фактически не отличается от предыдущего варианта ядра. Чтобы заставить компьютеры работать в одной связке и обмениваться нагрузкой, необходимо установить пакет openmosix-tools. Его также можно получить уже в виде перекомпилированных пакетов или все это проделать самому. Ничего особенного в компиляции нет:

# ./configure –with-kerneldir=/usr/src/linux

Флагом -with-kerneldir указываем путь к исходным файлам ядра, по умолчанию /usr/src/linux-openmosix:

# make && make install

Или строим пакет для rpm-based дистрибутивов:

# rpmbuild -ta openmosix-tools-0.3.4.tar.gz

После окончания установки приступаем к настройке. Для начала в файле /etc/openmosix.map, определим узлы, которые будут задействованы в кластере. Каждая строка в этом файле состоит из трех частей:

1   192.168.0.1  1

2   192.168.0.100 10

Первым идет openMosix node-number узла в указанном диапазоне, второй строкой – IP-адрес или имя, описанное в файле /etc/hosts, и третьей – количество узлов в этом диапазоне. В данном примере нашему серверу присвоен openMosix node-number 1, а десяти узлам в диапазоне 192.168.0.100-192.168.0.109, номера 2-11. Если бы IP-адреса шли подряд, то можно было бы обойтись и одной строкой. После правки файла делаем его доступным и другим узлам.

# cp /etc/openmosix.map /opt/ltsp/i386/etc/

Туда же копируем и бинарные файлы openmosix-tools.

# cp /sbin/setpe /opt/ltsp/i386/sbin/

# cp /bin/mosrun /opt/ltsp/i386/bin/

# cp /bin/mosmon /opt/ltsp/i386/bin/

# cp /bin/mosctl /opt/ltsp/i386/bin/

# cp /bin/migrate /opt/ltsp/i386/bin/

# cp /etc/rc.d/init.d/openmosix /opt/ltsp/i386/etc/rc.openmosix

И запускаем openМosix:

# /etc/init.d/openmosix start

После перезагрузки slave-узлов работу можно проконтролировать при помощи утилиты mosctl, введя номер нужного:

# mosctl status 2

А в файле /etc/inittab рекомендуется строку:

si::sysinit:/etc/rc.d/rc.sysinit

заменить на:

si::sysinit:/bin/mosrun -h /etc/rc.d/rc.sysinit

Чтобы избежать проблем при использовании сервиса SSH в файле /etc/rc.d/init.d/sshd в функции start(), добавьте следующую линию:

test -f /proc/$$/lock && echo 0 > /proc/$$/lock

Вот и все. Остается пожелать успехов, и я надеюсь, эта статья кому-то поможет.

Кроме документации на сайтах проектов LTSP и openMosix советую просмотреть еще и следующие документы:

  1. Колисниченко Д. Загрузка по сети. – Журнал «Системный администратор», №9(10), 2003 г. – 47-49 с. 
  2. LTSP + openMosix: Integration How-To: http://home.onestop.net/jjensen/ltsp-om5r3c.html
  3. openMosix and Diskless Nodes: http://www.gentoo.org/doc/en/openmosix-howto.xml

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru