5.1 Планирование установки Linux (Designing a Linux Installation)¶
Если вы читаете эту книгу, скорее всего, вы — технический специалист. Вы любите компьютеры и не боитесь новых технологий. Вам интересно исследовать новшества в аппаратном и программном обеспечении и экспериментировать с ними. Самый радостный момент вашей недели — когда большой коричневый грузовик службы доставки привозит на работу очередную партию нового оборудования. Вы счастливо работаете сверхурочно целыми днями, налаживая всё это с широкой улыбкой на лице.
Установщики Linux и экзамен LPIC-1/Linux+
Поскольку существует правильный и неправильный способ развёртывания новой системы Linux, на экзамене LPIC-1/Linux+ вам потребуются глубокие знания по теме установки. Примерно 20 процентов экзамена составляют вопросы об установке Linux и управлении пакетами. При этом от вас ожидается знакомство не только с самим процессом установки, но и с темами планирования развёртывания.
Одна из проблем, с которой сталкиваются CompTIA и LPIC, — огромное разнообразие установщиков, используемых различными дистрибутивами Linux. Охватить все их на экзамене невозможно. Да и требовать знания каждого из них было бы неразумно: дистрибутивов просто слишком много. Поэтому вам нужно хорошо знать общие концепции и задачи установки, характерные для всех дистрибутивов.
Охватить установку всех дистрибутивов в рамках этой книги тоже не представляется возможным. Поэтому автор останавливается на одном дистрибутиве — openSUSE. Тем не менее принципы, освоенные при его установке, без труда переносятся на другие дистрибутивы.
Быть технарём — огромное удовольствие. Однако технари печально известны общим набором привычек:
- Технари никогда не читают документацию ни к чему. Куда веселее экспериментировать и разбираться самостоятельно. К тому же мы и так всё знаем, правда?
- Технари ненавидят что-либо планировать на бумаге, особенно когда речь идёт о развёртывании аппаратного или программного обеспечения. Это отнимает всё удовольствие от игры с новыми игрушками. К тому же всё и так у нас в голове, правда?
- Технари ненавидят документировать что-либо. Мы ведь вспомним, что делали три года назад, когда что-то сломается, правда?
При развёртывании Linux (как и любой другой системы) необходимо преодолеть эти привычки и делать всё правильно. Если не изменить свои подходы, придётся тратить много времени на исправление собственных ошибок. Если продолжать в том же духе достаточно долго, придётся тратить время ещё и на обновление резюме.
Если вы работаете с тестовой системой дома или в лабораторных условиях, можно, как правило, позволить себе «технарский» подход. Цена ошибки здесь невысока. Это даже может быть отличным учебным опытом, и при наличии времени такая практика очень рекомендуется.
Однако при развёртывании систем в производственной среде организации «технарский» подход совершенно недопустим. Ваши ошибки приведут к простоям систем. Простои обходятся организации временем и деньгами и, вероятно, обойдутся лично вам потерей работы.
Вместо хаотичного, бессистемного развёртывания следует разработать план развёртывания до того, как вы начнёте закупать оборудование и устанавливать программное обеспечение. Это поможет избежать дорогостоящих ошибок (и, возможно, сохранить работу).
Будучи признанным технарём, автор знает, насколько болезненным может быть этот процесс. Когда перед вами стоит задача развернуть новые системы Linux, первый порыв — зайти на сайт поставщика оборудования и начать заказывать. Сдержите этот порыв! Если вместо этого следовать процессу, изложенному в данной главе, и реально спланировать внедрение до начала заказа оборудования и программного обеспечения, жизнь будет хороша — и для вас, и для тех, кто придёт после вас.
Вот пример. Несколько лет назад автор работал у крупного поставщика сетевого программного обеспечения. Одна из функциональных групп в его подразделении хотела внедрить новое приложение, которое упростило бы их работу. Изучив системные требования, они обнаружили, что программному обеспечению нужна конкретная версия серверной операционной системы Windows — та, которой у них не было. Для внедрения приложения сначала требовалось установить новый сервер. Вместо того чтобы разработать план развёртывания, сотрудники группы полностью проигнорировали этот шаг. Они заказали новый сервер и самостоятельно установили программное обеспечение, не поставив никого в известность.
Ничего страшного, думаете вы? Подумайте вот о чём: все критически важные данные той группы, а также группы автора хранились на этом сервере. Они представляли тысячи часов работы и стоили миллионы долларов. Никто в команде автора не задумывался об этом, пока несколько лет спустя не выяснилось, что служба информационных систем компании понятия не имела о существовании этого сервера в сети. На сервере не было сделано ни единой резервной копии данных. К нему не был подключён источник бесперебойного питания (ИБП). Никто не занимался установкой обновлений операционной системы. Никто не управлял безопасностью системы (сервер стоял в пустующей кабинке). Информация стоимостью в миллионы долларов была совершенно беззащитной. Один скачок напряжения в сети питания мог полностью уничтожить всё, над чем работали годами, без какой-либо возможности восстановления. Кроме того, только один человек знал пароль административной учётной записи. Уйди он или попади под сокращение — и административный доступ к системе был бы потерян.
В чём был корень этой проблемы? Для нового сервера не был разработан план внедрения. Если бы кто-то спланировал развёртывание, все эти проблемы были бы выявлены до установки сервера и учтены должным образом.
В этой части главы рассматривается, как планировать установку Linux. Будут рассмотрены следующие темы:
- Анализ требований
- Выбор дистрибутива
- Проверка системных требований и совместимости оборудования
- Планирование файловой системы
- Выбор программных пакетов
- Определение учётных записей пользователей
- Сбор сетевых параметров
- Выбор источника установки
Первый шаг любого плана развёртывания — анализ требований.
Анализ требований (Conducting a Needs Assessment)¶
Анализ требований (needs assessment) — один из важнейших элементов плана развёртывания Linux. Именно этот шаг чаще всего пропускается. К сожалению, даже когда он выполняется, то, как правило, выполняется плохо.
Что же такое анализ требований? Это процесс определения того, зачем предпринимается развёртывание Linux, каких результатов оно должно достичь и в какие сроки должно быть завершено. Для проведения анализа требований придётся снять шляпу техника и надеть шляпу руководителя проекта.
В этой роли необходимо встретиться с разными людьми и собрать данные о развёртывании. Да, это означает общение с людьми. Вы справитесь! Результаты следует зафиксировать в текстовом документе, который можно легко распространить и который другие смогут изучить. Когда работа будет завершена, раздел анализа требований в плане развёртывания должен содержать как минимум следующее:
- Каковы цели проекта? Следует выяснить, зачем запрашивается внедрение. Какую проблему решит эта установка? Каким будет конечный результат внедрения? Какие организационные задачи будут достигнуты? При перечислении целей проекта необходимо использовать чёткие и измеримые формулировки.
Пример из практики
При определении целей обязательно поговорите со всеми причастными лицами. Иначе у вас не сложится полной картины ожиданий и вы, вероятно, упустите какую-нибудь цель. Вот пример. Несколько лет назад автора пригласили для развёртывания Linux-сервера в новом главном офисе финансовой организации и прокладки всей необходимой проводки для подключения каждого сотрудника к сети. Он потратил немало времени на интервью с одним из владельцев при проведении анализа требований. По завершении у него сложилось довольно чёткое понимание желаемого результата.
Если коротко: офис был подключён к сети, затем развёрнут Linux-сервер. Всё шло гладко. Когда автор собирался уходить, в серверную вошёл владелец и вручил ему CD с популярным сетевым программным обеспечением для финансового учёта. Он сообщил, что его персоналу нужно это программное обеспечение для повседневной работы. Взглянув на системные требования и обнаружив, что ему нужен Windows-сервер, автор поёжился.
В чём была ошибка? Не было уделено времени разговору с сотрудниками офиса, которые будут работать с новым сервером. Беседы с одним человеком оказалось недостаточно. Владелец не знал об этом программном обеспечении, когда его изначально интервьюировали при анализе требований. Знай он об этом, данное ПО можно было бы учесть в плане, и тем же вечером автор вернулся бы домой вовремя.
-
Кто является заинтересованными сторонами проекта? В рамках анализа требований необходимо выявить всех, кого проект затрагивает в той или иной мере. Следует ответить на вопросы:
- Кто запросил новую систему?
- Кто будет пользоваться системой после её установки?
- Кто имеет полномочия утверждать финансирование проекта?
- Кто имеет полномочия выделить ваше время на проект?
- Кто должен дать окончательное одобрение проекту перед его началом?
- Кто будет обслуживать и поддерживать систему после внедрения?
- Соответствует ли новая система текущей технологической среде и стратегическому направлению компании?
Это абсолютно критические вопросы, на которые необходимо ответить до начала любого проекта. Немало сотрудников компании попытаются обойти установленные процедуры и добиться от вас каких-либо действий без надлежащего согласования.
Не допускайте ошибки, считая проект утверждённым и профинансированным только потому, что кто-то попросил вас над ним поработать. Если вы выявите всех заинтересованных сторон, вы убедитесь, что проект одобрен и необходимые средства выделены прежде, чем разместите первый заказ.
-
Когда система необходима? Ключевой вопрос — когда проект должен быть завершён. Прежде чем составлять расписание проекта, нужно знать, когда заинтересованные стороны ожидают его завершения.
Собрав эти данные в ходе анализа требований, можно определить один из важнейших элементов плана установки: область охвата проекта (project scope). Область охвата точно определяет, что нужно сделать, когда и кем. Если вам когда-либо приходилось управлять проектами, вы знаете, что любой проект представляет собой трёхстороннее противостояние следующих элементов:
- Расписание
- Ресурсы
- Масштаб
Этот баланс показан на рис. 5-1.

