Сергей Яремчук
Втоая жизнь старых компьютеров

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

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

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

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

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

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

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

¦ Снижение стоимости и упрощение операции обновления программного обеспечения, так как это производится только на одном компьютере.

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

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

¦ UPS можно предоставить только серверу.

¦ Также будет существенно ниже общая цена – экономия = (стоимость жесткого диска + стоимость CD-ROM + стоимость флоппи-дисковода) * количество компь- теров.

¦ Защищать от вирусов необходимо только сервер, так как другие компьютеры не имеют жесткого диска.

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

¦ Большая долговечность клиентских машин как моральная, так и физическая.

¦ Возможность работы в запыленных помещениях (здесь желателен «холодный» процессор типа VIA СЗ, ЖК монитор).

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

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

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

¦ 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*-KapTy». Пришлось раскрывать корпус одного из компьютеров и смотреть, что там такое установлено, заодно и сам узнал марку чипа – rtl8029. В меню «Choose ROM output format» выберите интересующий формат.

Доступны следующие варианты образов:

¦ Floppy Bootable ROM Image (.Izdsk) – загрузчик с дискеты (на первом этапе лучше воспользоваться именно им).

¦ Binary ROM Image (.Izrom) – прошивка ПЗУ сетевой карты.

¦ LILO Bootable ROM (.Izlilo) – загрузка с использованием LILO.

¦ DOS Executable ROM Image (.com) – DOS-загрузчик тоже подходит, только уберите загрузку himem.sys и emm386.exe, а то работать, скорее всего, не будет, и добавьте соответствующие строки в файл config.sys для загрузки.

¦ РХЕ loadable ROM Image (.Izpxe) – то же, что и второй пункт, но разработки Intel.

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

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

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

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

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

¦ lts pcore – основной пакет , необходимый для работы;

¦ lts pkernel – ядро , загружаемое на клиентский компьютер;

¦ lts px core – пакет, необходимый для запуска X- Window версии 4.x на клиентском компьютере;

¦ lts px fonts – пакет со шрифтами (скачал по рекомендации на сайте, но вполне можно обойтись и без него).

Если видеокарта не поддерживается в версии 4.x, необходимо дополнительно выбрать пакет с версией сервера 3.3.6 применительно к видеокарте, установленной на ваших клиентских компьютерах (в моем случае это Its px336 s3), или, если нет, то Its px336 svga, но при этом не будут работать ТгueТуре-шрифты и сглаживание. На сайте также доступны пакеты для поддержки звука, сканера, веб-камер и wireless-устройств на терминале, пакеты для организации Windows-терминала и еще много чего. Первым обязательно должен быть установлен пакет lts pcore . Установка заключается в распаковке (tar xvzf) и запуске инсталляционного скрипта (cd lts pxxx , ,/install.sh). Остальные устанавливаются аналогично. Для rpm-пакетов просто дайте команду:

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

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

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

Для того чтобы правильно е

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

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

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

Далее идут индивидуальные настройки для каждого компьютера клиента. Здесь можно переопределить настройки сервера индивидуально. В строке 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 указать каталоги, доступные для сетевого монтирования:

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

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

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

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

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

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

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

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

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

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

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

на

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

на

и строку:

на

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

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

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

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

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

¦ XkbModel – модель клавиатуры, наиболее распространенные – рс 101, рс 102, рс 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 и /о pt /I t s р/ i 3 8 б/et с/ г с. s et и рх для четвертой версии, которые, кстати, берут основные параметры для настройки из файла Its.conf. Так вот, для того чтобы переключатель заработал, необходимо после строки XkbLayout «${XkbLayout}» для rc.setupx3 или Option «XkbLayout» «${XkbLayout:-»us»}» для rc.setupx прописать параметр,

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

¦ XkbOptions «grp:cap stoggle» – переключение по Caps Lock;

¦ XkbOptions «grp:al tshift toggle» – более привычное для пользователей Windows переключение по Alt + Shift.

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

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

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

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

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

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

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

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

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

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

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

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

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

И настраиваем его загрузку описанным выше способом. В принципе для этого не обязательно иметь установленный полный пакет Itsp, а все необходимое создать вручную, как это все сделать, можно найти в дополнительной литературе, указаной в конце статьи. Но все равно, для того чтобы избежать большого количества ручной работы, советую в таком случае скачать файл lts pinitrd kit и lts putil src ( http://prdown loads .sou reef orge. n et/ltsp/lts pin itrd kit-3.0.11- i386.tgz и http://prdownloads.sourceforge.net/ltsp/lts putil src- 3.0.0-i386.tgz).

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

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

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

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

И запускаем openMosix:

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

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

заменить на:

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

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

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