15.07.2007

Стратегии относительно Open Source

Если внимательно присмотреться, то оказывается, что компании по их отношению к open source можно разделить на 7 основных категорий:

  1. Приверженцы
  2. Со смешанной базой кода
  3. Прагматики
  4. Со стратегией «анти»
  5. «Обезглавленные цыплята»
  6. Отрицающие
  7. Противники

Первая категория - «приверженцы» - это компании, которые считают open source своей основной стратегией. Они делают свои продукты открытыми, строят свои решения на open source.

Подход таких компаний – open source дает принципиальные преимущества (разумеется, для разных компаний разные), поэтому они принципиально ориентируются на него. Примеры успешных компаний с такой стратегией – Red Hat, JBoss, MySQL. В последнее время появляется довольно большое количество новых компаний с подобной стратегией. Причина, по которой они становятся приверженцами open source, очень проста – такая стратегия позволяет им очень быстро стартовать и занимать новые ниши.

Вторая категория - «со смешанной базой кода» - это компании, которые в заметной степени участвуют в развитии open source, но при этом критично важные для них источники дохода связаны с проприетарными продуктами. Из-за этого они не могут быстро переключиться на первую стратегию. Однако такие компании осознают преимущества open source и не только используют его в своих проектах, но и активно участвуют в разработке тех или иных открытых программ.

Наиболее ярким примером такой компании является Novell. С одной стороны, компания создает дистрибутив SuSe и участвует во многих других open source проектах. Но, с другой стороны, основную прибыль компания получает от продажи своих проприетарных продуктов, из-за чего нельзя гарантировать постоянство ее интереса к Linux.

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

Третья категория - «прагматики» - делают много заявлений о своей приверженности open source, хотя при этом вносят крайне малый вклад в открытые проекты (если вносят хотя бы какой-то).

Как правило, эти компании разрабатывают проприетарные продукты используя open source как платформу для них. Причина такого подхода предельно проста – это наиболее дешевый способ заявить, что компания поддерживает open source, использовать «модную» тему open source, но при этом не нести никаких рисков. Особенно удобно использовать такую стратегию, если на своем основном рынке компания не сталкивается с конкуренцией со стороны open source. Наиболее известный пример такой компании – Oracle, использующий Linux как основную платформу для своих продуктов.

Четвертая категория – компании со стратегией «анти». Эти компании крайне похожи на компании «со смешанной базой кода» - и те, и другие участвуют в открытых проектах и поддерживают open source. Но между ними есть одна принципиальная разница. Компании «со смешанной базой кода» рассматривают open source как средство развития компании (ускорение разработки, более простой выход на рынок и т.д.), в то время как компании «со стратегией анти» рассматривают open source в первую очередь как средство борьбы со своими конкурентами. То есть open source для них средство борьбы за рынок, но не более того, внутренней ценности для таких компаний open source не представляет. Изначально именно к этой категории можно было отнести IBM (использование Linux против Windows), хотя сейчас это уже не столь очевидно.

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

Как правило, это бывшие компании-«отрицающие» (см. ниже), которые внезапно обнаружили, что конкуренты, опирающиеся на open source, крайне быстро и эффективно вытесняют их с рынка. В такой ситуации компании начинают метаться между различными стратегиями в отношении open source, не имея при этом четкого понимания целей. Типичные действия таких компаний – открытие кода никого не интересующих продуктов, создание «open source версий» для образовательных учреждений, присоединение к случайным open source проектам из исключительно маркетинговых соображений. Основная цель при этом – заполнить чем-то «стратегический вакуум» и вернуть себе место на рынке. В отличие от куриц, компании при должном управлении вполне могут оправиться.

Шестая категория - «отрицающие» - компании, предпочитающие не замечать open source, и упоминать его как можно меньше. Как правило, если в разговоре с представителями такой компании возникает тема open source, они предпочитают отделывать общими фразами. Эту стратегию, как и стратегию «со смешанной базой кода», скорее всего, стоит рассматривать лишь как временную. Если компания слишком долго не предпринимает никаких шагов по смене стратегии, то рано или поздно она попадает в предыдущую категорию.