Рис. 5-1. Расписание, ресурсы и масштаб в области охвата проекта.
Для успешного управления любым проектом эти три элемента должны находиться в равновесии. Если расписание чрезмерно сжато, придётся либо увеличить число ресурсов, либо уменьшить масштаб проекта. Например, если проект установки предполагает развёртывание 300 рабочих станций Linux и вы — единственный ресурс, то при достаточном расписании задача выполнима. Однако если расписание требует завершить всё за неделю, скорее всего, понадобится добавить ресурсы, уменьшить количество рабочих станций или отказаться от физиологической потребности есть и спать.
Автор называет эту взаимосвязь «трёхногим табуретом управления проектами». Если ноги трёхногого табурета неодинаковой длины, он будет неустойчивым. То же верно для управления проектами: если расписание, масштаб и ресурсы не сбалансированы, проект, вероятно, потерпит неудачу.
Автор занимался управлением проектами большую часть своей карьеры, и эта аналогия неоднократно выручала. Суть в том, что спонсор проекта, как правило, захочет, чтобы вы сделали значительно больше возможного в нереальные сроки и с недостаточными ресурсами.
В начале карьеры автор стремился произвести впечатление на руководителей и нередко соглашался браться за проекты с невыполнимыми параметрами. Это было неразумно. Непрекращающийся стресс и долгие часы работы серьёзно сказываются на здоровье. В результате он понял: необходимо настаивать на балансе этих трёх параметров. Простая схема, подобная рис. 5-1, или аналогия с трёхногим табуретом — весьма эффективный инструмент, чтобы донести необходимость баланса до спонсоров проекта.
Использование программного обеспечения для управления проектами может оказаться чрезвычайно полезным при расчёте точных сроков реализации проекта. С его помощью можно назначать конкретные задачи конкретным ресурсам и задавать продолжительность. Кроме того, можно определять зависимости (dependencies) — указывать, какие задачи должны быть завершены прежде, чем начнутся другие. Пример проекта с зависимостями показан на рис. 5-2.

Рис. 5-2. Использование программного обеспечения для управления проектами для планирования проекта и определения зависимостей.
Замечательное свойство программного обеспечения для управления проектами состоит в том, что оно рассчитывает расписание автоматически. Вводя задачи и их продолжительность и связывая их с конкретными ресурсами, можно легко увидеть, сколько времени займёт проект. Также можно менять различные параметры (помните о трёхногом табурете) и наблюдать за результатом. Например, можно добавить дополнительный ресурс и посмотреть, как это повлияет на общее расписание. Или оценить эффект от перехода на девятичасовой рабочий день вместо восьмичасового.
Однако при работе с проектом обязательно нужно руководствоваться здравым смыслом. Многие менеджеры проектов приходят в восторг, увидев, что манипуляции с параметрами позволяют существенно сократить сроки. Однако вносимые ими изменения нереалистичны. Например, задав 18-часовой рабочий день для всех участников, можно действительно сильно сократить расписание. Но большинство людей не способны работать столько часов подряд длительное время. Страдает личная жизнь, страдает здоровье, наступает профессиональное выгорание, производительность резко падает. Короче говоря, следует сверять расписание с реальностью. То, что выглядит хорошо на бумаге, может не работать в жизни.
Определив область охвата проекта, можно переходить к следующему компоненту плана.
Выбор дистрибутива (Selecting a Distribution)¶
Как уже обсуждалось в этой книге, Linux доступен в широком разнообразии вариантов, называемых дистрибутивами (distributions). Один из ключевых элементов плана развёртывания — указание того, какой дистрибутив будет использован. Какой из них лучший? Это зависит от ваших предпочтений и назначения системы. Ниже приведены ориентиры для выбора подходящего дистрибутива.
Система будет использоваться как рабочая станция или как сервер? (Will the System Function as a Workstation or a Server?)¶
Одно из замечательных свойств Linux состоит в том, что практически любой дистрибутив можно использовать как в роли рабочей станции, так и в роли сервера. Это уникально среди операционных систем. Большинство ОС предназначены либо для роли сервера, либо для роли рабочей станции, но не для обеих сразу. Большинство дистрибутивов Linux, напротив, применимы в обоих качествах.
Тем не менее следует знать, что существуют дистрибутивы Linux, специально разработанные и оптимизированные для использования в качестве серверов, и другие — для использования в качестве рабочих станций. Например, Red Hat предлагает дистрибутив Red Hat Enterprise Linux, предназначенный для предоставления сетевых служб средним и крупным организациям с высокой нагрузкой на серверы.
Red Hat также предлагает два дистрибутива, специально предназначенных для настольных систем:
- Red Hat Enterprise Linux Desktop — предназначен для рядовых конечных пользователей на настольных системах, используемых в повседневной работе.
- Red Hat Enterprise Linux Workstation — предназначен для опытных пользователей, таких как инженеры и графические дизайнеры, которым нужно высокопроизводительное настольное оборудование для более сложных вычислительных задач.
- Red Hat Enterprise Linux Developer — предназначен для разработчиков программного обеспечения, создающих новые приложения. Операционная система оптимизирована для максимального ускорения разработки.
Аналогично, Novell предлагает две версии SUSE Linux:
- SUSE Linux Enterprise Server — предназначен для использования на серверах в очень крупных организациях.
- SUSE Linux Enterprise Desktop — предназначен для использования конечными пользователями на настольных рабочих станциях.
Существуют также специализированные дистрибутивы для создания Linux-устройств на основе стандартного оборудования ПК. Например, с помощью таких дистрибутивов, как Untangle, можно создать мощный межсетевой экран.
Предлагает ли дистрибутив техническую поддержку? (Does the Distribution Offer Support?)¶
Одни поставщики предлагают техническую поддержку своих дистрибутивов Linux, другие — ограниченную или никакой. Если система будет использоваться в корпоративной среде, следует применять хорошо поддерживаемый дистрибутив. Если после установки системы возникнет проблема, нужно иметь возможность оперативно её устранить. Времени на самостоятельный поиск решения в Интернете не будет — нужно иметь возможность позвонить и получить ответ немедленно.
Следует учитывать: хотя сам дистрибутив может быть бесплатным или почти бесплатным, за техническую поддержку придётся платить. Стоимость поддержки варьируется от поставщика к поставщику, поэтому имеет смысл сравнивать предложения.
В отрасли сейчас существует немало путаницы относительно различий между дистрибутивами одного поставщика. Обычно одна версия бесплатна, другая — платная. Например, можно купить Red Hat Enterprise Linux Desktop или скачать Fedora бесплатно. Одно из ключевых различий — поддержка. Приобретя Red Hat Enterprise Linux Desktop, вы получаете право на техническую поддержку от Red Hat: чем больше платите, тем выше её уровень. Если скачать бесплатную копию, поддержку придётся искать самостоятельно на сайтах, форумах и в группах новостей.
В этой книге будут использоваться Fedora, openSUSE и Ubuntu. Однако при развёртывании в производственной среде настоятельно рекомендуется использовать поддерживаемую версию Linux.
Поддерживаются ли нужные приложения выбранным дистрибутивом? (Will the Applications You Need Run on the Distribution?)¶
Перед выбором конкретного дистрибутива следует оценить программное обеспечение, которое планируется использовать, и убедиться, что оно поддерживается операционной системой.
Помимо этих соображений, необходимо также убедиться, что выбранный дистрибутив работает на имеющемся аппаратном обеспечении.
Проверка системных требований и совместимости оборудования (Verifying System Requirements and Hardware Compatibility)¶
Как и любой технический специалист, вы, вероятно, любите заказывать оборудование — особенно если расходы несёт работодатель! Поэтому велик соблазн начать просматривать сайты поставщиков ещё до того, как план развёртывания Linux будет готов.
Сдержите этот порыв любой ценой! Прежде чем скачивать или приобретать дистрибутив, нужно убедиться, что он действительно заработает на вашем оборудовании. Многие системные администраторы пренебрегают этим шагом. Это плохая практика, и рано или поздно неизбежно наступает момент «ну как же так». Может оказаться, что оборудование несовместимо с операционной системой. Когда это происходит, срок реализации проекта оказывается под угрозой, и многие люди остаются недовольны. Возврат и повторный заказ оборудования занимают немало времени. Если это случится, придётся провести немало приятных минут в кабинете начальника, объясняя причины отставания от графика.
В этом разделе рассматриваются два шага, позволяющих этого избежать:
- Проверка совместимости оборудования
- Проверка системных требований
Проверка совместимости оборудования (Checking Hardware Compatibility)¶
В ранние дни Linux совместимость с оборудованием была проблематичной, особенно при установке на ноутбуки и другие системы с большим количеством проприетарного оборудования. Разработчиков драйверов Linux просто не хватало. При установке на универсальную систему с распространёнными аппаратными компонентами Linux обычно устанавливался и работал нормально. Однако если в системе использовалось нетипичное или проприетарное оборудование (например, высокопроизводительная видеокарта), Linux мог работать некорректно или не работать вовсе.
В те времена большинство производителей оборудования не предоставляли драйверов Linux для своих устройств. Они не воспринимали Linux как широко распространённую ОС и не хотели тратить время и деньги на разработку драйверов. Приходилось рассчитывать на добросовестность разработчиков по всему миру, которые могли написать драйвер для конкретного устройства. Если драйвера не существовало — выход был только один: обходиться без устройства.
Сегодня эта проблема стоит менее остро. Большинство поставщиков теперь предлагают версии драйверов для Linux. Кроме того, драйверы для большинства распространённых аппаратных компонентов ПК уже включены в различные дистрибутивы Linux.
Тем не менее для надёжности по-прежнему стоит зайти на сайт дистрибутива и убедиться, что аппаратное обеспечение значится в списке совместимого оборудования (hardware compatibility list, HCL). Несмотря на то что поддержка оборудования существенно улучшилась за последнее десятилетие, некоторые устройства всё ещё не поддерживаются. Хороший пример — встроенные беспроводные сетевые интерфейсы, используемые во многих ноутбуках: их поддержка в Linux по-прежнему нестабильна. Список HCL дистрибутива позволяет проверить, поддерживаются ли устройства системы.
HCL обычно доступен в двух местах. Во-первых, большинство дистрибутивов включают список поддерживаемого оборудования в текстовый файл на установочном DVD. Однако такой вариант HCL автор использует редко: это статический документ, который не обновлялся с момента создания образа диска. Если устройство было выпущено после создания образа, никакой информации о его поддержке не будет.
Предпочтительнее использовать HCL, поддерживаемый на сайте дистрибутива: там, как правило, содержатся актуальные данные о поддерживаемом оборудовании. Например, если вы решили установить дистрибутив openSUSE, можно воспользоваться браузером и обратиться к его HCL по адресу http://en.opensuse.org/Hardware. Там можно найти своё оборудование и проверить его поддержку. На рис. 5-3 показан HCL openSUSE для видеокарт.