Седьмая и последняя категория - «противники». На самом деле, не так много компаний принадлежат к этой категории, ведь, учитывая растущую популярность open source, такой подход может выйти боком. Наиболее заметной компанией с такой стратегией является Microsoft. Честно говоря, их приверженностью непопулярной стратегии можно даже восхищаться. Но и они понимают, что слишком явно высказывать такую позицию не стоит, и пытаются смягчить ее. Например, указывая на примеры кода из MSDN (библиотека для разработчиков) как на «open source».

В целом, стабильны в долговременной перспективе лишь стратегии 1, 3 и 7. Также при некоторых условиях могут быть стабильны стратегии 2 и 4. Стратегии 5 и 6 не жизненны, так как open source стало слишком заметным явлением, чтобы его просто игнорировать.

А к какой категории принадлежит Ваша компания? ;-)

01.07.2007

Автоматизация развертывания RHEL. Неинтерактивная инсталляция.

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

Такая технология давно существует в стенах Red Hat и имя ей KickStart. Сегодня мы рассмотрим эту технологию и ее применений на примере сетевой инсталляции RHEL5. Операционная система сервера в примере – RHEL4, но может быть произвольной.

Итак, создаем kickstart-файл.

Что такое kickstart-файл? Kickstart-файл – это сценарий установки. «У меня все ходы записаны». То есть сценарий установки подразумевает заранее записанные в определенном формате ответы на вопросы инсталлятора. Добавьте возможность выполнять собственные скрипты до и после установки и вы получите более-менее полное представление о возможностях kickstart. Приведем простой пример ks-файла

  1. install
  2. url --url ftp://192.168.0.2/redhat/disk1
  3. key [installation number]
  4. lang en_US.UTF-8
  5. keyboard us
  6. xconfig --startxonboot --defaultdesktop kde --resolution 1400x1050 --depth 32
  7. network --device eth0 --bootproto dhcp --onboot=on
  8. rootpw --iscrypted $1$vFt/3HTE$N16kauXMVOmNHurppHAo0/
  9. firewall --disabled
  10. authconfig --useshadow --enablemd5
  11. selinux --disabled
  12. timezone --utc Europe/Moscow
  13. bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
  14. #
  15. clearpart --all --initlabel
  16. part /boot --fstype ext3 --size=100 --asprimary
  17. part pv.100001 --size=20000 --asprimary
  18. part pv.100000 --size=20000 --asprimary
  19. part pv.100002 --size=1 --grow --asprimary
  20. volgroup sysvg --pesize=32768 pv.100000 pv.100001 pv.100002
  21. logvol swap --fstype swap --name=swap --vgname=sysvg --size=2000
  22. logvol /home --fstype ext3 --name=home --vgname=sysvg --size=1 --grow
  23. logvol / --fstype ext3 --name=root --vgname=sysvg –size=20000
  24. firstboot --disable
  25. reboot
  26. #
  27. %packages
  28. @admin-tools
  29. @base
  30. @core
  31. @system-tools
  32. @text-internet
  33. @web-server
  34. #
  35. %post
  36. #!/bin/bash
  37. useradd -m -s /bin/bash -G wheel vpupkin

А теперь разберем его. Для удобства строки пронумерованы и я буду просто ссылаться на номера. В строчках [1-3] мы определяем, что это будет чистая инсталляция (не обновление) , местоположение дистрибутива (если быть точным – первого диска дистрибутива) и задаем инсталляционный номер.

Далее [4-5] мы указываем язык системы и тип клавиатуры. Нотация стандартная, то есть чтобы установить русский язык системы надо исправить en_US.UTF-8 на ru_RU.UTF-8.

В [6] мы конфигурируем X.org сервер, задавая рабочий стол по умолчанию (KDE), разрешение и глубину цвета, а также определяем, что X.org должен стартовать при загрузке.

В [7] находится простая сетевая конфигурация, определяющая, что у нас единственная сетевая карта, которая использует DHCP для получения сетевых настроек. Это рекомендованный вариант, так как в случае, если вы устанавливаете много систем с одного kickstart-файла, вы не можете использовать одни и те же сетевые настройки. Кроме того, DHCP-сервер в любом случае является необходимым для сетевой инсталляции.

В [8] мы устанавливаем административный пароль (он заранее зашифрован).

В [9] и [11] мы отключаем брандмауэр и мандатный контроль доступа соответственно (не будем забывать, что мы рассматриваем простой пример).

В [10] мы конфигурируем стандартную аутентификацию через /etc/passwd и /etc/shadow с шифрованными паролями. В этой строке возможно заранее сконфигурировать аутентификацию с использованием Kerberos, LDAP, NIS, или Windows-домена.

В [12] мы задаем временную зону, а в [13] задаем положение загрузчика, опции передаваемые ядру и, если у вас более одного жесткого диска – порядок следования их в BIOS системы.

Строки [13-21] задают разметку диска. В нашем случае создается одна 100Мб ext3-партиция /boot для ядра, initrd и загрузчика, остальное место размечается на 3 партиции, поверх которых располагается LVM, на котором выделяется 20Гб том под основную систему (/), 2Гб под место для подкачки, а остальное место монтируется как /home для данных пользователей.

Строки [24-25] отключают агент настройки системы при первой загрузке и указывают, что системы должна перезагрузиться после установки.

Строки [27-31], как это видно, находятся в области %packages, и определяют пакеты и группы пакетов, которые должны быть установлены. Синтаксис простой: имя пакета, чтобы установить один пакет (например dhcp) и @имя_группы, чтобы установить определенную группу пакетов.

Оставшиеся строки (секция %post) – постинсталляционный скрипт. В нашем случае он просто добавляет пользователя vpupkin. Вообще говоря, это может быть произвольный скрипт, который обновляет систему, скачивает и устанавливает конфигурацию или выполняет прочие произвольные действия.

Использование ks-файла

Теперь наш kickstart-файл готов к использованию. Осталось разместить его на сервере и передавать параметром при установке. Я предполагаю, что у вас сетевые службы настроены в соответствии с описанием в предыдущем выпуске рассылки.

Сохраните ваш kickstart-файл куда-нибудь на сервер. Я разместил его в /var/ftp/rhel-ks.cfg и, соответственно, он стал доступен по сети по адресу ftp://192.168.0.2/rhel-ks.cfg. Осталось «сообщить» об этом примечательном факте загружающимся по PXE системам. Для этого изменим файл '/tftpboot/prelinux.cfg/default' так, чтобы он содержал следующую информацию:
label linux
kernel vmlinuz
append initrd=initrd.img ramdisk_size=9216 noapic acpi=offo ks=ftp://192.168.0.2/ks.cfg

На этом конфигурация заканчивается. Если вам необходимо установить 1000 типовых рабочих станций за день – это не более трудная задача, чем нажать кнопку «Power» на 1000 компьютерах.

Удобности и вкусности.

Естественно, механизм kickstart чрезвычайно удобен для проведения типовых инсталляций. Однако писать сценарий установки не всегда удобно вручную. Для этого существует инструмент system-config-kickstart (входит в поставку RHEL), который в окошке, похожем на этапы инсталляции позволит сформировать костяк конфигурационного файла. Фактически ручного редактирования требует только секция разметки диска и постинсталляционные действия.

Инструментарий kickstart очень удобно интегрирован в RHN. Вы можете сгенерировать сценарий по установленной ранее системе, а также пользоваться каналами конфигурации для приведения типовых систем в боевую готовность непосредственно от состояния «голое железо» (Bare HW).

Полную информацию о синтаксисе kickstart-файлов вы можете почерпнуть по адресу
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation...

20.06.2007

Безопасность. В чем ее мерить?

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

Основным аргументом, как правило, служат результаты независимых исследований. Что ж, разумно. Но все же, пожалуй, стоит посмотреть, насколько эти исследования отражают реальную картину.

Одним из основных источников информации об уязвимостях служит база NVD (National Vulnerability Database), поддерживаемая комитетом при правительстве США. Эта база содержит полный список всех известных уязвимостей во всех программных продуктах и их рейтинги критичности. Рейтинги могут иметь значение «Высокий», «Средний» и «Низкий» в зависимости от того, насколько опасной признана уязвимость.