Рис. 5-3. Использование HCL openSUSE.
Если вы выбрали дистрибутив Red Hat, можно аналогичным образом проверить HCL на сайте Red Hat (https://access.redhat.com/search/browse/certified-hardware#?) для подтверждения поддержки оборудования.
Большинство дистрибутивов размещают на своих сайтах HCL того или иного вида, хотя и не все. У некоторых поставщиков просто нет времени и ресурсов для проведения масштабного тестирования совместимости со всем многообразием доступных на рынке ПК-устройств.
Примечание
Доступность драйверов — одна из причин, по которым при развёртывании в производственной среде предпочтительно придерживаться крупных, хорошо поддерживаемых дистрибутивов Linux. Конечно, с плохо поддерживаемым дистрибутивом можно поэкспериментировать дома или в лабораторных условиях — потери здесь минимальны. Однако одна из ключевых обязанностей системного администратора Linux в производственной среде — защита данных и обеспечение максимальной эффективности работы систем. В такой ситуации нужна уверенность в поддержке оборудования. Нельзя тратить время на поиск драйверов в Интернете или устранение нестабильной работы системы.
Проверка системных требований (Verifying System Requirements)¶
В ранние дни Linux системными требованиями различных дистрибутивов мало кто занимался: тогдашние версии Linux работали на минимальном оборудовании и не предъявляли высоких требований к памяти, дисковому пространству или вычислительной мощности.
Однако по мере зрелости Linux большинство дистрибутивов стали требовать значительно более мощного оборудования для обеспечения приемлемой производительности. Откуда узнать системные требования? Как и в случае с HCL — с сайта поставщика дистрибутива.
При составлении плана развёртывания обязательно укажите оборудование, необходимое для выбранного дистрибутива.
Важный аспект системных требований — архитектура процессора вашего ПК. При скачивании дистрибутива Linux убедитесь, что выбрана правильная архитектура для вашего процессора. Долгое время этот вопрос не стоял остро, поскольку повсеместно использовалась единственная архитектура — 32-разрядная x86 от Intel. Хотя большинство ранних дистрибутивов были доступны для архитектур x86 и Alpha, в распоряжении среднего системного администратора почти не было машин Alpha. Почти каждая система работала на той или иной вариации архитектуры x86.
Сегодня системных администраторам доступно значительно больше вариантов оборудования. По-прежнему существуют архитектуры x86 и Alpha, но добавилась и новая 64-разрядная архитектура x86. Intel также выпускает архитектуру IA-64, применяемую в процессорах Itanium. Каждая из этих архитектур требует своей версии Linux. Многие дистрибутивы Linux портированы даже для архитектуры Power PC (PPC) от Apple Computer. Другие дистрибутивы доступны для серверов iSeries, pSeries и RS/6000 от IBM. Существуют уже и версии Linux, портированные для архитектуры ARM, используемой в планшетных устройствах.
Главное — выбрать правильную архитектуру для своего дистрибутива. Например, если вы выбрали Ubuntu и открыли страницу загрузки на сайте дистрибутива, вы увидите варианты, показанные на рис. 5-4.

Рис. 5-4. Архитектуры Ubuntu.
Независимо от выбранного дистрибутива, убедитесь, что скачиваете правильную версию для архитектуры вашей системы. Например, для установки Linux на систему с 32-разрядным процессором нужна версия x86 (32-разрядная). Если в вашей системе 64-разрядный процессор — нужна версия x86-64 (64-разрядная). При выборе неправильной версии большинство установщиков Linux сгенерируют ошибку, и завершить установку не получится.
Разобравшись с вопросами оборудования, можно переходить к следующему компоненту плана.
Планирование файловой системы (Planning the File System)¶
При планировании реализации Linux необходимо указать, как будет создана и организована файловая система (file system) на жёстком диске системы. Это ещё одна уникальная особенность Linux. При внедрении других операционных систем, например Microsoft Windows, как правило, создаётся единственный раздел диска, форматируемый в файловой системе NTFS.
В случае с Linux, однако, выбор значительно шире. Можно настроить разбивку диска на разделы и выбрать используемую файловую систему. В этой части главы рассматриваются следующие вопросы:
- Выбор файловой системы
- Планирование разделов
Выбор файловой системы (Choosing a File System)¶
Жёсткий диск состоит из нескольких алюминиевых пластин, каждая из которых оснащена двумя головками чтения-записи для чтения и записи данных. При выполнении операций ввода-вывода операционная система должна знать, где хранятся данные, как к ним получить доступ и куда безопасно записать новую информацию.
Это задача файловой системы: надёжно хранить данные на жёстком диске и организовывать их так, чтобы они были легко доступны. Когда вы с помощью файлового менеджера перемещаетесь по каталогам жёсткого диска и открываете файл — именно файловая система обеспечивает весь этот процесс.
Большинство дистрибутивов Linux предлагают широкий выбор файловых систем. В этом разделе рассматриваются наиболее распространённые из них:
- ext2
- ext3
- Reiser
- ext4
- btrfs
Примечание
В Linux можно использовать и многие другие файловые системы. Например, XFS от Silicon Graphics. Можно даже использовать VFAT или NTFS, хотя поддержка NTFS пока не является полноценной. Создание файловых систем VFAT и XFS рассматривается в главе 10.
ext2 Файловая система ext2 — одна из старейших файловых систем Linux, до сих пор остающаяся в употреблении. Аббревиатура ext2 расшифровывается как «Second Extended File System» («вторая расширенная файловая система»). Впервые представленная в 1993 году, ext2 хранит данные в стандартной иерархической форме, принятой в большинстве других файловых систем: данные хранятся в файлах, файлы — в каталогах, каталог может содержать как файлы, так и другие каталоги (подкаталоги).
Максимальный размер файла в ext2 составляет 2 ТБ (терабайта). Максимальный объём тома ext2 — 4 ТБ. Имена файлов могут содержать до 255 символов. Файловая система ext2 поддерживает пользователей, группы и права доступа Linux (так называемые права POSIX), а также сжатие файлов.
ext2 — отличная файловая система. Она существует достаточно долго, чтобы большинство ошибок в ней были устранены. Вероятно, это наиболее широко применявшаяся файловая система Linux за всю историю. Она также считается самой быстрой из доступных файловых систем Linux.
Однако у ext2 есть один существенный недостаток, который послужил толчком к разработке других файловых систем: при аварийном завершении работы системы её восстановление занимает много времени. При штатном завершении работы операционная система сначала корректно размонтирует файловую систему, обеспечивая запись всех ожидающих транзакций на диск до отключения питания.
Проблема возникает, когда система останавливается без корректного размонтирования. Например, при отключении электроэнергии система вдруг выключается без прохождения надлежащей процедуры завершения работы. В таком случае возможно, что ожидавшие завершения дисковые транзакции не были выполнены.
Совет
Для защиты от подобных ситуаций используйте источник бесперебойного питания (ИБП). Автор однажды потерял данные на файловой системе ext2 из-за отключения электроэнергии и с тех пор не допускает повторения этого.
Для восстановления файловой системы при следующей загрузке ext2 автоматически запускает программу e2fsck. Эта утилита пытается исправить проблемы, возникшие из-за некорректного отключения диска. Если обнаруживаются незанятые файлы или необработанные блоки данных, они записываются в каталог lost+found. Таким образом ext2 старается сохранить целостность данных несмотря на некорректное завершение работы.
Проблема в том, что e2fsck при этом анализирует всю файловую систему, а не только те несколько файлов, которые находились в процессе изменения. На базовой Linux-системе это может занять от 10 до 15 минут. На крупной системе с большим объёмом данных (например, на сетевом файловом сервере) процесс может занять несколько часов. Само по себе неожиданное отключение системы уже достаточно неприятно; и теперь приходится ещё часами ждать повторного запуска!
Именно эта проблема привела к появлению других файловых систем Linux, постепенно вытесняющих ext2.
ext3 Файловая система ext3 — это обновлённая версия ext2. Аббревиатура ext3 означает «Third Extended File System» («третья расширенная файловая система»). Они настолько похожи, что большинство утилит для работы с файловой системой ext2 используются и для ext3. Можно легко выполнить обновление файловых систем ext2 до ext3 и даже откатить ext3 обратно до ext2.
Однако ext3 обладает одним ключевым преимуществом, делающим её предпочтительнее ext2: журналирование (journaling). Напомним, что главный недостаток ext2 — необходимость проверять всю файловую систему при некорректном завершении работы. Журналирование устраняет эту проблему.
Перед записью транзакции на жёсткий диск файловая система ext3 фиксирует транзакцию в журнале, помечая её как незавершённую. После завершения дисковой транзакции ext3 отмечает её в журнале как завершённую. Таким образом, ext3 ведёт журнал последних дисковых транзакций с указанием того, были ли они фактически завершены.
Если событие — например, отключение электроэнергии — приводит к некорректному завершению работы без размонтирования диска, ext3 воспроизводит журнал при следующем запуске системы. Это позволяет проверить данные на диске и привести файловую систему в согласованное состояние (если возможно) с использованием информации из журнала. В отличие от ext2, ext3 не проверяет всю файловую систему: имея журнал с записями о последних транзакциях, она просматривает только те, которые помечены как незавершённые.
Благодаря журналированию время восстановления диска после некорректного завершения работы значительно сокращается по сравнению с ext2. Вместо часов ext3 воспроизводит журнал за несколько секунд или минут — даже для очень большой файловой системы.
Недостаток ext3 — журналирование потребляет больше системной памяти и незначительно замедляет дисковые операции ввода-вывода. Однако поскольку ext3 лучше обеспечивает целостность данных и делает это быстрее, большинство системных администраторов предпочитают её ext2 несмотря на незначительное снижение производительности.
Reiser Файловая система Reiser — альтернатива ext3. Как и ext3, Reiser использует журналирование для быстрого восстановления после сбоев. Однако Reiser — это совершенно другая файловая система с принципиально иной внутренней структурой по сравнению с ext2 и ext3. Это позволяет Reiser поддерживать максимальный размер файла 8 ТБ и максимальный размер тома 16 ТБ. Кроме того, структура Reiser обеспечивает значительно более высокую производительность по сравнению с ext2 или ext3.
ext4 Файловая система ext4 была выпущена в конце 2008 года. Как нетрудно догадаться, ext4 (Fourth Extended File System, «четвёртая расширенная файловая система») — это обновлённая версия ext3. Так же как ext3 обратно совместима с ext2, ext4 обратно совместима с ext3 (и с ext2). Файловая система ext4 поддерживает тома объёмом до 1 эксабайта и файлы размером до 16 терабайт. На томе ext4 может храниться до четырёх миллиардов файлов. Как и в ext2/ext3, максимальная длина имени файла или каталога — 255 символов. ext4 также использует контрольные суммы для проверки самого файла журнала, что повышает общую надёжность системы, поскольку журнальный файл — один из наиболее активно используемых. Таким образом, ext4 представляет собой значительный шаг вперёд по сравнению с ext3 и Reiser.
btrfs Файловая система btrfs (произносится «батер-эфэс»; butter-fs) — более новая файловая система Linux, представляющая эволюционный скачок в способах организации и защиты данных. btrfs — это файловая система с копированием при записи (copy-on-write), весьма похожая на файловую систему NSS в продуктах Novell и технологию Storage Spaces в последних версиях Windows.
Благодаря технологии копирования при записи btrfs предоставляет несколько принципиально новых возможностей, отсутствующих в более ранних файловых системах:
- Пулы хранения
- Моментальные снимки
btrfs предлагает альтернативу традиционному созданию разделов диска. Вместо этого из устройств хранения в системе создаются пулы хранения (storage pools). Из пула хранения можно выделять пространство для конкретных томов хранения. Вместо монтирования разделов монтируются тома хранения в точках монтирования файловой системы. Это обеспечивает большую гибкость при распределении пространства. Например, если на томе /home заканчивается место, достаточно установить новый жёсткий диск в систему и добавить его пространство в пул, где находится том /home. После этого размер тома автоматически увеличится — без необходимости создавать резервную копию данных и восстанавливать их, как это требуется при работе с традиционными разделами.
Функция моментальных снимков (snapshots) в btrfs защищает данные. По сути, файловую систему можно настроить на создание снимков данных через заданные интервалы с сохранением на отдельном носителе. Если файл когда-либо будет утерян или повреждён, его предыдущую версию можно извлечь из сохранённого снимка и восстановить за считанные секунды.
Большинство дистрибутивов позволяют выбрать файловую систему при разбиении жёстких дисков в процессе установки. К этому моменту выбор уже должен быть сделан. Поэтому при планировании реализации Linux следует заранее указать в плане развёртывания, какую файловую систему вы будете использовать.
Какую файловую систему выбрать? Это зависит от личных предпочтений и потребностей конкретного развёртывания. Долгое время предпочтением автора была Reiser, однако в последнее время выбором стала ext4.
Помимо указания файловой системы, в план развёртывания необходимо включить схему разбиения жёсткого диска на разделы.
Планирование разделов (Planning Your Partitions)¶
Раздел (partition) — это логическое деление жёсткого диска. С помощью головок чтения-записи внутри жёсткого диска утилита разбиения на разделы создаёт магнитные разграничения на пластинах диска, деля его на отдельные секции. Жёсткий диск может иметь один раздел, охватывающий весь диск, или несколько разделов.
В системе Linux используется как минимум два раздела, но их можно создать и больше. Разделы должны быть определены в ходе начальной установки системы. Изменить разбиение диска после установки системы можно, но это требует определённых усилий и времени. Поэтому рекомендуется спланировать разбиение системного жёсткого диска до начала установки.
По умолчанию большинство дистрибутивов Linux в процессе установки предлагают два раздела, как показано на рис. 5-5:

Рис. 5-5. Стандартная схема разбиения Linux на разделы.
-
swap— этот раздел используется операционной системой Linux как виртуальная память. По существу, Linux использует дисковое пространство в разделе подкачки так, как если бы оно было оперативной памятью. При высокой нагрузке на оперативную память операционная система может перемещать в раздел подкачки данные, загруженные в RAM, но в данный момент не используемые. Этот процесс называется подкачкой (swapping): перемещение страницы памяти в заранее выделенный раздел подкачки на жёстком диске.Когда данные снова потребуются, они перемещаются из раздела подкачки обратно в RAM. По существу, это позволяет системе одновременно запускать больше программ, чем позволяет физическая RAM.
Оптимальный размер раздела подкачки зависит от назначения системы. Для настольных систем общее правило — раздел подкачки примерно вдвое больше объёма RAM: настольные системы обычно запускают большое количество приложений, которые легко вытесняются на диск. Например, при 2 ГБ RAM рекомендуется раздел подкачки около 4 ГБ. Для серверных систем пространства подкачки, как правило, требуется меньше: обычно достаточно раздела, равного по размеру установленной RAM.
Совет
В Linux вместо раздела подкачки можно также использовать файл подкачки. Это рассматривается в главе 10.
-
/— этот раздел монтируется в корневом каталоге (/) файловой системы Linux. Все пользовательские данные, программы, журнальные и конфигурационные файлы содержатся в этом единственном разделе.
Несмотря на то что именно такую схему разбиения предлагает большинство дистрибутивов по умолчанию, стоит создать больше разделов, чем два или три. Чтобы понять, зачем это нужно, необходимо сначала осознать, что Linux использует единую структуру файловой системы для представления всего доступного пространства хранения. Это показано на рис. 5-6.

Рис. 5-6. Иерархия файловой системы Linux.
Различные разделы могут монтироваться в разных точках этой иерархии. Например, на рис. 5-7 на первом диске SATA (/dev/sda) создан дополнительный раздел (/dev/sda3), смонтированный в каталоге /home.

Рис. 5-7. Монтирование /dev/sda3 в /home.
При переходе по иерархии файловой системы Linux и открытии каталога /home происходит перенаправление на другой раздел жёсткого диска. При наличии нескольких жёстких дисков раздел, смонтированный в /home, можно разместить на совершенно другом диске. Разбиение полностью прозрачно для конечного пользователя.
Автор настоятельно рекомендует при планировании разделов Linux создавать несколько разделов на жёстких дисках. Это повышает отказоустойчивость системы: проблема в одном разделе изолируется от остальных. Например, если используется стандартная схема разбиения с одним корневым разделом (/) и пользователь заполнит всё доступное пространство, копируя огромные файлы в свой домашний каталог в /home, это может вызвать крах всей системы, поскольку операционная система не сможет записывать критически важные системные файлы.
Пример из практики
Несколько лет назад автор получил звонок от клиента: их Linux-сервер работал некорректно, и никто в офисе не мог получить доступ к своим файлам. Расследование показало, что в конфигурационном файле, управляющем ротацией системных журналов, было несколько ошибок. В результате ни один системный журнал не ротировался годами! Журнальные файлы разрослись настолько, что заняли всё оставшееся место на жёстком диске.
Проблема была двоякой. Во-первых, тот, кто настраивал ротацию журналов, должен был убедиться в её работоспособности, прежде чем оставлять систему без присмотра. Во-вторых, сервер использовал стандартную схему разбиения: один раздел подкачки и один раздел, смонтированный в /. Если бы первоначальный администратор создал отдельный раздел для каталога /var (где хранится большинство системных журналов), проблема была бы изолирована только этим разделом, и пользователи по-прежнему смогли бы работать.
Если же для /home создан отдельный раздел и пользователь снова заполняет всё доступное место, скопировав очень большие файлы в свой домашний каталог, система продолжит работать. Разделы, содержащие системные, журнальные и прикладные файлы, не затронуты, поскольку проблема изолирована в пределах одного раздела.
При планировании разделов Linux рекомендуется создавать отдельные разделы для каталогов, перечисленных в таблице 5-1.
Внимание
Раздел /boot должен быть создан в пределах первых 1024 цилиндров жёсткого диска. Для надёжности рекомендуется всегда создавать этот раздел начиная с цилиндра 0.
| Точка монтирования | Рекомендация |
|---|---|
/ |
Создайте раздел для корневого каталога. Размер должен быть не менее 4 ГБ. Рекомендуется значительно больше — с запасом на обновления программного обеспечения, которые будут устанавливаться в течение всего жизненного цикла системы. |
/boot |
Создайте раздел для каталога /boot, содержащего системные файлы Linux. Этому разделу требуется небольшое пространство — обычно достаточно от 100 до 200 МБ. |
/home |
Создайте раздел для файлов пользователей. Выделите столько пространства, сколько необходимо для данных пользователей. Разумеется, сколько бы места вы ни выделили, его всегда кажется мало. |
/opt |
Создайте раздел для файлов приложений, устанавливаемых в /opt. Выделите столько пространства, сколько необходимо для приложений, использующих этот каталог. |
/tmp |
Создайте раздел для временных файлов системы, хранящихся в /tmp. Выделите не менее 1 ГБ. |
/usr |
Создайте раздел для системных утилит в /usr. Выделите не менее 5 ГБ — возможно, значительно больше в зависимости от устанавливаемых пакетов. |
/var |
Создайте раздел для журнальных файлов в /var. Поскольку журнальные файлы могут стать весьма объёмными, их стоит изолировать в собственном разделе. Выделите не менее 3 ГБ — лично автор рекомендует значительно больше. |
Таблица 5-1. Рекомендуемые разделы Linux.
Использование этих рекомендованных разделов повысит стабильность системы. К сожалению, такая схема разбиения неэффективно использует дисковое пространство. Например, раздел /home может исчерпать пространство, и пользователи не смогут сохранять данные, даже если в других разделах есть свободное место. Однако дополнительная стабильность окупает эту неэффективность. Известно: жёсткие диски дёшевы, а данные бесценны.
После планирования разделов следующая задача — указать программное обеспечение, которое будет установлено.
Выбор программных пакетов (Selecting Software Packages)¶
Одно из того, что автор искренне любит в Linux, — широчайший спектр программного обеспечения с открытым исходным кодом. Ваш дистрибутив Linux, скорее всего, включает довольно обширный набор пакетов (packages), которые можно установить вместе с операционной системой. Именно наличие этого дополнительного программного обеспечения делает набор для установки таким большим — большинство дистрибутивов требуют полного DVD для хранения всех доступных пакетов.
Когда впервые видишь весь список доступного программного обеспечения, впечатление незабываемое. Например, openSUSE предлагает множество разнообразных игр для установки, как показано на рис. 5-8.

Рис. 5-8. Установка программных пакетов в openSUSE Linux.
Будучи технарём, вы можете захотеть установить почти всё подряд: бесплатное программное обеспечение! Однако делать этого не следует. Вы установите очень мощное программное обеспечение, к которому, вероятно, не хотите предоставлять доступ конечным пользователям. Например, вряд ли нужно, чтобы пользователи размещали собственные сайты с рабочего стола из-за установленного Apache. Что важнее — установка лишнего программного обеспечения может потенциально открыть скрытые пути для доступа, создав угрозы безопасности.
Гораздо лучше использовать план развёртывания для определения роли системы (это обсуждалось ранее в главе). Имея эту информацию, следует изучить пакеты, доступные в вашем дистрибутиве, и точно указать, какие именно необходимы. Общее правило таково: устанавливать только то, что нужно для выполнения задачи, и ничего лишнего.
Например, если система будет функционировать как сетевой сервер, предоставляющий доменную аутентификацию, файловый и печатный сервис, понадобится установить пакеты Samba и CUPS (Common UNIX Printing System). Если это сетевой сервер для веб-хостинга и электронной почты — возможно, потребуется установить Apache, Tomcat, Postfix и пакеты IMAP. Если система предназначена для использования в качестве настольной рабочей станции, имеет смысл установить OpenOffice.org, предоставляющий конечным пользователям текстовый процессор, электронные таблицы и программу для работы с презентациями.
Суть в следующем: устанавливайте необходимые пакеты и избегайте лишнего. Если после установки системы выяснится, что нужны дополнительные пакеты, их можно легко установить позднее — об этом рассказывается в главе 8.
Одна из удобных возможностей большинства графических установщиков Linux — автоматический расчёт зависимостей (dependencies). Зависимость — это конкретный программный пакет, необходимый для работы другого пакета. У большинства пакетов Linux, устанавливаемых в ходе установки системы, имеется множество зависимостей.
В ранние дни Linux зависимости между пакетами приходилось вычислять вручную и самостоятельно включать их в установку. Это могло превратиться в настоящий кошмар из-за многоуровневых зависимостей, как показано на рис. 5-9.

Рис. 5-9. Бесконечная цепочка зависимостей пакетов.
Хорошая новость: установщики большинства современных дистрибутивов автоматически рассчитывают зависимости пакетов и включают необходимые зависимые пакеты в установку.
Определение учётных записей пользователей (Identifying User Accounts)¶
Linux — истинная многопользовательская операционная система. Это означает, что одна система может включать несколько учётных записей пользователей. Более того, несколько пользователей могут одновременно работать с одной и той же системой через сетевое подключение.
Поэтому при планировании установки Linux следует определить, какие учётные записи пользователей понадобятся. Утилиты установки большинства дистрибутивов Linux позволяют создавать эти учётные записи непосредственно в процессе установки. Независимо от выбранного дистрибутива, в ходе установки всегда создаётся учётная запись суперпользователя root, а также одна стандартная пользовательская учётная запись.
Учётная запись суперпользователя root (root user) — это учётная запись с полными правами в системе Linux. Она обладает неограниченными возможностями и должна применяться с осторожностью. Откровенно говоря, при неосторожном использовании можно нанести серьёзный ущерб системе. Поскольку вы вошли в систему как root, она предполагает, что вы знаете, что делаете, и позволяет это делать. В целях безопасности не следует использовать учётную запись root для повседневной работы. Вместо этого рекомендуется создать стандартную пользовательскую учётную запись для ежедневных задач. Когда действительно потребуются права суперпользователя, можно переключиться на учётную запись root, а после выполнения задачи вернуться к стандартной учётной записи.
При установке Linux вам будет предложено задать пароль для учётной записи root. Вы также сможете создать дополнительные пользовательские учётные записи. В плане развёртывания следует указать, какие учётные записи планируется создать. Как и в случае с программными пакетами, добавление или удаление учётных записей после завершения установки не представляет сложности. Linux предоставляет обширный набор инструментов для управления учётными записями пользователей и паролями — об этом рассказывается в главе 9.
Сбор сетевых параметров (Gathering Network Information)¶
В современном сетевом мире большинство систем Linux будут подключены к той или иной компьютерной сети. Поэтому необходимо собрать сетевые параметры, необходимые для подключения системы к сети, до начала установки, и включить их в план развёртывания. Ниже приведён список вопросов, на которые нужно ответить:
-
Будет ли сетевая конфигурация назначена динамически, или её нужно будет задавать вручную? В большинстве современных IP-сетей используется сервер DHCP (Dynamic Host Configuration Protocol) для динамического назначения IP-адресов и других сетевых параметров рабочей станции при загрузке в сети. Большинство систем Linux, работающих как настольные рабочие станции, скорее всего, будут использовать этот вариант. В таком случае настройка сетевых параметров не требует особых усилий: необходимые данные динамически присваиваются системе при каждой загрузке.
Однако если Linux-система будет работать как сервер в сети, не следует использовать DHCP для динамического назначения сетевых параметров. При использовании DHCP система может получать разный IP-адрес при каждой загрузке. Для рабочей станции это неважно, но для сервера создаёт массу проблем. Поэтому сетевым серверам обычно присваивается статический IP-адрес.
Если системе необходим статический IP-адрес, нужно собрать следующие параметры: - IP-адрес - Маска подсети - Адрес маршрутизатора - Адрес(а) DNS-сервера
-
Какое имя хоста будет назначено системе? Каждой Linux-системе необходимо имя хоста. Оно должно быть уникальным в пределах сети: ни одна другая система не должна иметь то же имя хоста. В процессе установки будет предложено указать имя хоста.
-
В каком DNS-домене будет находиться система? Скорее всего, у вашей организации есть собственный DNS-домен, например
mycorp.com. В процессе установки будет предложено указать доменное имя организации. -
Нужно ли настраивать межсетевой экран хоста? Большинство дистрибутивов Linux включают межсетевой экран хоста, который по умолчанию включается в процессе установки. Межсетевой экран хоста — ценный элемент обеспечения безопасности организации: по существу, он предотвращает установление соединений с системой из других узлов сети.
Для настольных систем следует включить этот межсетевой экран и закрыть все IP-порты и службы. Межсетевой экран хоста следует включать и на серверных системах. Однако большинство серверных систем запускают приложения, предоставляющие сетевые службы другим узлам сети. Поэтому в межсетевом экране необходимо открыть нужные IP-порты для предоставления доступа к соответствующим службам.
Если устанавливается серверная система, в плане развёртывания следует перечислить сетевые службы, которые она будет предоставлять, с указанием соответствующих номеров портов. Этот список предоставит необходимые данные для создания нужных исключений в конфигурации межсетевого экрана. Например, если Linux-система будет использоваться как веб-сервер, в межсетевом экране необходимо открыть порты 80 и 443 для подключения клиентов к службе
httpd.
Выбор источника установки (Selecting an Installation Source)¶
Большинство дистрибутивов Linux предлагают несколько вариантов установки системы:
- Локальная установка с оптического диска
- Удалённая установка с сетевого сервера
- Удалённая установка с использованием VNC
Локальная установка с оптического диска (Installing Locally from an Optical Disc)¶
Один из наиболее распространённых способов установки Linux — с набора установочных дисков. При этом нужно просто вставить соответствующий оптический диск в дисковод системы и загрузиться с него.
Для большинства дистрибутивов можно скачать копию образа(ов) установочного диска с сайта поставщика. Например, для установки Fedora достаточно открыть браузер, перейти на http://fedora.project.org и выбрать ссылку Download. Выбрав архитектуру системы, вы будете перенаправлены на зеркальный сайт в Интернете с дистрибутивом.
Скачанный файл имеет расширение .iso. Такие файлы называются ISO-образами (ISO images). Скачав нужный .iso-файл, можно с помощью программы записи дисков записать образ на физический диск — см. документацию по используемой программе.
Примечание
После скачивания очень большого ISO-файла из Интернета рекомендуется проверить контрольную сумму md5sum, чтобы убедиться в целостности файла и отсутствии повреждений. Об этом рассказывается в главе 8.
При установке Linux в виртуальную машину записывать образ на диск не обязательно. Вместо этого можно настроить виртуальную машину на прямое подключение к ISO-образу. Виртуальная машина будет считать этот образ настоящим CD или DVD и выполнит установку с него. Этот способ значительно быстрее, поскольку данные хранятся на жёстком диске, скорость обращения к которому выше, чем к оптическому диску.
Удалённая установка с сетевого сервера (Installing Remotely from a Network Server)¶
Ещё один удобный вариант — установка с сетевого сервера. Установку можно выполнить с Linux-сервера в сети, настроенного как источник установки по протоколу SMB, NFS, HTTP или FTP. Возможна также установка непосредственно с FTP- или HTTP-сервера в Интернете.
Примечание
Не все дистрибутивы Linux поддерживают сетевую установку.
Ключевое преимущество сетевой установки Linux — возможность установить большое количество систем одновременно без необходимости записывать DVD для каждой из них. Недостаток — сетевая установка обычно выполняется медленнее, чем с DVD. Установка через Интернет может быть весьма долгой.
Для выполнения сетевой установки необходимо выполнить ряд подготовительных шагов. Во-первых, если планируется установка через локальный сервер, нужно скопировать установочные файлы Linux с DVD в каталог на сервере. Можно также смонтировать DVD или ISO-файл в файловой системе, чтобы сетевые клиенты могли обращаться к нему. Затем нужно выбрать протокол для доступа к установочным файлам. Например, для использования протокола SMB необходимо установить и настроить службу Samba на сервере, а затем создать сетевой ресурс для каталога с установочными файлами. Аналогичным образом можно настроить службу HTTP, NFS или FTP.
После настройки сервера источника установки необходимо скачать базовый образ загрузочного CD. Например, для сетевой установки SUSE Linux нужно открыть браузер, перейти на http://en.opensuse.org и выбрать ссылку Downloads. На открывшейся странице можно скачать образ загрузки по сети, как показано на рис. 5-10.

Рис. 5-10. Загрузка образа загрузки по сети.
Образ нужно записать на диск и загрузиться с него. Для наших целей рассмотрим этот процесс на примере openSUSE — большинство других дистрибутивов, поддерживающих сетевую установку, используют аналогичный порядок действий.
Совет
При установке системы Fedora можно записать сетевой диск из соответствующего файла образа в каталоге /images на установочном DVD и загрузиться с него. После этого можно выбрать альтернативный источник установки.
На первом экране установки нажмите F4 для указания источника установки, как показано на рис. 5-11.

Рис. 5-11. Выбор источника установки.
При выборе SMB/CIFS необходимо указать адрес сервера установки, имя общего ресурса и каталога с установочными файлами, имя домена, а также имя пользователя и пароль с правами доступа к общему ресурсу. Это показано на рис. 5-12.

Рис. 5-12. Настройка сетевой установки по протоколу SMB.
При выборе FTP необходимо указать IP-адрес или DNS-имя сервера установки, каталог с установочными файлами, а также имя пользователя и пароль для доступа к FTP-службе на удалённом сервере. Удалённый сервер может быть как локальным, так и FTP-сервером в Интернете. На рис. 5-13 показан экран настройки FTP-сервера установки.

Рис. 5-13. Настройка сетевой установки по протоколу FTP.
При выборе HTTP необходимо указать URL сервера установки и каталог на удалённом сервере с установочными файлами. Как и при FTP-установке, HTTP-сервер установки может находиться в локальной сети или в Интернете. На рис. 5-14 установщик настроен на выполнение установки с HTTP-сервера SUSE через Интернет.

Рис. 5-14. Настройка сетевой установки по протоколу HTTP.
При выборе NFS необходимо указать IP-адрес или DNS-имя сервера установки и каталог на удалённом сервере с установочными файлами. Это показано на рис. 5-15.

Рис. 5-15. Настройка сетевой установки по протоколу NFS.
После выбора источника установки выберите пункт «Установка» в главном меню — и установка продолжится с использованием файлов с удалённого сервера.
Удалённая установка с использованием VNC (Completing a Remote Installation Using VNC)¶
VNC расшифровывается как Virtual Network Computing («виртуальные сетевые вычисления»). По существу, VNC позволяет перенаправить видеовывод одной системы на другую. С помощью протокола VNC можно запустить установку на целевой системе, а затем через веб-браузер или клиентскую программу VNC на другой системе просматривать экраны установки.
Во многих дистрибутивах, например в openSUSE, на первом экране установки в поле Boot Options можно ввести vnc=1, как показано на рис. 5-16.

Рис. 5-16. Настройка установки через VNC.
После запуска установки будет предложено указать различные сетевые параметры для создания VNC-соединения. Система установки загружается, и на экране отображается IP-адрес для подключения. Можно получить доступ к экранам установки удалённо через веб-браузер или клиентскую программу VNC. Например, можно открыть браузер на другой системе и перейти по адресу http://IP_адрес_системы:5801. Если системе был назначен IP-адрес 192.168.1.126, доступ осуществляется по адресу http://192.168.1.126:5801 в браузере, как показано на рис. 5-17.

Рис. 5-17. Завершение установки удалённо через браузер.
Можно также получить доступ к установке с помощью клиентской программы VNC. Большинство дистрибутивов Linux включают утилиту vncviewer для подключения к VNC-серверу. На Windows-системах можно использовать VNC Viewer от RealVNC. При использовании клиентов VNC необходимо указать IP-адрес устанавливаемой системы и номер дисплея — например, 192.168.1.126:1.
Используя это VNC-соединение, можно завершить процесс установки не покидая рабочего места.
При составлении плана развёртывания необходимо определить, какой источник установки будет использован, и при необходимости подготовить соответствующую инфраструктуру.
После выполнения этого шага план развёртывания Linux готов. Теперь у вас есть всё необходимое для выполнения установки организованно, эффективно и в соответствии с измеримыми критериями. Сохраните план развёртывания в надёжном месте после завершения установки. Эта информация может оказаться бесценной помощью для других системных администраторов, которым в будущем придётся работать с вашими системами.
В своей работе автор сотрудничает с различными компаниями по контракту. Когда у них возникают проблемы, они звонят, и автор выезжает на место. В большинстве случаев всё работает хорошо. Однако иногда приходится выезжать к компаниям, которые не задокументировали ни свою сеть, ни компьютерные системы. Это крайне неприятный опыт. Как консультант, не имея понятия о том, как настроена система и почему она настроена именно так, за работой, которая должна занять два-три часа, проводишь два-три дня. Это стоит клиентам лишних денег и существенно повышает кровяное давление.
На данном этапе вы готовы заказать оборудование, скачать дистрибутив и приступить к установке Linux.