Инженеры Red Hat провели сравнение уязвимостей, относящихся к Red Hat Enterprise Linux 4 за последние 12 месяцев, по данным NVD и по данным Red Hat.

В Red Hat используют чуть другую систему оценки критичности уязвимостей - «Критичная», «Важная», «Средняя» и «Второстепенная». К «Критичным» уязвимостям относятся те, которые могут быть использованы без участия пользователя. Именно эти уязвимости представляют наибольшую опасность, так как от любых других можно защититься грамотными политиками безопасности.

Теперь посмотрим на результаты сравнения. NVD присвоила рейтинг «Высокий» 90 уязвимостям, относящимся к Red Hat Enterprise Linux 4. Рейтинги Red Hat для этих уязвимостей:

23 - «Критичная»
24 - «Важная»
35 - «Средняя»
8 - «Второстепенная»

NVD присвоила рейтинг «Средний» 61 уязвимости. Рейтинги Red Hat для этих уязвимостей:

9 - «Критичная»
18 - «Важная»
22 - «Средняя»
12 - «Второстепенная»

NVD присвоила рейтинг «Низкий» 152 уязвимостям. Рейтинги Red Hat для этих уязвимостей:

7 - «Критичная»
32 - «Важная»
62 - «Средняя»
51 - «Второстепенная»

Таким образом, мы видим, что среди уязвимостей, которым NVD присвоила высший рейтинг, меньше четверти были критичными для Red Hat Enterprise Linux. При этом среди неопасных по мнению NVD уязвимостей были критичные для RHEL.

Почему же так происходит? На самом деле, ничего странного в этом нет. Дело в том, что NVD содержит один рейтинг для каждой уязвимости вне зависимости от платформы, на которой работает приложение.

Рассмотрим популярный web-сервер Apache. Он работает на множестве платформ (Linux, Windows, FreeBSD и т.д.), многие компании включают его в свои продукты. При этом, например, одна и та же уязвимость в нем приводила к исполнению произвольного кода под FreeBSD, вызывала отказ в обслуживании под Windows, но ей нельзя было воспользоваться под Linux. При этом в базе NVD у нее был один рейтинг, на зависящий от платформы.

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

Что же делать в такой ситуации? Как сравнивать защищенность различных платформ? Путь здесь один – поставщики должны регулярно предоставлять полностью прозрачные отчеты по безопасности с разбором всех уязвимостей. Red Hat такие отчеты предоставляет. Надеемся, другие поставщики последуют его примеру.

14.06.2007

Linux реального времени

Термин «реальное время» при обсуждении тех или иных систем сегодня употребляется в таком количестве значений, что уже часто невозможно понять, о чем именно идет речь. В большинстве заявлений «реальное время» означает «очень быстро» и не более того. Но, вообще говоря, изначально «реальное время» означает больше, чем просто быстро.

Система реального времени – это система, которая гарантирует, что выполняемая задача будет получать процессорное время не реже, чем через заданный промежуток. Это не так просто гарантировать, когда речь идет о миллисекундах. А уж если о микросекундах...

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

Системы общего назначения, например Red Hat Enterprise Linux, фокусируются на производительности. Все устройство системы подчинено этой цели – достижение максимальной общей производительности. Но в результате в работе отдельных приложений могут иногда возникать задержки. В подавляющем большинстве случаев задержка в несколько десятых долей секунды – это абсолютно нормально, она даже не будет замечена. Но не в системах реального времени.

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

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

Но, тем не менее, есть области, где системы реального времени необходимы. Это управление производственными процессами на заводах, управление на транспорте и подобные задачи. В этих областях подход «достаточно быстро» неприемлем, здесь нужны гарантированные сроки. Кроме того, системы реального времени становятся все более актуальными в финансовом секторе. В этой области «время – деньги» в буквальном смысле слова. И по мере распространения автоматизированных торговых систем и электронных платежных систем работа банковских систем в реальном времени становится все более актуальной.

Около 2 лет назад Red Hat выдвинул инициативу по включению в основную ветку ядра Linux поддержки работы в реальном времени. До этого существовали проекты использования Linux в системах реального времени, но все они использовали нестандартный инструментарий, не включенный в основное ядро. Это упрощало и ускоряло разработку, но в итоге они оказывались не совместимы с основной веткой, на них не работали многие приложения.

Red Hat выбрал иной подход. Инженеры Red Hat в течение долгого времени работали над включением поддержки работы в реальном времени в основную ветку ядра. Их успехи вдохновили других разработчиков ядра присоединиться к проекту. Сейчас силами инженеров Red Hat, IBM и независимых разработчиков уже проделан большой объем работ.

Разработка продолжается, в ближайшем будущем Red Hat представит Red Hat Enterprise Linux реального времени. Как было указано выше, работа в реальном времени принесет пользу далеко не всем пользователям, поэтому Red Hat будет предлагать две версии дистрибутива – систему общего назначения и систему реального времени.

Если Вы заинтересованы в Linux реального времени, Вы всегда можете присоединиться к проекту.

01.06.2007

Построение инфраструктуры для масштабного развертывания RHEL

Какой самый интуитивный и простой способ установить операционную систему на компьютер? Разумеется взять DVD-диск, вставить его, ответить на несколько вопросов, после чего подождать порядка получаса, и приступить к конфигурации системы.

Это хорошо, когда вся ваша инфраструктура представляет из себя один-два сервера. При большем количестве систем или в ситуации, когда типовую установку ОС приходится выполнять достаточно часто, такой подход становится неудобным. Ниже мы приводим сценарий подготовки развертывания Red Hat Enterprise Linux по сети. Все примеры будут приводиться для установки Red Hat Enterprise Linux 5. Операционная система сервера – RHEL4/5.

PXE-загрузка

Данный этап является наиболее сложным и плохо документированным. А между тем грамотная настройка PXE-окружения является наиболее важным компонентом работающей инфраструктуры развертывания.

Необходимые компоненты:

  1. DHCP сервер.
  2. TFTP сервер.
  3. Созданные нами файлы и настройки.

Итак, по-порядку. TFTP-сервер.

Сначала настроим TFTP-сервер. (TFTP – Trivial File Transfer Protocol, простой протокол передачи файлов, работающий через UDP.)

  1. Убедитесь, что в системе, которая будет TFTP-сервером, установлены пакеты tftp-server и xinetd. Проверяется это так:
    $ rpm -qi tftp-server
    $ rpm -qi xinetd
    Если вы получили информацию по этим пакетам, то они у вас установлены. В противном случае их необходимо установить.
    # yum -y install xinetd tftp-server (RHEL5)
    # up2date install xinetd tftp-server (RHEL4)
  2. Разрешите в конфигурации xinetd запуск tftp в качестве сервиса по требованию. Для этого откройте файл /etc/xinet.d/tftp
    И исправьте там строчку
    disable = yes
    на
    disable = no
  3. В конфигурации по умолчанию корневой директорией для tftp-сервера является директория /tftpboot/
    Туда нам необходимо перенести файлы, необходимые для начала инсталляции. Установите пакет syslinux и перенесите PXE-загрузчик в директорию /tftpboot/
    # yum install syslinux
    # cp /usr/lib/syslinux/pxelinux.0 /tftpboot/
  4. Далее нам необходимо поместить в /tftpboot/ ядро и initrd для системы, которую мы желаем устанавливать по сети. Обычно такая возможность предусмотрена и нужные файлы есть на образах инсталляционных дисков. Итак, смонтируйте образ диска:
    # mount -o loop /[путь к директории с образами]/rhel-5-server-i386-disc1.iso /mnt
    # cp /mnt/images/pxeboot/{vmlinuz,initrd.img} /tftpboot/
  5. Осталось сделать конфигурацию для загрузчика. Отредактируйте файл
    /tftpboot/pxelinux.cfg/default
    Содержимое этого файла для рассматриваемого случая будет следующим:
    default linux
    prompt 1
    timeout 100

    label linux
    kernel vmlinuz
    append initrd=initrd.img ramdisk_size=9216

    Для тех, кто сталкивался с конфигурированием lilo, конфигурация, должно быть, выглядит знакомо. Для тех, кто не имел подобного опыта, краткое описание:
    default– метка записи, загружаемой по умолчанию
    prompt – надо ли давать возможность выбора
    timeout – время, после которого default запись будет загружена
    label – метка, название конфигурации. Может быть произвольной.
    kernel – путь к файлу ядра. Путь задается относительно директории /tftpboot/
    append – различные опции, передаваемые ядру, в том числе и файл initrd
  6. На этом базовая конфигурация TFTP-сервера закончилась. Запустите сервис xinetd и (опционально) добавьте его в автозагрузку.
    # service xinetd start
    # chkconfig xinetd on

DHCP-сервер

DHCP-сервер нужен для того чтобы при PXE загрузке сообщить новой системе параметры сети и передать информацию, необходимую для сетевой установки. Желательно, чтобы DHCP-сервер и TFTP-сервер находились в пределах одной сети. Если у вас уже есть работающий вариант DHCP-сервера, то вам достаточно просто добавить несколько опция для нужных IP-адресов. Ниже приведем простейшую конфигурацию с комментариями

ddns-update-style interim;
ignore client-updates;

subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.0.2;
option time-offset 10800; # GMT+3
range dynamic-bootp 192.168.0.4 192.168.2.254;
default-lease-time 21600;
max-lease-time 43200;
next-server 192.168.0.2;
filename "pxelinux.0";
}

Итак, по порядку. Опции routers, subnet-mask, domain-name, domain-name-servers аналогичны сетевым настройкам Default Gateway, Network Mask, DNS Domain name и DNS Servers. Адаптируйте их в соответствии со своими параметрами. Опция time-offset – разница во времени с Гринвичем в секундах. range dynamic-bootp – диапазон выдаваемых адресов, default-lease-time и max-lease time – времена в секундах аренды адреса по умолчанию и максимальное время аренды соответственно. Наиболее интересующие нас параметры:

next-server – IP-адрес TFTP-сервера
filename – путь к файлу PXE-загрузчика (относительно каталога /tftpboot/)

На данном этапе ваши компьютеры должны уже «уметь» загружаться по сети и запускать инсталлятор. Для полного процесса установки нам не хватает только дистрибутива, доступного в сети.

Установочный репозитарий

В процессе установки установочный репозитарий необходим для того, чтобы предоставить инсталляторам, которые могут работать параллельно, доступ к дистрибутиву и избавить пользователя от необходимости создания нескольких копий (например записывать диски). Репозитарий можно располагать на FTP, HTTP и NFS серверах. Мы рассмотрим одну из этих конфигураций, остальные выполняются аналогично.

FTP-сервер

Конфигурация проста. Пример ниже приведен для установки RHEL5. Если у вас другая версия – обратитесь к документации по дистрибутиву. Предполагается что у вас есть 5 образов, скачанных c RHN. Для некоторых версий и архитектур количество может отличаться.

  1. Создайте директории для монтирования этих образов.
    # for i in $(seq 1 5); do mkdir -p /var/ftp/rhel5-server-x68/disk${i}; done
  2. Смонтируйте образы в созданные директории. Обратите внимание, что из-за внутренних ограничений ядра Linux число одновременно смонтированных образов не может превышать 8. Таким образом, если вы хотите обеспечить окружения для инсталляции более чем одной версии, лучшим выбором будет скопировать содержимое образов в эти директории. В нашем случае монтирование быстрее и не требует дополнительного дискового пространства.
    # for i in $(seq 1 5); do mount -o loop [путь к директории с образами]/rhel-5-server-i386-disc${i}.iso /var/ftp/rhel5-server-x68/disk${i}; done
  3. Проверьте, что у вас включен анонимный ftp и корневой директорией для vsftpd является /var/ftp (В RHEL это настроено по умолчанию). Запустите сервис FTP и (опционально) добавьте его в автозагрузку.
    # service vsftpd start
    # chkconfig vsftp on
  4. Проверьте доступность ресурса, напрмимер с помощью браузера по URL
    ftp://[ваш FTP-сервер]/rhel5-server-x86/disk1
    Вы должны увидеть содержимое инсталляционного образа CD #1. Если этого не произошло, проверьте выполнение предыдущих пунктов еще раз.

Конец

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